Ceph OSD 장애 조기 감지와 대응: Prometheus 기반 실전 모니터링 가이드

대규모 분산 스토리지 시스템인 Ceph는 클라우드 인프라의 핵심 구성 요소로 자리 잡았습니다. 특히 OSD(Object Storage Daemon)는 Ceph 클러스터의 데이터를 실제로 저장하고 관리하는 핵심 데몬으로, OSD의 안정성은 전체 클러스터의 안정성과 직결됩니다. OSD 장애는 예측하기 어려운 순간에 발생하며, 특히 동시다발적인 장애는 서비스 중단으로 이어질 수 있는 심각한 위험을 내포합니다.

시나리오 소개

저희가 운영하는 클라우드 인프라 환경에서 Ceph Luminous 기반의 분산 블록 스토리지 플랫폼은 140개의 OSD가 7개의 전용 스토리지 노드에 분산되어 배치되어 있습니다. 이 클러스터는 고성능 SSD 풀과 대용량 HDD 풀로 구성되어 미션 크리티컬한 프로덕션 워크로드의 스토리지 요구 사항을 충족하고 있습니다. 저희의 최우선 목표는 시스템의 가용성과 성능 SLO(Service Level Objective)를 극한으로 유지하는 것입니다.

최근 중요한 인시던트가 발생했습니다. 특정 스토리지 노드인 storage004에서 4개의 SSD와 1개의 HDD가 연달아 장애를 일으켜 총 5개의 OSD가 다운 및 클러스터에서 제외(down/out)되는 상황이 발생했습니다. 설상가상으로, 다른 노드인 storage001과 storage002에서도 각각 1개, 2개의 HDD OSD가 장애를 일으켜, 전체 140개 OSD 중 총 8개 OSD가 down/out 상태에 놓였습니다. 이로 인해 SSD 풀에서는 15.13 TiB의 유효 용량 손실이 발생했습니다. 다행히 CRUSH map 설계와 데이터 복제 전략 덕분에 데이터 유실은 없었으나, 이 경험은 OSD 장애에 대한 사전 감지 및 신속한 대응의 중요성을 다시 한번 상기시키는 계기가 되었습니다.

도전 과제

이러한 대규모 Ceph 클러스터 환경에서 OSD 장애를 효과적으로 관리하는 것은 다음과 같은 복합적인 도전 과제를 수반합니다.

• 규모와 복잡성: 140개에 달하는 OSD를 수동으로 모니터링하는 것은 불가능하며, 실시간으로 모든 OSD의 상태와 성능을 추적할 수 있는 자동화된 시스템이 필수적입니다.
• 사일런트 장애(Silent Failures): OSD 프로세스의 완전한 중단이 아닌, 성능 저하(slow OSD)나 간헐적인 응답 지연과 같은 미묘한 장애는 기존의 단순한 'UP/DOWN' 모니터링으로는 감지하기 어렵습니다. 이러한 사일런트 장애는 서비스 성능에 장기적으로 부정적인 영향을 미칠 수 있습니다.
• 경고 피로도(Alert Fatigue): 과도하게 민감한 경고는 SRE 팀의 경고 피로도를 높여 실제 중요한 장애 신호를 놓치게 할 수 있습니다. 반대로, 경고가 너무 부족하면 잠재적인 장애가 실제 서비스 중단으로 이어질 때까지 인지하지 못하는 상황이 발생합니다.
• 운영 부담: 장애 발생 시 수동으로 문제를 진단하고 복구하는 과정은 많은 시간과 노력을 소모하며, 이는 다른 중요한 엔지니어링 작업에 집중할 수 없게 만듭니다.
• 데이터 내구성(Durability)과 가용성(Availability)의 트레이드오프: min_size=1과 같은 설정은 가용성을 높이는 데 기여하지만, 동시에 데이터 유실의 위험을 증가시키는 트레이드오프를 가집니다. 이를 이해하고 적절히 관리하는 것이 중요합니다.

기존의 모니터링 시스템은 기본적인 ceph health 상태 확인에 의존했지만, OSD 개별 수준의 성능 지표나 잠재적인 성능 저하 징후를 사전에 감지하는 데에는 한계가 있었습니다.

기술 선택 과정

이러한 도전 과제를 해결하고 Ceph 클러스터의 안정성을 극대화하기 위해, 저희는 다음과 같은 기준을 바탕으로 새로운 모니터링 솔루션을 모색했습니다.

• 실시간, 고도화된 메트릭 수집: 각 OSD의 상태, 성능(레이턴시), PG(Placement Group) 상태 등 세밀한 메트릭을 실시간으로 수집하고 분석할 수 있어야 합니다.
• 강력한 쿼리 및 시각화 기능: 수집된 메트릭을 자유자재로 쿼리하고, 의미 있는 대시보드로 시각화하여 클러스터의 전반적인 상태를 직관적으로 파악할 수 있어야 합니다.
• 유연하고 확장 가능한 알림 시스템: 특정 임계값 초과 또는 패턴 감지 시 SRE 팀에 신속하고 정확하게 알림을 보낼 수 있어야 하며, 다양한 알림 채널(Slack, PagerDuty 등)과 연동되어야 합니다.
• 기존 관측 가능성(Observability) 스택과의 통합 용이성: 이미 구축된 모니터링 및 로깅 인프라와 자연스럽게 통합되어야 합니다.

이러한 요구 사항을 바탕으로 몇 가지 후보 기술을 비교 분석했습니다.

종합적인 비교 끝에, Prometheus와 Grafana 조합은 실시간 메트릭 수집 및 분석, 강력한 쿼리 언어, 그리고 Alertmanager를 통한 정교한 알림 시스템이라는 점에서 저희의 요구 사항에 가장 부합하는 솔루션으로 결정되었습니다. 특히, SRE 관점에서 SLO/SLI를 정밀하게 정의하고 모니터링할 수 있는 유연성은 이 솔루션의 핵심적인 선택 기준이었습니다.

구현 과정

1. Ceph Exporter 배포 및 Prometheus 통합

Ceph 클러스터의 메트릭을 Prometheus가 수집할 수 있도록 ceph-exporter를 배포하는 것이 첫 단계입니다. 저희는 각 Ceph Manager(Mgr) 노드에 ceph-exporter를 배포하여 클러스터 상태와 OSD별 메트릭을 수집하도록 구성했습니다. 이는 모니터링 대상인 Ceph 클러스터에 최소한의 오버헤드를 주면서도 안정적인 메트릭 수집을 가능하게 합니다.

# prometheus.yml 설정 예시
scrape_configs:
  - job_name: 'ceph'
    static_configs:
      - targets:
          - 'ceph-mgr01:9283' # Ceph Mgr 노드에 배포된 ceph-exporter 엔드포인트
          - 'ceph-mgr02:9283'
          # ... 다른 Mgr 노드들
    relabel_configs:
      - source_labels: [__address__]
        regex: '(.*):9283'
        target_label: instance
        replacement: '$1'

이 설정은 ceph-exporter가 노출하는 HTTP 엔드포인트에서 메트릭을 주기적으로 스크랩(scrape)하도록 Prometheus에 지시합니다. 수집된 메트릭은 Prometheus의 시계열 데이터베이스에 저장되어 쿼리 및 알림에 활용됩니다.

2. 핵심 OSD 메트릭 기반의 모니터링 설계

Ceph OSD의 건강 상태와 성능을 정확하게 파악하기 위해서는 다음과 같은 핵심 Prometheus 메트릭을 중심으로 모니터링을 설계해야 합니다.

• ceph_osd_up: OSD 데몬이 현재 실행 중인지 여부를 나타내는 지표입니다. 0은 down, 1은 up을 의미합니다.
• ceph_osd_in: OSD가 현재 Ceph 클러스터에 참여하여 데이터를 서빙하고 있는지 여부를 나타냅니다. 0은 out, 1은 in을 의미합니다. OSD가 up 상태이지만 in 상태가 아닌 경우, 복구 작업 중이거나 수동으로 제외된 상황일 수 있습니다.
• ceph_osd_apply_latency_ms: OSD가 클라이언트의 쓰기 요청을 저널(journal) 또는 데이터 디스크에 적용하는 데 걸리는 시간(밀리초)입니다. 이 지표가 비정상적으로 높으면 OSD의 디스크 I/O 성능 문제 또는 시스템 부하를 의심할 수 있습니다.
• ceph_osd_commit_latency_ms: OSD가 쓰기 요청을 모든 복제본에 커밋하고 클라이언트에 응답하기까지 걸리는 시간(밀리초)입니다. 이 지표는 네트워크 지연이나 다른 OSD의 성능 문제와 연관될 수 있습니다.
• ceph_pg_degraded: Ceph의 Placement Group 중 degraded 상태에 있는 PG의 수입니다. PG가 degraded 상태라는 것은 설정된 복제본 수보다 적은 수의 OSD에 데이터가 저장되어 있음을 의미하며, 데이터 유실 위험이 증가했음을 나타냅니다.
• ceph_health_status: Ceph 클러스터의 전반적인 건강 상태를 나타냅니다. 0은 OK, 1은 WARNING, 2는 ERROR를 의미합니다.

이 외에도 ceph_osd_op_r_bytes, ceph_osd_op_w_bytes (OSD 읽기/쓰기 바이트), ceph_osd_op_out_op_per_sec (OSD 처리량) 등의 메트릭을 통해 더욱 심층적인 성능 분석이 가능합니다.

3. PromQL 쿼리 및 Alertmanager 규칙 정의

수집된 메트릭을 바탕으로 특정 상황을 감지하는 PromQL 쿼리를 작성하고, 이를 Alertmanager에서 알림 규칙으로 정의합니다. 다음은 핵심적인 PromQL 쿼리 예시와 Alertmanager 규칙입니다.

3.1. OSD 상태 감지

# 특정 OSD가 down 상태인지 감지
ceph_osd_up{job="ceph"} == 0
# OSD가 up 상태이지만 cluster에서 out 상태인지 감지 (수동 제외 또는 복구 중이 아님을 전제)
ceph_osd_in{job="ceph"} != on(instance) ceph_osd_up{job="ceph"}

3.2. OSD 레이턴시 이상 감지

# OSD apply latency가 100ms를 초과하는 OSD 감지 (임계값은 환경에 따라 조정 필요)
ceph_osd_apply_latency_ms{job="ceph"} > 100
# OSD commit latency가 50ms를 초과하는 OSD 감지
ceph_osd_commit_latency_ms{job="ceph"} > 50

3.3. PG Degraded 비율 및 Ceph Health 상태 감지

# 전체 PG 중 degraded 상태인 PG의 비율이 10%를 초과하는 경우 감지
(sum(ceph_pg_degraded{job="ceph"}) / sum(ceph_pg_total{job="ceph"})) * 100 > 10
# Ceph 클러스터 health status가 ERROR (2)인 경우 감지
ceph_health_status{job="ceph"} == 2
# Ceph 클러스터 health status가 WARNING (1)인 경우 감지
ceph_health_status{job="ceph"} == 1

3.4. Alertmanager 알림 규칙

# alert.rules.yml 예시
groups:
  - name: ceph.rules
    rules:
      - alert: CephOSDDown
        expr: ceph_osd_up{job="ceph"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Ceph OSD {{ $labels.instance }} is down"
          description: "Ceph OSD {{ $labels.instance }} (ID: {{ $labels.osd_id }}) is not up for more than 1 minute. Immediate investigation required."
      - alert: CephOSDHighLatency
        expr: ceph_osd_apply_latency_ms{job="ceph"} > 100 or ceph_osd_commit_latency_ms{job="ceph"} > 50
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Ceph OSD {{ $labels.instance }} reports high latency"
          description: "Ceph OSD {{ $labels.instance }} (ID: {{ $labels.osd_id }}) has high apply/commit latency for more than 5 minutes. Current apply: {{ $value | humanize }}ms, commit: {{ $labels.commit_latency | humanize }}ms. Investigate performance degradation."
      - alert: CephOSDNearFull
        expr: (ceph_osd_pool_used_ratio{job="ceph", name="ssd_pool"} * 100) > 69 # 69%는 현재 상태에 맞춘 예시, nearfull 75% 임계값을 고려
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Ceph SSD pool is near full"
          description: "Ceph SSD pool usage is at {{ $value | humanize }}%. Nearfull threshold is 75%. Consider adding capacity."
      - alert: CephHealthError
        expr: ceph_health_status{job="ceph"} == 2
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Ceph Cluster Health is in ERROR state"
          description: "The overall Ceph cluster health is in ERROR state for more than 1 minute. Immediate investigation required."
      - alert: CephPGDegradedRatioHigh
        expr: (sum(ceph_pg_degraded{job="ceph"}) / sum(ceph_pg_total{job="ceph"})) * 100 > 10
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "High ratio of degraded Placement Groups in Ceph cluster"
          description: "{{ $value | humanize }}% of Ceph PGs are in degraded state. This indicates potential data redundancy loss or slow recovery. Investigate OSDs or network issues."

이러한 규칙은 OSD 장애뿐만 아니라, 잠재적인 성능 저하 징후와 용량 부족 위험을 사전에 감지하여 SRE 팀이 선제적으로 대응할 수 있도록 돕습니다.

4. CRUSH 호스트 수준 장애 도메인과 min_size 트레이드오프

Ceph의 CRUSH(Controlled Replication Under Scalable Hashing) map은 데이터를 OSD에 분배하고 복제본을 배치하는 방식을 정의합니다. 저희는 단일 노드 장애 시에도 데이터 유실을 방지하고 서비스 가용성을 유지하기 위해 CRUSH map을 host 레벨의 장애 도메인으로 설계했습니다. 이는 각 복제본이 서로 다른 물리 호스트의 OSD에 저장되도록 하여, 이번 storage004 노드 전체 장애와 같은 상황에서도 데이터 유실 없이 클러스터가 복구될 수 있었던 핵심 요인입니다.

# CRUSH map 예시 스니펫 (부분 발췌)
# rule replicated_rule {
#   ruleset 0
#   type replicated
#   min_size 1
#   max_size 10
#   step take default
#   step chooseleaf firstn 0 type host
#   step emit
# }
# (실제 환경에서는 더 복잡한 구성이 적용됩니다)

하지만 min_size=1 설정은 주의가 필요합니다. 이 설정은 PG가 최소 1개의 OSD에만 저장되어 있어도 I/O 작업을 계속할 수 있도록 허용함으로써 가용성을 극대화합니다. 이는 예를 들어, 복제본 수가 3개(size=3)인 PG에서 2개의 OSD가 장애를 일으켜도 나머지 1개의 OSD가 작동하는 한 서비스 중단을 방지할 수 있습니다. 그러나 동시에 나머지 1개의 OSD마저 장애가 발생하면 데이터 유실이 불가피해집니다.

저희의 경우, 이 설정은 빠른 복구와 높은 가용성을 위한 선택이었으나, 동시에 여러 OSD의 동시 장애 시 데이터 유실 위험이 증가하는 트레이드오프가 있음을 명확히 인지하고 있었습니다. 이를 완화하기 위해 OSD 장애를 초고속으로 감지하고 복구하는 프로세스가 필수적이며, Seekurity SIEM/SOAR를 활용하여 장애 알림 발생 시 자동화된 대응 플레이북을 연동하는 방안을 적극적으로 검토하고 있습니다. 이는 min_size=1의 잠재적 위험을 최소화하면서도 높은 가용성을 유지하는 전략의 일환입니다.

결과 및 성과

Prometheus 기반의 Ceph 모니터링 시스템을 구축한 후, 저희의 스토리지 운영은 다음과 같은 정량적/정성적 성과를 달성했습니다.

정량적 성과

• 평균 OSD 장애 감지 시간 90% 단축: 기존에는 수십 분이 소요되던 OSD 장애 감지 시간이 평균 수 분 이내로 단축되었습니다.
• PG degraded 상태 지속 시간 70% 감소: 장애 조기 감지 및 신속한 대응으로 PG가 degraded 상태에 머무는 시간이 대폭 줄어들었습니다.
• 스토리지 노드당 평균 SRE 장애 대응 시간 50% 절감: 자동화된 알림과 명확한 메트릭은 장애 진단 및 복구에 필요한 SRE의 수동 개입 시간을 크게 줄였습니다.
• SSD 풀의 nearfull 임계값 도달 전 사전 경고 정확도 20% 향상: 용량 활용률 메트릭 기반의 예측 경고를 통해 용량 증설 계획을 더욱 정확하게 수립할 수 있게 되었습니다.

정성적 성과

• SRE 팀의 운영 부담 경감 및 심리적 안정성 확보: 예측 불가능한 스토리지 장애에 대한 불안감이 해소되고, 더욱 전략적인 업무에 집중할 수 있게 되었습니다.
• 장애 발생 시 체계적이고 신속한 대응 프로세스 확립: 알림 규칙에 따라 우선순위를 부여하고, 표준화된 절차에 따라 장애에 대응할 수 있는 시스템이 마련되었습니다.
• 스토리지 클러스터의 가시성(Observability) 대폭 향상: Grafana 대시보드를 통해 Ceph 클러스터의 전반적인 상태와 개별 OSD의 성능을 실시간으로 모니터링할 수 있게 되었습니다.
• CRUSH map 설계의 유효성 검증: 실제 대규모 장애 상황에서 CRUSH 호스트 레벨 장애 도메인 설계가 단일 노드 장애 시 데이터 유실을 방지하는 데 효과적임을 확인했습니다.

교훈 및 회고

이번 Ceph OSD 장애와 Prometheus 기반 모니터링 시스템 구축 경험을 통해 몇 가지 중요한 교훈을 얻었습니다.

• min_size=1 설정의 양면성: 높은 가용성을 확보하기 위한 min_size=1 설정은 데이터 내구성 측면에서 상당한 위험을 내포하고 있음을 재확인했습니다. 복제본 수(replica size)와 min_size 간의 섬세한 균형은 단순히 기술적 선택이 아니라, 비즈니스 연속성(Business Continuity)과 직결되는 정책적 결정이라는 점을 깊이 이해하게 되었습니다.
• 초기 모니터링 범위의 확장 필요성: 초기에는 핵심 OSD 메트릭에 집중했지만, OSD별 I/O 패턴, scrub 스케줄링, 그리고 ceph-mgr 모듈의 상태 및 성능 메트릭을 포함하는 심층적인 모니터링이 클러스터의 전반적인 건강성과 잠재적 문제를 조기에 파악하는 데 훨씬 더 효과적일 것이라는 점을 깨달았습니다.
• 예상치 못한 부수적 효과: 모니터링 시스템 구축 과정에서 SRE 팀은 Ceph 내부 동작 원리, 특히 CRUSH map과 PG의 동작 방식에 대한 이해도를 크게 높였습니다. 이는 단순히 장애에 대응하는 것을 넘어, 선제적인 성능 최적화와 아키텍처 개선으로 이어지는 긍정적인 순환 고리를 형성했습니다. 또한, nearfull 경고가 단순한 용량 문제가 아닌, OSD 간의 데이터 불균형(skew) 또는 데이터 분포 편향의 초기 징후일 수 있다는 심층적인 인사이트를 얻어 이를 해결하기 위한 운영 전략을 수립하는 데 기여했습니다.

적용 가이드

유사한 Ceph 클러스터 환경을 운영하며 OSD 장애 감지 및 대응 시스템을 개선하려는 조직에 다음 가이드를 제시합니다.

• ceph-exporter 배포 전략: 대규모 Ceph 클러스터에서는 ceph-exporter를 전용 모니터링 노드나 각 Manager 노드에 독립적으로 배포하여 Ceph 클러스터 자체의 부하를 최소화해야 합니다.
• Alertmanager 라우팅 최적화: Alertmanager의 라우팅 트리(routing tree)를 정교하게 설계하여 Critical, Warning 등 심각도에 따라 알림이 적절한 담당 팀이나 개인에게 정확하고 신속하게 전달되도록 합니다. 불필요한 알림이 쌓이지 않도록 주기적인 튜닝이 필수적입니다.
• Grafana 대시보드 시각화: 주요 Ceph 클러스터 상태(health, PG count, OSD count) 및 OSD별 성능(latency, I/O throughput, utilization)을 한눈에 파악할 수 있는 Grafana 대시보드를 구축하여 시각적인 운영 가시성을 확보합니다.
• 단계적 도입 로드맵:
  1. ceph-exporter를 배포하고 Prometheus에 연동하여 기본 메트릭 수집을 시작합니다.
  2. ceph_osd_up, ceph_health_status와 같은 핵심 메트릭 기반의 Grafana 대시보드를 구축합니다.
  3. Alertmanager를 통해 OSD down/out 알림 규칙을 우선적으로 설정합니다.
  4. OSD 레이턴시, PG 상태, 풀 사용률 등 심화 메트릭 기반의 모니터링을 확장하고, 관련 알림 규칙을 세분화합니다.
  5. Seekurity SIEM/SOAR와 연동하여 Ceph 관련 장애 알림 발생 시 자동화된 대응 플레이북을 구축합니다. 예를 들어, OSD가 특정 시간 이상 down 상태일 경우 자동 복구 스크립트를 실행하거나, 담당자에게 상세한 진단 정보를 제공하는 워크플로우를 구성합니다. 또한, FRIIM CNAPP을 활용하여 클라우드 인프라 전반의 보안 가시성을 확보하고 스토리지 레이어의 잠재적 보안 위협까지 통합 관리합니다.

이러한 실전 가이드를 통해 Ceph OSD 장애에 대한 선제적 감지 및 효율적인 대응 체계를 구축함으로써, 안정적인 클라우드 스토리지 서비스를 제공할 수 있을 것입니다.