AWS 서버를 가용 영역 하나에만 두어도 괜찮습니까?

단일 가용 영역이 위험한 이유

AWS 리전은 세 개 이상의 가용 영역(AZ)으로 이뤄집니다. 가용 영역은 서로 물리적으로 떨어져 있고 전력·냉방·네트워크를 따로 갖춘 데이터센터 묶음이라, 화재나 정전 같은 사고가 한 영역에서 생겨도 다른 영역에는 번지지 않도록 설계돼 있습니다. 같은 리전 안의 영역끼리는 지연이 한 자릿수 밀리초 수준이라, 대부분의 업무에서 영역 사이에 데이터를 동기식으로 복제해도 사용자 경험에 큰 영향이 없습니다.

AWS Well-Architected 프레임워크의 안정성 원칙은 「운영 워크로드가 가용 영역 하나에만 있는 것」을 대표적인 잘못된 패턴으로 꼽고, 운영 워크로드를 한 리전 안의 최소 두 개 가용 영역에 배포하라고 권합니다. 단일 가용 영역 구성은 평소에는 아무 문제 없이 동작하다가, 그 영역에 장애가 생기는 날 서비스 전체가 함께 멈춥니다.

지금 구성이 단일 영역인지 확인하는 법

먼저 현재 상태를 정확히 봅니다. 생각보다 「일부만 이중화된」 구성이 있습니다.

• 데이터베이스: RDS 콘솔의 데이터베이스 목록에서 다중 AZ 여부와 보조 가용 영역을 확인합니다. 읽기 복제본이 있어도 다중 AZ 대기 인스턴스와는 다른 기능입니다.
• 서버: EC2 인스턴스와 오토스케일링 그룹이 어떤 서브넷, 즉 어떤 가용 영역에 있는지 봅니다. 오토스케일링 그룹에 서브넷이 하나만 지정돼 있으면 서버가 몇 대든 한 영역에 모입니다. 지정된 서브넷은 콘솔의 오토스케일링 그룹 상세 화면에서 바로 볼 수 있습니다.
• 영역 단위 자원: NAT 게이트웨이, EBS 볼륨처럼 특정 영역에 속하는 자원이 어디에 있는지 확인합니다.

AWS 관리형 서비스 가운데 S3·DynamoDB·Aurora·SQS 등은 기본적으로 여러 가용 영역에 데이터를 복제하지만, RDS·ElastiCache·Redshift는 다중 AZ를 직접 켜야 합니다. EC2에 붙인 EBS 볼륨의 영역 간 복제는 사용자가 직접 관리해야 합니다.

무엇부터 이중화합니까 — 데이터가 먼저

비용 때문에 한 번에 갖추기 어렵다면 되돌릴 수 없는 손실부터 막는 순서로 진행합니다. 서버는 다시 만들 수 있지만 데이터는 다시 만들 수 없기 때문입니다.

1. 다른 영역에서 복원 가능한 백업EBS 스냅샷은 리전의 모든 가용 영역에 복제돼 어느 영역에서나 볼륨으로 복원할 수 있습니다. 백업 주기와 복원 절차를 먼저 확인합니다.
2. 데이터베이스 다중 AZRDS는 다중 AZ 옵션을 켜면 다른 영역에 동기식 대기 인스턴스를 두고, 장애 시 자동으로 넘깁니다.
3. 서버 이중화로드 밸런서 뒤에 두 개 영역의 서버를 두고, 오토스케일링 그룹이 장애 영역의 서버를 다른 영역에서 다시 만들게 합니다.
4. 주변 구성 정리NAT 게이트웨이 같은 영역 단위 자원이 한 영역에만 있으면 그 영역 장애 때 다른 영역의 서버도 외부 통신이 끊깁니다.

이미 Application Load Balancer를 쓰고 있다면 로드 밸런서 자체는 최소 두 개 가용 영역의 서브넷을 요구하므로 이미 두 영역에 있습니다. 그런데 뒤에 연결된 서버가 한 영역에만 있다면, 앞단만 이중화되고 실제 서비스는 단일 영역인 상태입니다.

이중화를 켠 뒤에는 넘어가는지 직접 확인합니다. RDS는 장애 조치를 포함한 재부팅으로 대기 인스턴스로 넘기는 시험을 할 수 있습니다. 이때 애플리케이션이 연결이 끊긴 뒤 다시 접속하는지, 데이터베이스 주소를 고정 IP가 아니라 엔드포인트 이름으로 쓰고 있는지 함께 봅니다. 인프라가 넘어가도 애플리케이션이 따라오지 못하면 사용자에게는 똑같은 장애입니다.

다중 가용 영역의 대가

다중 가용 영역 구성은 공짜가 아닙니다. 비용과 성능에 따라오는 변화를 미리 알고 결정합니다.

단일 가용 영역으로 두어도 되는 경우

모든 환경을 다중 가용 영역으로 만들 필요는 없습니다. 중단과 데이터 손실을 얼마나 견딜 수 있는지로 나눕니다.

단일 영역으로 두기로 했다면 그 결정을 문서로 남기고, 영역 장애 때 다른 영역에서 다시 세우는 절차와 걸리는 시간을 미리 확인해 둡니다. 그래야 「몰라서 단일 영역」이 아니라 「정해서 단일 영역」이 됩니다.

빌드업웍스가 가용성 수준을 함께 정할 때 먼저 묻는 것은 사양이 아니라 「이 서비스가 반나절 멈추면 누가 무엇을 못 하는가」입니다. 답이 구체적일수록 필요한 구성과 쓰지 않아도 되는 비용이 분명해집니다.

리전 전체 장애까지 견뎌야 하는 서비스라면 다중 리전을 검토하지만, AWS는 먼저 한 리전 안의 다중 가용 영역으로 요구를 충족할 수 있는지 판단하라고 안내합니다. 다중 리전은 가용성을 더 높일 수 있지만 구성의 복잡도와 비용이 함께 늘어납니다. 그 판단은 재해복구 수준을 다룬 인사이트 글에서 복구 목표 시간(RTO)과 복구 목표 시점(RPO)을 기준으로 정리했습니다.

참고 자료

• AWS Well-Architected 안정성 원칙 — REL10-BP01 여러 위치에 배포
• Amazon RDS 사용 설명서 — 다중 AZ DB 인스턴스 배포
• Application Load Balancer 사용 설명서 — 서브넷 요건
• Amazon EBS 사용 설명서 — 스냅샷
• AWS Data Exports — 데이터 전송 요금 이해