Azure 신뢰성·복원력·복구 가능성 차이와 설계 가이드

Introduction: why this matters

많은 사후(incident) 리뷰에서 팀은 ‘잘못된 것’을 최적화했음을 뒤늦게 발견하곤 합니다. 예를 들어 애플리케이션에는 더 나은 장애 격리(fault isolation)가 필요했는데 재해 복구(disaster recovery) 런북에 과도하게 투자했거나, “중복(redundant)” 인프라가 자동으로 신뢰할 수 있는 사용자 경험을 만든다고 가정하는 경우가 그렇습니다. Microsoft의 최신 가이드는 Azure에서 reliability, resiliency, recoverability를 명확히 구분하고, 가정이 아니라 **설계(by design)**로 연속성(continuity)을 구축하는 방법을 제시합니다.

Key concepts (and the anchor principle)

Microsoft는 이를 서로 구분되는 동시에 상호 보완적인 개념으로 설명합니다:

• Reliability: 정의된 비즈니스 제약 내에서, 서비스/워크로드가 의도된 서비스 수준을 일관되게 수행하는 정도. 고객이 최종적으로 체감하는 목표(결과)입니다.
• Resiliency: 장애와 중단을 견뎌내고(가용 영역/지역 장애, 인프라 장애, 사이버 공격, 부하 급증) 고객에게 보이는 영향 없이 계속 운영할 수 있는 능력.
• Recoverability: 복원력의 한계를 초과하는 중단이 발생했을 때 정상 운영을 복구할 수 있는 능력.

Anchor principle: Reliability가 목표입니다. Resiliency는 중단 중에도 운영을 지속하게 합니다. Recoverability는 중단이 설계 한계를 초과했을 때 서비스를 복원합니다.

What’s new / what Microsoft is emphasizing

1) Align operating model with architecture

이 글은 조직의 의도를 기술 설계와 연결합니다:

• **Microsoft Cloud Adoption Framework (CAF)**는 거버넌스, 책임, 연속성 기대치를 정의하는 데 도움을 줍니다.
• **Azure Well-Architected Framework (WAF)**는 이러한 기대치를 아키텍처 패턴과 트레이드오프로 구체화합니다.

2) Make reliability measurable and operational

신뢰성은 지속적으로 입증할 수 있을 때만 의미가 있습니다:

• 핵심 사용자 플로우에 대한 허용 가능한 서비스 수준을 정의합니다.
• Azure Monitor와 Application Insights로 정상 상태(steady-state)와 고객 경험을 계측(instrument)합니다.
• 통제된 장애 테스트로 가정을 검증합니다(예: Azure Chaos Studio).
• Azure Policy, Azure landing zones, Azure Verified Modules로 거버넌스를 확장합니다.
• Reliability Maturity Model을 사용해 신뢰성 실천의 일관성을 평가합니다.

3) Treat resiliency as a lifecycle (not a checklist)

복원력은 체크리스트가 아니라 지속적인 실천으로 제시됩니다:

• Start resilient (설계 단계 패턴, secure-by-default 구성, 플랫폼 보호)
• Get resilient (기존 앱 평가, 미션 크리티컬 워크로드 우선순위화, 격차 해소)
• Stay resilient (모니터링, 드리프트 감지, 지속적 검증)

4) Shift to application-centric resiliency posture

Microsoft는 사용자가 경험하는 것은 VM/디스크 이벤트가 아니라 애플리케이션 중단이라는 점을 강조합니다. Azure의 zone resiliency experience는 리소스를 논리적 애플리케이션 서비스 그룹으로 묶고, 위험을 평가하며, 드리프트를 추적하고, 비용 가시성과 함께 개선(remediation)을 안내하는 기능을 지원합니다.

Impact for IT administrators and platform teams

• 더 명확한 공유 책임 경계: Azure Reliability 가이드를 통해 서비스에 내장된 동작과 사용자가 구성해야 하는 항목이 명확해집니다.
• 더 나은 설계 의사결정: 가용 영역/멀티 리전 설계(복원력)에 투자해야 하는 경우와 백업/페일오버 프로세스(복구 가능성)에 투자해야 하는 경우를 구분할 수 있습니다.
• 향상된 장애 대응 준비도: 측정 가능한 SLO, 관측 가능성(observability), 카오스 드릴을 통해 실제 장애 시 “알 수 없는 위험(unknown unknowns)”을 줄일 수 있습니다.

Action items / next steps

1. 팀 전반에서 용어(reliability vs. resiliency vs. recoverability)를 기준화하고, 이에 맞춰 아키텍처 표준을 업데이트합니다.
2. 운영 중인 핵심 서비스별로 Azure Reliability guides를 검토하여 장애 동작과 구성 요구사항을 확인합니다.
3. 장애 도메인과 비즈니스 영향도를 기준으로 워크로드를 zonal, zone-resilient, 또는 multi-region 패턴에 매핑합니다.
4. SLOs + monitoring(Azure Monitor/Application Insights)을 구현하고 fault injection drills(Chaos Studio)을 일정화합니다.
5. Policy/landing zones를 사용해 구성 드리프트를 방지하고, 대규모로 복원력 통제를 표준화합니다.