신뢰성

신뢰성(Reliability) 기둥은 “장애가 발생해도 예상한 대로 시스템이 동작하고, 수요 변화에 맞춰 컴퓨팅 리소스를 동적으로 확보할 수 있는 능력"을 다룹니다. 핵심 전제는 “장애는 반드시 일어난다"는 것이고, 따라서 장애를 막는 것보다 장애로부터 빠르게 회복하는 능력을 설계하는 것이 더 중요합니다.

장애 복구 자동화

사람이 장애를 발견하고 수동으로 조치하는 것보다, 시스템이 스스로 감지하고 복구하는 구조가 훨씬 빠르고 안정적입니다.

• Auto Scaling Group의 헬스 체크: 비정상 인스턴스를 자동으로 종료하고 새 인스턴스로 교체
• ALB/NLB의 헬스 체크: 비정상 타겟으로는 트래픽을 라우팅하지 않고 자동 제외
• RDS Multi-AZ: 프라이머리 DB 장애 시 자동으로 스탠바이로 페일오버 (보통 1~2분 이내)
• Route 53 헬스 체크 + 페일오버 라우팅: 엔드포인트 장애 감지 시 DNS 차원에서 대체 엔드포인트로 전환

수평적 확장과 용량 관리

단일 대형 서버를 더 강력하게 만드는 수직적 확장(Scale Up)은 한계가 있고 단일 장애점이 됩니다. 동일한 역할을 하는 여러 인스턴스를 늘리는 수평적 확장(Scale Out)이 신뢰성과 확장성 모두에 유리합니다.

• 상태를 인스턴스에 저장하지 않는 Stateless 설계 — 세션 정보는 ElastiCache나 DynamoDB로 외부화
• Auto Scaling으로 트래픽에 따라 인스턴스 수를 동적으로 조절, 갑작스러운 트래픽 증가에도 대응
• 용량 계획 시 단일 인스턴스의 한계가 아니라 “최대 몇 대까지 확장 가능한가"를 기준으로 설계

Multi-AZ와 Multi-Region 복원력

가용 영역(AZ) 하나가 통째로 장애를 일으키는 경우를 대비해, 최소한 2개 이상의 AZ에 리소스를 분산하는 것이 AWS 아키텍처의 기본 전제입니다. 더 높은 복원력이 필요하면 Multi-Region으로 확장합니다.

• Multi-AZ: 같은 리전 내 여러 데이터센터에 복제. 대부분의 워크로드에 충분한 복원력 제공
• Multi-Region: 리전 전체 장애(드물지만 발생 가능)에도 대응. 비용과 복잡성이 크게 증가하므로 실제 비즈니스 요구사항(RTO/RPO)에 따라 신중히 결정