AWS 글로벌 인프라 개념

🌍 AWS 글로벌 인프라 계층 구조

• 리전 (Region)
  • 전 세계 AWS 데이터 센터 그룹
  • 예: ap-northeast-2 (서울), us-east-1 (버지니아)
  • 가용 영역 (AZ, Availability Zone)
    • 한 리전 내 서로 독립적인 데이터 센터
    • 예: ap-northeast-2a, ap-northeast-2b
    • 여러 AZ에 분산하여 배포하면 가용성이 높아짐
    • 서브넷 (Subnet)
      • 퍼블릭 서브넷 / 프라이빗 서브넷으로 나뉨
      • EC2, RDS, S3, EBS 등의 서비스 배포 가능
• 엣지 로케이션 (Edge Location)
  • CloudFront, Global Accelerator 제공
  • CDN 캐싱, DDoS 방어 등의 역할 수행

🏆 AWS 리전 선택 기준

• 한국 대상 서비스 → ap-northeast-2 (서울)
• 글로벌 사용자 대상 서비스 → us-east-1 (버지니아)
• 빠른 응답속도 필요 → CloudFront + Local Zone 활용

🔄 Multi-AZ vs Multi-Region 비교

✅ Multi-AZ vs Multi-Region 예제

Multi-AZ 배포

• AZ-1: EC2, RDS Primary
• AZ-2: EC2, RDS Standby (Failover 발생 시 Primary로 승격)

Multi-Region 배포

• Region 1 (서울): Active 서비스 운영
• Region 2 (도쿄): Passive 대기 (재해 복구용)

🚀 실무에서 Multi-AZ 활용 사례

✅ (1) 데이터베이스 (DB) Multi-AZ 배포 (자동 장애 복구)

• 설명
  • 데이터베이스가 한 AZ에서 장애가 발생하더라도 다른 AZ에서 자동으로 복구되도록 구성할 수 있다.
  • 예를 들어, AWS RDS의 Multi-AZ 기능을 활성화하면 Primary(Writer) 데이터베이스가 다운될 경우 Standby(Replica)가 자동으로 Primary 로 승격된다.
  • 동일한 개념이 MySQL Replication, PostgreSQL Streaming Replication, MongoDB Replica Set 등에도 적용될 수 있다.
• 트래픽 흐름
  1. 정상 상태
     • AZ-1: Primary DB (Read/Write 가능)
     • AZ-2: Standby DB (복제만 수행, 장애 발생 시 승격)
  2. 장애 발생 후
     • AZ-2: Standby → Primary로 자동 승격
     • AZ-1: 복구 후 Standby로 변경

✅ (2) 웹 애플리케이션 (EC2 Auto Scaling + ALB)

• 설명
  • 웹 서버 및 API 서버를 여러 AZ에 배포하여 하나의 AZ가 다운되더라도 서비스가 계속 운영될 수 있도록 설정한다.
  • 일반적으로 ALB(Application Load Balancer)를 통해 트래픽을 여러 AZ로 분산하고, Auto Scaling 그룹을 활용하여 인스턴스를 동적으로 조정한다.
• 트래픽 흐름
  1. 사용자 요청
  2. ALB (로드 밸런싱)
     • AZ-1: EC2 (웹 서버)
     • AZ-2: EC2 (Auto Scaling)
  3. AZ-1 장애 발생 시
     • Auto Scaling이 AZ-2에 EC2 인스턴스를 추가하여 트래픽을 유지

✅ (3) 컨테이너 오케스트레이션 (ECS / EKS Multi-AZ 배포)

• 설명
  • 컨테이너 기반 애플리케이션을 운영할 때, Amazon ECS (Fargate 포함) 또는 Amazon EKS(Kubernetes) 를 여러 AZ에 걸쳐 배포하여 장애 대비 가능.
  • AWS Fargate 또는 EC2 기반의 컨테이너 클러스터를 사용하여 각 AZ에 컨테이너 인스턴스를 분산 배포할 수 있다.
• 트래픽 흐름
  1. 사용자 요청
  2. ALB → Target Group (ECS/EKS Service)
     • AZ-1: ECS Task / Kubernetes Pod 실행
     • AZ-2: ECS Task / Kubernetes Pod 실행
  3. AZ-1 장애 발생 시
     • ALB가 자동으로 AZ-2의 컨테이너로 트래픽을 라우팅

✅ (4) 메시징 시스템 (SQS, Kafka, RabbitMQ)

• 설명
  • 메시지 큐 시스템을 Multi-AZ에 배포하여 메시지 손실 없이 고가용성을 유지할 수 있다.
  • AWS SQS와 같은 Fully Managed 서비스는 기본적으로 Multi-AZ를 지원하며, Kafka 또는 RabbitMQ는 멀티 브로커 구성을 통해 AZ 간 복제를 설정할 수 있다.
• 트래픽 흐름
  1. 프로듀서(Producer) 가 메시지를 메시지 큐에 전달
  2. 브로커(Broker) 노드 가 Multi-AZ에 분산되어 메시지를 저장
  3. 컨슈머(Consumer) 가 메시지를 읽어가며 장애가 발생해도 다른 AZ의 노드에서 계속 처리 가능

✅ (5) 파일 스토리지 & 오브젝트 스토리지 (EFS, S3, FSx)

• 설명
  • AWS EFS(Elastic File System), Amazon S3, FSx 등은 기본적으로 Multi-AZ를 지원하는 스토리지 서비스이다.
  • 여러 AZ에 걸쳐 데이터를 복제하여 내구성을 높이고 장애 발생 시에도 정상적으로 데이터에 접근할 수 있도록 한다.
• 트래픽 흐름
  1. EFS 사용 시
     • AZ-1의 EC2 인스턴스가 EFS 마운트
     • AZ-2의 EC2 인스턴스가 동일한 EFS에 접근 가능
  2. S3 사용 시
     • 객체 저장소로서 여러 AZ에 걸쳐 데이터 자동 복제
     • 한 AZ 장애 발생 시에도 데이터 손실 없이 접근 가능

🔧 실무에서 Multi-AZ를 적용하는 주요 원칙

1. 한 개 AZ에서만 운영하지 말 것
   • 하나의 AZ에서만 서비스를 운영하면 해당 AZ 장애 발생 시 전체 서비스가 중단될 위험이 있다.
   • 최소한 2개 이상의 AZ에 배포하여 가용성을 확보해야 한다.
2. ALB 또는 NLB를 활용하여 Multi-AZ 트래픽 분산
   • AWS ALB(Application Load Balancer) 또는 NLB(Network Load Balancer)를 사용하면 AZ 간 트래픽을 분산하여 장애 발생 시에도 서비스가 지속 가능하다.
3. Auto Scaling 그룹을 활용하여 인프라 자동 확장
   • EC2 또는 ECS/EKS 같은 컴퓨팅 리소스는 Auto Scaling 그룹을 활용하여 Multi-AZ 환경에서 동적으로 조정할 수 있다.
4. RDS, Kafka, Elasticsearch 등 AZ 장애 대비 설정 필요
   • 데이터베이스, 메시징 시스템 등은 Multi-AZ 복제 기능을 활성화해야 하며, 장애 발생 시 자동으로 Failover 되도록 설정해야 한다.
5. 백업 & DR 전략을 수립할 것
   • Multi-AZ로 배포해도 리전 단위의 장애(예: 전체 리전 장애)가 발생할 수 있으므로, Multi-Region 백업 또는 재해 복구(DR) 계획이 필요하다.

🎯 결론

• Multi-AZ는 고가용성을 위한 필수 전략이며, 모든 핵심 서비스에서 활용 가능
• 웹 서버, 데이터베이스, 컨테이너 오케스트레이션, 메시징 시스템, 스토리지 등 다양한 서비스에 적용할 수 있음
• ALB, Auto Scaling, RDS Multi-AZ, Kafka Replication 등을 적절히 조합하여 안정적인 아키텍처 구축
• 리전 장애까지 대비하려면 Multi-Region 복제 및 DR 전략도 고려해야 함