테이프가 저렴한 이유 중 하나는 대부분의 매체가 쉬고 있기 때문입니다. Huawei Cloud의 운영 라이브러리 한 대에는 카트리지 1,000개와 드라이브 네 개가 들어갑니다[1]. 카트리지는 보관 슬롯에 있을 때 드라이브도 전력도 쓰지 않지만 데이터를 제공할 수도 없습니다. 이전 카트리지를 되감아 꺼내고 새 카트리지를 로봇이 장착하는 데 보고된 장비에서는 약 80초가 걸립니다. 한 드라이브의 전송률은 360 MB/s입니다. 10 PB가 넘는 용량 가운데 동시에 동작할 수 있는 매체는 네 개뿐입니다.
TapeOBS는 더 빠른 큐로 이 차이를 감추지 않습니다. 시간 계약을 바꿉니다. 사용자 쓰기는 먼저 HDD 준비 영역에서 내구성을 얻고 나중에 묶음으로 테이프로 이동합니다. 복원 요청은 객체를 디스크로 옮긴 뒤에야 일반 읽기를 허용합니다. 서비스가 복원에 수 시간을 허용하므로 제어기는 같은 카트리지를 요구하는 요청을 모으고 장착 횟수를 줄이며 한 번 올린 테이프를 길게 읽을 수 있습니다. 이 시스템에서 비동기성은 지연을 감수한 결과가 아니라 능동적으로 쓰는 자원입니다.
2022년 말 단계적 배포를 시작한 TapeOBS는 2024년부터 고객 서비스를 제공했고 논문 작성 시점에 원시 사용자 데이터 수백 PB를 저장했습니다. 약 1.25년 동안 200대 미만의 라이브러리에서 발생한 장비 관련 장애 17건도 공개했습니다. 로봇과 드라이브 펌웨어, 정비 절차가 데이터 구조만큼 중요한 테이프 시스템에서는 이런 운영 기록이 핵심 근거입니다.
용량과 활성 대역폭은 의도적으로 분리됩니다
운영 라이브러리 한 대는 카트리지당 10,742 GB를 저장해 비압축 용량 10.24 PB를 제공합니다. 드라이브 네 개의 이론상 합산 스트리밍 속도는 1.44 GB/s입니다. 카트리지가 드라이브보다 싸고 쉬는 동안 전력을 쓰지 않기 때문에 경제적으로 유리한 비율입니다. 반대로 무작위 객체를 차례로 읽으면 실제 데이터 전송보다 카트리지 교체와 탐색에 더 오래 걸릴 수 있습니다.
논문의 10년 비용 모델은 초기 데이터 100 PB와 연간 50% 증가를 가정합니다. 이 조건에서 테이프의 설비비는 HDD보다 2.68배 낮고 운영비는 16.11배 낮아 총소유비용이 4.95배 낮았습니다. 테이프 수명은 10년, HDD는 5년으로 놓았고, 해당 환경의 바닥 면적은 44% 줄었습니다.
이 비율은 모든 구매에 적용되는 가격 보장이 아닙니다. 증가율과 교체 주기, 시설 비용, 라이브러리 사용률, 데이터 이관 정책, 복원 수요에 따라 달라집니다. 다만 테이프가 이기는 원인은 분명합니다. 조밀하고 비활성인 매체를 소수 드라이브가 공유하고 세대 교체를 덜 자주 합니다. 테이프를 항상 켜진 디스크처럼 만들려는 기능은 이 장점을 다시 비용으로 소비합니다.
4%의 디스크가 스케줄링 시간을 만듭니다
운영 HDD 풀은 테이프 용량의 약 4%입니다. 쓰기는 고가용 디스크에 먼저 들어가므로 카트리지를 기다리지 않고 응답할 수 있고, 이후 준비된 데이터를 테이프로 비웁니다. 읽기는 복원한 객체를 디스크에 실체화한 다음 일반 객체 요청을 처리합니다.
이 작은 풀은 즉시 처리해야 할 요청을 이동 가능한 작업으로 바꿉니다. 디스크의 합산 대역폭이 사용자 급증을 흡수하고, 복원 요청은 같은 카트리지나 가까운 위치를 기준으로 묶입니다. 불규칙한 사용자 트래픽에서도 테이프에는 더 일정한 속도로 데이터를 공급할 수 있습니다. 운영 클러스터를 24시간 측정한 결과 HDD 풀 사용률은 71.625%와 71.675% 사이를 오갔고, 테이프의 시간당 증가량은 비교적 일정했습니다.
TapeOBS는 디스크 풀 상한을 75%로 둡니다. 남은 25%는 고객의 순간 쓰기, HDD 풀 복구, 높은 사용률에서 나타날 성능 저하를 감당합니다. 테이프 라이브러리 전체가 멈춰도 이 공간에 쓰기를 계속 받을 수 있습니다. 측정한 하루 유입량은 HDD 풀 용량의 4%보다 작았으므로 설명한 조건에서는 정비팀에 수십 시간을 벌어 줍니다.
준비 용량은 전체 아카이브의 고정 비율보다 장애 복구 시간과 급증량으로 정해야 합니다. 이 운영 트래픽에는 4%가 맞았지만 유입 급증이 크거나 복원 약속이 짧은 서비스에는 다른 값이 필요합니다. 실무에서는 사용 가능한 여유 용량을 장애 중 순유입률로 나눈 시간이 정비 한계가 됩니다.
수명이 비슷한 객체를 모으면 순차 매체의 약점이 줄어듭니다
현대 테이프는 소프트웨어 관점에서 덧붙여 쓰는 매체입니다. 여기저기 남은 유효 객체를 회수하려면 다른 테이프로 복사해야 합니다. TapeOBS는 준비 영역에서 예상 수명이 비슷한 객체를 모아 같은 테이프에 연속으로 기록합니다. 보존 기간이 끝나면 무관한 장수명 객체를 옮기지 않고 카트리지나 삭제 코딩 그룹의 더 큰 부분을 회수할 수 있습니다.
영구적인 준비 영역이 없으면 이런 배치는 어렵습니다. 수명 구간마다 카트리지를 하나씩 장착해 둘 수 없고 드라이브는 네 개뿐입니다. 디스크는 한 번의 일관된 테이프 쓰기를 구성할 만큼 객체가 모일 때까지 기다리는 장소입니다. 따라서 HDD 풀은 단순히 빠른 캐시가 아닙니다. 세밀한 도착 순서를 순차 매체에 맞는 물리 배치로 바꾸는 곳입니다.
수명 예측이 항상 맞는 것은 아닙니다. 사용자가 보존 기간을 바꾸거나 일찍 삭제하고 예상보다 오래 유지할 수 있습니다. 운영자는 회수하는 테이프의 유효 데이터 비율과 확보한 바이트당 복사 바이트를 측정해야 합니다. 수명 상관관계가 낮으면 처음의 저렴한 쓰기가 나중의 큰 정리 비용으로 돌아옵니다.
묶음 삭제 코딩은 객체 하나가 요구하는 드라이브 수를 줄입니다
운영 구성은 테이프 랙 14개에 12+2 삭제 코딩을 적용하며 저장 중복도는 1.17배입니다. 객체마다 세밀하게 스트라이프를 만들면 작은 객체 하나도 여러 테이프에 퍼질 수 있습니다. TapeOBS는 여러 객체를 큰 코딩 단위로 묶어 전체 배치는 랙에 걸쳐 보호하되 개별 객체는 더 적은 테이프에 놓이게 합니다.
정상 복원에서는 필요한 드라이브와 교체 횟수가 줄어듭니다. 대가는 장애 때 나타납니다. 사라진 조각을 재구성할 때 객체 단위 스트라이프보다 더 많은 생존 데이터를 읽을 수 있습니다. 저자들은 성능을 제한하는 활성 드라이브를 정상 경로에서 아끼고 드문 성능 저하 읽기에 비용을 옮겼습니다.
따라서 코딩률만으로 아카이브 효율을 판단할 수 없습니다. 복원 객체당 장착 카트리지 수, 점유한 드라이브 시간, 복구 읽기 바이트, 랙 장애 동안 줄어든 복원 대역폭을 함께 세어야 합니다. 묶음 코딩은 정상 경로의 일을 장애 경로로 이동시키므로 장애 빈도와 복구 시간이 이를 정당화해야 합니다.
세부 메타데이터를 로봇 뒤에 두면 안 됩니다
테이프에서 작은 객체 위치를 찾으려면 조회 자체가 물리 작업이 됩니다. 각 라이브러리는 NVMe SSD 두 개에 단순한 키-값 저장소를 두어 로그 메타데이터와 준비 데이터를 관리합니다. 카트리지를 장착하거나 훑지 않고 테이프 주소를 찾습니다. 테이프가 가득 차면 복구용 메타데이터를 별도 파티션에도 기록하며, 4 KB 데이터 블록마다 무결성 필드를 넣어 SSD 메타데이터가 사라져도 복원할 수 있게 합니다.
운영 인덱스와 아카이브의 권위 있는 상태를 분리한 구조입니다. SSD는 빠른 현재 상태를 제공하고 테이프는 그 상태를 다시 만들 정보와 검증값을 보존합니다. 미러 SSD도 함께 고장 나거나 소프트웨어 오류로 매체와 불일치할 수 있으므로 필요합니다. 실제 운영에서는 테이프만으로 인덱스를 재구축하는 훈련을 하고 완료 시간과 객체 지도의 정확성을 확인해야 합니다.
안정적인 스트리밍은 더 빨리 보내는 것이 아니라 속도를 맞추는 일입니다
테이프 드라이브는 호스트의 공급 속도를 보고 내부 스트리밍 속도를 고릅니다. 한 측정에서는 처음 평균 335.94 MB/s를 내던 드라이브가 요청 공급의 흔들림을 잘못 해석해 285초 동안 평균 168.65 MB/s로 떨어졌습니다. 라이브러리 스케줄러는 드라이브 버퍼를 관찰하고 추정한 매체 속도에 맞게 요청을 제한했습니다. 적용 뒤 평균은 336.53 MB/s로 안정됐고, 헤드가 랩 사이에서 방향을 바꾸는 짧은 구간만 떨어졌습니다.
가능한 한 빨리 요청을 밀어 넣는 일반적인 직관이 이 장치에서는 처리량을 절반으로 만들 수 있습니다. 목표는 순간 제출률이 아니라 테이프가 알맞은 속도로 계속 움직이게 하는 파이프라인입니다. TapeOBS는 드라이브 두 개를 쓰기, 하나를 복원, 하나를 내부 작업에 고정 배정합니다. 유연성은 줄지만 복구나 복원이 쓰기 카트리지를 계속 밀어내는 일을 막습니다. 쓰기가 압도적으로 많은 실제 트래픽에 맞춘 선택입니다.
운영 트래픽은 비동기 전제가 맞았음을 보여 줍니다
가장 큰 고객 다섯 곳에서 쓰기는 객체 연산의 최소 99.325224%였습니다. 읽기 비중이 가장 높은 고객도 0.674776%였고 두 고객은 관찰 기간에 읽기가 없었습니다. 500 MB 이하 객체가 전체 용량의 93.81%였으며, 50~100 MB 구간만 69.95%를 차지했습니다. 실제로 복원이 드물고 작은 객체를 단순 스트라이프하면 많은 장착을 낭비할 수 있는 워크로드입니다.
한 24시간 구간에서 테이프 풀은 분당 평균 11만8,810개의 코딩 스트라이프를 썼습니다. 여기서 한 연산은 데이터 12개와 패리티 2개를 합친 7 MB이므로 측정 지점의 처리량은 분당 831.67 GB입니다. 이는 사용자 객체 호출 수가 아닙니다. 논문이 계측 단위를 구분한 이유도 이 수치를 객체 처리량으로 잘못 바꾸지 않게 하기 위해서입니다.
쓰기 완료는 자기 테이프가 아니라 각 랙의 SSD 준비 영역에 데이터와 패리티가 도착한 시점입니다. 7 MB 스트라이프의 중앙값은 18.51 ms, 99퍼센타일은 27.75 ms였습니다. 커널 TCP/IP 경로가 약 10 ms, SSD 데이터·메타데이터 쓰기가 1~4 ms를 차지하고 나머지는 패리티와 체크섬, 메모리 복사, 서비스 로직입니다. 이 값은 준비 영역의 쓰기 지연시간이며 테이프 영속화는 비동기로 이어집니다.
장애 기록은 HDD 풀이 운영 기반 시설임을 보여 줍니다
장비 관련 장애 17건에는 드라이브 소프트웨어 문제 네 건, 드라이브 고장 네 건, 카트리지 인식 실패 네 건, 드라이브 미발견 한 건, 로봇 멈춤 두 건, 헤드 서버와 라이브러리 단절 두 건이 포함됐습니다. 일반적인 고장률을 계산하기에는 표본이 작지만 장애 유형마다 운영 영향이 다름을 보여 줍니다.
쓰기 드라이브가 고장 나면 유입 대역폭이 줄고, 읽기 드라이브가 멈추면 다른 랙을 이용하는 성능 저하 복원으로 바뀝니다. 내부 작업 드라이브의 고장은 유지보수를 늦춥니다. 로봇이나 연결이 끊기면 라이브러리 전체가 빠지지만 HDD 풀이 쓰기를 받고 삭제 코딩이 생존 랙에서 읽기를 제공합니다. 역할 고정은 영향을 예측하기 쉽게 만드는 대신 안전한 재배정 절차가 없으면 남은 능력을 쓰지 못합니다.
제어기는 장애 상태에서 남은 디스크 준비 시간, 랙 손실 뒤 복원 능력, 복구 트래픽, 특정 드라이브 세대에 읽기 가능성이 의존하는 카트리지 수를 보여 줘야 합니다. 그래야 기계 고장이 갑작스러운 용량 위기가 아니라 일정이 있는 정비 작업이 됩니다.
지연에 사업 가치가 있을 때만 테이프가 맞습니다
TapeOBS는 시간 단위 복원 계약과 묶음 처리를 선호하는 매체가 잘 맞는 사례입니다. 일반 저지연 객체 API 뒤에 테이프를 놓아도 된다는 결과는 아닙니다. 즉시 읽기와 잦은 덮어쓰기, 예측하기 어려운 삭제가 필요하면 스케줄러가 비용 이점을 만드는 자유를 잃습니다. 더 빡빡한 계약을 맞추기 위한 드라이브와 준비 공간, 운영 복잡성을 포함하면 HDD나 플래시가 더 저렴할 수 있습니다.
도입 판단은 유입률과 복원 빈도, 보존 기간의 상관관계, 허용 가능한 최대 복원 시간을 측정하는 데서 시작합니다. 이 값으로 준비 용량과 드라이브 수요, 장착 빈도, 예상 정리 비용을 계산할 수 있습니다. 4.95배 비용 결과는 논문의 10년 증가 모델에 속합니다. 다른 환경에도 옮길 수 있는 결론은 아카이브 서비스가 시간을 인터페이스의 일부로 판매하고, 그 시간을 매체 물리에 맞게 요청을 정렬하는 데 써야 한다는 것입니다.
출처와 저작권 안내
이 글은 저자들이 공개한 FAST 논문을 Silicon & Systems가 독립적으로 분석한 편집 요약입니다. 메커니즘과 배포 관찰, 측정값, 한계를 새로운 표현으로 설명했으며 원문 문장과 표, 출판사 도판을 옮기지 않았습니다. 도판과 썸네일은 보고된 사실과 일반적인 서버 재질 원판으로 이 글을 위해 만들었습니다. 논문의 저작권은 저자들에게 있습니다. 전체 원문은 USENIX FAST 2026 공식 페이지에서 확인할 수 있습니다.