HA와 내결함성: 정의 및 절충점

고가용성(HA)과 장애 허용(FT)은 아키텍트가 자주 혼동하는 서로 다른 안정성 목표입니다. 고가용성은 시스템의 중단 시간을 최소화한다는 의미입니다. 장애를 견딜 수 있지만 복구 중 짧은 중단이 발생할 수 있습니다. 장애 허용은 구성 요소에 장애가 발생해도 완전히 이중화된 경로가 즉시 인계하므로 중단 없이 시스템이 계속 작동한다는 의미입니다.

가용성은 1년 동안 작동한 시간의 비율로 측정합니다. 99.9% 가용성(9가 3개)은 연간 약 8.7시간의 중단 시간을 의미하며, 99.99%(9가 4개)는 52.6분만 허용합니다. 99.999%(9가 5개)는 5.26분만 허용합니다. 일반적으로 9가 하나 추가될 때마다 더 많은 이중화, 자동화, 비용이 필요합니다. SAA-C03 시험에서는 주어진 가용성 목표를 충족하는 아키텍처를 식별하도록 자주 묻습니다.

고가용성 아키텍처는 한 구성 요소의 장애를 자동으로 감지하고 수초 또는 수분 내에 정상 대체 구성 요소로 전환하여 장애를 견딥니다. 예로는 RDS Multi-AZ(다른 AZ의 대기 인스턴스로 자동 장애 조치), Auto Scaling Groups(종료된 인스턴스 대체), Elastic Load Balancers(정상 상태가 아닌 대상에서 트래픽을 우회)가 있습니다. 짧은 중단은 발생하지만 수동 개입 없이 시스템이 복구됩니다.

장애 허용 아키텍처에는 활성 이중화가 있습니다. 즉, 동일한 여러 구성 요소가 동시에 요청을 처리하므로 하나에 장애가 발생하면 나머지가 즉시 부하를 흡수하여 중단 시간이 0이 됩니다. 예로는 여러 EC2 인스턴스를 사용하는 active-active ELB, 여러 리전에서 동시에 읽기와 쓰기를 처리하는 DynamoDB Global Tables, 여러 읽기 전용 복제본을 사용하는 Aurora가 있습니다. 장애 허용을 구현하려면 항상 더 많은 리소스를 실행해야 합니다.

장애 허용은 항상 완전히 프로비저닝된 이중화 용량이 필요하므로 고가용성보다 훨씬 비쌉니다. 고가용성 RDS Multi-AZ 인스턴스는 장애가 발생할 때만 활성화되는 대기 인스턴스를 위해 데이터베이스 비용이 두 배로 듭니다. 장애 허용 다중 리전 active-active Aurora 배포는 비용이 네 배까지 증가할 수 있지만 리전 장애 중에도 모든 중단 시간을 제거합니다. 아키텍트는 이중화 비용과 중단으로 인해 발생하는 비즈니스 비용 사이에서 균형을 맞춰야 합니다.

복구 시간 목표(RTO)는 시스템을 사용할 수 없어도 허용되는 최대 시간입니다. 고가용성 아키텍처는 자동 장애 조치를 통해 일반적으로 수분 수준의 낮은 RTO를 목표로 합니다. 장애 허용 아키텍처는 거의 0에 가까운 RTO를 목표로 합니다. HA를 설계할 때는 RTO 예산 내에 복구가 보장되도록 서비스와 구성을 선택해야 합니다. 예를 들어 RDS Multi-AZ는 대략 60~120초의 RTO를 제공하므로 많은 HA 요구 사항에 적합합니다.

단일 장애 지점(SPOF)은 장애가 발생하면 전체 시스템이 중단되는 구성 요소입니다. 일반적인 SPOF로는 ASG가 없는 단일 EC2 인스턴스, 단일 AZ RDS 데이터베이스, 단일 NAT gateway, 단일 가용 영역이 있습니다. SPOF를 제거하는 것은 HA와 FT를 모두 구현하기 위한 첫 단계입니다. SAA-C03 시험에서는 주어진 아키텍처 다이어그램에서 SPOF를 식별하고 제거하는 능력을 자주 평가합니다.

상태 비저장 서비스(웹 서버나 Lambda 함수 등)는 어떤 인스턴스든 어떤 요청이나 처리할 수 있으므로 HA나 FT를 달성하기가 훨씬 쉽습니다. 상태 저장 서비스(데이터베이스, 캐시, 파일 시스템)는 더 어렵습니다. 복제본 간에 상태를 동기화하고, 복제 지연을 처리하며, 장애 조치 중 일관성을 보장해야 합니다. EFS(공유 파일 시스템), 복제 그룹을 사용하는 ElastiCache, Aurora(공유 스토리지)와 같은 AWS 서비스는 상태 저장 HA를 더 쉽게 구현하도록 설계되었습니다.

AWS의 일반적인 HA 패턴은 다음과 같습니다. 1) 다중 AZ 로드 밸런싱 — ALB 뒤의 여러 AZ에 EC2 인스턴스를 분산합니다. 2) 읽기 전용 복제본 — 읽기 트래픽을 분산하고 DR 상황에서 승격합니다. 3) 상태 비저장 자산에 S3 사용 — S3는 11개의 9로 표시되는 내구성을 갖춘 본질적으로 HA인 서비스입니다. 4) Global Accelerator — 고정 Anycast IP를 사용해 리전 전반의 정상 엔드포인트로 라우팅합니다. 각 패턴은 특정 수준의 가용성을 얻는 대신 비용이 증가합니다.

장애 허용 패턴은 모든 영역에서 활성 이중화를 요구합니다. 주요 FT 패턴은 다음과 같습니다. DynamoDB는 장애 조치가 필요하지 않도록 세 AZ에 데이터를 복제하므로 본질적으로 장애를 허용합니다. S3에는 FT 기능이 내장되어 있습니다. Aurora Multi-Master(현재는 Aurora Serverless v2 multi-writer)는 여러 AZ에 동시에 쓰기를 수행할 수 있습니다. Kinesis는 기본적으로 여러 AZ에 데이터를 저장합니다. FT가 내장된 관리형 서비스를 선택하는 것이 중단 시간이 없는 아키텍처를 구현하는 가장 비용 효율적인 방법입니다.

HA 또는 FT를 위한 설계의 품질은 테스트 수준에 달려 있습니다. AWS는 AWS Fault Injection Simulator(FIS)를 사용해 인스턴스 종료, API 처리량 제한, 네트워크 장애 주입과 같은 통제된 실험을 수행할 것을 권장합니다. 장애 조치가 실제로 RTO 내에 완료되는지, RPO를 초과하는 데이터 손실이 없는지, 경보가 올바르게 발생하는지 확인해야 합니다. 정기적인 게임 데이와 카오스 엔지니어링 훈련은 운영 환경에서 장애가 발생하기 전에 복원력에 대한 가정의 빈틈을 찾아냅니다.

이번 레슨에서 다룬 AWS Solutions Architect(SAA-C03) 개념을 제대로 이해했는지 확인해 보세요.

이번 레슨에서는 다음을 배웠습니다. 고가용성은 자동 복구를 통해 중단 시간을 최소화합니다(수분 수준의 RTO). 장애 허용은 활성 이중화를 통해 중단 시간을 제거합니다(RTO 0). 또한 복원력 수준이 높아질수록 비용이 크게 증가합니다. 단일 장애 지점을 제거하는 것은 두 접근 방식의 기반입니다. 다음에는 상태 저장 서비스를 위한 다중 AZ 패턴을 살펴보겠습니다.