글로벌 서비스 구축을 위한 AWS 멀티 리전 아키텍처 구성 가이드
전 세계 사용자를 위한 서비스를 제공하기 위해서는 AWS 멀티 리전 기반 애플리케이션을 구축해야 하며, 이를 위해서는 많은 준비와 작업이 필요합니다. 대다수 AWS 서비스에는 멀티 리전 아키텍처를 구축하고 관리하는 데 도움이 되는 기능이 있지만, 200개 이상의 서비스에서 이러한 기능을 모두 알아 내는 것은 어려울 수 있습니다.
AWS 리전은 전 세계적으로 주요한 국가 및 도시에 물리적으로 분리되어 있으며, 한 리전 내에서도 여러 개의 가용 영역(AZ)을 구성하고 있습니다. 이 접근 방식을 사용하면, 여러 가용 영역에 걸쳐 있는 고 가용성을 활용하여, Well-Architected 모범 사례를 통해 내결함성을 높일 수 있습니다.
멀티 리전으로 서비스를 확장해야 하는 경우는 세 가지 정도입니다.
- 전 세계 사용자 대상 서비스 – 서비스 특성상 글로벌 사용자를 위해 낮은 대기 시간 제공
- 복구 시점 목표(RPO) 및 복구 시간 목표(RTO) – 재해 복구(DR) 계획의 일부로 타 리전 사용
- 법률 및 규정 준수 – 국가별 엄격한 데이터 보존 및 개인 정보 보호 요구 사항 준수
이 글에서는 멀티 리전 애플리케이션을 구축하는 데 도움이 되는 기능이 포함된 보안, 네트워킹 및 컴퓨팅 서비스, 데이터 및 스토리지 복제, 애플리케이션 및 관리 계층으로 나누어 살펴보겠습니다.
1. 보안 고려 사항
보안은 서비스 아키텍처 구성시, 가장 높은 우선 순위를 가집니다. 보안 기반 구축은 최소 권한 원칙을 구현하기 위한 적절한 인증, 권한 부여 및 계정으로 시작됩니다. AWS Identity and Access Management (AWS IAM)는 기본적으로 글로벌 컨텍스트에서 작동합니다. IAM을 사용하면 누가 어떤 조건에서 어떤 AWS 리소스에 액세스할 수 있는지 지정합니다. 디렉터리 서비스를 사용하는 워크로드의 경우, AWS Directory Service for Microsoft Active Directory Enterprise Edition을 설정한 후 여러 리전에서 디렉터리 데이터를 자동으로 복제하면 됩니다. 이를 통해 애플리케이션은 가장 가까운 디렉토리를 사용하여 조회 대기 시간을 줄이고 여러 리전에 걸쳐 내구성을 생성할 수 있습니다.
데이터베이스 암호와 같은 비밀을 안전하게 저장, 교체 및 감사해야 하는 애플리케이션은 AWS Secrets Manager를 사용하고, 데이터 암호화를 위해 AWS Key Management Service (AWS KMS)키를 보조 리전에 복제 하여 애플리케이션이 가장 가까운 리전에서 암호 키를 얻을 수 있도록 할 수 있습니다.
AWS KMS는 미사용 데이터를 암호화하는 데 사용할 수 있을 뿐만 아니라 AWS 서비스 전반의 암호화에 광범위하게 사용됩니다. 기본적으로 암호 키는 단일 리전으로 제한됩니다. 단, AWS KMS 멀티 리전 키를 생성하여 두 번째 리전에 키를 복제할 수 있으므로 각 리전에서 다른 키로 데이터를 해독하고 다시 암호화할 필요가 없습니다.
AWS CloudTrail은 사용자 활동 및 API 사용량을 기록합니다. 각 로그는 역시 각 리전에서 생성되지만 멀티 리전 및 멀티 계정 에서 단일 Amazon Simple Storage Service (Amazon S3)버킷으로 합칠 수 있습니다. 물론 이렇게 모인 로그는 오용을 방지하기 위해 필요한 보안 담당자만 액세스할 수 있는 계정으로 집계되어야 합니다.
애플리케이션이 새로운 리전으로 확장됨에 따라 AWS Security Hub 는 결과를 집계하고 단일 리전에 연결하여 계정 및 리전에 걸쳐 중앙 집중식 보기를 생성할 수 있습니다. 이러한 결과는 리전 간에 지속적으로 동기화되어 글로벌 결과에 대한 최신 정보를 제공합니다.
각각의 보안 기능을 멀티 리전으로 사용한다면 다음과 같이 구성할 수 있습니다.
2. 글로벌 네트워크 구축
다른 리전의 가상 네트워크로 시작된 클라우드 리소스의 경우, 일반적으로 Amazon Virtual Private Cloud (Amazon VPC)는 VPC 피어링이 있는 계정과 리전 간 프라이빗 라우팅을 제공합니다. 이러한 리소스는 사설 IP 주소를 사용하여 통신할 수 있으며 인터넷 게이트웨이, VPN 또는 별도의 네트워크 어플라이언스가 필요하지 않습니다. 이것은 몇 개의 피어링 연결만 필요한 소규모 네트워크에 적합합니다. 그러나, 피어링된 연결의 수가 증가함에 따라 피어링된 연결 사이를 관리하고 문제를 해결하기가 어려워질 수 있습니다.
VPC 피어링의 숫자가 관리 범위를 넘어갈 정도가 된다면, AWS Transit Gateway 는 클라우드 라우터 역할을 하는 중앙 이전 허브를 생성하여 이러한 어려움을 줄이는 데 도움이 될 수 있습니다. Transit Gateway의 라우팅 기능은 Transit Gateway 리전 간 피어링 을 통해 추가 리전으로 확장하여 전 세계적으로 분산된 사설 네트워크를 생성할 수 있습니다.
사용자를 분산 인터넷 응용 프로그램으로 라우팅하는 안정적이고 비용 효율적인 방법을 구축하려면, 가용성과 확장성이 뛰어난 DNS(Domain Name System) 서비스가 필요합니다. Amazon Route 53이 바로 그 일을 합니다.
Route 53 라우팅 정책 은 대기 시간이 가장 짧은 레코드로 트래픽을 라우팅하거나 레코드를 자동으로 장애 조치할 수 있습니다. 더 큰 오류가 발생하는 경우, Route 53 Application Recovery Controller 는 멀티 리전, 가용영역 및 온프레미스에서 애플리케이션 오류에 대한 모니터링 및 장애 조치 프로세스를 단순화할 수 있습니다.
Amazon CloudFront의 콘텐츠 전송 네트워크는 전 세계에 걸쳐 400개 이상의 제공 지점(Points of Presence)에 구축된 진정한 글로벌 네트워크입니다. 여러 리전과 같이 가능한 여러 오리진이 있는 애플리케이션은 CloudFront 원본 장애 조치 하여 오리진을 자동으로 장애 조치할 수 있습니다. CloudFront 함수는 엣지에서 AWS Lambda 함수를 실행할 수 있는 기능으로, 콘텐츠 제공 이상으로 다양한 기능을 수행할 수 있습니다. CloudFront 함수를 사용하면, 경량 JavaScript 기능을 쉽게 실행할 수 있으며 AWS Lambda@Edge 를 사용하면 이러한 300개 이상의 PoP에서 Node.js 및 Python 기능을 쉽게 실행할 수 있습니다.
AWS Global Accelerator 는 AWS 글로벌 네트워크 인프라를 사용하여 애플리케이션에 2개의 고정 애니캐스트 IP를 제공합니다. 가장 가까운 리전 배포로 트래픽을 자동으로 라우팅하고 오류가 감지되면 몇 초 이내에 트래픽을 정상 엔드포인트로 자동 리디렉션합니다 .
지금까지 살펴본 서비스들을 결합하면, 두 리전에 걸쳐 다음과 같은 글로벌 네트워크를 생성할 수 있습니다.
3. 컴퓨팅 계층 구축
보안 및 네트워크를 구성했다면, 이제 컴퓨팅 인프라 단계로 넘어가겠습니다. 가장 먼저 서버를 띄우기 위해서 Amazon 머신 이미지(AMI)를 통해 Amazon Elastic Compute Cloud (Amazon EC2) 인스턴스를 만듭니다 . AMI는 인스턴스의 스토리지, 시작 권한 및 디바이스 매핑과 같은 인스턴스 구성을 지정합니다. 새 표준 이미지를 생성해야 하는 경우 EC2 Image Builder 를 사용하여 AMI를 선택한 리전에 복사할 수 있습니다.
EC2 인스턴스 및 연결된 Amazon Elastic Block Store (Amazon EBS) 볼륨이 단일 가용 영역에 있지만 Amazon Data Lifecycle Manager 는 여러 리전에서 EBS 스냅샷을 생성하고 복사하는 프로세스를 자동화할 수 있습니다. 이는 EBS 볼륨에 대해 비교적 쉬운 콜드 백업 및 복원 옵션을 제공하여 장애 복구 전략을 만들 수 있습니다.
그러나, 아키텍처가 여러 리전으로 확장됨되면, 각 인스턴스가 프로비저닝된 위치를 추적하기가 어려워질 수 있습니다. 이때, Amazon EC2 Global View 는 모든 활성 리전의 인스턴스, VPC, 서브넷, 보안 그룹 및 볼륨과 같은 Amazon EC2 리소스를 볼 수 있는 중앙 집중식 대시보드를 제공하여 이 문제를 해결하는 데 도움이 됩니다.
만약, 컨테이너를 사용하는 마이크로서비스 기반 애플리케이션이라면, 좀 더 쉽게 할 수 있습니다. 예를 들어, Amazon Elastic Container Registry (Amazon ECR)을 통해 등록된 콘테이너를 통해 리전 전체에서 이러한 작업이 일관되게 발생하도록 할 수 있습니다 프라이빗 이미지 복제는 레지스트리 수준에서 리전간 또는 계정간 복제에 대해 ECR 프라이빗 레지스트리를 구성하여 필요할 때 이미지가 보조 리전에서 준비할 수 있습니다.
지금까지 설명한 서비스를 활용해서 아래와 같은 컴퓨팅 계층을 구성할 수 있습니다.
4. 스토리지 서비스 구축
멀티 리전에 데이터를 제공할 때는 네트워크 속도를 고려해야 합니다. AWS 글로벌 네트워크에서 데이터 전송은 매우 빠른 속도를 제공합니다. 하지만, 데이터 복제 작업은 빛의 속도의 제한을 받습니다. 이러한 이유로 멀티 리전 애플리케이션을 구축할 때, 데이터 제공 일관성을 고려해야 합니다. 일반적으로 물리적 거리가 멀수록 데이터가 거기에 도달하는 데 더 오래 걸리니까요.
분산 시스템을 구축할 때 가장 많이 사용하는 원칙은 일관성, 가용성, 파티션 허용 오차 등에 대한 CAP 정리입니다. 이 정리에 따르면 애플리케이션은 3개 중 2개만 선택할 수 있으며, 그 사이의 절충점을 고려해야 합니다.
- 일관성 (Consistency) – 모든 클라이언트는 항상 동일한 데이터를 볼 수 있습니다.
- 가용성(Availability) – 모든 클라이언트는 항상 데이터를 읽고 쓸 수 있습니다.
- 파티션 허용 오차 (Partition Tolerance) – 물리적 파티션 장애에도 불구하고 데이터를 제공합니다.
일반적으로, 단일 리전 애플리케이션의 경우 일관성과 가용성을 달성합니다. 예를 들어, 여러 애플리케이션이 단일 리전 내 데이터베이스에 연결하는 경우입니다. 그러나, 장거리 데이터 전송으로 인해 추가되는 대기 시간으로 인해 멀티 리전에서는 이것이 더 어려워집니다. 이러한 이유로 고도로 분산된 시스템은 일반적으로 가용성 및 파티션 허용 오차를 선호하는 접근 방식을 따릅니다.
4.1 파일 개체 저장 및 복제
Amazon S3에 제공하는 파일 객체를 단방향 혹은 양방향으로 멀티 리전에 자동 복제할 수 있습니다. 방향 또는 양방향 . 만약, S3 버킷에 있는 일부 객체의 하위 집합에 대해서 복제 규칙를 정할 수도 있습니다.
빠르게 복제를 하는 것이 중요한 경우, S3 Replication Time Control 은 15분 이내에, 대부분은 몇 초 이내에 객체의 99.99%를 복제하여 요구 사항을 충족하는 데 도움이 될 수 있습니다. 객체의 복제 상태를 모니터링하기 위해서는 Amazon S3 복제 지표 및 이벤트 모니터링 기능을 통해 복제를 추적하고 문제가 있는 경우, 알림을 보낼 수 있습니다.
전통적으로 각 S3 버킷에는 고유한 단일 리전 엔드포인트가 있습니다. 여러 엔드포인트에 대한 연결 및 관리를 단순화하기 위해, S3 멀티 리전 액세스 포인트는 서로 다른 리전의 여러 S3 버킷에 걸쳐 단일 글로벌 엔드포인트를 생성합니다. 각 애플리케이션이 이 엔드포인트에 연결되면, AWS Global Accelerator를 사용하여, AWS 글로벌 네트워크를 통해 대기 시간이 가장 짧은 버킷으로 라우팅됩니다. 버킷에 대한 연결 또는 가용성이 변경되면 장애 조치 라우팅도 자동으로 처리됩니다.
Amazon S3 외부에 저장된 파일의 경우, AWS DataSync을 통해 리전 및 계정 간에 파일 데이터 이동, Amazon Elastic File System (Amazon EFS), Amazon FSx, AWS Snowcone 및 Amazon S3에서 NFS, SMB, HDFS 및 자체 관리형 객체 스토리지에 저장된 온프레미스 파일을 하이브리드 아키텍처용 AWS와 동기화하는 데에도 사용할 수 있습니다.
파일 및 개체 복제는 최종 일관성이 있어야 합니다. 주어진 데이터 세트가 전송할 수 있는 속도는 데이터 양, I/O 대역폭, 네트워크 대역폭 및 네트워크 조건의 함수입니다.
4.2 백업 복사
AWS Backup을 사용하여 데이터 백업을 예약하거나 실행할 수 있습니다. 비즈니스 요구 사항을 충족하기 위해, 하나 이상의 AWS 리전 또는 계정으로 데이터 백업 복사를 자동화 할 수 있고, Amazon EBS나 Amazon Neptune과 같이 다른 리전에 실시간 복제를 제공하지 않는 서비스에 특히 유용할 수 있습니다.
지금까지 소개한 스토리지 서비스는 다음과 같이 결합할 수 있습니다.
5. 데이터베이스 계층
관계형 데이터 모델이 필요한 애플리케이션의 경우, Amazon Aurora 글로벌 데이터베이스는 Aurora PostgreSQL 호환 및 MySQL 호환 에디션에 대해 멀티 리전에서 데이터베이스 읽기 확장을 제공합니다.
전용 복제 인프라는 물리적 복제를 활용하여, 논리적 복제 데이터베이스 엔진이 제공하는 것보다 훨씬 낮은 복제 지연을 달성할 수 있습니다. 아래 벤치마크 데이터는 R4.16xlarge에서 600초마다 단계별로 실행되는 SysBench OLTP(쓰기 전용)에서 측정할 결과입니다.
Amazon Aurora 글로벌 데이터베이스를 사용하면 하나의 기본 리전이 쓰기(Write)로 지정되고, 보조 리전은 읽기(Read) 전용입니다. Aurora MySQL은 쓰기 요청에 대한 전달 기능을 통해, 보조 리전에서 기본 리전으로 전달하여 애플리케이션 코드 로직을 단순화하는 장애 조치 테스트는 관리형 계획 장애 조치 복제 토폴로지를 그대로 유지하면서 활성 쓰기 클러스터를 다른 리전으로 변경하는 관리형 복구 지점 목표(RPO)에 허용되는 최대 복제본 지연을 설정하는 옵션이 있습니다 .
Amazon RDS는 MariaDB, MySQL, Oracle, PostgreSQL 및 Aurora 데이터베이스에서 리전 간 읽기 전용 복제본 을 설정하여, 기본 리전의 쓰기 인스턴스로부터 변경 사항을 수신합니다. AWS Database Migration Service을 활용하면, Microsoft SQL Server용 RDS를 기반으로 구축된 애플리케이션에 대해 리전 간 복제 기능을 활용하여 장애 복구도 가능합니다. 리전 간 복제본을 사용하면 더 빠른 로컬 읽기가 가능하며, 독립 실행형 인스턴스로 승격되어 재해 발생 시 데이터 손실 및 복구 시간을 줄일 수 있습니다.
만약 조금 더 긴 RPO 및 RTO가 허용되는 상황인 경우, 백업을 여러 리전에 복사할 수 있습니다. Redis용 Amazon ElastiCache를 제외한, 모든 관계형 및 비관계형 데이터베이스에 사용할 수 있습다. Amazon Redshift에서도 리전 간 스냅샷 복사 구성을 통해 데이터 웨어하우스에 대한 백업 구성이 가능합니다.
비 관계형 데이터베이스인 경우, Amazon DynamoDB 글로벌 테이블은 글로벌 애플리케이션을 대규모로 구축하는 데 도움이 되는 멀티 리전 및 멀티 쓰기 작업을 제공합니다. DynamoDB 글로벌 테이블은 멀티 리전 토폴로지(액티브- 액티브 및 멀티 리전)에서 여러 리전에 액티브 쓰기 작업을 허용하는 유일한 AWS 매니지드 서비스입니다. 이를 통해 애플리케이션은 가장 가까운 리전에서 읽고 쓸 수 있으며 변경 사항은 자동으로 다른 리전에 복제됩니다.
Amazon DocumentDB에 대한 전역 읽기 및 빠른 복구는 글로벌 클러스터를 사용하여 달성할 수 있습니다. 해당 클러스터에는 쓰기 작업을 처리하는 기본 리전이 있습니다. 전용 스토리지 기반 복제 인프라를 통해 일반적으로 1초 미만의 지연 시간으로 짧은 글로벌 읽기를 수행할 수 있습니다.
리전 간에 동일한 데이터로 인-메모리 캐시를 지속적으로 유지하는 것은 애플리케이션 성능을 유지하는 데 중요할 수 있습니다. Redis용 Amazon ElastiCache이 제공하는 글로벌 데이터 저장소는 캐시 및 데이터베이스에 대해 리전 간 복제본을 생성할 수 있는 글로벌 데이터 저장소입니다. 한 리전에서 발생하는 쓰기 작업을 최대 2개의 다른 리전간 복제본 클러스터에서 읽을 수 있습니다.
지금까지 살펴본 방식으로 다음과 같이 글로벌 데이터베이스 아키텍처를 구성할 수 있습니다.
6. 애플리케이션 개발 및 관리
코드 기반 인프라 관리(Infrastructure as Code, IaC) 기능을 사용하면 인프라 생성 및 구성을 위한 자동화가 가능합니다. 여러 리전에 일관된 환경을 배포할 수 있는 반복 가능한 템플릿을 사용하여 빠르게 구성이 가능합니다.
AWS CloudFormation StackSets을 통해 여러 계정 및 리전에서 구성 스택을 생성, 업데이트 및 삭제할 수 있습니다. 작성할 때 AWS CloudFormation 파라미터를 조건부 로직과 페어링하여 배포 동작을 변경할 수도 있습니다. 예를 들어, 대기 리전에 배포된 오토스케일링용 Amazon EC2 인스턴스 수를 제한하는 “대기” 파라미터를 설정할 수도 있습니다.
AWS CodePipeline을 사용하면, 여러 리전에 걸쳐 배포되는 애플리케이션의 리전 간 작업 에서 일관된 출시 파이프라인을 구성할 수 있으며, 각 리전에서 다른 작업을 설정할 필요가 없습니다. 또한, EC2 Image Builder 및 Amazon ECR에서 리전간 복사 기능을 사용하면, 일관된 AMI 및 컨테이너 이미지 배포를 할 수 있습니다.
6.1 이벤트 기반 아키텍처 구성
애플리케이션 구성 시, 이벤트 기반 응용 프로그램은 각 구성 요소가 특정 작업을 독립적으로 수행하도록 하여 보다 확장 가능하고 유지 관리 가능한 아키텍처를 생성합니다.
Amazon EventBridge는 AWS 리소스 간에 이벤트를 보낼 수 있습니다. 교차 리전 이벤트 라우팅을 활용하여 다른 리전과 여러 계정의 워크로드 간 이벤트를 공유할 수 있습니다. 이를 통해, 리전 간에 상태 및 사용률 이벤트를 공유하여 요청에 가장 적합한 리전 워크로드 배포를 결정할 수 있습니다.
이벤트 기반 애플리케이션이 게시/구독 메시징에 의존하는 경우, Amazon Simple Notification Service (Amazon SNS)가 여러 대상으로 확장할 수 있습니다. 그 대상이 Amazon Simple Queue Service (Amazon SQS) 대기열 또는 AWS Lambda 함수인 경우 Amazon SNS는 다른 리전의 수신자에게 알림을 보낼 수 있습니다. 예를 들어, 멀티 리전 애플리케이션에 대한 주문을 처리하는 중앙 SQS 대기열에 메시지를 보낼 수 있습니다.
6.2 모니터링 및 관찰 가능성(Observability)
클라우드 리소스와 배포 위치의 수가 증가함에 따라 관찰 가능성(Observability)은 더욱 중요해 지고 있습니다. 이를 통해 문제의 영향과 근본 원인을 신속하게 식별할 수 있으면, 장애 복구 활동에 영향을 미치며 실패에 대한 탄력성을 갖도록 하는 데 도움이 됩니다. AWS를 기반으로 구축할 때, AWS 서비스의 상태를 애플리케이션 지표와 연결하여 인프라 상태에 대해 전체를 조망할 수 있습니다.
AWS 상태 대시보드 및 API 는 리소스에 영향을 미칠 수 있는 계정별 이벤트 및 예약된 활동을 표시합니다. 이러한 이벤트는 모든 리전에서 EventBridge를 통해 이벤트 기반으로 즉각적인 조치를 취할 수 있습니다. 예를 들어 여러 서비스가 성능 저하를 보고하는 경우, EventBridge 이벤트 대상을 AWS Systems Manager 자동화 운영으로 지정하여 장애 조치를 위해 재해 복구 애플리케이션을 준비할 수 있습니다.
AWS Trusted Advisor는 비용 최적화, 성능 향상, 보안 및 내결함성 개선을 위해 실행 가능한 알림을 제공합니다. 기업 내 모든 계정에 대해 확인 결과에 대한 집계 상황을 표시하는 보고서를 생성할 수 있습니다
여러 리전 및 계정에 배포된 애플리케이션에 대한 가시성을 유지하기 위해, AWS Systems Manager Explorer를 이용하여 Trusted Advisor 대시보드 및 운영 대시보드를 만들 수 있습니다. 이들 대시보드를 통해, 같은 리소스에 대해 Amazon CloudWatch 및 AWS Config 데이터에 대한 통합적으로 볼 수 있습니다. Amazon Athena를 이용하면, 멀티 리전 및 계정 인벤토리 보기를 위해 각 리소스의 메타 데이터를 통합 할 수 도 있습니다.
또한, CloudWatch 콘솔에서 여러 리전에 배포된 애플리케이션 및 리소스의 지표를 볼 수 있습니다. 교차 계정 기능을 통해 멀티 리전 애플리케이션을 위한 그래프와 대시보드를 쉽게 생성할 수 있습니다.
Amazon OpenSearch Service 는 비정형 및 반정형 로그 파일, 메시지, 지표, 문서, 구성 데이터 등을 집계합니다. 클러스터 간 복제 기능은 사용하면, 액티브-패시브 설정에서 인덱스, 매핑 및 메타데이터를 각 OpenSearch Service 도메인 간에 복제할 수 있습니다. 이렇게 하면 리전 간 지연 시간이 줄어들고 데이터의 고가용성이 보장됩니다.
AWS Resilience Hub 는 애플리케이션의 복원력을 평가하고 추적합니다. 리전 장애 조치를 수행할 때, 애플리케이션이 얼마나 가용성을 잘 유지하는지 확인할 수 있습니다. 예를 들어 애플리케이션에 S3 버킷에 리전 간 복제가 구성되어 있는지 또는 RDS 인스턴스에 리전 간 읽기 전용 복제본이 있는지 확인할 수 있습니다.
아래는 AWS Resilience Hub 평가 결과를 보여줍니다. 예를 들어, Route 53 애플리케이션 복구 컨트롤러를 사용하여 리전 내 Amazon EC2 Auto Scaling 그룹을 설정하여, 장애 조치하기 전에 트래픽을 수락할 준비가 되었는지 확인하고 있습니다.
6.3 인프라 거버넌스 및 운영 관리
애플리케이션을 새로운 국가로 확장한다는 것은 따라야 할 추가 데이터 개인정보 보호법 및 규정이 있을 수 있음을 의미합니다. 이는 국가에 따라 다르므로, 법무팀과 함께 조사하여 애플리케이션에 어떤 영향을 미치는지 완전히 이해하는 것이 좋습니다.
AWS Control Tower를 사용하면, 데이터 상주 요구 사항을 제어하고 충족하기 위한 가드레일을 통해 데이터 규정 준수를 지원합니다. 이러한 가드레일은 서비스 제어 정책(SCP) 및 AWS Config 규칙을 모아 둔 것입니다. 필요한 경우 AWS Control Tower와 독립적으로 구현할 수 있습니다.
AWS Config는 AWS 리소스의 구성 및 기록에 대한 자세한 보기를 제공합니다. 여러 계정 및 리전에서 구성 및 규정 준수 데이터를 수집하여, 중앙 계정에서 계정 또는 리전에 관계없이 리소스에 대한 규정 준수 및 작업에 대한 포괄적인 보기를 제공합니다.
AWS Systems Manager 기능을 사용하면, 애플리케이션이 성장함에 따라 AWS 리소스를 더 쉽게 관리할 수 있습니다. Systems Manager Automation을 자동화된 Runbook을 사용하여 AWS 리소스에 대한 일반적인 유지 관리 및 배포 작업을 단순화합니다. Systems Manager Patch Manager와 페어링 하여, 리전 및 계정 전반의 최신 패치를 유지할 수 있습니다.
아래는 멀티 지역 아키텍처에서 여러 자동화 문서를 실행하는 Systems Manager를 보여줍니다.
7. 전체 보기
지금까지 살펴본 부분을 종합하여 멀티 리전 애플리케이션을 구축하는 방법을 살펴보겠습니다. 리전 전반에 걸쳐 고가용성이 필요한 경우, 그리고 엄격한 일관성보다 성능을 선호하는 아키텍처입니다.
- CloudFormation StackSets는 IaC로 모든 것을 배포합니다. 이렇게 하면 인프라가 여러 리전에 일관되게 배포됩니다.
- AWS Config 규칙은 리소스 구성을 모니터링, 기록 및 평가할 수 있는 중앙 집중식 장소를 제공합니다.
- 관찰 가능성을 높이기 위해 CloudWatch 대시보드, Personal Health 대시보드 및 Trusted Advisor 대시보드로 대시보드를 만들었습니다.
본 아키텍처의 주요 목표는 전 세계 대상으로 확장하는 것이지만, CloudFormation StackSets와 같은 일부 서비스는 리전 1에 의존합니다. 각 리전 내 배포는 정적 안정성을 위해 설정되지만, 리전 1에서 장기간인 장애가 발생한 경우, 시간이 지나면 재해 복구 플레이북에서 리전 2에서 CloudFormation을 변경하게 됩니다.
많은 AWS 서비스에는 다중 리전 아키텍처를 구축하고 관리하는 데 도움이 되는 기능이 있지만 200개 이상의 서비스에서 이러한 기능을 식별하는 것은 압도적일 수 있습니다. 이 블로그에서는 멀티 리전 애플리케이션 구축을 지원하는 기능이 포함된 AWS 서비스를 살펴보았습니다.
시작할 준비가 되셨나요? AWS Well-Architected Labs을 통해 직접 실습을 해보시기 바랍니다!
– Joe Chapman, AWS Sr. Solutions Architect
– Seth Eliot, Principal Reliability Solutions Architect
이 글은 AWS Architecture Blog의 Creating a Multi-Region Application with AWS Services series 시리즈를 한국어로 편집하였습니다.
Leave a Reply