분산 스토리지·병렬 파일시스템 검증 — 학습 데이터·체크포인트 I/O 와 일관성

개념

GPU 가 노는 이유는 대개 스토리지다

레슨 5 에서 GPU 워크로드를, 레슨 6 에서 추론 서빙을 다뤘다. 두 레슨의 전제는 연산 자원이 제대로 쓰이고 있다 는 것이었다. 실제 학습 클러스터에서 그 전제가 깨지는 가장 흔한 원인이 스토리지 다.

구조를 보면 당연하다. 학습 한 스텝은 데이터를 읽고 → 연산하고 → 가끔 체크포인트를 쓴다. 세 작업이 직렬로 묶여 있으면, 읽기가 느리면 GPU 가 기다리고, 체크포인트를 쓰는 동안 GPU 가 기다린다. 비싼 자원이 값싼 자원을 기다리는 구조다.

QA 가 이 영역에서 답해야 하는 질문은 셋이다.

1. 데이터 읽기가 연산 속도를 따라가는가 — 못 따라가면 어디가 병목인가
2. 체크포인트 쓰기가 학습을 얼마나 멈추는가 — 그 시간이 허용 범위인가
3. 여러 노드가 같은 파일시스템을 볼 때 보이는 것이 일치하는가 — 아니면 어디까지 보장되는가

세 번째가 QA 고유의 질문이다. 1·2 번은 성능 담당도 본다. 3 번은 보장 범위를 문서에서 확인하고 그 경계를 시험으로 확인하는 일 이라서 QA 의 작업이다.

병렬 파일시스템의 구조 — 병목이 생기는 자리

분산·병렬 파일시스템은 대개 데이터와 메타데이터를 분리 한다. 파일 내용은 여러 저장 서버에 조각내어 흩어 두고(스트라이핑), 어느 파일의 조각이 어디 있는지와 디렉터리 구조는 별도의 메타데이터 서비스가 관리한다.

[클라이언트 노드 여러 대]
        │
        ├──── 메타데이터 경로 ────→ [메타데이터 서버]
        │      (open, stat, create, 디렉터리 조회)
        │
        └──── 데이터 경로 ────────→ [저장 서버 1..N]
               (read, write — 파일 조각이 흩어져 있다)

이 구조에서 병목이 생기는 자리가 세 군데 이고, 각각 다른 작업 부하에서 드러난다.

첫 번째가 AI 학습에서 가장 자주 문제가 된다. 이미지 수백만 장을 개별 파일로 두면 한 에포크마다 수백만 번의 파일 열기가 일어난다. 대역폭은 한참 남는데 메타데이터 경로에서 막힌다. 그래서 학습 데이터를 큰 묶음 파일로 모으는 것이 흔한 해법이고, QA 는 그 묶음 전략이 실제로 효과가 있는지 측정해 보여 줄 수 있다.

Lustre, IBM Storage Scale(이전 명칭 GPFS) 같은 병렬 파일시스템이 이 범주에 들고, 각각 스트라이핑 설정과 메타데이터 구성 방식이 다르다. 구성 항목의 이름과 기본값, 설정 방법, 권고 사항은 해당 제품·프로젝트의 공식 문서에서 확인한다(원문 확인). 벤더마다 용어가 다르고 판본에 따라 바뀐다.

작업 부하를 섞어서 재면 아무것도 모른다

스토리지 측정에서 가장 흔한 실패다. "스토리지 성능 2.5 GB/s" 라는 숫자 하나로 보고하면, 그 숫자가 어느 작업 부하에서 나온 것인지 알 수 없고 판정에 쓸 수 없다.

AI 플랫폼에서 구분해야 하는 작업 부하는 최소 넷이다.

1) 학습 데이터 읽기 — 작은 파일 다수, 무작위 순서. 에포크마다 섞어 읽으므로 순차 읽기가 아니다. 메타데이터 경로와 작은 I/O 처리량이 관건이다.

2) 학습 데이터 읽기 — 큰 묶음 파일, 순차. 묶음 전략을 쓸 때의 모습이다. 대역폭이 관건이고, 여러 노드가 같은 파일을 읽는 공유 읽기 패턴이 된다.

3) 체크포인트 쓰기 — 큰 파일, 동시 다발, 짧은 폭발. 여러 랭크가 동시에 큰 데이터를 쏟아낸다. 평시 대역폭과 전혀 다른 조건이고, 쓰기 폭발을 견디는지 가 관건이다.

4) 메타데이터 집중 — 생성·조회·삭제. 로그, 중간 산출물, 실험 디렉터리. 처리량과 무관하게 응답 시간이 문제가 된다.

측정 도구도 이 구분에 맞춰 고른다. 공개된 표준 도구로는 fio(유연한 I/O 작업 부하 생성), IOR(병렬 대역폭 측정), mdtest(메타데이터 성능 측정) 가 널리 쓰이고, 이들을 조합한 IO500 이 비교 가능한 측정 묶음으로 쓰인다. 각 도구의 옵션·실행 방법·결과 해석은 공식 문서에서 확인한다(원문 확인).

QA 가 할 일은 도구를 돌리는 것이 아니라 작업 부하 정의서를 만드는 것 이다. 우리 플랫폼에서 실제로 돌아가는 학습 작업의 I/O 특성을 네 분류로 정리하고, 각 분류에 대응하는 측정 설정을 문서로 고정한다. 그러면 이후 모든 측정이 비교 가능해진다.

측정을 망치는 네 가지 — 캐시, 이웃, 준비 상태, 표본

측정값이 재현되지 않으면 판정에 쓸 수 없다. 재현을 깨뜨리는 요인이 넷이다.

1) 캐시. 방금 쓴 파일을 바로 읽으면 메모리에서 나온다. 실제 학습은 그렇지 않다. 측정 전 캐시를 비우거나, 데이터 크기를 메모리보다 충분히 크게 잡는다. 캐시 처리 방법을 측정 보고서에 반드시 적는다 — 이것이 빠지면 숫자가 수 배 차이 난다.

2) 이웃 작업. 공유 스토리지에서 다른 사람의 작업이 돌고 있으면 측정값이 흔들린다. 전용 시간을 받거나, 같은 측정을 여러 시간대에 반복해 분포를 남긴다. 한 번 잰 값으로 "이 스토리지는 2.5 GB/s" 라고 쓰지 않는다.

3) 준비 상태. 파일시스템이 비어 있을 때와 80% 찬 상태의 성능이 다르다. 그리고 새로 만든 저장 장치는 처음 한동안 빠르다. 측정 시점의 사용률을 기록 하고, 가능하면 운영과 비슷한 사용률에서 측정한다.

4) 표본과 요약. 평균만 적으면 안 되는 이유는 모듈 31 레슨 4 에서 다룬 그대로다. I/O 는 꼬리가 특히 길다 — 대부분의 요청이 빠르고 일부가 아주 느린 분포가 흔하다. 백분위와 최대값 을 함께 남긴다. GPU 를 멈추는 것은 평균이 아니라 꼬리다.

체크포인트 — 학습을 멈추는 시간을 재는 일

체크포인트는 성능 문제이면서 동시에 신뢰성 문제 다. QA 가 볼 축이 네 개다.

축 1 — 멈추는 시간. 체크포인트를 쓰는 동안 학습이 실제로 멈추는 시간이 얼마인가. 측정의 요점은 쓰기 처리량이 아니라 학습이 멈춘 시간 이다. 비동기로 쓰는 구현이면 멈춤이 짧고, 동기로 쓰면 길다. 어느 쪽인지 확인하고 그에 맞게 재야 의미 있는 숫자가 나온다.

축 2 — 주기와 손실의 교환. 체크포인트를 자주 쓰면 손실이 적고 느리다. 드물게 쓰면 빠르고 손실이 크다. "장애가 나면 몇 분을 잃는가" 가 판정 기준이 되고, 그 허용 범위는 요구사항에서 온다. 숫자를 상상해 넣지 않는다.

축 3 — 중단 시 남는 상태. 쓰는 중에 장애가 나면 반만 쓰인 체크포인트 가 남는다. 이것이 가장 위험하다. 확인할 질문은 둘이다.

• 불완전한 체크포인트를 알아볼 수 있는가(완료 표시, 체크섬, 원자적 교체)
• 불완전한 것을 읽으려 하면 어떻게 되는가(거부하는가, 조용히 손상된 상태로 이어 학습하는가)

두 번째에서 "조용히 이어 학습한다" 가 나오면 심각한 결함이다. 학습이 며칠 돌고 나서 결과가 이상한 것을 발견하게 되고, 원인을 찾을 수 없다.

축 4 — 복구. 체크포인트에서 학습을 재개했을 때 상태가 온전한가. 모델 가중치만이 아니라 최적화기 상태, 데이터 적재 위치, 난수 상태, 에포크 번호가 함께 복구되어야 한다. 일부만 복구되면 재개는 성공하는데 결과가 달라진다 — 통과처럼 보이는 결함이다. 레슨 7 의 "정상 상태 가설" 발상으로, 재개 후 지표가 중단 직전과 이어지는지 확인하는 검증을 둔다.

일관성 — 무엇을 보장하는지 먼저 확인한다

여러 노드가 같은 파일시스템을 쓸 때 "한 노드가 쓴 것을 다른 노드가 언제 보는가" 는 자명하지 않다. 파일시스템과 접근 방식에 따라 보장 범위가 다르다.

QA 가 여기서 할 일은 보장 범위를 추측하지 않는 것 이다. 순서는 이렇다.

1. 문서에서 보장 범위를 확인한다. 사용 중인 파일시스템·프로토콜·마운트 옵션이 무엇을 보장하는지. 네트워크 파일 프로토콜 중에는 파일을 닫을 때까지 다른 클라이언트에 보이지 않는 형태의 느슨한 보장을 쓰는 것도 있다 (닫기-열기 일관성). 정확한 보장 모델과 옵션별 차이는 해당 문서에서 확인한다(원문 확인)
2. 보장 범위를 시험으로 확인한다. 문서가 보장한다고 적은 것이 실제로 성립하는지 — 그리고 보장하지 않는다고 적은 것에 우리 코드가 의존하고 있지는 않은지
3. 의존이 발견되면 결함으로 올린다. "지금까지 잘 돌았다" 는 근거가 되지 않는다. 보장되지 않는 동작에 의존한 코드는 부하가 올라가거나 구성이 바뀔 때 깨진다

시험으로 확인할 전형적 상황 다섯 가지다.

세 번째가 학습 플랫폼에서 실제로 사고를 만든다. 여러 랭크가 같은 출력 디렉터리를 만들려 할 때 경쟁이 제대로 처리되지 않으면, 두 랭크가 같은 경로에 쓰거나 한쪽이 조용히 실패한다.

장애 시 데이터가 어떤 상태로 남는가

레슨 7 에서 장애 주입을 다뤘다. 스토리지에 적용하면 확인할 것이 달라진다 — 서비스가 복구되는가 가 아니라 데이터가 어떤 상태로 남는가 다.

네 번째와 다섯 번째가 자주 빠진다.

용량 소진 — 학습 로그와 체크포인트가 쌓여 용량이 차는 것은 예외가 아니라 시간 문제다. 그때 쓰기 실패가 학습 작업에 제대로 전달되는지 가 중요하다. 실패를 삼키고 계속 돌면 체크포인트 없는 학습이 며칠 돌아간다.

클라이언트 급정지 — 노드가 갑자기 죽으면 쓰던 파일이 중간 상태로 남는다. 축 3(불완전 체크포인트) 와 같은 문제이고, 여기서 알아볼 수 있게 설계되어 있는지 가 판정된다.

이 시험들은 실제 장애를 일으키는 조작 을 포함하므로, 레슨 7 의 원칙이 그대로 적용된다 — 전용 환경에서, 승인과 계획 아래, 영향 범위를 통제하고, 되돌리기 절차를 준비해 수행한다. 공유 스토리지에 임의로 장애를 주입하지 않는다.

QA 가 만들 산출물

정리하면 넷이다.

1. 작업 부하 정의서 — 네 분류와 각 분류의 측정 설정
2. 측정 보고서 양식 — 캐시 처리, 사용률, 이웃 작업 조건, 분포(백분위·최대)
3. 일관성 보장 범위 대조표 — 문서가 보장하는 것 / 시험으로 확인한 것 / 우리 코드가 의존하는 것
4. 장애 시 데이터 상태 점검표 — 다섯 장애와 각각의 판정 기준

3번이 가장 저평가되어 있다. 보장되지 않는 동작에 의존한 코드는 평소에 잘 돌기 때문에 아무도 보지 않는다. 그것을 찾아내는 것이 이 영역에서 QA 가 만드는 가장 값진 결과다.

실무에서 왜 필요한가

GPU 클러스터를 운영하는 조직에서 자주 나오는 보고가 "GPU 사용률이 낮다" 다. 그리고 원인 분석이 연산 쪽에서만 이뤄지는 경우가 많다 — 배치 크기, 모델 병렬화, 커널 효율. 스토리지가 원인일 때 그 분석은 답을 찾지 못한다.

QA 가 기여할 수 있는 지점이 분명하다. 읽기·쓰기·메타데이터를 분리해 측정해 보여 주면 원인이 어디인지가 드러난다. "메타데이터 경로에서 막힙니다, 작은 파일 수백만 개가 원인입니다, 묶음 파일로 바꾸면 이만큼 달라집니다" 는 측정으로만 할 수 있는 말이고, 그 말 한 번이 조직의 방향을 바꾼다.

두 번째 가치는 조용한 손상을 막는 것 이다. 불완전한 체크포인트를 거부하지 않는 플랫폼, 쓰기 실패를 삼키는 작업, 보장되지 않는 일관성에 의존한 코드 — 이 셋은 모두 평소에 잘 돌고 어쩌다 한 번 결과를 망친다. 그리고 그때 원인을 찾기가 거의 불가능하다. 이런 결함은 설계를 보고 찾는 것 이지 부하를 걸어 찾는 것이 아니다. QA 가 질문을 던져야 발견된다.

채용 관점에서 이 영역은 GPUaaS·AI 인프라 플랫폼 QA 공고에서 요구되지만 지원자 대부분이 준비하지 못하는 부분 이다. Kubernetes 는 공부한 사람이 많고, 병렬 파일시스템과 체크포인트 I/O 를 아는 사람은 적다. 면접에서 "학습 작업의 스토리지 병목을 어떻게 찾겠습니까" 에 네 작업 부하를 분리해 재겠다 고 답할 수 있으면 그 자리에서 구분된다.

실습 과제

랩 환경에서 할 수 있는 범위로 설계했다. 실제 병렬 파일시스템이 없어도 작업 부하 분리와 측정 규율 은 로컬 디스크와 네트워크 마운트로 익힐 수 있다.

과제 1 — 작업 부하 정의서 (30분)

본문의 네 분류로 작업 부하 정의서를 쓴다.

1. 분류마다 실제 학습 작업의 어느 단계에 해당하는지 적는다
2. 분류마다 측정 설정을 정한다 — 파일 크기, 파일 수, I/O 단위, 동시성, 읽기·쓰기 비율, 접근 패턴(순차·무작위), 지속 시간
3. 각 설정을 왜 그 값으로 정했는지 근거를 한 줄 적는다. 근거는 우리 학습 작업의 특성이어야 한다
4. 분류마다 어느 도구로 재는 것이 적합한지 적고, 옵션은 공식 문서에서 확인 표시를 둔다
5. 네 분류 중 우리 플랫폼에서 가장 중요한 하나 를 고르고 이유를 쓴다

과제 2 — 측정 규율 적용 (35분)

로컬 디스크 또는 네트워크 마운트에서 실제로 측정한다.

1. 같은 읽기 측정을 캐시를 비운 상태 와 비우지 않은 상태 로 각각 한다. 두 값의 차이를 기록한다
2. 데이터 크기를 메모리보다 작게 / 충분히 크게 두 가지로 측정한다. 차이를 기록하고, 어느 쪽이 의미 있는 숫자인지 적는다
3. 같은 측정을 10회 반복 해 분포를 남긴다. 평균·중위·p95·최대를 모두 적는다
4. 측정 중 다른 부하를 일부러 걸고 다시 측정한다(이웃 작업 효과)
5. 측정 보고서 양식 을 만든다. 캐시 처리 방법, 데이터 크기와 메모리 크기, 파일시스템 사용률, 이웃 작업 조건, 반복 횟수, 분포가 모두 들어가게 한다
6. 1~4 의 결과를 그 양식으로 정리한다. 숫자 하나로 보고하면 왜 안 되는지 를 자신의 측정값으로 설명하는 한 문단을 쓴다

과제 3 — 메타데이터 병목 재현 (30분)

1. 같은 총 용량을 작은 파일 다수 와 큰 파일 소수 로 각각 만든다 (예: 1 KB × 10만 개 vs 100 MB × 1개 — 규모는 환경에 맞게 조정)
2. 각각을 전부 읽는 시간을 측정한다
3. 처리량(초당 바이트) 과 초당 파일 처리 수 를 모두 계산해 비교한다
4. 작은 파일 쪽에서 대역폭이 남는데 느린 것 을 숫자로 보인다
5. 작은 파일들을 하나의 묶음 파일로 모아 다시 측정한다. 개선 폭을 적는다
6. 이 결과를 플랫폼 팀에 제안하는 한 장 보고서 로 쓴다. 측정 조건, 결과, 제안, 제안의 한계(묶음 전략이 가져오는 비용) 를 포함한다

과제 4 — 체크포인트 네 축 설계 (35분)

학습 작업의 체크포인트를 가정해(또는 간단한 스크립트로 흉내 내) 시험을 설계한다. 주기·허용 손실 시간 같은 수치는 상상해 넣지 않고 "요구사항에서 확인한 값 (원문 확인)" 으로 표시 한다.

1. 축 1 — 학습이 멈춘 시간을 재는 방법을 설계한다. 쓰기 처리량과 멈춘 시간이 다른 숫자임을 명시한다. 동기·비동기 구현 각각에서 어떻게 재는지 적는다
2. 축 2 — 주기와 손실의 교환을 표로 만든다. 주기 후보 3개에 대해 예상 손실 시간과 예상 멈춤 비용을 적는다
3. 축 3 — 쓰는 중 중단을 만들어 불완전한 체크포인트 를 남긴다. 그것을 알아볼 수 있는지 확인하고, 읽으려 할 때의 동작을 기록한다. "조용히 이어 학습한다" 가 나오면 결함 보고서를 쓴다
4. 축 4 — 체크포인트에서 재개하고 모델 가중치 외에 함께 복구되어야 할 상태 를 목록으로 만든다(최적화기 상태, 데이터 적재 위치, 난수 상태, 에포크·스텝 번호 등). 각각이 복구되지 않았을 때의 증상을 적는다
5. 재개 후 지표가 중단 직전과 이어지는지 확인하는 판정 기준 을 쓴다. "재개는 성공했는데 결과가 달라지는" 결함을 잡는 기준이다

과제 5 — 일관성 보장 범위 대조표 (30분)

1. 사용 중인(또는 가정한) 파일시스템·프로토콜·마운트 옵션을 적는다
2. 문서에서 보장 범위를 확인 한다. 확인한 내용과 출처를 적고, 확인하지 못한 항목은 원문 확인 으로 남긴다
3. 본문의 다섯 상황 각각에 대해 시험을 설계하고, 가능한 것은 실제로 수행한다 (두 터미널·두 컨테이너·두 노드 중 환경에 맞는 수단으로)
4. 대조표 를 만든다 — 상황 / 문서가 보장하는 것 / 시험 결과 / 우리 코드가 의존하는 것 / 판정
5. "보장되지 않는 동작에 의존" 이 발견되면 결함 보고서를 쓴다. "지금까지 잘 돌았다" 가 근거가 되지 않는 이유 를 한 문단 포함한다
6. 디렉터리 생성 경쟁(세 번째 상황) 은 반드시 수행한다. 여러 프로세스가 같은 디렉터리를 만들려 할 때의 동작을 직접 확인한다

과제 6 — 장애 시 데이터 상태 점검표 (25분)

본문의 다섯 장애로 점검표를 만든다. 설계 과제이며, 실제 장애 주입은 전용 환경에서 승인과 계획 아래 수행한다 는 전제를 명시한다.

1. 장애마다 주입 방법(소프트웨어 계층으로 가능한 것부터), 관찰 지표, 판정 기준, 되돌리기 절차를 적는다
2. 용량 소진 항목은 랩에서 실제로 해 본다(작은 볼륨을 채운다). 쓰기 실패가 상위 작업에 전달되는지 확인하고, 삼켜지면 결함으로 기록한다
3. 클라이언트 급정지 항목은 쓰던 파일의 상태를 확인한다. 불완전함을 알아볼 수 있는지 축 3 과 연결한다
4. 각 장애에 대해 "데이터가 어떤 상태로 남아야 하는가" 를 요구사항 문장 으로 쓴다. 수치가 필요한 자리는 원문 확인으로 표시한다
5. 공유 스토리지에 임의 장애 주입을 하지 않는 이유를 한 줄 적는다

자가 체크리스트

• GPU 가 노는 원인이 스토리지일 수 있는 구조(읽기·연산·체크포인트 직렬) 를 설명할 수 있다
• 이 영역에서 QA 가 답할 세 질문을 들고, 세 번째가 QA 고유 질문인 이유를 안다
• 병렬 파일시스템이 데이터와 메타데이터를 분리하는 구조를 그릴 수 있다
• 병목이 생기는 세 자리와 각각 드러나는 작업 부하를 짝지을 수 있다
• 작은 파일 다수에서 "대역폭은 남는데 느리다" 가 나오는 이유를 설명할 수 있다
• 파일시스템 제품별 구성 항목·기본값은 공식 문서 확인임을 안다
• AI 플랫폼의 네 작업 부하를 구분하고 각각의 관건을 말할 수 있다
• fio·IOR·mdtest·IO500 의 용도를 구분하고 옵션은 공식 문서 확인임을 안다
• 도구를 돌리는 것보다 작업 부하 정의서를 만드는 것이 QA 의 일인 이유를 안다
• 측정을 망치는 네 요인(캐시·이웃 작업·준비 상태·표본) 을 들 수 있다
• 캐시 처리 방법을 보고서에 적지 않으면 숫자가 수 배 차이 날 수 있음을 안다
• 한 번 측정한 값으로 성능을 단정하지 않고 분포를 남겨야 하는 이유를 안다
• I/O 의 꼬리가 길어 백분위와 최대값이 필요한 이유를 설명할 수 있다
• 체크포인트 축 1 에서 재야 할 것이 처리량이 아니라 학습이 멈춘 시간임을 안다
• 동기·비동기 구현에 따라 측정 방법이 달라진다는 것을 안다
• 체크포인트 주기와 손실의 교환을 표로 설계할 수 있다
• 불완전한 체크포인트를 알아볼 수 있는지와, 읽으려 할 때의 동작을 확인해야 함을 안다
• "조용히 이어 학습한다" 가 왜 심각한 결함인지 설명할 수 있다
• 재개 시 모델 가중치 외에 함께 복구되어야 할 상태를 들 수 있다
• "재개는 성공하는데 결과가 달라지는" 결함을 잡는 판정 기준을 설계할 수 있다
• 일관성 보장 범위를 추측하지 않고 문서 → 시험 → 의존 확인 순으로 다룰 수 있다
• 닫기-열기 일관성처럼 느슨한 보장이 있다는 것과 세부는 원문 확인임을 안다
• 보장되지 않는 동작에 의존한 코드가 왜 결함인지, "잘 돌았다" 가 근거가 안 되는 이유를 말할 수 있다
• 일관성 시험 다섯 상황을 들고, 디렉터리 생성 경쟁이 학습 플랫폼에서 사고를 만드는 이유를 안다
• 스토리지 장애 시험의 판정이 "서비스 복구" 가 아니라 "데이터가 어떤 상태로 남는가" 임을 안다
• 용량 소진 시 쓰기 실패가 상위에 전달되는지 확인해야 하는 이유를 설명할 수 있다
• 공유 스토리지에 임의 장애 주입을 하지 않는다는 원칙을 안다
• QA 산출물 넷을 들고, 일관성 대조표가 가장 저평가되어 있는 이유를 안다

흔한 실수

스토리지 성능을 숫자 하나로 보고한다. "2.5 GB/s" 는 어느 작업 부하에서 나왔는지 알 수 없어 판정에 쓸 수 없다. 작업 부하를 분리해 각각 보고한다.

캐시를 처리하지 않고 측정한다. 방금 쓴 것을 바로 읽으면 메모리에서 나온다. 숫자가 수 배 부풀고, 운영에서는 그 성능이 나오지 않는다.

데이터 크기를 메모리보다 작게 잡는다. 같은 문제의 다른 형태다. 전부 캐시에 들어가 실제 스토리지를 거의 쓰지 않는다.

한 번 재고 단정한다. 공유 스토리지는 이웃 작업에 따라 흔들린다. 반복해 분포를 남기고, 측정 조건을 함께 적는다.

빈 파일시스템에서 재고 운영 성능으로 보고한다. 사용률이 올라가면 성능이 달라진다. 측정 시점의 사용률을 기록한다.

평균만 적는다. I/O 는 꼬리가 길다. GPU 를 멈추는 것은 평균이 아니라 느린 소수다. 백분위와 최대값을 남긴다.

메타데이터 작업 부하를 빼놓는다. AI 학습에서 가장 자주 병목이 되는 곳인데, 대역폭 측정만 하면 영원히 보이지 않는다.

체크포인트를 쓰기 처리량으로 평가한다. 재야 할 것은 학습이 멈춘 시간 이다. 비동기 구현이면 처리량과 멈춤이 전혀 다른 숫자다.

불완전한 체크포인트를 시험하지 않는다. 쓰는 중 중단은 반드시 일어난다. 알아볼 수 없게 설계되어 있으면 손상된 상태로 학습이 이어진다.

재개 성공을 통과로 본다. 가중치만 복구되고 최적화기 상태나 데이터 위치가 복구되지 않으면, 재개는 성공하고 결과는 달라진다. 지표가 이어지는지 확인한다.

일관성 보장을 추측한다. "같은 파일시스템이니 바로 보일 것" 이라고 가정한 코드가 부하가 올라가면 깨진다. 문서에서 확인하고 시험으로 대조한다.

보장되지 않는 동작에 의존한 코드를 "잘 돌고 있다" 로 넘긴다. 구성이 바뀌거나 부하가 올라가면 깨지고, 그때 원인을 찾기 어렵다. 결함으로 올린다.

디렉터리 생성 경쟁을 시험하지 않는다. 여러 랭크가 같은 출력 경로를 만들려 할 때의 결함은 학습 플랫폼에서 실제로 사고를 만든다.

용량 소진을 예외로 본다. 로그와 체크포인트가 쌓이면 반드시 찬다. 쓰기 실패가 삼켜지면 체크포인트 없는 학습이 며칠 돌아간다.

스토리지 장애 시험을 "복구되는가" 로 판정한다. 서비스가 돌아와도 데이터가 깨져 있으면 실패다. 판정은 데이터 상태로 한다.

공유 스토리지에 임의로 장애를 주입한다. 다른 사람의 학습 작업을 망친다. 전용 환경에서 승인과 계획 아래 수행한다.

참고 자료

• 사용 중인 병렬 파일시스템의 공식 문서(Lustre, IBM Storage Scale 등) — 스트라이핑 설정, 메타데이터 구성, 일관성 보장 모델, 권고 사항. 벤더·판본마다 용어와 기본값이 다르다(원문 확인)
• fio 공식 문서 — 작업 부하 정의 방법, 캐시 우회 옵션, 결과 해석(원문 확인)
• IOR 과 mdtest 문서 — 병렬 대역폭과 메타데이터 측정의 표준 도구. 옵션과 실행 방법을 확인한다(원문 확인)
• IO500 — 비교 가능한 측정 묶음. 구성과 제출 규칙을 확인한다(원문 확인)
• 사용 중인 네트워크 파일 프로토콜과 마운트 옵션 문서 — 일관성 보장 범위는 프로토콜과 옵션이 정한다. 추측하지 않고 여기서 확인한다(원문 확인)
• 학습 프레임워크의 체크포인트 문서 — 무엇이 저장되고 무엇이 저장되지 않는지, 원자적 교체 여부, 재개 시 복구되는 상태의 범위(원문 확인)
• GPU 직접 접근 저장 경로 관련 공식 문서 — CPU 를 거치지 않는 경로를 쓸 때의 전제 조건과 제약(원문 확인)
• 모듈 39 레슨 5 — GPU·AI 학습 워크로드 검증: 연산 쪽 지표와 짝을 이룬다
• 모듈 39 레슨 7 — 장애 주입: 과제 6 의 원칙과 안전 조건
• 모듈 39 레슨 10 — 실습 랩: 폴링·스냅샷 기법을 스토리지 검증에 가져와 쓴다
• 모듈 31 레슨 4 — 성능 결과의 통계적 표현: 평균만 적으면 안 되는 이유
• 모듈 62 레슨 5 — 연속 가동과 복구: 용량 소진·버퍼 한계의 같은 발상