안녕하세요, AI 서비스 & 솔루션 프로바이더 베스핀글로벌입니다.
AWS re:Invent 2025의 [Deep dive on Amazon S3]을 확인해보시기 바랍니다.

Overview of monitoring in Amazon RDS

Amazon RDS는 크게 세 가지 레벨에서 모니터링을 합니다.

1. 개요 및 설계 목표

Amazon S3는 500조 개 이상의 객체와 수백 엑사바이트의 데이터를 처리하는 방대한 규모의 스토리지 서비스입니다. S3의 핵심 설계 목표는 99.99%의 가용성과 11, 9s(9가 11개)의 내구성을 달성하는 것입니다. 이 세션은 이 목표를 달성하기 위해 시스템 아키텍처 레벨과 서버 구현 레벨에서 장애(Failure)에 어떻게 대비하는지를 설명합니다. 장애는 영구적인 부품 손실부터 전원 문제나 네트워크 오버로드로 인한 일시적 사용 불가(Transient Unavailability)까지 다양합니다

2. 시스템 레벨 가용성 및 일관성 확보

2-1. 쿼럼 기반 메타데이터 인덱스 (Quorum-Based Index)

S3의 인덱싱 서브시스템은 모든 객체의 메타데이터(이름, 태그 등)를 저장하며, 모든 데이터 요청(GET, PUT, LIST, HEAD, DELETE)의 핵심입니다.

• 설계 원칙: 메타데이터는 쿼럼 기반 알고리즘을 사용하여 여러 AZ(Availability Zone)에 걸쳐 복제되어 저장됩니다.
• 장애 허용 (Failure Allowance): 읽기 및 쓰기는 과반수(majority)의 서버 응답만 성공하면 완료됩니다. 이를 통해 단일 디스크, 서버, 랙, 또는 AZ 장애가 발생해도 서비스의 가용성에는 영향이 없습니다.

2-2. 강력한 쓰기 후 읽기 일관성 확보 (Strong Read-After-Write Consistency)

2020년 이전 S3는 일관성이 보장되지 않았습니다. 이는 프론트엔드 캐싱 레이어에서 읽기/쓰기가 겹치지 않아 최신 쓰기가 반영되지 않은 이전 값을 읽는 문제가 발생했기 때문입니다. 일관성을 위해 다음 메커니즘이 도입되었습니다.

• 복제된 저널 (Replicated Journal): 쓰기 요청이 노드들을 순차적으로(sequentially) 흐르는 분산 데이터 구조입니다. 이를 통해 시스템 내 모든 쓰기(mutation)에 명확한 순서(Well-Defined Ordering)를 부여하고 순서 번호(Sequence Number)를 할당합니다.
• 증인 시스템 (Witness System): 저널 옆에 위치한 인메모리 데이터 구조로, 캐시 노드가 가진 순서 번호보다 더 높은 순서 번호의 쓰기가 있었는지(즉, 캐시 값이 오래되었는지) 추적하여 캐시 일관성(Cache Coherency)을 유지합니다. 읽기/쓰기는 이 증인을 통해 겹치도록(overlap) 설계됩니다.
• 동적 재구성 (Dynamic Reconfiguration): 저널은 순차적 처리 방식의 특성상 단일 노드 장애 시 전체가 중단될 수 있습니다. 이를 막기 위해 저널 노드들은 서로의 가용성을 확인하고, 장애 발생 시 쿼럼 기반 구성 시스템에 요청하여 즉시 저널을 재구성함으로써 가용성을 확보합니다.

3. 서버 레벨의 장애 유형과 대응 전략

S3 엔지니어링팀은 개별 노드 자체의 장애에 대비합니다.

3-1. 상관 관계 장애 (Correlated Failures) 대비

• 유형: 하드 드라이브 고장, 서버 고장(연결된 모든 드라이브), 랙 정전, AZ 전체 장애(물리적), 또는 특정 소프트웨어 버전의 버그(논리적)처럼, 여러 컴포넌트가 동시에 실패하는 장애를 말합니다.
• 대응: 객체 데이터를 여러 AZ와 랙 등 다수의 장애 도메인에 복제(Replication)하여, 하나의 장애 도메인이 실패해도 데이터의 가용성은 보존되도록 합니다. 또한, AZ 간 링크 장애 시 우회 경로(Long Way Around)를 통해 가용성 문제를 지연 시간 문제(Latency Problem)로 전환하여 서비스 연속성을 유지합니다.

3-2. 상관 관계 장애 (Correlated Failures) 대비

• 회색 장애: 서버가 완전히 멈추지 않고, 일부 기능만 상실하거나(예: 다운스트림 통신 불가) 단순히 과부하(Overloaded)로 인해 느리게 응답하는 상태입니다.
• 재시도 및 타임아웃: 클라이언트 측 SDK는 회색 장애에 대응하기 위해 재시도(Retries) 및 타임아웃(Timeouts)을 사용합니다. 특히 AWS SDK는 단일 웹 서버의 문제를 피하기 위해 의도적으로 다른 IP 주소로 재시도합니다.

3-3. 혼잡 붕괴 (Congestive Collapse)

• 혼잡 붕괴 방지: 재시도는 작업 증폭을 유발하여 서버의 과부하를 심화시키고, 결국 클라이언트가 타임아웃한 쓸모없는 요청(Useless Work)만 처리하는 혼잡 붕괴(Congestive Collapse)라는 메타 안정성 상태에 빠질 수 있습니다. 
• 이를 방지하기 위해 LIFO(Last In, First Out) 큐 처리: 큐가 가득 찼을 때 후입선출 방식으로 처리하여 최근 요청부터 성공시켜 혼잡에서 벗어날 공간을 마련합니다.
• 또한 지연 재시도 (Backoff and Retry): 클라이언트가 실패 후 즉시 재시도하지 않고 시간 간격을 두어 서버가 백로그를 처리할 시간을 제공합니다.

4. Self-healing Systems(자가 치유 시스템)

S3는 운영자가 수동으로 개입하지 않고 시스템이 스스로 장애를 감지하고 자가 치유(Self-healing)하도록 설계되었습니다.

4-1. 상관 관계 장애 (Correlated Failures) 대비

• 헬스 체크 (Health Checks): 별도의 서버가 주기적으로 웹 서버의 기능성을 확인하고, 불량 서버를 감지하면 DNS에서 제거하여 트래픽을 차단합니다.
• 핵심 원칙: “We never make local decisions about the health of a distributed system”
  "우리는 로컬 시스템이 서비스의 상태에 대해 로컬 결정을 내리는 것을 절대 허용하지 않는다"  
  전체 시스템의 가용성을 유지하기 위한 매우 중요한 요소입니다.
• 글로벌 방어: 단일 헬스 체크 서버의 오작동(모든 서버를 불량으로 오진) 위험을 막기 위해, S3는 동일 리전, 다른 리전, 공용 인터넷 등 다중 관점에서 오는 헬스 체크 신호를 결합하여 서버 상태의 전체적인 시각(Holistic View)을 형성합니다.

5. 총평

본 세션은 Amazon S3가 극한의 규모와 엄격한 SLA를 만족시키기 위해 가용성과 일관성을 어떻게 구조적으로 설계했는지 심도 있게 보여줍니다. 단순한 장애 복구를 넘어 쿼럼, 저널, 동적 재구성 같은 고급 분산 시스템 개념을 적용하여 일관성 문제를 해결하고, 회색 장애나 혼잡 붕괴 등 복잡한 장애 모드까지 예측하고 대응하는 치밀함이 돋보입니다. 특히, 시스템의 자가 치유 능력과 글로벌 관점의 통제(Global Rate Limiter)를 강조하며 로컬 의사결정의 위험성을 경계하는 접근 방식은 대규모 분산 시스템 설계의 모범 사례를 제시합니다.