Transit Gateway 피어링으로 글로벌 네트워크 구축

AWS Transit Gateway 피어링을 활용하여 전 세계 리전을 하나의 네트워크로 연결하는 방법을 알아봅니다. 글로벌 서비스 구축에 필요한 네트워크 아키텍처의 핵심을 쉽게 설명합니다.

---

목차

1. 글로벌_네트워크의_필요성
2. 리전_간_Transit_Gateway_피어링
3. 교차_리전_라우팅_설정
4. 대륙별_Transit_Gateway_허브_구성
5. 레이턴시_기반_라우팅_전략
6. 글로벌_재해_복구_DR_아키텍처

---

1. 글로벌 네트워크의 필요성

글로벌 서비스를 운영하는 스타트업에 입사한 김개발 씨는 첫 출근 날부터 당황했습니다. 한국 사용자는 빠른데 미국 사용자는 왜 이렇게 느리다는 걸까요?

선배 박시니어 씨가 네트워크 구성도를 보여주며 설명을 시작했습니다.

글로벌 네트워크란 전 세계에 흩어진 서버와 서비스를 하나의 통합된 네트워크로 연결하는 것입니다. 마치 전 세계 지사를 본사와 전용선으로 연결하는 것과 같습니다.

이를 통해 어느 나라 사용자든 빠르고 안정적인 서비스를 경험할 수 있게 됩니다.

다음 코드를 살펴봅시다.

// AWS CDK로 글로벌 네트워크 필요성 확인을 위한 레이턴시 측정
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

// 각 리전별 VPC 정의 - 글로벌 서비스의 시작점
const regions = ['ap-northeast-2', 'us-east-1', 'eu-west-1'];

// 리전 간 통신 시 인터넷 경유 vs 전용 연결 비교
const internetLatency = 150; // ms - 인터넷 경유 시
const directConnectLatency = 50; // ms - 전용 연결 시

// 글로벌 네트워크가 필요한 이유: 3배의 성능 차이
console.log(`레이턴시 개선: ${internetLatency - directConnectLatency}ms 단축`);

김개발 씨는 입사 첫 주에 흥미로운 사실을 발견했습니다. 회사의 서비스는 한국, 미국, 유럽에 서버를 두고 있었지만, 각 서버가 마치 외딴 섬처럼 따로 놀고 있었던 것입니다.

"선배님, 왜 미국 서버에서 한국 데이터베이스에 접근하는 게 이렇게 느린 거죠?" 박시니어 씨는 화이트보드에 세계 지도를 그리며 설명했습니다. "지금 우리 네트워크는 각 리전이 인터넷을 통해 통신하고 있어요.

마치 서울에서 뉴욕으로 편지를 보낼 때 일반 우편을 쓰는 것과 같죠." 글로벌 네트워크의 필요성은 바로 여기서 시작됩니다. 인터넷을 경유하면 데이터가 수많은 라우터를 거치며 지연이 발생합니다.

게다가 경로도 예측할 수 없어서 어떤 날은 빠르고 어떤 날은 느립니다. 쉽게 비유하자면, 글로벌 네트워크는 마치 전 세계 지사를 전용 고속도로로 연결하는 것과 같습니다.

일반 도로를 이용하면 신호등도 만나고 교통 체증도 겪지만, 전용 고속도로는 목적지까지 막힘없이 달릴 수 있습니다. AWS에서는 이런 전용 고속도로 역할을 Transit Gateway가 담당합니다.

각 리전에 Transit Gateway를 배치하고, 이들을 서로 연결하면 AWS 백본 네트워크를 통해 데이터가 이동합니다. 그렇다면 글로벌 네트워크가 없으면 어떤 문제가 발생할까요?

첫째, 레이턴시 문제입니다. 사용자 요청이 여러 대륙을 오가며 수백 밀리초가 지연됩니다.

둘째, 보안 문제입니다. 인터넷을 경유하면 데이터가 노출될 위험이 있습니다.

셋째, 안정성 문제입니다. 인터넷 경로는 예측 불가능하여 서비스 품질이 들쭉날쭉합니다.

김개발 씨는 고개를 끄덕였습니다. "그래서 Transit Gateway 피어링이 필요한 거군요!" 박시니어 씨가 미소 지었습니다.

"맞아요. 이제 우리 회사도 진정한 글로벌 네트워크를 구축할 때가 됐어요." 글로벌 네트워크를 구축하면 전 세계 어디서든 일관된 성능을 제공할 수 있습니다.

이것이 바로 글로벌 서비스의 첫걸음입니다.

실전 팁

💡 - 글로벌 서비스를 계획할 때는 주요 사용자 지역을 먼저 파악하세요

• 레이턴시 측정 도구를 활용하여 현재 네트워크 상태를 진단하세요
• Transit Gateway는 리전당 하나씩 배치하는 것이 기본 원칙입니다

---

2. 리전 간 Transit Gateway 피어링

글로벌 네트워크의 필요성을 이해한 김개발 씨는 이제 실제 구현에 들어갔습니다. 하지만 서울 리전의 Transit Gateway를 버지니아 리전과 어떻게 연결해야 할지 막막했습니다.

박시니어 씨가 Transit Gateway 피어링의 세계로 안내합니다.

Transit Gateway 피어링은 서로 다른 리전에 있는 Transit Gateway를 직접 연결하는 기능입니다. 마치 두 도시의 고속도로 톨게이트를 전용 터널로 연결하는 것과 같습니다.

이를 통해 AWS 백본 네트워크를 활용한 안전하고 빠른 리전 간 통신이 가능해집니다.

다음 코드를 살펴봅시다.

// Transit Gateway 피어링 설정 - AWS CDK
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

// 서울 리전 Transit Gateway 생성
const seoulTgw = new ec2.CfnTransitGateway(this, 'SeoulTGW', {
  description: 'Seoul Region Transit Gateway',
  autoAcceptSharedAttachments: 'enable',
  defaultRouteTableAssociation: 'enable',
  defaultRouteTablePropagation: 'enable',
  tags: [{ key: 'Name', value: 'seoul-tgw' }]
});

// 피어링 연결 요청 (버지니아 TGW ID 필요)
const peeringAttachment = new ec2.CfnTransitGatewayPeeringAttachment(
  this, 'SeoulToVirginiaPeering', {
    transitGatewayId: seoulTgw.ref,
    peerTransitGatewayId: 'tgw-virginia-id', // 버지니아 TGW
    peerRegion: 'us-east-1',
    peerAccountId: cdk.Aws.ACCOUNT_ID
  }
);

김개발 씨는 AWS 콘솔 앞에서 잠시 멈췄습니다. Transit Gateway는 만들었는데, 이걸 어떻게 다른 리전과 연결하지?

박시니어 씨가 옆에 앉으며 말했습니다. "피어링은 마치 악수와 같아요.

한쪽에서 손을 내밀고, 상대방이 받아줘야 연결이 완성되죠." Transit Gateway 피어링의 작동 방식은 생각보다 단순합니다. 먼저 한 리전에서 피어링 요청을 보냅니다.

그러면 상대 리전에서 이 요청을 수락해야 합니다. 이 2단계 프로세스는 의도치 않은 연결을 방지하는 보안 장치입니다.

피어링이 완료되면 두 Transit Gateway 사이에 가상의 전용선이 생깁니다. 이 연결은 인터넷을 거치지 않고 AWS의 글로벌 백본 네트워크를 통해 이루어집니다.

"선배님, 그런데 피어링 연결은 비용이 많이 들지 않나요?" 박시니어 씨가 대답했습니다. "피어링 자체는 무료예요.

다만 데이터 전송량에 따라 비용이 발생하죠. 하지만 인터넷 경유 비용과 비교하면 오히려 저렴한 경우가 많아요." 중요한 점은 피어링이 비전이적이라는 것입니다.

서울과 버지니아가 피어링되고, 버지니아와 프랑크푸르트가 피어링되어도, 서울에서 프랑크푸르트로 직접 갈 수는 없습니다. 별도의 피어링이 필요합니다.

김개발 씨는 코드를 작성하기 시작했습니다. 서울 리전에서 피어링 요청을 보내고, 버지니아 리전 콘솔에서 수락 버튼을 누르자 상태가 Available로 바뀌었습니다.

"와, 생각보다 간단하네요!" 하지만 박시니어 씨가 말했습니다. "아직 끝이 아니에요.

피어링을 만들었다고 바로 통신이 되는 건 아니거든요. 라우팅 설정이 필요해요." 피어링 연결은 도로를 닦은 것과 같습니다.

도로가 있어도 이정표가 없으면 목적지를 찾을 수 없듯이, 라우팅 테이블 설정이 반드시 필요합니다.

실전 팁

💡 - 피어링 요청 시 상대 리전의 Transit Gateway ID를 정확히 확인하세요

• 피어링은 같은 AWS 계정뿐 아니라 다른 계정과도 가능합니다
• 피어링 상태가 Available이 되어야 다음 단계로 진행할 수 있습니다

---

3. 교차 리전 라우팅 설정

Transit Gateway 피어링까지 완료한 김개발 씨는 자신만만하게 테스트를 시작했습니다. 하지만 서울 VPC에서 버지니아 VPC로 ping이 가지 않습니다.

뭐가 문제일까요? 박시니어 씨가 라우팅 테이블의 비밀을 알려줍니다.

교차 리전 라우팅은 피어링된 Transit Gateway 간에 트래픽이 올바른 목적지로 흘러가도록 경로를 지정하는 설정입니다. 마치 내비게이션에 목적지를 입력하는 것처럼, 각 네트워크 대역이 어디로 가야 하는지 명시해야 합니다.

이 설정이 없으면 연결된 도로가 있어도 데이터는 길을 찾지 못합니다.

다음 코드를 살펴봅시다.

// 교차 리전 라우팅 설정 - AWS CDK
import * as ec2 from 'aws-cdk-lib/aws-ec2';

// 서울 TGW 라우팅 테이블에 버지니아 경로 추가
const seoulToVirginiaRoute = new ec2.CfnTransitGatewayRoute(
  this, 'SeoulToVirginiaRoute', {
    transitGatewayRouteTableId: seoulRouteTableId,
    destinationCidrBlock: '10.1.0.0/16', // 버지니아 VPC CIDR
    transitGatewayAttachmentId: peeringAttachmentId // 피어링 연결 ID
  }
);

// 버지니아 TGW 라우팅 테이블에 서울 경로 추가
const virginiaToSeoulRoute = new ec2.CfnTransitGatewayRoute(
  this, 'VirginiaToSeoulRoute', {
    transitGatewayRouteTableId: virginiaRouteTableId,
    destinationCidrBlock: '10.0.0.0/16', // 서울 VPC CIDR
    transitGatewayAttachmentId: peeringAttachmentId
  }
);

// VPC 라우팅 테이블도 업데이트 필수!
// 각 VPC의 서브넷 라우팅 테이블에 상대 리전 CIDR 추가

김개발 씨의 화면에는 빨간색 오류 메시지가 떠 있었습니다. "Request timed out." 분명히 피어링 상태는 Available인데 왜 통신이 안 되는 걸까요?

박시니어 씨가 웃으며 말했습니다. "도로를 만들었다고 자동으로 길을 찾아가진 않아요.

이정표가 필요하죠." 라우팅 테이블은 네트워크 세계의 이정표입니다. 특정 IP 대역으로 가려면 어떤 경로를 타야 하는지 알려주는 역할을 합니다.

Transit Gateway 피어링에서 라우팅 설정은 세 군데에서 해야 합니다. 첫째, 서울 Transit Gateway의 라우팅 테이블입니다.

버지니아 VPC 대역(10.1.0.0/16)으로 가는 트래픽은 피어링 연결로 보내라고 설정합니다. 둘째, 버지니아 Transit Gateway의 라우팅 테이블입니다.

마찬가지로 서울 VPC 대역(10.0.0.0/16)으로 가는 트래픽을 피어링 연결로 보내도록 설정합니다. 여기서 중요한 점이 있습니다.

라우팅은 반드시 양방향으로 설정해야 합니다. 편지를 보내려면 가는 길도 알아야 하지만, 답장을 받으려면 오는 길도 있어야 하기 때문입니다.

셋째, 각 VPC의 서브넷 라우팅 테이블도 업데이트해야 합니다. VPC 내 EC2 인스턴스가 다른 리전으로 가는 트래픽을 Transit Gateway로 보내도록 설정해야 합니다.

"선배님, 이게 좀 복잡하네요. 리전이 늘어나면 설정할 게 더 많아지겠죠?" 박시니어 씨가 고개를 끄덕였습니다.

"맞아요. 그래서 CIDR 설계가 중요해요.

처음부터 IP 대역을 체계적으로 계획하면 라우팅 관리가 훨씬 쉬워져요." 실무에서는 흔히 이런 규칙을 사용합니다. 아시아 리전은 10.0.0.0/8 대역, 미주 리전은 10.64.0.0/8 대역, 유럽 리전은 10.128.0.0/8 대역.

이렇게 대륙별로 대역을 나누면 라우팅 규칙을 단순화할 수 있습니다. 김개발 씨는 라우팅 테이블을 하나씩 설정했습니다.

그리고 다시 ping 테스트. 이번에는 초록색 성공 메시지가 떴습니다.

"드디어 됐어요!"

실전 팁

💡 - CIDR 설계는 글로벌 네트워크의 기초입니다. 처음부터 계획적으로 설계하세요

• 라우팅 문제 발생 시 VPC Flow Logs를 활용하면 어디서 막히는지 확인할 수 있습니다
• 라우팅 테이블 변경은 즉시 적용되므로 운영 환경에서는 신중하게 진행하세요

---

4. 대륙별 Transit Gateway 허브 구성

서울과 버지니아 연결에 성공한 김개발 씨에게 새로운 미션이 떨어졌습니다. 유럽 리전도 추가하고, 아시아에 싱가포르와 도쿄도 연결해야 합니다.

리전마다 피어링을 만들다 보니 벌써 머리가 아픕니다. 박시니어 씨가 허브 앤 스포크 아키텍처를 제안합니다.

허브 앤 스포크 아키텍처는 중앙 허브 Transit Gateway를 두고 나머지 리전들이 허브에 연결되는 구조입니다. 마치 항공사의 허브 공항처럼, 모든 지점이 허브를 경유하면 연결 수를 크게 줄일 수 있습니다.

대륙별로 허브를 두면 글로벌 네트워크를 효율적으로 관리할 수 있습니다.

다음 코드를 살펴봅시다.

// 대륙별 허브 앤 스포크 아키텍처 구성
// 아시아 허브: 싱가포르, 미주 허브: 버지니아, 유럽 허브: 프랑크푸르트

interface RegionalHub {
  region: string;
  role: 'hub' | 'spoke';
  hubRegion?: string;
  cidrBlock: string;
}

const globalArchitecture: RegionalHub[] = [
  // 아시아 태평양 허브 구성
  { region: 'ap-southeast-1', role: 'hub', cidrBlock: '10.0.0.0/12' },
  { region: 'ap-northeast-2', role: 'spoke', hubRegion: 'ap-southeast-1', cidrBlock: '10.16.0.0/16' },
  { region: 'ap-northeast-1', role: 'spoke', hubRegion: 'ap-southeast-1', cidrBlock: '10.17.0.0/16' },

  // 미주 허브 구성
  { region: 'us-east-1', role: 'hub', cidrBlock: '10.64.0.0/12' },
  { region: 'us-west-2', role: 'spoke', hubRegion: 'us-east-1', cidrBlock: '10.80.0.0/16' },

  // 유럽 허브 구성
  { region: 'eu-central-1', role: 'hub', cidrBlock: '10.128.0.0/12' },
];

// 허브 간 피어링만 설정 (3개 연결로 전체 연결 완성)

김개발 씨는 화이트보드에 그려진 네트워크 구성도를 보며 한숨을 쉬었습니다. 6개 리전을 모두 연결하려면 피어링이 15개나 필요했습니다.

관리가 불가능해 보였습니다. 박시니어 씨가 새로운 그림을 그리기 시작했습니다.

"허브 앤 스포크라는 패턴이 있어요. 비행기 노선을 생각해보세요." 인천공항에서 뉴욕, LA, 시카고, 마이애미로 직항을 모두 운영하면 비용이 엄청납니다.

하지만 인천에서 뉴욕 허브로 간 다음, 뉴욕에서 미국 내 도시로 연결하면 훨씬 효율적입니다. 네트워크도 마찬가지입니다.

모든 리전을 서로 직접 연결하는 대신, 대륙별 허브를 지정합니다. 아시아태평양은 싱가포르를 허브로 삼습니다.

지리적으로 중앙에 위치하고 AWS 인프라가 잘 갖춰져 있기 때문입니다. 서울, 도쿄, 시드니는 싱가포르 허브에 연결됩니다.

미주는 버지니아(us-east-1)가 허브입니다. AWS의 가장 오래된 리전이자 서비스가 가장 먼저 출시되는 곳입니다.

오레곤, 캘리포니아는 버지니아에 연결됩니다. 유럽은 프랑크푸르트가 허브 역할을 합니다.

아일랜드, 파리, 런던이 여기에 연결됩니다. "그러면 허브끼리만 피어링하면 되는 거네요?" 박시니어 씨가 고개를 끄덕였습니다.

"맞아요. 6개 리전을 15개 피어링 대신 5개 피어링으로 연결할 수 있어요." 물론 이 구조에는 트레이드오프가 있습니다.

서울에서 도쿄로 가는 트래픽이 싱가포르를 경유해야 합니다. 약간의 레이턴시 증가가 있을 수 있습니다.

하지만 관리 복잡도가 크게 줄어들고, 비용도 절감됩니다. 대부분의 경우 이 정도 레이턴시 증가는 허용 범위 내입니다.

김개발 씨는 새로운 아키텍처를 적용하기로 했습니다. 허브 리전을 먼저 설정하고, 스포크 리전들을 하나씩 연결해 나갔습니다.

실전 팁

💡 - 허브 리전은 지리적 중심지와 AWS 인프라 성숙도를 고려하여 선정하세요

• 허브 리전에 장애가 생기면 전체 대륙이 영향받으므로 이중화를 고려하세요
• 스포크 간 직접 통신이 빈번하다면 추가 피어링을 검토하세요

---

5. 레이턴시 기반 라우팅 전략

글로벌 네트워크 구축을 마친 김개발 씨에게 운영팀에서 연락이 왔습니다. 유럽 사용자들이 가끔 아시아 서버로 연결된다는 것입니다.

박시니어 씨와 함께 레이턴시 기반 라우팅의 세계로 들어갑니다.

레이턴시 기반 라우팅은 사용자를 가장 응답이 빠른 리전으로 자동 연결하는 전략입니다. 마치 내비게이션이 실시간 교통 상황을 반영하여 가장 빠른 경로를 안내하는 것처럼, 네트워크 상태에 따라 최적의 경로를 선택합니다.

Route 53과 Transit Gateway를 조합하여 구현합니다.

다음 코드를 살펴봅시다.

// Route 53 레이턴시 기반 라우팅 + Transit Gateway 연동
import * as route53 from 'aws-cdk-lib/aws-route53';
import * as elbv2 from 'aws-cdk-lib/aws-elasticloadbalancingv2';

// 각 리전별 ALB 엔드포인트 정의
const regionalEndpoints = {
  'ap-northeast-2': 'alb-seoul.example.com',
  'us-east-1': 'alb-virginia.example.com',
  'eu-central-1': 'alb-frankfurt.example.com'
};

// 레이턴시 기반 레코드 생성
Object.entries(regionalEndpoints).forEach(([region, endpoint]) => {
  new route53.CfnRecordSet(this, `LatencyRecord-${region}`, {
    hostedZoneId: hostedZone.hostedZoneId,
    name: 'api.example.com',
    type: 'CNAME',
    ttl: '60',
    setIdentifier: region,
    region: region, // 레이턴시 라우팅 활성화
    resourceRecords: [endpoint]
  });
});

// Health Check로 장애 리전 자동 제외

김개발 씨는 모니터링 대시보드를 확인했습니다. 분명히 독일 사용자인데 서울 서버에 접속한 기록이 있었습니다.

왜 이런 일이 발생한 걸까요? 박시니어 씨가 설명했습니다.

"지금 우리 DNS는 라운드 로빈으로 설정되어 있어요. 순서대로 서버를 할당하니까 가끔 멀리 있는 서버로 연결되는 거죠." 레이턴시 기반 라우팅은 이 문제를 해결합니다.

AWS Route 53의 레이턴시 라우팅 정책을 사용하면, 사용자의 위치에서 가장 응답이 빠른 리전으로 자동 연결됩니다. 작동 원리는 이렇습니다.

AWS는 전 세계 곳곳에서 각 리전까지의 레이턴시를 지속적으로 측정합니다. 사용자가 DNS 요청을 보내면, AWS는 해당 사용자 위치에서 가장 레이턴시가 낮은 리전의 IP를 반환합니다.

"마치 실시간 교통 정보를 반영하는 내비게이션 같네요!" 김개발 씨의 비유가 정확했습니다. 일반 내비게이션은 최단 거리만 알려주지만, 실시간 교통 내비게이션은 막히는 구간을 피해 가장 빠른 경로를 안내합니다.

레이턴시 기반 라우팅을 Transit Gateway와 결합하면 더욱 강력해집니다. 사용자가 가장 가까운 리전에 도착하면, 그 리전의 Transit Gateway를 통해 필요한 다른 리전의 리소스에도 빠르게 접근할 수 있습니다.

여기에 Health Check를 추가하면 장애 대응까지 완벽해집니다. 특정 리전에 문제가 생기면 Health Check가 이를 감지하고, Route 53은 자동으로 해당 리전을 라우팅에서 제외합니다.

김개발 씨는 Route 53 콘솔에서 레이턴시 라우팅을 설정했습니다. 각 리전별로 레코드를 만들고, Health Check도 연결했습니다.

테스트 결과는 만족스러웠습니다. 유럽 테스트 서버에서 접속하면 프랑크푸르트로, 아시아에서 접속하면 서울로 자동 연결되었습니다.

"이제 진정한 글로벌 서비스가 됐네요!"

실전 팁

💡 - TTL을 너무 길게 설정하면 리전 전환이 느려집니다. 60초 정도가 적당합니다

• Health Check 간격은 10초 또는 30초 중 서비스 특성에 맞게 선택하세요
• Weighted 라우팅과 결합하면 카나리 배포도 가능합니다

---

6. 글로벌 재해 복구 DR 아키텍처

어느 날 새벽, 김개발 씨의 휴대폰이 울렸습니다. 아시아 리전에 대규모 장애가 발생했다는 알림이었습니다.

다행히 미리 구축해둔 DR 아키텍처 덕분에 서비스는 유럽 리전에서 계속 운영되고 있었습니다. 글로벌 DR 아키텍처의 중요성을 실감한 순간이었습니다.

글로벌 DR 아키텍처는 한 리전 전체가 장애를 겪어도 다른 리전에서 서비스를 계속 운영할 수 있게 하는 구조입니다. Transit Gateway 피어링은 이 구조의 핵심 인프라입니다.

마치 회사에 본사와 백업 사무실이 있어서 본사에 문제가 생겨도 업무가 중단되지 않는 것과 같습니다.

다음 코드를 살펴봅시다.

// 글로벌 DR 아키텍처 구성 - 멀티 리전 페일오버
interface DRConfiguration {
  primaryRegion: string;
  drRegion: string;
  rpo: string; // Recovery Point Objective
  rto: string; // Recovery Time Objective
}

const drConfig: DRConfiguration = {
  primaryRegion: 'ap-northeast-2', // 서울 (Primary)
  drRegion: 'us-east-1',           // 버지니아 (DR)
  rpo: '1 hour',                   // 최대 1시간 데이터 손실 허용
  rto: '15 minutes'                // 15분 내 복구 목표
};

// Transit Gateway 피어링을 통한 데이터 동기화 경로
const drPeering = {
  primaryTgw: 'tgw-seoul',
  drTgw: 'tgw-virginia',
  replicationCidr: '10.200.0.0/16', // 복제 전용 대역

  // 장애 감지 시 자동 페일오버
  failoverTrigger: 'Route53 Health Check',
  dnsFailoverTime: '60 seconds'
};

// Aurora Global Database + S3 Cross-Region Replication 활용

새벽 3시, 김개발 씨는 긴급 알림에 잠에서 깼습니다. "서울 리전 장애 발생." 심장이 쿵 내려앉았습니다.

하지만 서비스 모니터링 대시보드를 확인하니 예상 외로 평온했습니다. 사용자들은 정상적으로 서비스를 이용하고 있었습니다.

DR 아키텍처가 제대로 작동한 것입니다. **재해 복구(Disaster Recovery)**란 예상치 못한 대규모 장애에서 서비스를 복구하는 체계입니다.

글로벌 DR은 한 리전 전체가 마비되어도 다른 리전에서 서비스를 이어갈 수 있게 합니다. 박시니어 씨가 평소에 강조하던 말이 떠올랐습니다.

"장애는 '만약'이 아니라 '언제'의 문제예요." Transit Gateway 피어링은 글로벌 DR의 핵심 인프라입니다. Primary 리전과 DR 리전 사이에 안정적인 데이터 동기화 경로를 제공하기 때문입니다.

DR 아키텍처를 설계할 때는 두 가지 지표가 중요합니다. **RPO(Recovery Point Objective)**는 장애 시 허용 가능한 최대 데이터 손실량입니다.

1시간 RPO라면 최악의 경우 1시간 치 데이터를 잃을 수 있다는 뜻입니다. **RTO(Recovery Time Objective)**는 장애 발생 후 서비스 복구까지 걸리는 최대 시간입니다.

15분 RTO라면 15분 안에 서비스가 다시 정상화되어야 합니다. 김개발 씨의 회사는 Aurora Global Database를 사용하고 있었습니다.

Primary 리전의 데이터가 Transit Gateway 피어링을 통해 DR 리전으로 거의 실시간 복제됩니다. Route 53 Health Check가 Primary 리전 장애를 감지하면, 자동으로 DNS를 DR 리전으로 전환합니다.

사용자들은 장애를 거의 인지하지 못합니다. "이렇게 잘 작동하니까 그동안 준비한 보람이 있네요." 박시니어 씨가 미소 지었습니다.

"DR은 평소에는 비용처럼 보이지만, 장애가 발생하면 가치를 증명하죠. 오늘 밤처럼요." 아침이 되어 서울 리전이 복구되었습니다.

김개발 씨는 Failback 절차를 진행하며 생각했습니다. 글로벌 네트워크와 DR 아키텍처는 선택이 아닌 필수라는 것을.

실전 팁

💡 - DR 테스트를 정기적으로 수행하세요. 실제 장애 시 처음 해보면 실수하기 쉽습니다

• RPO와 RTO는 비즈니스 요구사항에 맞게 설정하세요. 더 짧을수록 비용이 증가합니다
• Runbook을 문서화하여 장애 시 누구나 복구 절차를 수행할 수 있게 하세요

---

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