Ceph 이레이저 코딩 아키텍처: 저장·조회 흐름, 메타데이터, 그리고 CRUSH

Ceph에서 이레이저 코딩(EC)은 복제(replication)보다 적은 공간으로 내구성을 확보하려는 선택지입니다. 그런데 EC 풀을 안정적으로 운영하는 데 필요한 지식은 인코딩 수식이 아니라, 데이터가 어디에 놓이고(CRUSH), 어떻게 쓰이고 읽히며(I/O 경로), 그 매핑을 누가 기억하는지(메타데이터)입니다. 이 글은 EC 데이터의 수명주기를 배치, 쓰기, 읽기, 메타데이터 순서로 따라가며 운영 관점에서 정리합니다.

배치의 기초: CRUSH

CRUSH(Controlled Replication Under Scalable Hashing)는 "객체를 어디에 저장할지"를 중앙 테이블 없이 결정하는 Ceph의 핵심 알고리즘입니다. EC의 쓰기와 읽기 경로를 이해하려면 이 배치 계층부터 봐야 합니다.

동작은 다음 순서로 이루어집니다.

1. 객체/PG를 해시합니다.
2. CRUSH map과 rule을 적용합니다.
3. 호스트/랙/존으로 이루어진 계층 구조에서 대상 OSD를 선택합니다.
4. 클라이언트와 OSD가 동일한 계산으로 동일한 결과를 얻습니다.

중앙 조회가 없기 때문에 세 가지 장점이 생깁니다.

• 결정론적 배치: 같은 입력이면 같은 결과가 나오므로, 위치를 물어볼 중앙 서버가 필요 없습니다.
• 확장성: 배치 계산이 각 참여자에게 분산되므로 대규모 확장에 유리합니다.
• 실패 도메인 인식: 호스트/랙/존 단위로 데이터를 흩뿌리는 정책을 표현할 수 있습니다.

주의할 점은 CRUSH가 단순한 해시 함수가 아니라 배치 정책 엔진이라는 것입니다. CRUSH map 설계가 잘못되면 복제 풀과 EC 풀 모두 취약해집니다. 하드웨어 추가·제거 시 rebalance 영향 범위를 예측해야 하고, rule 변경은 사용자 트래픽과 recovery 부하를 함께 고려해 점진적으로 적용해야 합니다.

쓰기 경로: 분할, 인코딩, 쿼럼

CRUSH라는 배치 기반 위에서, EC 쓰기는 "객체를 분할하고, 인코딩하고, 실패 도메인을 고려해 배치하는 과정"입니다.

1. 객체를 PG(Placement Group)에 매핑합니다.
2. 해당 PG의 primary OSD가 쓰기를 수신합니다.
3. 데이터를 k개의 데이터 조각과 m개의 패리티 조각으로 인코딩합니다.
4. CRUSH 규칙에 따라 조각들을 서로 다른 실패 도메인의 OSD에 배치합니다.
5. 쓰기 쿼럼이 충족되면 성공을 응답합니다.

여기서 k/m 비율은 저장 효율과 복구 비용 사이의 균형점입니다. 대규모 워크로드라면 읽기 패턴까지 함께 고려해 결정해야 합니다. 또 하나 기억할 점은 EC가 작은 random write에서 비용이 크다는 것입니다. 워크로드 특성에 따라 replicated pool을 병행하는 구성이 필요할 수 있습니다.

결국 EC 저장 경로는 단순한 공간 절감 기능이 아니라 가용성 정책입니다. k/m, CRUSH 규칙, 워크로드 특성을 분리해서 설계해야 합니다.

읽기 경로: 정상 읽기와 degraded read

EC 읽기는 정상 경로와 복구 경로를 구분해 이해해야 합니다.

정상 읽기는 단순합니다. 필요한 데이터 조각이 모두 살아 있으면 조합해서 바로 응답합니다.

문제는 일부 조각이 없을 때의 degraded read입니다.

1. 최소 복구 조합을 선택합니다.
2. 패리티를 포함한 추가 조각을 요청합니다.
3. 디코딩 연산을 수행합니다.
4. 원본을 재구성해 응답합니다.

이 경로에서는 지연과 네트워크 비용이 크게 증가합니다. 그래서 EC 읽기 성능은 평시 평균이 아니라 장애 시 최악 지연을 기준으로 봐야 하며, SLO 역시 degraded 상황 기준으로 설정하는 것이 안전합니다.

운영에서는 다음 세 가지를 챙깁니다.

1. 디스크 장애 시 degraded read 비율을 별도로 모니터링합니다.
2. 복구 작업(backfill/recovery)과 사용자 읽기 사이의 자원 경쟁을 제어합니다.
3. 핫 오브젝트는 읽기 패턴에 맞게 계층·풀 전략을 분리합니다.

메타데이터: 제어면의 신뢰성

EC 운영에서 실제로 어려운 부분은 인코딩이 아니라 메타데이터 일관성입니다. 조각이 어떤 규칙으로 어디에 흩어져 있는지에 대한 기록이 곧 복구 가능성이기 때문입니다.

핵심 메타데이터는 네 가지입니다.

1. EC 프로파일(k, m, 인코딩 알고리즘)
2. CRUSH 규칙과 실패 도메인 정의
3. 객체-청크 매핑 정보
4. PG/OSD 상태 로그

데이터 조각이 물리적으로 살아 있어도 매핑 정보가 깨지면 복구가 어려워집니다. 클러스터 확장이나 장비 교체 시 규칙 변경이 기존 데이터 배치에 영향을 준다는 점도 위험 요소입니다.

운영 원칙은 다음과 같습니다.

1. 프로파일과 CRUSH 변경은 변경 이력과 함께 관리합니다.
2. 장애 복구 플레이북에 메타데이터 검증 절차를 포함합니다.
3. 스크럽/딥스크럽 결과를 메타데이터 오류와 연결해 분석합니다.
4. 버전 불일치를 감지하면 자동 조치보다 격리를 우선합니다.

EC 메타데이터는 제어면(control plane)의 핵심 자산입니다. 데이터 복구 계획보다 먼저 메타데이터 신뢰성을 보장해야 합니다.

통합 운영 체크리스트

네 개 영역을 관통하는 점검 항목을 하나로 모으면 다음과 같습니다.

• k/m 트레이드오프: 저장 효율을 올릴수록 복구 시 읽어야 할 조각과 디코딩 비용이 커집니다. 읽기 패턴과 복구 비용을 함께 놓고 결정합니다.
• 실패 도메인 설계: host/rack 단위 분산이 잘못되면 장애 한 번에 복구 가능성을 잃습니다. CRUSH map이 실제 토폴로지와 실패 모델을 반영하는지 검증합니다.
• small write 비용: 작은 random write가 많은 워크로드는 EC 단독보다 replicated pool 병행을 검토합니다.
• rebalance 영향: 증설·교체·rule 변경 전에 recovery 부하와 사용자 트래픽의 경쟁을 계획하고 점진 적용합니다.
• SLO 기준: 평시 평균이 아니라 degraded read 상황의 최악 지연을 기준으로 잡습니다.
• 메타데이터 우선: 프로파일, 객체-청크 매핑, 상태 로그의 신뢰성 확보가 데이터 복구 계획보다 먼저입니다.

정리

• CRUSH는 중앙 테이블 없는 결정론적 배치 엔진이며, 인프라 토폴로지와 실패 모델을 정확히 반영해야 기대한 내구성이 나옵니다.
• 쓰기 경로는 객체→PG 매핑, k+m 인코딩, 실패 도메인 분산, 쿼럼 응답으로 이루어집니다.
• 읽기 경로는 정상 읽기와 degraded read로 나뉘며, SLO는 장애 시 최악 지연을 기준으로 세웁니다.
• EC의 성패는 인코딩 알고리즘이 아니라 메타데이터 일관성과 운영 규율, 즉 제어면의 신뢰성에서 갈립니다.