멀티 리전 아키텍처로 글로벌 서비스 설계

전 세계 사용자에게 빠르고 안정적인 서비스를 제공하기 위한 AWS 멀티 리전 아키텍처를 다룹니다. Route 53, Aurora Global Database, S3 복제, DynamoDB Global Tables, 그리고 재해 복구 전략까지 실무에 필요한 모든 것을 배워봅니다.

---

목차

1. 멀티_리전_아키텍처의_장점과_복잡성
2. Route_53_지리_기반_라우팅
3. Aurora_Global_Database_구성
4. S3_교차_리전_복제
5. DynamoDB_Global_Tables
6. 재해_복구_전략

---

1. 멀티 리전 아키텍처의 장점과 복잡성

김개발 씨가 운영하는 서비스가 드디어 해외 진출을 앞두게 되었습니다. 한국에서는 빠르게 동작하던 서비스가 미국이나 유럽 사용자에게는 왜 느리게 느껴질까요?

CTO님이 "멀티 리전 아키텍처를 검토해보세요"라고 말씀하셨는데, 대체 어디서부터 시작해야 할지 막막합니다.

멀티 리전 아키텍처는 하나의 서비스를 전 세계 여러 지역에 분산 배치하는 설계 방식입니다. 마치 글로벌 프랜차이즈 매장이 각 나라마다 지점을 두는 것과 같습니다.

이를 통해 사용자와 가까운 곳에서 서비스를 제공하여 빠른 응답 속도를 보장하고, 한 지역에 장애가 발생해도 다른 지역에서 서비스를 계속할 수 있습니다.

다음 코드를 살펴봅시다.

// 멀티 리전 아키텍처 구성 개념 - AWS CDK
import * as cdk from 'aws-cdk-lib';

// 각 리전별로 독립적인 스택 배포
const regions = ['ap-northeast-2', 'us-east-1', 'eu-west-1'];

regions.forEach(region => {
  // 각 리전에 동일한 인프라 구성
  new GlobalServiceStack(app, `Service-${region}`, {
    env: { region },
    // 리전별 설정 주입
    isPrimary: region === 'ap-northeast-2',
    replicaRegions: regions.filter(r => r !== region)
  });
});

김개발 씨는 스타트업에서 3년차 백엔드 개발자로 일하고 있습니다. 그의 회사가 만든 SaaS 서비스가 국내에서 큰 인기를 얻으면서, 해외 고객들의 문의가 쏟아지기 시작했습니다.

그런데 미국에서 접속한 고객이 "너무 느려서 쓸 수가 없어요"라는 피드백을 보내왔습니다. 박시니어 팀장이 김개발 씨를 불러 말했습니다.

"지금 우리 서버는 서울 리전 하나에만 있잖아요. 미국 사용자가 서울까지 왕복하려면 물리적으로 200ms 이상 걸려요.

멀티 리전으로 가야 할 때가 됐어요." 그렇다면 멀티 리전 아키텍처란 정확히 무엇일까요? 쉽게 비유하자면, 멀티 리전은 마치 전 세계에 체인점을 두는 커피 전문점과 같습니다.

서울에만 매장이 있다면 뉴욕 고객은 커피 한 잔 마시려고 태평양을 건너야 합니다. 하지만 뉴욕에도 매장이 있다면 걸어서 5분이면 됩니다.

AWS의 리전도 마찬가지입니다. 전 세계 30개 이상의 리전에 인프라를 배치하면 사용자와 가까운 곳에서 서비스를 제공할 수 있습니다.

멀티 리전의 첫 번째 장점은 지연 시간 단축입니다. 빛의 속도에도 한계가 있어서, 서울에서 미국 버지니아까지는 약 200ms의 네트워크 지연이 발생합니다.

미국 리전에 서버를 두면 이 지연을 20ms 이하로 줄일 수 있습니다. 두 번째 장점은 고가용성입니다.

2011년 AWS 도쿄 리전에 대규모 장애가 발생했을 때, 단일 리전만 사용하던 서비스들은 수 시간 동안 다운되었습니다. 하지만 멀티 리전으로 구성된 서비스들은 다른 리전으로 트래픽을 우회하여 서비스를 계속할 수 있었습니다.

세 번째 장점은 규정 준수입니다. GDPR 같은 규정은 유럽 사용자의 데이터가 유럽 내에 저장되어야 한다고 요구합니다.

멀티 리전 아키텍처를 사용하면 각 지역의 규정을 준수하면서도 글로벌 서비스를 운영할 수 있습니다. 하지만 멀티 리전에는 복잡성도 따릅니다.

가장 큰 도전은 데이터 일관성입니다. 서울에서 업데이트한 데이터가 미국에도 즉시 반영되어야 할까요?

아니면 약간의 지연을 허용할 수 있을까요? 이 결정에 따라 아키텍처가 완전히 달라집니다.

비용도 무시할 수 없습니다. 리전마다 인프라를 구축하면 비용이 2배, 3배로 늘어납니다.

게다가 리전 간 데이터 전송에도 비용이 발생합니다. 따라서 모든 서비스에 멀티 리전이 필요한 것은 아닙니다.

운영 복잡도 역시 크게 증가합니다. 배포를 여러 리전에 동시에 해야 하고, 모니터링도 각 리전별로 해야 합니다.

장애가 발생하면 어느 리전의 문제인지 빠르게 파악해야 합니다. 김개발 씨는 박시니어 팀장의 설명을 들으며 고개를 끄덕였습니다.

"단순히 서버만 복사하면 되는 줄 알았는데, 생각보다 고려할 게 많네요." 멀티 리전 아키텍처를 성공적으로 구축하려면 Active-Active와 Active-Passive 중 어떤 방식을 선택할지 먼저 결정해야 합니다. Active-Active는 모든 리전이 동시에 트래픽을 처리하고, Active-Passive는 평소에는 한 리전만 사용하다가 장애 시 다른 리전으로 전환합니다.

각각 장단점이 있으며, 서비스의 특성에 맞게 선택해야 합니다.

실전 팁

💡 - 처음부터 완벽한 멀티 리전을 목표로 하지 말고, 가장 중요한 리전 2개부터 시작하세요

• 데이터 일관성 요구사항을 먼저 정의하고, 그에 맞는 데이터베이스 전략을 선택하세요
• 리전 간 장애 조치 테스트를 정기적으로 수행하여 실제 장애 시 대응할 수 있도록 준비하세요

---

2. Route 53 지리 기반 라우팅

멀티 리전에 서버를 배치했다면, 이제 사용자를 가장 가까운 리전으로 안내해야 합니다. 미국 사용자가 서울 서버로 접속하면 멀티 리전의 의미가 없겠죠?

AWS Route 53의 지리 기반 라우팅이 바로 이 문제를 해결합니다.

Route 53 지리 기반 라우팅은 사용자의 위치에 따라 가장 적합한 리전으로 트래픽을 자동 분배하는 DNS 서비스입니다. 마치 공항의 안내 데스크가 승객의 목적지에 따라 적절한 게이트를 알려주는 것과 같습니다.

이를 통해 사용자는 항상 자신과 가까운 서버에 접속하여 빠른 응답을 받을 수 있습니다.

다음 코드를 살펴봅시다.

// Route 53 지리 기반 라우팅 설정 - AWS CDK
import * as route53 from 'aws-cdk-lib/aws-route53';

// 서울 리전 레코드
new route53.ARecord(this, 'SeoulRecord', {
  zone: hostedZone,
  recordName: 'api.myservice.com',
  target: route53.RecordTarget.fromAlias(seoulAlb),
  geoLocation: route53.GeoLocation.country('KR') // 한국 사용자
});

// 미국 리전 레코드
new route53.ARecord(this, 'USRecord', {
  zone: hostedZone,
  recordName: 'api.myservice.com',
  target: route53.RecordTarget.fromAlias(usAlb),
  geoLocation: route53.GeoLocation.country('US') // 미국 사용자
});

// 기본 레코드 (매칭되지 않는 지역)
new route53.ARecord(this, 'DefaultRecord', {
  zone: hostedZone,
  recordName: 'api.myservice.com',
  target: route53.RecordTarget.fromAlias(seoulAlb),
  geoLocation: route53.GeoLocation.default()
});

김개발 씨는 서울과 버지니아 두 리전에 서버를 배포했습니다. 그런데 문제가 생겼습니다.

미국 사용자가 여전히 서울 서버로 접속하는 것이었습니다. "서버를 두 곳에 뒀는데 왜 자동으로 가까운 곳으로 안 가죠?" 박시니어 팀장이 웃으며 대답했습니다.

"서버를 배치하는 것과 사용자를 안내하는 것은 별개예요. 사용자를 적절한 리전으로 보내주는 교통 경찰이 필요해요.

그게 바로 Route 53이에요." Route 53은 AWS의 DNS 서비스입니다. DNS는 도메인 이름을 IP 주소로 변환해주는 인터넷의 전화번호부 같은 존재입니다.

하지만 Route 53은 단순한 DNS가 아닙니다. 사용자의 위치, 서버의 상태, 지연 시간 등을 고려하여 최적의 서버로 안내해주는 스마트한 라우팅 기능을 제공합니다.

**지리 기반 라우팅(Geolocation Routing)**은 사용자의 지리적 위치에 따라 다른 서버로 연결해줍니다. 한국에서 접속하면 서울 리전으로, 미국에서 접속하면 버지니아 리전으로 자동 연결되는 것입니다.

이는 사용자의 IP 주소를 기반으로 위치를 파악합니다. 비유하자면, 지리 기반 라우팅은 마치 전화 상담 센터의 자동 연결 시스템과 같습니다.

한국어로 전화하면 한국 상담원에게, 영어로 전화하면 미국 상담원에게 연결되는 것처럼, DNS 요청의 출발지에 따라 적절한 서버로 안내해줍니다. Route 53에는 비슷하지만 다른 **지연 시간 기반 라우팅(Latency-Based Routing)**도 있습니다.

이는 지리적 위치가 아니라 실제 네트워크 지연 시간을 기준으로 라우팅합니다. 일본 사용자의 경우 지리적으로는 서울이 가깝지만, 네트워크 상황에 따라 도쿄 리전이 더 빠를 수 있습니다.

지연 시간 기반 라우팅은 이런 상황을 자동으로 처리합니다. 위 코드를 살펴보면, 각 리전에 대한 A 레코드를 생성하고 geoLocation 속성으로 어떤 지역의 사용자를 해당 레코드로 보낼지 지정합니다.

대륙 단위로도 설정할 수 있고, 미국처럼 큰 나라는 주 단위로도 설정할 수 있습니다. **기본 레코드(Default Record)**는 매우 중요합니다.

지리 기반 라우팅에서 명시적으로 지정하지 않은 지역의 사용자는 기본 레코드로 연결됩니다. 기본 레코드가 없으면 일부 사용자가 서비스에 접속하지 못하는 심각한 문제가 발생할 수 있습니다.

Route 53의 또 다른 강력한 기능은 **헬스 체크(Health Check)**입니다. 각 리전의 서버 상태를 주기적으로 확인하여, 장애가 발생한 리전으로는 트래픽을 보내지 않습니다.

서울 리전에 장애가 발생하면 한국 사용자도 자동으로 버지니아 리전으로 연결됩니다. **장애 조치 라우팅(Failover Routing)**을 함께 설정하면 더욱 안정적인 서비스가 가능합니다.

Primary 레코드와 Secondary 레코드를 지정하여, Primary에 문제가 생기면 자동으로 Secondary로 전환됩니다. 김개발 씨가 Route 53을 설정하고 나서 미국 동료에게 테스트를 부탁했습니다.

"오, 진짜 빨라졌어! 예전엔 3초 걸리던 게 이제 0.5초면 돼." 미국 사용자가 버지니아 리전으로 자동 연결되면서 체감 성능이 크게 향상된 것입니다.

한 가지 주의할 점은 DNS 캐싱입니다. 사용자의 로컬 DNS나 ISP DNS가 결과를 캐싱하면, 리전 전환이 즉시 반영되지 않을 수 있습니다.

따라서 TTL(Time To Live)을 적절히 설정하는 것이 중요합니다. 일반적으로 60초에서 300초 사이로 설정합니다.

실전 팁

💡 - 지리 기반과 지연 시간 기반 라우팅을 상황에 맞게 선택하세요. 규정 준수가 중요하면 지리 기반, 순수 성능이 중요하면 지연 시간 기반이 적합합니다

• 반드시 기본 레코드를 설정하고, 모든 리전에 헬스 체크를 구성하세요
• TTL을 너무 짧게 설정하면 DNS 쿼리 비용이 증가하고, 너무 길게 설정하면 장애 조치가 느려집니다

---

3. Aurora Global Database 구성

이제 트래픽은 적절한 리전으로 분배됩니다. 하지만 데이터베이스는 어떻게 해야 할까요?

서울에서 저장한 데이터를 미국에서도 읽을 수 있어야 합니다. Aurora Global Database가 이 문제를 해결해줍니다.

Aurora Global Database는 전 세계 여러 리전에 걸쳐 데이터베이스를 복제하는 AWS의 관리형 서비스입니다. 마치 본사의 중요 문서를 각 지사에도 실시간으로 사본을 보내두는 것과 같습니다.

1초 미만의 지연으로 데이터를 복제하여, 어느 리전에서든 빠르게 데이터를 읽을 수 있고, 재해 발생 시 신속한 복구가 가능합니다.

다음 코드를 살펴봅시다.

// Aurora Global Database 구성 - AWS CDK
import * as rds from 'aws-cdk-lib/aws-rds';

// Primary 클러스터 (서울)
const primaryCluster = new rds.DatabaseCluster(this, 'PrimaryCluster', {
  engine: rds.DatabaseClusterEngine.auroraMysql({
    version: rds.AuroraMysqlEngineVersion.VER_3_04_0
  }),
  instances: 2,
  instanceProps: { vpc: primaryVpc },
  // Global Database 활성화
  enableGlobalWriteForwarding: true
});

// Global Database 생성
const globalCluster = new rds.CfnGlobalCluster(this, 'GlobalCluster', {
  globalClusterIdentifier: 'my-global-db',
  sourceDbClusterIdentifier: primaryCluster.clusterIdentifier,
  // 스토리지 레벨 복제로 1초 미만 지연
  engine: 'aurora-mysql'
});

// Secondary 클러스터 (버지니아) - 별도 스택에서 생성
// headless 모드로 읽기 전용 복제본 역할

김개발 씨는 새로운 고민에 빠졌습니다. 서울과 버지니아에 각각 서버를 두었는데, 데이터베이스는 서울에만 있습니다.

미국 서버가 데이터를 조회할 때마다 태평양을 건너 서울 데이터베이스에 접속해야 하니, API 응답이 여전히 느렸습니다. "데이터베이스도 미국에 복사해두면 안 될까요?" 김개발 씨의 질문에 박시니어 팀장이 답했습니다.

"그게 바로 Aurora Global Database예요. AWS가 데이터베이스 복제를 알아서 해줍니다." Aurora Global Database는 Amazon Aurora의 글로벌 복제 기능입니다.

Primary 클러스터에서 데이터 변경이 발생하면, 스토리지 레벨에서 Secondary 클러스터로 복제됩니다. 일반적인 MySQL 복제가 SQL 문을 재실행하는 것과 달리, Aurora는 스토리지 블록 자체를 복제하므로 1초 미만의 지연으로 데이터를 동기화할 수 있습니다.

비유하자면, 일반 복제가 요리 레시피를 보고 다시 요리하는 것이라면, Aurora Global Database는 완성된 요리를 순간이동시키는 것과 같습니다. 훨씬 빠르고 정확합니다.

이 아키텍처에서 **쓰기(Write)**는 Primary 클러스터에서만 가능합니다. 서울이 Primary라면, 데이터를 추가하거나 수정하는 작업은 서울에서 처리됩니다.

하지만 **읽기(Read)**는 모든 리전에서 가능합니다. 미국 사용자가 데이터를 조회할 때는 버지니아의 Secondary 클러스터에서 읽으므로 빠른 응답이 가능합니다.

대부분의 웹 애플리케이션은 읽기 작업이 쓰기 작업보다 훨씬 많습니다. 일반적으로 80~90%가 읽기입니다.

따라서 읽기를 로컬 리전에서 처리하는 것만으로도 큰 성능 향상을 얻을 수 있습니다. Write Forwarding 기능을 활성화하면, Secondary 리전에서 쓰기 요청을 받아도 자동으로 Primary 리전으로 전달해줍니다.

애플리케이션 코드를 수정하지 않고도 글로벌 아키텍처를 구현할 수 있어 편리합니다. 재해 복구 상황에서 Aurora Global Database는 빛을 발합니다.

Primary 리전에 장애가 발생하면, Secondary 클러스터를 1분 이내에 새로운 Primary로 승격시킬 수 있습니다. **RTO(Recovery Time Objective)**가 매우 짧아 비즈니스 연속성을 보장할 수 있습니다.

하지만 주의할 점도 있습니다. 복제 지연이 1초 미만이라고 해도, 완벽한 실시간 동기화는 아닙니다.

서울에서 데이터를 업데이트한 직후 미국에서 조회하면 이전 데이터가 보일 수 있습니다. 이를 **최종적 일관성(Eventual Consistency)**이라고 합니다.

금융 거래처럼 강한 일관성이 필요한 경우에는 반드시 Primary 리전에서 읽고 쓰도록 설계해야 합니다. 비용도 고려해야 합니다.

Aurora Global Database는 각 리전의 스토리지 비용과 리전 간 데이터 전송 비용이 추가로 발생합니다. 하지만 직접 복제를 구현하는 것보다 훨씬 안정적이고 운영 부담이 적습니다.

김개발 씨가 Aurora Global Database를 도입한 후, 미국 사용자의 데이터 조회 속도가 10배 이상 빨라졌습니다. "이제 미국 팀에서도 불만이 없어요!" 기술 선택이 사용자 경험을 얼마나 크게 바꿀 수 있는지 실감하는 순간이었습니다.

실전 팁

💡 - 읽기 위주의 애플리케이션에 가장 효과적입니다. 읽기/쓰기 비율을 분석한 후 도입을 결정하세요

• 강한 일관성이 필요한 기능은 Primary 리전에서 처리하도록 애플리케이션을 설계하세요
• 장애 조치 테스트를 정기적으로 수행하여 실제 상황에서 원활하게 복구할 수 있도록 준비하세요

---

4. S3 교차 리전 복제

데이터베이스는 해결되었습니다. 하지만 사용자가 업로드한 이미지, 동영상, 문서 파일은 어떻게 해야 할까요?

S3에 저장된 정적 파일도 전 세계에서 빠르게 접근할 수 있어야 합니다. S3 교차 리전 복제가 답입니다.

**S3 교차 리전 복제(Cross-Region Replication, CRR)**는 한 리전의 S3 버킷에 저장된 객체를 다른 리전의 버킷으로 자동 복제하는 기능입니다. 마치 중요한 사진을 여러 외장 하드에 백업해두는 것과 같습니다.

이를 통해 사용자가 가까운 리전에서 파일을 다운로드할 수 있고, 한 리전의 데이터가 손실되어도 다른 리전에서 복구할 수 있습니다.

다음 코드를 살펴봅시다.

// S3 교차 리전 복제 설정 - AWS CDK
import * as s3 from 'aws-cdk-lib/aws-s3';

// 소스 버킷 (서울)
const sourceBucket = new s3.Bucket(this, 'SourceBucket', {
  bucketName: 'my-app-assets-ap-northeast-2',
  versioned: true, // CRR 필수 조건
});

// 대상 버킷 (버지니아) - 별도 스택에서 생성
// versioned: true 필수

// 복제 규칙 설정
sourceBucket.addReplicationRule({
  destination: {
    bucket: destinationBucket,
    storageClass: s3.StorageClass.STANDARD
  },
  // 모든 객체 복제
  filter: { prefix: '' },
  // 복제 시간 제어 (15분 내 99.99% 복제 보장)
  replicationTimeControl: {
    enabled: true,
    time: cdk.Duration.minutes(15)
  }
});

김개발 씨의 서비스에는 사용자들이 프로필 사진, 첨부 파일 등을 업로드하는 기능이 있습니다. 이 파일들은 모두 서울 리전의 S3 버킷에 저장되어 있었습니다.

미국 사용자가 이미지를 볼 때마다 서울에서 가져오니, 페이지 로딩이 느렸습니다. "CloudFront를 쓰면 되지 않나요?" 김개발 씨가 물었습니다.

박시니어 팀장이 고개를 끄덕이며 말했습니다. "맞아요, CloudFront가 기본이에요.

하지만 교차 리전 복제를 함께 사용하면 오리진 자체가 가까워지니까 더 효과적이에요. 특히 규정 준수나 재해 복구 측면에서도 중요하고요." **S3 교차 리전 복제(CRR)**는 한 버킷의 객체를 다른 리전의 버킷으로 자동 복사합니다.

서울 버킷에 파일을 업로드하면, AWS가 알아서 버지니아 버킷에도 복사해줍니다. 애플리케이션은 가까운 리전의 버킷에서 파일을 가져오면 됩니다.

CRR을 사용하려면 **버전 관리(Versioning)**가 필수입니다. 소스 버킷과 대상 버킷 모두 버전 관리를 활성화해야 합니다.

버전 관리는 파일의 모든 변경 이력을 보관하여 실수로 삭제하거나 덮어써도 복구할 수 있게 해줍니다. 복제는 비동기로 이루어집니다.

파일을 업로드하면 몇 초에서 몇 분 내에 대상 버킷에 복제됩니다. **복제 시간 제어(RTC)**를 활성화하면 15분 내에 99.99%의 객체가 복제됨을 보장받을 수 있습니다.

규정 준수가 중요한 경우에 유용합니다. 복제 규칙에서 필터를 설정하면 특정 폴더나 파일 유형만 복제할 수 있습니다.

예를 들어 사용자 업로드 파일만 복제하고, 임시 파일은 복제하지 않을 수 있습니다. 비용 최적화에 도움이 됩니다.

**양방향 복제(Bidirectional Replication)**도 가능합니다. 서울에서 버지니아로, 버지니아에서 서울로 양쪽 모두 복제하면, 어느 리전에서 업로드하든 모든 리전에 파일이 존재하게 됩니다.

Active-Active 아키텍처에서 유용합니다. CloudFront와 함께 사용하면 효과가 배가됩니다.

CloudFront는 전 세계 엣지 로케이션에서 콘텐츠를 캐싱하여 더욱 빠르게 전달합니다. CRR로 오리진을 가깝게 하고, CloudFront로 엣지 캐싱을 추가하면 최상의 성능을 얻을 수 있습니다.

비용 측면에서 CRR은 복제된 데이터의 스토리지 비용과 리전 간 전송 비용이 추가됩니다. 모든 파일을 복제할 필요는 없으므로, 자주 접근하는 파일이나 중요한 파일만 선별적으로 복제하는 전략도 고려해볼 만합니다.

삭제 동기화도 설정할 수 있습니다. 소스에서 파일을 삭제하면 대상에서도 삭제하도록 하거나, 백업 목적으로 대상에서는 삭제하지 않도록 설정할 수 있습니다.

용도에 맞게 선택하면 됩니다. 김개발 씨는 프로필 이미지와 자주 사용되는 정적 파일에 CRR을 적용했습니다.

그리고 CloudFront를 통해 전 세계에 배포했습니다. "이미지 로딩 시간이 3초에서 0.3초로 줄었어요!" 사용자 경험이 극적으로 개선되었습니다.

실전 팁

💡 - 버전 관리를 활성화하고, 수명 주기 규칙으로 오래된 버전을 정리하여 스토리지 비용을 관리하세요

• 모든 파일을 복제하지 말고, 비즈니스에 중요한 파일만 선별적으로 복제하세요
• CloudFront와 함께 사용하여 엣지 캐싱의 이점도 누리세요

---

5. DynamoDB Global Tables

관계형 데이터베이스는 Aurora Global Database로 해결했습니다. 하지만 세션 정보, 실시간 게임 상태, IoT 데이터처럼 초고속 읽기/쓰기가 필요한 데이터는 어떻게 할까요?

DynamoDB Global Tables가 이 영역을 담당합니다.

DynamoDB Global Tables는 여러 리전에 걸쳐 완전 관리형 다중 마스터 데이터베이스를 제공합니다. Aurora Global Database와 달리 모든 리전에서 읽기와 쓰기가 모두 가능합니다.

마치 전 세계 모든 지사에서 동시에 문서를 편집할 수 있고, 변경 사항이 자동으로 동기화되는 것과 같습니다.

다음 코드를 살펴봅시다.

// DynamoDB Global Table 구성 - AWS CDK
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';

// Global Table 생성 (자동으로 여러 리전에 복제)
const globalTable = new dynamodb.TableV2(this, 'SessionTable', {
  tableName: 'user-sessions',
  partitionKey: { name: 'sessionId', type: dynamodb.AttributeType.STRING },
  // 온디맨드 용량 (글로벌 테이블에 권장)
  billing: dynamodb.Billing.onDemand(),
  // 복제할 리전 지정
  replicas: [
    { region: 'ap-northeast-2' },  // 서울
    { region: 'us-east-1' },       // 버지니아
    { region: 'eu-west-1' }        // 아일랜드
  ],
  // 충돌 해결: 마지막 쓰기 우선
  // (DynamoDB는 자동으로 last-writer-wins 적용)
});

김개발 씨의 서비스에 실시간 채팅 기능이 추가되었습니다. 사용자의 온라인 상태, 읽음 표시, 타이핑 인디케이터 같은 데이터는 밀리초 단위의 빠른 응답이 필요합니다.

관계형 데이터베이스로는 감당하기 어려운 영역이었습니다. "이런 데이터는 DynamoDB가 적합해요." 박시니어 팀장이 조언했습니다.

"그리고 Global Tables를 사용하면 멀티 리전에서도 빠르게 동작해요. 무엇보다 모든 리전에서 쓰기가 가능하다는 게 큰 장점이에요." DynamoDB는 AWS의 완전 관리형 NoSQL 데이터베이스입니다.

밀리초 단위의 응답 시간을 보장하며, 자동으로 확장되어 어떤 규모의 트래픽도 처리할 수 있습니다. Global Tables는 이 DynamoDB를 여러 리전에 복제하는 기능입니다.

Aurora Global Database와의 가장 큰 차이점은 다중 마스터(Multi-Master) 구조입니다. Aurora는 한 리전에서만 쓰기가 가능하지만, DynamoDB Global Tables는 모든 리전에서 읽기와 쓰기가 모두 가능합니다.

미국 사용자가 미국에서 데이터를 쓰고, 한국 사용자가 한국에서 데이터를 쓸 수 있습니다. 이것이 가능한 이유는 DynamoDB의 충돌 해결 방식 때문입니다.

같은 항목을 여러 리전에서 동시에 수정하면 어떻게 될까요? DynamoDB는 last-writer-wins 방식을 사용합니다.

타임스탬프를 기준으로 가장 마지막에 쓴 값이 최종 값이 됩니다. 이 방식은 대부분의 사용 사례에서 잘 작동합니다.

세션 데이터, 사용자 상태, 설정값 같은 데이터는 "마지막 값이 정답"인 경우가 많기 때문입니다. 하지만 카운터나 잔액 같은 데이터에는 적합하지 않습니다.

동시에 증가시키면 하나의 증가분이 사라질 수 있기 때문입니다. 복제 지연은 보통 1초 미만입니다.

서울에서 데이터를 쓰면 1초 내에 버지니아와 아일랜드에서도 읽을 수 있습니다. 글로벌 채팅 서비스에서도 거의 실시간으로 메시지가 동기화됩니다.

위 코드에서 replicas 속성으로 복제할 리전을 지정합니다. 새로운 리전을 추가하면 AWS가 자동으로 데이터를 복제하고 동기화를 시작합니다.

기존 데이터도 모두 새 리전으로 복사됩니다. 온디맨드(On-Demand) 용량 모드를 사용하면 트래픽에 따라 자동으로 확장됩니다.

글로벌 서비스는 리전별로 트래픽 패턴이 다를 수 있어서, 온디맨드 모드가 관리하기 편합니다. Global Tables는 리전 장애에도 강합니다.

한 리전이 완전히 다운되어도 다른 리전의 테이블은 독립적으로 동작합니다. 장애 리전이 복구되면 자동으로 데이터가 동기화됩니다.

김개발 씨는 실시간 채팅의 읽음 표시, 타이핑 인디케이터, 사용자 온라인 상태를 DynamoDB Global Tables로 구현했습니다. "미국 사용자끼리 채팅해도 한국 서버를 거치지 않으니까 훨씬 빨라요!" 사용자들의 만족도가 크게 올라갔습니다.

실전 팁

💡 - 카운터나 잔액 같은 데이터는 Global Tables 대신 단일 리전에서 처리하고 결과만 복제하세요

• 애플리케이션에서 가장 가까운 리전의 엔드포인트로 접근하도록 설계하세요
• 온디맨드 용량으로 시작하고, 트래픽 패턴이 안정되면 프로비저닝 용량으로 전환을 검토하세요

---

6. 재해 복구 전략

멀티 리전 아키텍처의 또 다른 중요한 목적은 재해 복구입니다. 자연재해, 대규모 정전, 클라우드 리전 장애 등 예상치 못한 사태에도 서비스를 계속 운영할 수 있어야 합니다.

AWS는 Pilot Light, Warm Standby, Multi-Site 세 가지 전략을 제안합니다.

재해 복구(Disaster Recovery, DR) 전략은 비용과 복구 시간 사이의 균형을 결정합니다. Pilot Light는 최소한의 핵심 시스템만 가동하여 비용을 절약하고, Warm Standby는 축소된 규모로 항상 운영하며, Multi-Site는 양쪽 리전이 동등하게 트래픽을 처리합니다.

각 전략은 RTO(복구 시간 목표)와 RPO(복구 시점 목표)에 따라 선택합니다.

다음 코드를 살펴봅시다.

// DR 전략별 아키텍처 개념 - Terraform/CDK 스타일 의사코드

// 1. Pilot Light: 핵심 시스템만 최소 가동
const pilotLight = {
  primary: { ec2: 10, rds: 'active', elasticache: 'active' },
  secondary: { ec2: 0, rds: 'replica', elasticache: 'off' }
  // 장애 시 EC2 시작, RDS 승격 필요 (RTO: 수십 분)
};

// 2. Warm Standby: 축소된 규모로 상시 운영
const warmStandby = {
  primary: { ec2: 10, rds: 'active' },
  secondary: { ec2: 2, rds: 'replica-active' }
  // 장애 시 Auto Scaling으로 확장 (RTO: 수 분)
};

// 3. Multi-Site Active-Active: 완전 이중화
const multiSite = {
  primary: { ec2: 10, rds: 'global-write' },
  secondary: { ec2: 10, rds: 'global-write' }
  // 트래픽 자동 우회 (RTO: 초 단위)
};

어느 날 김개발 씨가 출근하니, 회사가 발칵 뒤집혀 있었습니다. 새벽에 서울 리전에 대규모 장애가 발생했고, 서비스가 6시간 동안 완전히 중단되었던 것입니다.

다행히 김개발 씨의 서비스는 멀티 리전이라 30분 만에 복구했지만, 경영진은 "더 빠른 복구가 가능하지 않나요?"라고 물었습니다. 박시니어 팀장이 설명했습니다.

"재해 복구에는 여러 전략이 있어요. 비용과 복구 시간은 트레이드오프 관계예요.

어느 수준까지 투자할지는 비즈니스 결정이에요." 재해 복구를 논할 때 두 가지 핵심 지표가 있습니다. **RTO(Recovery Time Objective)**는 장애 발생 후 서비스가 복구되기까지의 목표 시간입니다.

**RPO(Recovery Point Objective)**는 복구 시 손실을 감수할 수 있는 데이터의 양을 시간으로 표현한 것입니다. RPO가 1시간이라면 최대 1시간 분량의 데이터 손실을 감수한다는 뜻입니다.

첫 번째 전략은 Pilot Light입니다. 항공기의 조종석 표시등처럼 최소한의 핵심 시스템만 켜두는 방식입니다.

데이터베이스 복제본은 계속 동기화하지만, 애플리케이션 서버는 꺼두거나 최소한만 유지합니다. 장애 발생 시 서버를 시작하고 데이터베이스를 승격시켜야 합니다.

RTO는 수십 분에서 몇 시간 정도이며, 비용은 가장 저렴합니다. 두 번째 전략은 Warm Standby입니다.

Secondary 리전에 축소된 규모의 시스템을 항상 운영합니다. Primary가 EC2 인스턴스 10대라면 Secondary는 2대만 운영하는 식입니다.

장애 발생 시 Auto Scaling으로 빠르게 확장하면 됩니다. RTO는 수 분 정도이며, 비용은 중간 수준입니다.

세 번째 전략은 Multi-Site Active-Active입니다. 양쪽 리전이 동등한 규모로 트래픽을 처리합니다.

평소에도 50:50으로 트래픽을 분산하거나, 지역별로 나누어 처리합니다. 한 리전에 장애가 발생하면 다른 리전이 모든 트래픽을 흡수합니다.

RTO는 거의 0에 가깝고, 사용자는 장애를 인지하지 못할 수도 있습니다. 물론 비용은 가장 높습니다.

어떤 전략을 선택해야 할까요? 이는 순전히 비즈니스 결정입니다.

은행이나 의료 시스템처럼 다운타임이 치명적인 서비스는 Multi-Site가 필수입니다. 반면 내부 도구나 개발 환경은 Pilot Light로 충분할 수 있습니다.

중요한 것은 RTO와 RPO를 명확히 정의하고, 그에 맞는 전략을 선택하는 것입니다. 장애 조치 테스트도 매우 중요합니다.

실제 장애 상황에서 계획대로 동작하는지 검증해야 합니다. Netflix는 Chaos Monkey라는 도구로 프로덕션 환경에서 의도적으로 장애를 일으켜 시스템의 복원력을 테스트합니다.

규모가 작은 회사라도 정기적인 DR 훈련을 해야 합니다. 자동화도 필수입니다.

장애는 새벽 3시에도 발생할 수 있습니다. 수동으로 복구 절차를 수행하면 실수하기 쉽고 시간도 오래 걸립니다.

Route 53 헬스 체크와 연동하여 자동으로 트래픽을 전환하고, 데이터베이스 장애 조치도 자동화해야 합니다. 김개발 씨는 경영진과 논의 끝에 Warm Standby 전략을 선택했습니다.

Multi-Site보다 비용을 절약하면서도 5분 이내 복구가 가능했습니다. "다음에 장애가 나도 걱정 없어요.

자동으로 전환되거든요." 김개발 씨의 말에 박시니어 팀장이 덧붙였습니다. "하지만 테스트는 계속해야 해요.

안 쓰는 DR 시스템은 작동 안 할 수도 있거든요."

실전 팁

💡 - RTO와 RPO를 먼저 정의하고, 비즈니스 이해관계자와 합의한 후 전략을 선택하세요

• 분기별로 DR 테스트를 수행하고, 결과를 문서화하세요
• 장애 조치는 최대한 자동화하여 인적 오류와 복구 시간을 최소화하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!