HDD의 저장 용량이 늘어도 데이터를 찾아 읽는 능력이 같은 비율로 늘어나는 것은 아닙니다. 디스크는 요청한 위치로 이동한 뒤에야 유효 데이터를 전송할 수 있습니다. 중간 크기의 읽기 하나를 여러 디스크의 작은 읽기로 나누면, 용량 효율은 좋아도 위치를 찾는 작업에 많은 시간을 쓸 수 있습니다.
Okapi는 기존 클러스터 파일 시스템에서 함께 정하던 두 가지 구성을 분리합니다[1]. 파일을 어떤 폭으로 나눠 저장하고 읽을지 정하는 스트라이핑과, 어느 블록을 함께 오류 정정 부호로 보호할지 정하는 그룹 구성을 별도로 선택합니다. Carnegie Mellon University와 Google 연구진은 이를 HDFS에 구현하고 HDD 클러스터에서 평가했습니다.
AI 인프라에서는 학습 데이터, 장기 보관 체크포인트, 공유 데이터셋을 담는 용량 중심 계층과 연결해 볼 수 있습니다. 다만 논문 자체가 AI 학습 성능을 측정한 것은 아닙니다. 스토리지 설계에 참고할 근거는 있지만, 읽기 처리량 증가를 그대로 GPU 사용률 개선으로 환산해서는 안 됩니다.
서로 다른 목적을 가진 두 가지 폭
스트라이핑은 파일의 연속된 부분을 여러 장치의 데이터 블록에 나누는 방식입니다. 분산 폭에 따라 한 요청에 참여하는 디스크 수와 각 디스크가 읽는 양이 달라집니다. 폭이 넓으면 병렬 대역폭을 활용하기 좋지만, 요청 하나가 여러 개의 작은 디스크 작업으로 나뉠 수도 있습니다.
오류 정정 그룹은 다른 목적을 가집니다. 데이터 블록과 추가 패리티 블록을 함께 구성해 일부 블록이 사라져도 내용을 복원합니다. 같은 패리티 수에서 데이터 블록 수를 늘리면 용량 효율은 좋아질 수 있지만, 복구할 때 읽는 양과 신뢰성 계산도 달라집니다. 읽기 병렬성보다 장애 허용과 저장 비용을 정하는 구성입니다.
두 폭을 같게 강제하면 하나를 선택하는 순간 다른 하나도 결정됩니다. 좁게 나눠 읽고 싶지만 용량 효율을 위해 넓은 오류 정정 그룹을 쓰고 싶은 응용은 이 조합을 표현할 수 없습니다. 읽기 배치만 바꾸려고 보호 그룹까지 좁히면 패리티 비중이 불필요하게 커질 수 있습니다.
Okapi에서는 파일의 데이터 블록 순서를 유지하면서 스트라이프와 보호 그룹을 각각 구성합니다. 보호 그룹이 여러 스트라이프의 블록을 포함할 수 있으므로 두 경계가 일치할 필요가 없습니다. 새로운 오류 정정 부호를 만든 것이 아니라, 데이터 배치와 보호를 결합하는 방식을 바꾼 것입니다.
HDD 탐색 비용이 바꾸는 유리한 배치
HDD 여러 개에서 조금씩 읽으면 각 장치가 위치를 찾는 비용을 반복해서 지불합니다. 더 적은 디스크에서 큰 연속 구간을 읽으면 이 고정 비용을 더 많은 유효 데이터에 나눌 수 있습니다. 부하가 높은 상황에서는 요청 하나의 병렬성을 줄여도 클러스터 전체의 디스크 작업량이 줄어 처리량이 늘 수 있습니다.
반대로 부하가 낮을 때는 여러 디스크가 동시에 읽는 편이 개별 요청을 빨리 끝낼 수 있습니다. 큰 순차 읽기 역시 넓은 분산의 이점을 얻습니다. 따라서 좁은 스트라이프가 언제나 좋다는 결론은 맞지 않습니다. 요청 크기와 동시성, 처리량과 지연 중 무엇을 우선할지에 따라 적합한 폭이 달라집니다.
논문이 제시한 Google 관찰에서는 보호 방식이 바뀌어도 파일의 읽기 크기는 오래 유지되는 경우가 많았습니다. 조사한 클러스터의 표본 파일 중 64~94%는 150일 동안 같은 크기로 읽혔습니다. 이 값은 해당 표본의 특징이며 모든 서비스나 앞으로 만들어질 AI 데이터셋이 안정적인 접근 패턴을 가진다는 뜻은 아닙니다.
별도 위치 지도를 늘리지 않는 메타데이터
스트라이프와 보호 그룹을 분리하면 위치 정보도 두 벌 필요할 수 있습니다. Okapi는 그룹을 임의로 구성하지 않고 순서가 정해진 데이터 블록에서 도출해 이를 줄입니다. 파일의 블록 순서와 두 폭을 알면 어느 블록이 어떤 보호 그룹에 속하는지 계산할 수 있습니다.
HDFS 구현에서는 데이터 스트라이프와 패리티 그룹을 나누되 기존 블록 관리 기능을 재사용합니다. 정상 읽기는 데이터 스트라이프의 위치를 따라가며 패리티 그룹을 참조할 필요가 없습니다. 복구나 보호 방식 변경이 필요할 때 관련 그룹을 도출합니다. 정상 경로에 불필요한 조회를 더하지 않도록 한 구성입니다.
이 규칙은 유연성을 일정 부분 제한하지만 실용적인 선택입니다. 모든 블록을 자유롭게 조합하도록 만들면 이론적 선택지는 늘어도 메타데이터와 관리 비용이 커집니다. Okapi는 규칙적인 그룹 구성을 유지해 기존 파일 시스템 안에서 적용 가능한 추가 선택지를 제공합니다.
물리적인 장애 조건은 여전히 지켜야 합니다. 같은 보호 그룹의 블록이 동일한 실패 도메인에 몰리면 한 번의 장애로 여러 블록을 잃을 수 있습니다. 논리적으로 폭을 분리했다는 이유로 배치의 독립성까지 자동으로 확보되는 것은 아닙니다. 보호 그룹 안의 실제 장치와 장애 범위를 확인해야 합니다.
완성 전 데이터를 대신하는 부분 패리티
파일을 순서대로 쓸 때 하나의 보호 그룹에 필요한 데이터가 여러 스트라이프에 걸쳐 들어올 수 있습니다. 모든 데이터가 모일 때까지 원본을 버퍼에 남겨두면 클라이언트 메모리 사용량이 커집니다. 읽기 구성을 자유롭게 만든 대가가 쓰기 중 메모리 부담으로 옮겨가는 문제입니다.
Okapi는 데이터가 도착할 때 부분 패리티를 계산하고, 원본 전체 대신 그 기여분을 보관합니다. 부호 연산의 선형성을 이용해 나중에 각 기여분을 합치면 최종 패리티를 얻을 수 있습니다. 최종 보호 데이터로 디스크에 기록하는 것은 완성된 패리티입니다.
버퍼를 줄이는 기능과 내구성 보장은 구분해야 합니다. 이 구현은 비교 시스템의 쓰기 완료 의미를 유지하며, 클라이언트 장애로 보호가 덜 끝난 그룹은 복구 과정에서 처리합니다. 데이터 조각 하나가 들어올 때마다 동기적으로 패리티 보호까지 완료하는 기능을 검증한 것은 아닙니다.
체크포인트에 적용한다면 새 데이터와 보호 정보가 모두 확정되는 시점을 확인한 뒤에야 이전의 유일한 복구 지점을 지울 수 있습니다. 전송을 시작한 시점은 안전하게 복구할 수 있는 시점과 다르기 때문입니다. 더 강한 동기 쓰기 보장이 필요하다면 그에 필요한 추가 기능과 비용을 별도로 검토해야 합니다.
장애가 난 상태에서 달라지는 읽기
정상 읽기는 스트라이프를 따라가지만, 요청한 블록이 없으면 보호 그룹을 따라 복구합니다. 두 폭이 다르면 복구에 필요한 일부 데이터가 원래 읽으려던 파일 구간 밖에 있을 수 있습니다. 정상 접근을 효율적으로 만든 배치가 장애 중에는 더 많은 데이터를 요구할 수 있는 이유입니다.
Okapi는 복구에 다시 사용할 데이터를 캐시해 중복 읽기를 줄이며, 큰 순차 접근에서는 이미 읽었거나 곧 읽을 데이터를 활용할 수 있습니다. 다만 중간 크기 요청에서는 이 재사용으로도 복구용 읽기 증폭을 충분히 줄이지 못해 지연이 늘어날 수 있습니다.
측정한 사례 중 6-of-9 보호와 3개 폭의 스트라이프를 사용한 24 MB 요청은 장애 중 읽기 지연이 33% 더 길었습니다. 평소 더 적은 디스크에 접근하므로 장애를 만나는 빈도는 낮지만, 실제 장애를 만난 요청 하나가 빨라지는 것은 아닙니다. 빈도가 낮다는 설명과 해당 요청의 지연은 별도 지표입니다.
운영자는 장애 노출 확률과 장애에 걸린 요청의 지연을 함께 봐야 합니다. 정상 상태의 처리량 이득을 복구 상태의 성능 보장으로 바꿔 읽으면 안 됩니다. 특히 장치 장애가 난 상태에서 체크포인트를 복원해야 한다면, 평소 읽기뿐 아니라 그 복구 경로가 허용 시간 안에 끝나는지도 시험해야 합니다.
원본 전체를 다시 쓰지 않는 보호 방식 변경
두 폭이 묶인 파일 시스템에서는 오류 정정 그룹을 바꿀 때 스트라이프 배치까지 바뀔 수 있습니다. 그러면 파일 데이터를 읽고 새 위치에 다시 써야 합니다. 디스크 고장률이 갑자기 높아져 보호 방식을 서둘러 바꿔야 하는 시점에 대규모 백그라운드 I/O가 추가될 수 있습니다.
Okapi는 데이터 배치를 유지한 채 기존 블록을 새로운 보호 그룹으로 묶습니다. 새 패리티 계산에 필요한 데이터를 읽고 새 패리티를 쓰되, 그룹 폭이 바뀐다는 이유만으로 원본 전체를 다시 쓰지는 않습니다. 읽기 효율을 위해 선택한 배치를 데이터 수명 동안 유지할 수 있다는 이점도 있습니다.
데이터 이동이 전혀 없다는 뜻은 아닙니다. 새로운 그룹에 같은 실패 도메인의 블록이 겹치면 일부를 다른 위치로 옮겨야 합니다. 향후 변경을 예상한 초기 배치로 줄일 수 있지만, 그렇지 않은 경우에는 재배치 비용이 남습니다. 논문의 장기 모의실험도 이런 비용을 포함합니다.
전환 중의 보호 역시 유지해야 합니다. 구현은 새로운 패리티가 완성될 때까지 기존 패리티를 남겨두고, 완료 후 메타데이터를 원자적으로 바꿉니다. I/O를 줄였더라도 두 보호 방식이 모두 불완전한 순간을 만들면 저장 시스템으로서 받아들이기 어렵습니다. 전환의 안전한 완료 조건이 성능 최적화보다 먼저 충족돼야 합니다.
실제 디스크에서 측정한 범위
평가 클러스터는 메타데이터 노드 1개와 데이터 노드 19개로 구성됩니다. 각 데이터 노드는 1 TB, 7,200 rpm HDD를 사용하며 네트워크는 40GbE입니다. 파일 시스템 시험의 데이터 블록은 8 MB, 스트라이핑 셀은 1 MB입니다. 어떤 장치와 접근 단위에서 결과가 나왔는지 확인해야 합니다.
이 시험의 주요 개선 원인인 기계적인 위치 탐색 비용은 NVMe에는 없으므로, 요청 분산과 보호 전환의 영향이 남더라도 개선 비율은 달라질 수 있습니다. 논문이 올플래시 학습 스토리지에서도 같은 효과를 측정했다고 볼 수는 없습니다.
같은 6-of-9 보호를 사용한 세부 시험에서는 접근 크기에 맞춰 스트라이프를 선택했을 때 읽기 처리량이 최대 80% 늘고 초당 탐색 수가 최대 70% 줄었습니다. 보호 방식과 용량 오버헤드를 유지한 비교이므로 패리티를 줄여 얻은 단순한 성능 향상은 아닙니다. 다만 최대값은 특정 요청 크기와 선택한 폭에서 나온 결과입니다.
맞춤형 폭이 기존 구성의 폭과 같아지면 새로운 대역폭이 생길 이유도 없습니다. 이 설계의 이득은 디스크 자체를 빠르게 만드는 것이 아니라, 기존에는 선택할 수 없었던 읽기와 보호의 조합을 허용하는 데 있습니다.
Google 분포를 사용한 재생 시험의 의미
별도 시험에서는 Google 운영 환경의 읽기 크기 분포를 가져와 시험 클러스터에서 읽기 전용 합성 워크로드를 실행했습니다. 클라이언트 스레드 64개가 각각 1만 번 읽으며, 비교 시스템은 같은 보호 구성을 사용합니다. 운영 환경에서 관찰한 분포를 반영했지만 실제 Google 서비스에 배포한 결과는 아닙니다.
이 시험에서 지속 읽기 처리량은 55% 늘었고 전체 탐색 횟수는 65% 줄었습니다. 초당 탐색 수의 감소율은 35%로 다릅니다. 작업이 더 빨리 끝나므로 총횟수와 시간당 횟수의 기준이 같지 않기 때문입니다. 36% 감소는 전체 시험 작업의 완료 시간에 관한 값이며, 모든 개별 요청의 지연이 일괄적으로 36% 줄었다는 뜻은 아닙니다.
작은 쪽의 읽기가 많이 포함된 분포에서 집중적인 읽기 배치가 유리하다는 근거로 볼 수 있습니다. 쓰기와 갱신이 자주 섞이는 다른 서비스에도 같은 결과가 남는지는 추가 검증이 필요합니다. 산업계의 실제 관찰과 연구용 구현의 측정 결과를 구분해야 도입 가능성을 정확히 판단할 수 있습니다.
기준에 따라 달라지는 메타데이터 증가율
메모리 오버헤드가 작다는 결과를 모든 메타데이터 구조의 증가율이 1% 미만이라는 뜻으로 읽으면 안 됩니다. 보고된 힙 할당 비중에서 관련 구조의 합은 3%에서 3.74%로 0.74%포인트 늘어나며, 이는 전체 힙에서 차지하는 비중의 변화이지 해당 구조 자체의 상대적인 증가율이 아닙니다.
시험한 구성의 파일당 메타데이터는 블록 위치 구조에서 26%, inode 위치 구조에서 22% 증가했다고 보고합니다. 이 구조들이 전체 할당의 일부이므로 두 설명은 동시에 성립할 수 있습니다. 메타데이터 서버의 실제 제한이 어디에 있는지에 따라 중요한 숫자가 달라집니다.
파일 수가 많고 해당 위치 구조가 주된 메모리 소비자라면 파일당 증가량을 더 중요하게 봐야 합니다. 충분히 크게 잡힌 힙 전체의 비중만으로 수용 가능한 파일 수를 계산하면 낙관적인 결과가 나올 수 있습니다. 용량 추정에는 파일 크기, 그룹 폭, 객체 수를 함께 반영해야 합니다.
측정과 계산을 구분해야 하는 전환 절감
기본 재그룹화는 원본 재쓰기를 피하면서 시험한 전환 I/O를 약 절반 가까이 줄입니다. 패리티 재계산에 필요한 읽기까지 줄이는 다른 기술과 결합하면 보고된 최대 70% 수준의 절감이 가능합니다. 이 결합 결과를 모든 일반적인 그룹 변경의 효과로 사용할 수는 없습니다.
긴급 전환 사례는 Google에서 발생한 사건을 바탕으로 대표적인 규모를 넣어 계산한 분석입니다. 별도의 6년 평가에서는 Backblaze 디스크 장애 데이터를 사용한 모의실험으로 재배치를 포함해 약 38%의 전환 I/O 감소를 보고합니다. 둘 다 실제 디스크에서 짧게 측정한 처리량 시험과는 다른 종류의 근거입니다.
이 분석들은 보호 방식 변경이 상당한 자원을 소비하고, 불필요한 재쓰기를 줄이는 것이 중요하다는 주장을 보강합니다. 그러나 운영 중인 모든 초대형 클러스터에서 특정 시간 안에 복구를 끝낼 수 있다는 실측 보장은 아닙니다. 실제 전환 시간에는 전경 작업에 남겨줄 I/O와 장애 상태의 여유도 영향을 줍니다.
AI 데이터 계층에 적용할 때의 판단
먼저 파일별 접근 크기와 여러 작업 사이에서 그 크기가 얼마나 유지되는지 측정할 필요가 있습니다. 일정한 크기의 샤드를 읽는 학습, 대화형 검색, 체크포인트 복원은 같은 내구성 목표를 가져도 적합한 배치가 다를 수 있습니다. 용량 계층이라는 이유만으로 모든 파일을 하나의 폭에 맞출 필요는 없습니다.
시험에는 대표 부하에서의 정상 읽기와 장애 중 읽기를 모두 포함해야 합니다. 처리량에 유리한 폭이 장애 중 상위 지연에는 불리할 수 있습니다. 어떤 결과를 우선할지는 응용의 결정이며, 저장 시스템은 그 선택을 오류 정정 설정 하나에 숨기기보다 별도로 드러내는 편이 낫습니다.
보호 방식 전환도 전경 읽기와 긴급 복구가 함께 진행되는 조건에서 봐야 합니다. 넓은 부호로 아낀 저장 공간보다 전환 중 소모하는 I/O 여유가 더 문제가 될 수 있습니다. 반대로 읽기 배치를 유지하면서 보호만 조정할 수 있다면 파일의 수명 동안 성능 변화를 줄일 수 있습니다.
Okapi의 중요한 제안은 목적을 구분하는 데 있습니다. 읽기 배치는 응용이 데이터를 어떻게 사용하는지에 맞추고, 보호 그룹은 어떤 장애를 견디며 중복 저장 비용을 얼마나 지불할지에 맞춥니다. 두 선택은 실제 디스크와 복구 과정에서 여전히 상호작용하지만, 처음부터 같은 폭으로 묶어두면 검토할 만한 선택지를 잃게 됩니다.
출처와 저작권 안내
이 글은 OSDI 2025 논문을 검토해 독립적으로 작성한 편집 분석입니다. 실험과 운영 관찰은 원문 저자들의 보고이며, AI 인프라 적용에 관한 판단은 본지의 해석입니다. 원문 저작권은 저자들에게 있습니다(© 2025). 도판은 이 글을 위해 새로 제작했으며, 개념적 하드웨어 표현은 시험 장비의 실제 사진과 구분했습니다.