KoreaDevKNOWLEDGE SHARING

콘텐츠 유형학습하기

AI INFRASTRUCTURE · 05 / 12

AI 스토리지

dataset·checkpoint·model artifact의 throughput·IOPS·latency·metadata 요구를 storage 계층과 복구 시험으로 연결합니다.

난이도
중급
구성
핵심 단원 4개 · 판단 활동 · 3단계 평가

NEW HIRE ONBOARDING

첫 업무를 받는 순서로 시작합니다

중학교를 졸업하고 처음 IT 업무를 맡은 신입사원도 따라올 수 있도록, 어려운 정의보다 상황·할 일·증거·보고할 경계를 먼저 확인합니다.

  1. 01

    상황을 한 문장으로 읽기

    throughput·IOPS·latency·metadata·consistency·failure domain을 workload 단계와 연결하고 backup이 아니라 실제 restore로 판정합니다.

  2. 02

    오늘 맡은 일

    성능·backup·restore 검증의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

  3. 03

    완료를 보여 주는 증거

    공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

  4. 04

    멈추고 선임에게 확인할 경계

    checkpoint 저장 시간이 두 배가 됐지만 평균 throughput은 같습니다. 다음 증거는?

낯선 용어 먼저 풀기

Data path(데이터 전달 경로)
저장된 데이터를 reader·CPU 처리·memory·GPU 입력으로 전달하는 실제 경로입니다.

이 과정의 운영 질문

dataset·checkpoint·model artifact마다 다른 병목과 복구 조건을 어떻게 선택할까?

throughput·IOPS·latency·metadata·consistency·failure domain을 workload 단계와 연결하고 backup이 아니라 실제 restore로 판정합니다.

CORE UNIT 1 / 4

AI workload의 data 경로

학습·추론 data가 CPU·memory·storage·GPU를 지나는 경로를 설명합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

격리 dataset과 read-only production inventory. storage lab 203.0.113.0/24.

3처음 보는 값과 아직 실행하지 않은 시험은 어떻게 적습니까?

미확인으로 기록합니다. 교육용 예상 출력과 실제 측정값을 구분하고, 승인 없는 작업으로 빈칸을 채우지 않습니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. AI workload의 data 경로의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. AI workload의 data 경로의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. AI workload의 data 경로의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
AI workload의 data 경로 실습 환경과 안전 경계
하드웨어NVMe·NFS·Ceph/S3 fixture
소프트웨어Ubuntu 24.04·fio 3.x·Ceph client·AWS CLI
필요 권한격리 dataset과 read-only production inventory
네트워크storage lab 203.0.113.0/24

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: fio 3.x · Ceph 18.x fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장dataset에서 확인을 시작합니다
  2. 2장host 경로의 실습 대상을 고정합니다
  3. 3장전송 경로의 출력과 의미를 구분합니다
  4. 4장GPU 소비의 진행과 중단을 결정합니다
  5. 5장AI workload의 data 경로의 복구를 재검증합니다
AI workload의 data 경로의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · dataset에서 확인을 시작합니다

다음 연결: host 경로의 실습 대상을 고정합니다

  1. dataset에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. host 경로의 실습 대상을 고정합니다

    실습 상황:: GPU utilization 45% fixture에서 storage, CPU decode, loader worker 중 실제 병목을 판정합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, GPU idle과 원인 signal의 시각 불일치 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. 전송 경로의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 storage queue와 CPU decode, GPU idle이 어느 경계에서 동시에 발생하는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. GPU 소비의 진행과 중단을 결정합니다

    step time을 storage read·decode·transfer·GPU compute 구간으로 나누고 가장 큰 대기와 검증 실험을 제시하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. AI workload의 data 경로의 복구를 재검증합니다

    병목 경계를 찾은 뒤 worker 수, prefetch, shard 크기 또는 storage path 중 한 변수만 바꿉니다. 변경 전후 step time과 자원 signal을 같은 조건으로 비교합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

dataset에서 GPU까지 data 대기 시간을 분해합니다

Data path(데이터 전달 경로): 저장된 데이터를 reader·CPU 처리·memory·GPU 입력으로 전달하는 실제 경로입니다.

학습 data는 storage에서 GPU memory로 순간 이동하지 않습니다. object/filesystem client, page cache, CPU memory, PCIe와 data loader queue를 거치며 각 경계의 대기와 변환이 GPU idle을 만듭니다.

큰 sequential shard는 bandwidth에, 작은 file과 random sample은 metadata·IOPS·latency에 민감합니다. compression·decode·augmentation은 storage 병목처럼 보이는 CPU 병목을 만들 수 있습니다.

GPU utilization이 낮다는 이유로 storage를 증설하기 전에 queue depth, CPU saturation, read throughput과 data loader wait를 같은 시간축으로 봅니다.

교육 사례에서 GPU 사용률은 30%인데 CPU 전처리 thread 하나가 계속 바쁩니다. storage bandwidth를 늘려도 해당 thread가 직렬로 처리하는 구간은 그대로 남습니다. 읽기 대기, decode·변환 시간과 GPU 대기를 구분한 뒤 한 변수를 바꿔 비교합니다. cache hit로 빨라진 두 번째 실행을 storage 개선 효과로 오해하지 않도록 cold·warm 조건도 기록합니다.

dataset 조건·storage read·CPU decode·GPU 소비 네 경계를 명령·측정 항목·통과 기준·건너뛸 때의 증상으로 비교한 점검 표
그림 읽는 법 표는 dataset에서 GPU까지의 네 경계를 위에서 아래로 놓았습니다. 각 행은 왼쪽부터 경계와 명령, 무엇을 재는가, 무엇을 보아야 통과인가, 건너뛰면 무엇이 깨지나 순서로 가로로 읽습니다. 세 번째 열의 값(nvme0n1 820 r/s·await 1.2·%util 72.0, python CPU 390%·read 620MB/s, GPU sm 45%·mem 18%)이 통과 판정의 근거이고, 네 번째 열은 그 경계를 건너뛰었을 때 남는 증상입니다. 네 행의 기록은 같은 timestamp로 묶어야 하며, GPU idle과 원인 signal의 시각이 어긋나면 근거가 부족하므로 다음 변경으로 넘어가지 않습니다. 마지막 초록 상자는 step time을 storage read·decode·transfer·GPU compute로 나눈 뒤 worker 수·prefetch·shard 크기·storage path 중 한 변수만 바꿔 같은 조건으로 다시 재라는 규칙입니다. 색과 배지는 열과 순서를 구분하려는 것이므로 색을 구별하지 않아도 읽을 수 있습니다. 표 안의 식별자와 수치는 저자 구성 교육용 예시이며 실제 장비에서 측정한 값이 아니고, 물리 배선이나 시간 비율이 아니라 확인 순서만 표현합니다. 자료: fio documentation · PyTorch Data Loading를 바탕으로 저자 구성.
왜 이런가
큰 sequential shard는 bandwidth에, 작은 file과 random sample은 metadata·IOPS·latency에 민감합니다. compression·decode·augmentation은 storage 병목처럼 보이는 CPU 병목을 만들 수 있습니다.
언제 문제가 되는가
GPU idle과 원인 signal의 시각 불일치 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
cache가 warm인 한 번의 결과와 cold start 결과를 섞지 않습니다. cache 조건과 dataset revision을 기록합니다.
직접 확인하는 방법
sample 크기·file 수·access pattern과 batch 조건을 기록합니다. client read bandwidth·IOPS·latency와 cache hit을 수집합니다.
이 절을 정리하면step time을 storage read·decode·transfer·GPU compute 구간으로 나누고 가장 큰 대기와 검증 실험을 제시하면 성공입니다.

CHAPTER 1 / 5

dataset에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. sample 크기·file 수·access pattern과 batch 조건을 기록합니다. 2. client read bandwidth·IOPS·latency와 cache hit을 수집합니다. 3. CPU decode 시간과 data loader queue depth를 확인합니다. 4. GPU utilization과 step time을 같은 timestamp로 연결합니다.

CHAPTER 2 / 5

host 경로의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
iostat -xz 1 5
pidstat -dru -p $(pgrep -n python) 1 5
nvidia-smi dmon -s pucm -c 5

CHAPTER 3 / 5

전송 경로의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
Device r/s rkB/s await %util
nvme0n1 820 640000 1.2 72.0
# python CPU 390%, read 620MB/s
# GPU sm 45%, mem 18%

CHAPTER 4 / 5

GPU 소비의 진행과 중단을 결정합니다

CHAPTER 5 / 5

AI workload의 data 경로의 복구를 재검증합니다

CONCRETE CASES

GPU utilization 45% fixture에서 storage, CPU decode, loader worker 중 실제 병목을 판정합니다.

GPU utilization이 낮다는 이유로 storage를 증설하기 전에 queue depth, CPU saturation, read throughput과 data loader wait를 같은 시간축으로 봅니다.

잘못된 대응과 확인할 경계

cache가 warm인 한 번의 결과와 cold start 결과를 섞지 않습니다. cache 조건과 dataset revision을 기록합니다.

병목 경계를 찾은 뒤 worker 수, prefetch, shard 크기 또는 storage path 중 한 변수만 바꿉니다. 변경 전후 step time과 자원 signal을 같은 조건으로 비교합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: GPU utilization 45% fixture에서 storage, CPU decode, loader worker 중 실제 병목을 판정합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, GPU idle과 원인 signal의 시각 불일치 조건이 보이면 다음 변경으로 넘어가지 마십시오.

Device r/s rkB/s await %util
nvme0n1 820 640000 1.2 72.0
# python CPU 390%, read 620MB/s
# GPU sm 45%, mem 18%

값 자체를 외우는 것이 아니라 storage queue와 CPU decode, GPU idle이 어느 경계에서 동시에 발생하는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

cache가 warm인 한 번의 결과와 cold start 결과를 섞지 않습니다. cache 조건과 dataset revision을 기록합니다.

KEY TERMS

이번 단원 핵심 용어

Data path(데이터 전달 경로)
저장된 데이터를 reader·CPU 처리·memory·GPU 입력으로 전달하는 실제 경로입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

AI workload의 data 경로의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 2 / 4

Local NVMe와 공유 storage

local disk·NFS·NAS의 일관성·성능·failure domain을 비교합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

격리 dataset과 read-only production inventory. storage lab 203.0.113.0/24.

3앞 단원 「AI workload의 data 경로」에서 어떤 증거를 남겼습니까?

step time을 storage read·decode·transfer·GPU compute 구간으로 나누고 가장 큰 대기와 검증 실험을 제시하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. Local NVMe와 공유 storage의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. Local NVMe와 공유 storage의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. Local NVMe와 공유 storage의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
Local NVMe와 공유 storage 실습 환경과 안전 경계
하드웨어NVMe·NFS·Ceph/S3 fixture
소프트웨어Ubuntu 24.04·fio 3.x·Ceph client·AWS CLI
필요 권한격리 dataset과 read-only production inventory
네트워크storage lab 203.0.113.0/24

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: fio 3.x · Ceph 18.x fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장workload 요구에서 확인을 시작합니다
  2. 2장local NVMe의 실습 대상을 고정합니다
  3. 3장NFS·NAS의 출력과 의미를 구분합니다
  4. 4장선택 증거의 진행과 중단을 결정합니다
  5. 5장Local NVMe와 공유 storage의 복구를 재검증합니다
Local NVMe와 공유 storage의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · workload 요구에서 확인을 시작합니다

다음 연결: local NVMe의 실습 대상을 고정합니다

  1. workload 요구에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. local NVMe의 실습 대상을 고정합니다

    실습 상황:: scratch와 checkpoint 두 workload를 local NVMe와 NFS에 배치하고 선택 근거를 작성합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, data 수명·mount semantics 미정 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. NFS·NAS의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 실제 data path와 filesystem/mount semantics가 설계 선택과 일치하는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. 선택 증거의 진행과 중단을 결정합니다

    scratch는 재생성 경로, checkpoint는 공유·복구 경로를 포함해 placement와 mount option을 명시하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. Local NVMe와 공유 storage의 복구를 재검증합니다

    mount option 불일치나 stale handle이 있으면 application write를 멈추고 client/server log를 보존합니다. 임의 강제 unmount보다 owner와 failover 절차를 따라 재연결한 뒤 무결성을 확인합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

local 성능과 공유 복구의 trade-off를 비교합니다

Scratch(재생성 가능한 작업 데이터): 원본에서 다시 만들 수 있는 임시 결과이며 유일한 복구 원본을 두는 장소가 아닙니다.

local NVMe는 높은 locality와 성능을 주지만 node failure와 scheduling에 data가 묶입니다. NFS/NAS는 공유 namespace를 주지만 server·network·mount option이 공통 failure domain이 됩니다.

filesystem cache와 sync semantics, file locking, UID/GID mapping은 application correctness에 영향을 줍니다. 같은 path가 보인다는 것과 여러 client가 같은 ordering·durability를 관찰한다는 것은 다릅니다.

선택은 빠른 쪽이 아니라 data 수명, 재생성 가능성, producer/consumer 수, failover와 restore 목표에서 시작합니다.

교육 사례에서 node-local NVMe에만 checkpoint를 저장한 job이 node 장애 뒤 재개하지 못했습니다. 빠르게 저장한 사실과 다른 node에서 읽을 수 있는 사실은 다릅니다. 재생성 가능한 scratch와 유실되면 긴 작업을 다시 해야 하는 checkpoint의 보존 경로를 분리합니다. 공유 storage를 택해도 server 장애와 권한 mapping은 따로 시험합니다.

local NVMe와 NFS·NAS 공유 storage를 성능·failure domain·semantics·배치·통과 기준 다섯 축으로 비교하고 수명과 복구 경로로 선택하는 표
그림 읽는 법 왼쪽 열의 배지 1부터 5까지가 비교 축이고, 같은 축에서 가운데의 local NVMe 열과 오른쪽의 NFS·NAS 공유 storage 열을 나란히 읽습니다. 1행은 무엇을 얻는가(nvme0n1p1 xfs /scratch, server:/training nfs4 vers=4.2), 2행은 무엇이 함께 묶이는 failure domain, 3행은 semantics가 무엇을 약속하는가, 4행은 무엇을 두는가, 5행은 무엇을 보아야 통과인가입니다. 통과 판정의 근거는 5행에 있습니다. lsblk 출력의 UUID·FSTYPE이 설계와 같고 격리된 quota path에서 시험했는지, nfsstat -m의 Flags rw,vers=4.2가 기대와 같고 server 장애 뒤 접근 시험을 통과했는지를 봅니다. 두 열은 같은 명도로 그렸으므로 색이 우열을 뜻하지 않으며, 색을 구별하지 않아도 읽을 수 있습니다. 마지막 초록 상자가 판단 기준입니다. 빠른 쪽이 아니라 data 수명·재생성 가능성·producer/consumer 수·failover와 restore 목표에서 시작해 scratch는 재생성 경로에, checkpoint는 공유·복구 경로에 둡니다. data 수명과 mount semantics가 정해지지 않았으면 진행 근거가 부족하므로 배치를 확정하지 않습니다. 표 안의 식별자와 수치는 저자 구성 교육용 예시이며 실제 장비에서 측정한 값이 아니고, 물리 배선이 아니라 선택 근거만 표현합니다. 자료: Linux NFS Documentation · fio documentation를 바탕으로 저자 구성.
왜 이런가
filesystem cache와 sync semantics, file locking, UID/GID mapping은 application correctness에 영향을 줍니다. 같은 path가 보인다는 것과 여러 client가 같은 ordering·durability를 관찰한다는 것은 다릅니다.
언제 문제가 되는가
data 수명·mount semantics 미정 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
benchmark file을 production dataset directory에 만들지 않습니다. quota와 삭제 범위가 정해진 격리 path를 사용합니다.
직접 확인하는 방법
scratch·dataset·checkpoint·artifact의 수명과 owner를 분류합니다. local device UUID·filesystem·mount option과 NUMA 위치를 기록합니다.
이 절을 정리하면scratch는 재생성 경로, checkpoint는 공유·복구 경로를 포함해 placement와 mount option을 명시하면 성공입니다.

CHAPTER 1 / 5

workload 요구에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. scratch·dataset·checkpoint·artifact의 수명과 owner를 분류합니다. 2. local device UUID·filesystem·mount option과 NUMA 위치를 기록합니다. 3. NFS server·export·protocol·mount option과 identity mapping을 확인합니다. 4. node 또는 server failure 뒤 data 접근과 복구 절차를 시험합니다.

CHAPTER 2 / 5

local NVMe의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
findmnt -T /mnt/training -o SOURCE,FSTYPE,OPTIONS,TARGET
lsblk -o NAME,UUID,FSTYPE,MOUNTPOINTS
nfsstat -m

CHAPTER 3 / 5

NFS·NAS의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
SOURCE server:/training FSTYPE nfs4 OPTIONS rw,vers=4.2,... TARGET /mnt/training
nvme0n1p1 UUID-... xfs /scratch
/mnt/training from server:/training Flags: rw,vers=4.2,...

CHAPTER 4 / 5

선택 증거의 진행과 중단을 결정합니다

CHAPTER 5 / 5

Local NVMe와 공유 storage의 복구를 재검증합니다

CONCRETE CASES

scratch와 checkpoint 두 workload를 local NVMe와 NFS에 배치하고 선택 근거를 작성합니다.

선택은 빠른 쪽이 아니라 data 수명, 재생성 가능성, producer/consumer 수, failover와 restore 목표에서 시작합니다.

잘못된 대응과 확인할 경계

benchmark file을 production dataset directory에 만들지 않습니다. quota와 삭제 범위가 정해진 격리 path를 사용합니다.

mount option 불일치나 stale handle이 있으면 application write를 멈추고 client/server log를 보존합니다. 임의 강제 unmount보다 owner와 failover 절차를 따라 재연결한 뒤 무결성을 확인합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: scratch와 checkpoint 두 workload를 local NVMe와 NFS에 배치하고 선택 근거를 작성합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, data 수명·mount semantics 미정 조건이 보이면 다음 변경으로 넘어가지 마십시오.

SOURCE server:/training FSTYPE nfs4 OPTIONS rw,vers=4.2,... TARGET /mnt/training
nvme0n1p1 UUID-... xfs /scratch
/mnt/training from server:/training Flags: rw,vers=4.2,...

값 자체를 외우는 것이 아니라 실제 data path와 filesystem/mount semantics가 설계 선택과 일치하는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

benchmark file을 production dataset directory에 만들지 않습니다. quota와 삭제 범위가 정해진 격리 path를 사용합니다.

KEY TERMS

이번 단원 핵심 용어

Scratch(재생성 가능한 작업 데이터)
원본에서 다시 만들 수 있는 임시 결과이며 유일한 복구 원본을 두는 장소가 아닙니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

Local NVMe와 공유 storage의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 3 / 4

병렬 filesystem과 object storage

Ceph·S3·병렬 filesystem의 선택 조건을 판정합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

격리 dataset과 read-only production inventory. storage lab 203.0.113.0/24.

3앞 단원 「Local NVMe와 공유 storage」에서 어떤 증거를 남겼습니까?

scratch는 재생성 경로, checkpoint는 공유·복구 경로를 포함해 placement와 mount option을 명시하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. 병렬 filesystem과 object storage의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. 병렬 filesystem과 object storage의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. 병렬 filesystem과 object storage의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
병렬 filesystem과 object storage 실습 환경과 안전 경계
하드웨어NVMe·NFS·Ceph/S3 fixture
소프트웨어Ubuntu 24.04·fio 3.x·Ceph client·AWS CLI
필요 권한격리 dataset과 read-only production inventory
네트워크storage lab 203.0.113.0/24

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: fio 3.x · Ceph 18.x fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장요구 분류에서 확인을 시작합니다
  2. 2장data 배치의 실습 대상을 고정합니다
  3. 3장metadata의 출력과 의미를 구분합니다
  4. 4장복구 경계의 진행과 중단을 결정합니다
  5. 5장병렬 filesystem과 object storage의 복구를 재검증합니다
병렬 filesystem과 object storage의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · 요구 분류에서 확인을 시작합니다

다음 연결: data 배치의 실습 대상을 고정합니다

  1. 요구 분류에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. data 배치의 실습 대상을 고정합니다

    실습 상황:: checkpoint는 CephFS, immutable model artifact는 S3 API에 두는 설계를 검토하고 반대 선택의 위험을 설명합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, application semantics와 storage API 불일치 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. metadata의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 cluster health, filesystem client, object identity와 checksum이 선택한 interface에서 검증되는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. 복구 경계의 진행과 중단을 결정합니다

    두 workload의 semantics·성능·failure domain·복구를 비교한 decision table과 시험 명령을 제시하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. 병렬 filesystem과 object storage의 복구를 재검증합니다

    interface semantics가 맞지 않으면 임시 adapter로 숨기지 말고 write를 중단합니다. data migration plan, dual-read 검증, checksum과 rollback window를 마련해 전환합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

POSIX와 object API의 data·metadata 경계를 구분합니다

Object key(객체 식별 키): bucket 안에서 object를 찾는 이름이며 POSIX 파일 경로와 같은 조작 의미를 약속하지 않습니다.

병렬 filesystem은 여러 storage target에 file data와 metadata를 분산해 POSIX namespace를 제공합니다. object storage는 key와 API를 중심으로 확장성과 durability를 제공하지만 file rename·append 의미를 그대로 약속하지 않습니다.

Ceph는 RADOS 위에 block·CephFS·Object Gateway를 제공하며 각 interface의 consistency와 failure 경계가 다릅니다. application의 access pattern과 correctness 요구가 interface 선택을 결정합니다.

S3-compatible이라는 말만으로 AWS S3와 모든 동작이 같다고 가정하지 않습니다. versioning, multipart, checksum, listing과 authentication 동작을 실제 구현 문서와 시험으로 확인합니다.

교육 사례에서 파일 기반 프로그램이 rename으로 checkpoint 공개를 완료했는데 object API로 옮긴 뒤 같은 가정을 사용했습니다. object key가 디렉터리처럼 보여도 rename·append와 다중 object 원자성이 자동으로 생기지 않습니다. 새 object를 올리고 checksum을 확인한 뒤 manifest가 가리키는 version을 전환하는 등 application protocol을 설계해야 합니다. 실제 제공 기능은 사용하는 구현의 문서와 시험으로 확인합니다.

CephFS의 POSIX semantics와 S3 API의 object key semantics를 이름·조작·checkpoint 공개 방법·시험 명령·보장하지 않는 것 다섯 축으로 비교한 표
그림 읽는 법 왼쪽 열의 배지 1부터 5까지가 확인 축이고, 같은 축에서 가운데의 병렬 filesystem(CephFS) 열과 오른쪽의 object storage(S3 API) 열을 나란히 읽습니다. 1행은 무엇으로 찾는가, 2행은 open·rename·append·list가 그대로 동작하는가, 3행은 checkpoint를 어떻게 공개하는가, 4행은 무엇을 시험하는가, 5행은 무엇을 보장하지 않는가입니다. 3행이 이 도판의 핵심입니다. file 기반 프로그램은 rename으로 완료를 표시했지만 object에서는 rename·append와 다중 object 원자성이 자동으로 생기지 않으므로, 새 object를 올리고 checksum을 확인한 뒤 manifest가 가리키는 version을 전환하는 application protocol을 설계해야 합니다. 시험 근거는 4행의 명령 출력(cluster: HEALTH_OK, model-fs - 3 clients, ContentLength: 842, ObjectSize: 12884901888, ChecksumSHA256)이며, 5행은 HEALTH_OK가 application data의 correctness를 보장하지 않고 S3-compatible이 versioning·multipart·checksum·listing의 동일 동작을 뜻하지 않는다는 한계입니다. 두 열은 같은 명도로 그렸으므로 색이 우열을 뜻하지 않으며 색을 구별하지 않아도 읽을 수 있습니다. 마지막 초록 상자가 판단 기준으로, rename·append와 POSIX reader가 필요한 checkpoint는 CephFS에 immutable model artifact는 S3 API에 두고, semantics가 맞지 않으면 임시 adapter로 숨기지 말고 write를 중단합니다. 표 안의 식별자와 수치는 저자 구성 교육용 예시이며 실제 장비에서 측정한 값이 아닙니다. 자료: Ceph Architecture · Ceph Object Gateway · Amazon S3 User Guide를 바탕으로 저자 구성.
왜 이런가
Ceph는 RADOS 위에 block·CephFS·Object Gateway를 제공하며 각 interface의 consistency와 failure 경계가 다릅니다. application의 access pattern과 correctness 요구가 interface 선택을 결정합니다.
언제 문제가 되는가
application semantics와 storage API 불일치 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
HEALTH_OK는 application data의 존재와 correctness를 보장하지 않습니다. 대표 object/file을 checksum과 application reader로 확인합니다.
직접 확인하는 방법
application이 요구하는 open/rename/append/list semantics를 적습니다. file/object 크기 분포와 동시 client 수를 측정합니다.
이 절을 정리하면두 workload의 semantics·성능·failure domain·복구를 비교한 decision table과 시험 명령을 제시하면 성공입니다.

CHAPTER 1 / 5

요구 분류에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. application이 요구하는 open/rename/append/list semantics를 적습니다. 2. file/object 크기 분포와 동시 client 수를 측정합니다. 3. data·metadata·gateway component와 failure domain을 표시합니다. 4. checksum·versioning·replication과 restore 방법을 시험합니다.

CHAPTER 2 / 5

data 배치의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
ceph status
ceph fs status
aws s3api head-object --bucket model-artifacts --key releases/model-a/manifest.json
aws s3api get-object-attributes --bucket model-artifacts --key releases/model-a/weights.bin --object-attributes Checksum,ObjectSize

CHAPTER 3 / 5

metadata의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
cluster: HEALTH_OK
model-fs - 3 clients
ContentLength: 842
ObjectSize: 12884901888
ChecksumSHA256: ...

CHAPTER 4 / 5

복구 경계의 진행과 중단을 결정합니다

CHAPTER 5 / 5

병렬 filesystem과 object storage의 복구를 재검증합니다

CONCRETE CASES

checkpoint는 CephFS, immutable model artifact는 S3 API에 두는 설계를 검토하고 반대 선택의 위험을 설명합니다.

S3-compatible이라는 말만으로 AWS S3와 모든 동작이 같다고 가정하지 않습니다. versioning, multipart, checksum, listing과 authentication 동작을 실제 구현 문서와 시험으로 확인합니다.

잘못된 대응과 확인할 경계

HEALTH_OK는 application data의 존재와 correctness를 보장하지 않습니다. 대표 object/file을 checksum과 application reader로 확인합니다.

interface semantics가 맞지 않으면 임시 adapter로 숨기지 말고 write를 중단합니다. data migration plan, dual-read 검증, checksum과 rollback window를 마련해 전환합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: checkpoint는 CephFS, immutable model artifact는 S3 API에 두는 설계를 검토하고 반대 선택의 위험을 설명합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, application semantics와 storage API 불일치 조건이 보이면 다음 변경으로 넘어가지 마십시오.

cluster: HEALTH_OK
model-fs - 3 clients
ContentLength: 842
ObjectSize: 12884901888
ChecksumSHA256: ...

값 자체를 외우는 것이 아니라 cluster health, filesystem client, object identity와 checksum이 선택한 interface에서 검증되는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

HEALTH_OK는 application data의 존재와 correctness를 보장하지 않습니다. 대표 object/file을 checksum과 application reader로 확인합니다.

KEY TERMS

이번 단원 핵심 용어

Object key(객체 식별 키)
bucket 안에서 object를 찾는 이름이며 POSIX 파일 경로와 같은 조작 의미를 약속하지 않습니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

병렬 filesystem과 object storage의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 4 / 4

성능·backup·restore 검증

fio 조건과 RPO·RTO를 정의하고 실제 restore 증거를 남깁니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

격리 dataset과 read-only production inventory. storage lab 203.0.113.0/24.

3앞 단원 「병렬 filesystem과 object storage」에서 어떤 증거를 남겼습니까?

두 workload의 semantics·성능·failure domain·복구를 비교한 decision table과 시험 명령을 제시하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. 성능·backup·restore 검증의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. 성능·backup·restore 검증의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. 성능·backup·restore 검증의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
성능·backup·restore 검증 실습 환경과 안전 경계
하드웨어NVMe·NFS·Ceph/S3 fixture
소프트웨어Ubuntu 24.04·fio 3.x·Ceph client·AWS CLI
필요 권한격리 dataset과 read-only production inventory
네트워크storage lab 203.0.113.0/24

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: fio 3.x · Ceph 18.x fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장시험 계약에서 확인을 시작합니다
  2. 2장성능 측정의 실습 대상을 고정합니다
  3. 3장격리 restore의 출력과 의미를 구분합니다
  4. 4장RPO·RTO의 진행과 중단을 결정합니다
  5. 5장성능·backup·restore 검증의 복구를 재검증합니다
성능·backup·restore 검증의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · 시험 계약에서 확인을 시작합니다

다음 연결: 성능 측정의 실습 대상을 고정합니다

  1. 시험 계약에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. 성능 측정의 실습 대상을 고정합니다

    실습 상황:: 제공된 4KiB random-read와 checkpoint sequential-write 결과, restore log로 SLO 통과 여부를 판정합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 대상 path 미확정·checksum 불일치 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. 격리 restore의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 명시된 workload의 tail latency와 복원된 artifact의 무결성이 목표 안인지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. RPO·RTO의 진행과 중단을 결정합니다

    재현 가능한 fio job, 원시 JSON, restore 시작/완료 시각, checksum과 application 검증으로 RPO/RTO를 계산하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. 성능·backup·restore 검증의 복구를 재검증합니다

    성능 미달이면 client·network·server·media 계층을 분리해 한 변수씩 재시험합니다. restore checksum이 다르면 승인을 중단하고 원본 snapshot과 transfer log부터 보존합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

성능 조건과 실제 restore를 하나의 승인 증거로 묶습니다

RPO·RTO(복구 시점·시간 목표): 허용 데이터 손실 구간과 서비스 복구까지 허용하는 시간을 각각 정하는 목표입니다.

storage 성능 수치는 block size, read/write 비율, queue depth, file 수, client 수, cache와 측정 시간 없이는 재현할 수 없습니다. backup 성공은 Recovery Point Objective(RPO)와 Recovery Time Objective(RTO)를 만족한 restore 성공과 다릅니다.

성능 시험은 workload model과 동일한 조건을 만들어 distribution과 error를 측정합니다. 복구 시험은 격리 위치에 data를 되살리고 checksum·metadata·application open을 검증한 뒤 소요 시간과 손실 지점을 계산합니다.

fio의 direct=1 결과를 모든 application 성능으로 일반화하지 않습니다. destructive write test는 명시된 test file 또는 전용 device에서만 실행합니다.

교육 사례에서 마지막 검증 backup은 09:45이고 장애는 10:00에 발생했습니다. 복구가 10:40에 끝났다면 검증 가능한 손실 구간은 15분, 장애부터 복구까지는 40분입니다. backup 파일을 푸는 데 걸린 시간만으로 서비스 RTO를 계산하면 권한·application 검증 시간을 빠뜨립니다. 복구 종료 시각은 사용자가 필요한 기능을 다시 수행할 수 있는 시점으로 정합니다.

시험 조건 고정, 성능 분포 측정, 격리 restore, RPO·RTO 판정의 네 단계를 통과 기준과 건너뛰었을 때 깨지는 것으로 나눠 적은 표입니다.
그림 읽는 법 성능 조건과 실제 restore를 하나의 승인 증거로 묶습니다. 표는 네 줄이고 왼쪽 배지 1에서 4까지가 순서입니다. 첫째 칸이 단계, 둘째 칸이 그 단계에서 고정하는 값, 셋째 칸이 무엇을 보아야 통과인가, 넷째 칸이 건너뛰었을 때 깨지는 것입니다. 판정에 쓰는 값은 셋째 칸에 있습니다. bw_bytes 3250000000, P99 31000000 ns, sha256sum 두 줄 일치, RPO 15분과 RTO 40분입니다. 마지막 초록 상자는 승인에 필요한 네 가지 증거를 한 묶음으로 묶고, 그 아래 회색 두 줄은 값의 성격과 성능 미달 시 재시험 방법을 적었습니다. 표 안의 경로·수치·시각은 교육용 재현 예시이며 실제 장비에서 측정한 값이 아닙니다. 대상 path가 미확정이거나 checksum이 불일치하면 다음 변경으로 넘어가지 않습니다. 자료: fio documentation · Amazon S3 User Guide · K3s Backup and Restore를 바탕으로 저자 구성.
왜 이런가
성능 시험은 workload model과 동일한 조건을 만들어 distribution과 error를 측정합니다. 복구 시험은 격리 위치에 data를 되살리고 checksum·metadata·application open을 검증한 뒤 소요 시간과 손실 지점을 계산합니다.
언제 문제가 되는가
대상 path 미확정·checksum 불일치 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
filename을 잘못 지정한 write benchmark는 실제 data를 파괴합니다. `/lab/fio` 소유권·quota·빈 공간을 확인하고 production mount를 제외합니다.
직접 확인하는 방법
시험 file/path·size·runtime·rw·bs·iodepth·client 수를 고정합니다. IOPS·bandwidth와 P95/P99 latency, error를 함께 기록합니다.
이 절을 정리하면재현 가능한 fio job, 원시 JSON, restore 시작/완료 시각, checksum과 application 검증으로 RPO/RTO를 계산하면 성공입니다.

CHAPTER 1 / 5

시험 계약에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. 시험 file/path·size·runtime·rw·bs·iodepth·client 수를 고정합니다. 2. IOPS·bandwidth와 P95/P99 latency, error를 함께 기록합니다. 3. backup snapshot과 catalog의 시각·revision·retention을 확인합니다. 4. 격리 restore 후 checksum·permission·application load와 시간을 측정합니다.

CHAPTER 2 / 5

성능 측정의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
fio --name=checkpoint --ioengine=libaio --filename=/lab/fio/checkpoint.bin --size=8G --rw=write --bs=4M --iodepth=16 --direct=1 --runtime=60 --time_based --group_reporting --output-format=json
sha256sum /backup/model-a.bin /restore-test/model-a.bin

CHAPTER 3 / 5

격리 restore의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
"write" : { "bw_bytes" : 3250000000, "clat_ns" : { "percentile" : { "99.000000" : 31000000 }}}
<same-hash>  /backup/model-a.bin
<same-hash>  /restore-test/model-a.bin

CHAPTER 4 / 5

RPO·RTO의 진행과 중단을 결정합니다

CHAPTER 5 / 5

성능·backup·restore 검증의 복구를 재검증합니다

CONCRETE CASES

제공된 4KiB random-read와 checkpoint sequential-write 결과, restore log로 SLO 통과 여부를 판정합니다.

fio의 direct=1 결과를 모든 application 성능으로 일반화하지 않습니다. destructive write test는 명시된 test file 또는 전용 device에서만 실행합니다.

잘못된 대응과 확인할 경계

filename을 잘못 지정한 write benchmark는 실제 data를 파괴합니다. `/lab/fio` 소유권·quota·빈 공간을 확인하고 production mount를 제외합니다.

성능 미달이면 client·network·server·media 계층을 분리해 한 변수씩 재시험합니다. restore checksum이 다르면 승인을 중단하고 원본 snapshot과 transfer log부터 보존합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: 제공된 4KiB random-read와 checkpoint sequential-write 결과, restore log로 SLO 통과 여부를 판정합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 대상 path 미확정·checksum 불일치 조건이 보이면 다음 변경으로 넘어가지 마십시오.

"write" : { "bw_bytes" : 3250000000, "clat_ns" : { "percentile" : { "99.000000" : 31000000 }}}
<same-hash>  /backup/model-a.bin
<same-hash>  /restore-test/model-a.bin

값 자체를 외우는 것이 아니라 명시된 workload의 tail latency와 복원된 artifact의 무결성이 목표 안인지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

filename을 잘못 지정한 write benchmark는 실제 data를 파괴합니다. /lab/fio 소유권·quota·빈 공간을 확인하고 production mount를 제외합니다.

KEY TERMS

이번 단원 핵심 용어

RPO·RTO(복구 시점·시간 목표)
허용 데이터 손실 구간과 서비스 복구까지 허용하는 시간을 각각 정하는 목표입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

성능·backup·restore 검증의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

DECISION ACTIVITY

checkpoint 저장 시간이 두 배가 됐지만 평균 throughput은 같습니다. 다음 증거는?

먼저 필요한 증거와 중단 기준을 적은 뒤 판단을 선택하십시오.

답 선택

THREE-LEVEL ASSESSMENT

기본 원리에서 운영 판단까지

답을 제출하면 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

기본 문제 1

작은 파일 dataset에서 중요한 지표는?

답 선택
적용 문제 2

object storage를 POSIX filesystem처럼 쓰기 전에 확인할 것은?

답 선택
종합 문제 3

backup 성공 job만으로 복구를 승인할 수 없는 이유는?

답 선택

LEARNING RECORD

본문·판단 활동·모든 해설을 확인했나요?

완료 기록은 이 브라우저에만 저장됩니다.