수 엑사바이트를 저장하는 오브젝트 스토리지는 노드 하나를 바꿔서는 경제성이 달라지지 않습니다. 전체 사본을 몇 개의 리전에 둘지, 각 리전에서 고장 난 드라이브를 어떻게 복구할지, 재구성 과정에서 클라이언트가 얼마의 지연을 감수할지가 비용을 정합니다. Apple이 FAST 2026에서 공개한 ACOS 논문은 이 세 계층을 함께 바꾼 10년 이상의 운영 전환을 설명합니다[1].
1세대는 활성 리전 두 곳에 완전한 사본을 두고 각 사본을 리전 내부 코드로 보호했습니다. ACOS 2.0은 오브젝트를 데이터 조각 네 개로 나누고 XOR 조각 하나를 만든 뒤 다섯 리전에 분산합니다. 어느 네 리전만 남아도 오브젝트를 복구할 수 있습니다. 각 리전의 조각에는 다시 (20,2,2) 로컬 복구 코드(LRC)를 적용합니다. 논문에 제시된 구성에서 물리 용량 배수는 2.40배에서 1.50배로 낮아집니다.
37.5% 용량 절감은 공짜가 아닙니다. 정상 읽기도 원격 조각을 필요로 할 수 있고, 로컬 조각 장애는 여러 복구 계층을 거칠 수 있으며, 쓰기는 여러 리전의 절차를 끝내야 내구성을 확보합니다. ACOS의 가치는 어떤 의무가 서로 교환되는지를 보여 주는 데 있습니다. 전체 리전 사본이 비싸다고 판단한 뒤 저장 사업자가 무엇을 추가로 구축해야 하는지 확인할 수 있습니다.
전체 사본 두 개는 장애 영역을 단순하게 만들었습니다
ACOS가 받는 작업은 요청 구성이 서로 다릅니다. iCloud는 오브젝트 읽기와 삭제가 많습니다. 미디어 서비스는 크기가 큰 음원과 영상을 저장하고, 전달 경로에 에지 캐시가 들어갈 수 있습니다. Maps는 다시 다른 크기와 접근 빈도를 가집니다. 하나의 저장소가 작은 메타데이터 중심 요청, 큰 순차 전송, 서비스별 보존 정책을 함께 처리해야 합니다.
첫 설계는 활성 리전 두 곳을 사용했습니다. 각 리전에 인코딩한 전체 사본이 있으므로 어느 한쪽에서도 오브젝트 전체를 읽을 수 있습니다. ACOS는 처음에 (12,2,2) LRC를 사용했고 나중에 (20,2,2)로 바꿨습니다. 이 표기는 흔한 장애를 전역 이레이저 코드보다 적은 조각으로 복구할 수 있도록 데이터와 패리티를 묶는 방식을 나타냅니다.
후기 로컬 코드를 적용한 리전 사본 두 개의 물리 용량 배수는 2.40배입니다. 대신 디스크와 서버 장애는 리전 안에서 처리하고, 리전 하나가 사라져도 다른 곳에 완전한 오브젝트가 남습니다. 서비스는 여러 지역의 조각을 먼저 조립하지 않고 가장 가까운 리전에서 읽을 수 있습니다.
수 엑사바이트에서는 ACOS 2.0보다 더 필요한 0.90배 용량이 큰 장비 집합이 됩니다. 비용에는 저장 매체만 들어가지 않습니다. 랙, 전력, 데이터 이동, 복구 대역폭, 운영 여유분이 모두 증가합니다. ACOS 2.0이 리전 사이의 보호 방식만 바꾸고 로컬 LRC를 남긴 이유는 광역 중복과 드라이브 복구가 서로 다른 장애를 해결하기 때문입니다.
다섯 리전 코드는 완전한 리전 사본을 없앴습니다
바깥쪽 코드는 의도적으로 단순합니다. 조각 네 개는 오브젝트 데이터를 담고, 다섯 번째는 네 조각의 XOR입니다. 리전 하나가 중단되면 남은 네 조각으로 사라진 조각을 계산합니다. 복잡한 Reed-Solomon 코드와 비교하면 계산량이 작고 복구 규칙이 분명합니다. 다만 장애 영역과 네트워크 경로가 충분히 독립적인 다섯 리전을 운영할 수 있다는 조건이 필요합니다.
각 조각은 로컬 LRC가 다시 보호합니다. 대부분의 디스크·서버·랙 장애가 네 원격 리전의 트래픽을 만들지 않도록 한 것입니다. 로컬 복구는 같은 배포 스탬프의 조각을 읽어 사용할 수 없는 부분을 재구성합니다. 이 경로가 끝나지 않을 때만 전역 계층이 다른 리전 조각을 가져옵니다.
논문의 모델은 다섯 리전 구조의 평균 데이터 손실 시간을 1.31 × 10^21년, 연간 사용 불가 시간을 0.0316초로 계산합니다. 실측 수명 보장은 아닙니다. 장애가 서로 독립이고 리전 가용성이 99.999%라는 가정을 사용했습니다. 같은 소프트웨어 결함, 운영자 실수, 공통 의존 서비스 장애, 공유 네트워크 제어부는 독립성 가정을 깨뜨릴 수 있습니다. 유효한 결론은 명시된 한 모델 안에서 다섯 리전 XOR이 내구성 목표를 유지하면서 용량 배수를 낮췄다는 비교입니다.
코드는 읽기의 의미도 바꿉니다. 이제 한 리전 끝점에는 전체 사본이 없습니다. ACOS가 충분한 조각을 가져와 결합하고 내부 배치를 숨긴 채 오브젝트를 반환해야 합니다. ACOS 2.0의 GET은 리전 간 접근 때문에 1.0보다 약 50밀리초 늘었다고 논문은 보고합니다. 용량 절감 비용의 일부를 네트워크 거리로 지불한 셈입니다.
계층형 복구가 흔한 장애를 로컬에 남깁니다
ACOS는 정상 읽기, 로컬 성능 저하 읽기, 전역 재구성을 구분합니다. 보고된 환경에서 로컬 LRC 재구성 계산은 90백분위에서 약 2밀리초입니다. 성능 저하 읽기는 중앙값 부근까지 약 30밀리초를 더하고, 분포 상단에서는 수백 밀리초에 이를 수 있습니다. 로컬 패리티를 최대 500밀리초 기다린 뒤 전역 복구로 넘어갑니다.
이 타임아웃은 운영 판단을 코드로 표현합니다. 너무 빨리 전환하면 로컬 장애 때 광역 트래픽이 급증합니다. 오래 기다리면 멈춘 요청의 지연을 클라이언트가 그대로 받습니다. 네트워크와 장치 상태가 시간에 따라 달라지므로 하나의 전체 지연 그래프가 아니라 경로별 관측값이 필요합니다.
전역 XOR 계산 자체는 보고된 측정에서 작습니다. 사라진 조각을 계산하는 비용은 90백분위에서 약 0.3밀리초입니다. 일반 전역 재구성은 GET 지연에 약 10밀리초를 더하고, 리전 장애 전환은 60백분위 이상에서 최대 50밀리초를 추가할 수 있습니다. 넓은 지역에서 데이터를 옮기고 장애를 판별하는 비용이 XOR 연산보다 크다는 뜻입니다.
동시 장애에서는 복구 트래픽도 제한해야 합니다. 로컬 복구는 정상 GET보다 많은 조각을 읽고, 전역 재구성은 네 리전으로 요청을 펼칩니다. 복구가 정상 사용자 요청에 필요한 대역폭을 소비하지 않도록 동시 실행 제한, 역압, 우선순위가 필요합니다. 이 논문의 기여는 계층을 연결한 전체 경로이며, 이레이저 코드 하나가 가용성을 보장한다는 주장이 아닙니다.
쓰기 내구성과 예외 지연을 함께 관리합니다
ACOS는 복제의 99.99%를 동기 PUT 경로 안에서 끝냅니다. 0.01%만 비동기 경로로 완료합니다. 대부분의 쓰기에 강한 내구성 계약을 적용하면서 느리거나 사용할 수 없는 의존성을 만난 예외 요청이 끝날 길을 남겼습니다. 응답했지만 복제가 덜 된 오브젝트는 손실 노출이 다르므로 그 경계를 정확히 추적해야 합니다.
클라이언트와 서버 경로에는 여러 지연 최적화가 들어갑니다. 논문은 최적화와 요청에 따라 서버에서 최대 60%, 클라이언트에서 최대 87% 감소를 보고했습니다. 중간 로드 밸런서를 우회하면 GET 지연이 중앙값에서 22%, 90백분위에서 32%, 95백분위에서 26% 줄었습니다. 인코딩 계산보다 코드를 둘러싼 네트워크 경로가 더 큰 영향을 줄 수 있음을 보여 줍니다.
메타데이터 미리 가져오기도 같은 사례입니다. 기본 경로가 필요성을 확정하기 전에 정보를 예측해 읽습니다. 불일치 비율은 약 0.001%이므로 대규모 ACOS에서 유용하지만, 틀린 요청도 자원을 씁니다. 실제 도입에서는 작은 비율뿐 아니라 낭비된 초당 요청의 절대값을 함께 추적해야 합니다.
이 최적화들이 구조적 비용을 없애는 것은 아닙니다. 분산 오브젝트 경로가 더한 왕복과 대기열을 줄입니다. 다섯 리전 시스템과 두 사본 시스템을 비교할 때는 양쪽에 같은 수준의 경로 최적화를 적용하고 직접 경로 유지와 예측 정확도 관리 비용까지 포함해야 합니다.
수 엑사바이트 이동은 유지보수가 아니라 시스템 기능입니다
Apple은 수년에 걸쳐 수 엑사바이트를 ACOS 1.0에서 2.0으로 무중단 이전했습니다. 이 기간에는 이전과 이후 배치가 공존하고, 클라이언트가 어느 표현도 찾을 수 있어야 하며, 배경 데이터 이동이 운영 트래픽을 압도하면 안 됩니다. 정상 상태의 효율만큼 이전의 정합성이 중요합니다.
안전한 전환에는 오브젝트별로 권위 있는 상태 기계가 필요합니다. 데이터 복사, 새 조각 검증, 메타데이터 포인터 변경, 이전 사본 폐기가 모든 경계에서 재시도를 견뎌야 합니다. 장애가 두 소유자를 애매하게 만들거나 마지막 정상 표현을 지워서는 안 됩니다. 지연되거나 재실행된 메시지가 삭제된 데이터를 되살릴 수 있으므로 삭제 처리가 특히 민감합니다.
장비 전체의 이동 속도도 사용자 요청량과 연결해야 합니다. 엑사바이트 규모에서는 하루에 작은 비율만 옮겨도 큰 네트워크·장치 부하입니다. 미디어 파일과 작은 메타데이터 오브젝트는 자원 사용이 다르므로 예약한 오브젝트 수가 아니라 검증을 마친 내구성 바이트로 진행률을 표현해야 합니다. ACOS는 인코딩 변경에 같은 수준의 이전 설계가 필요함을 보여 줍니다.
작업 구성이 용량 교환의 가치를 결정합니다
논문은 대표 작업의 요청 비율을 제시합니다. 제시된 구성에서 iCloud는 GET의 52%, PUT의 27%, 삭제의 81%를 차지합니다. 미디어는 각각 11%, 6%, 1%, Maps는 20%, 5%, 1%입니다. 기타 서비스는 나머지를 차지하며 PUT의 62%를 만듭니다. 요청 수 비율이며 바이트 비율이 아니므로 어느 서비스가 가장 많은 용량과 대역폭을 쓰는지는 이 숫자만으로 알 수 없습니다.
읽기 중심 오브젝트는 늘어난 리전 간 GET 경로를 반복해서 지불합니다. 쓰기 중심 오브젝트는 입력 때 여러 리전 배치 비용을 냅니다. 삭제가 많은 서비스는 메타데이터 정합성과 실제 공간 회수를 시험합니다. 하나의 전역 인코딩 정책을 사용하더라도 서비스별 요청 수, 바이트 분포, 꼬리 지연, 보존 기간을 함께 봐야 합니다.
ACOS 2.0에 가장 유리한 조건은 물리 용량 0.90배 절감이 수십 밀리초 읽기 지연보다 중요한 대규모 장기 보존 오브젝트입니다. 한 리전에 가까운 작은 오브젝트의 지연이 중요하면 로컬 전체 사본이나 상위 캐시가 유리할 수 있습니다. ACOS를 내구성 계층으로 두고 지연 전용 사본을 별도로 만들 수 있지만, 캐시는 용량과 무효화 비용의 일부를 다시 가져옵니다.
세 가지 예산이 모두 맞아야 전환할 수 있습니다
비슷한 전환을 검토하는 운영자는 용량, 지연, 장애 예산을 분리해야 합니다. 용량 예산에는 인코딩한 바이트, 이전 중 임시 사본, 복구 여유, 캐시가 들어갑니다. 지연 예산은 정상 네트워크 거리, 로컬 성능 저하 읽기, 전역 재구성, 장애 판별을 나눕니다. 장애 예산은 어떤 조합을 독립으로 가정했고 어떤 공유 시스템이 그 가정을 깨뜨리는지 명시합니다.
세 예산이 모두 맞아야 1.50배 용량이 의미를 가집니다. 이전 때문에 중복 데이터를 오래 유지하면 단기 용량은 이전 설계보다 커질 수 있습니다. 리전 연결이 불안하면 전역 복구가 꼬리 지연을 악화합니다. 다섯 리전이 제어부를 공유하면 분석 모델의 내구성은 실제 독립성을 과대평가합니다.
ACOS는 운영 저장 논문이 한 알고리즘 이상을 설명하는 이유를 보여 줍니다. XOR 수식은 시스템에서 가장 작은 부분입니다. 로컬 복구를 보존하고, 원격 읽기를 감당할 수 있게 만들고, 복구 부하를 제한하며, 기존 데이터를 안전하게 이동하는 일이 실제 구조를 완성합니다. 엑사바이트 규모에서 중복은 정적인 저장 형식이 아니라 운영 방식입니다.
출처와 저작권 안내
이 글은 공개된 FAST 2026 논문을 독립적으로 분석한 편집 다이제스트입니다. USENIX 공식 논문 페이지에서 원문을 확인하고 설계, 측정값, 가정, 한계를 우리 표현으로 다시 썼습니다. 원문의 문장, 표, Apple 로고, 시설 이미지, 도판은 사용하지 않았습니다. 본문 도판과 썸네일은 이 글을 위해 새로 만들었고 하드웨어 배경은 회사 표식이 없는 일반 편집용 재질 플레이트입니다. 저작권 © 2026 원저자.