AWS Route 53 라우팅 정책 완벽 가이드

AWS Route 53의 6가지 라우팅 정책을 실무 관점에서 완벽 정리합니다. 단순 라우팅부터 장애 조치까지, 초급 개발자도 쉽게 이해할 수 있도록 실전 예제와 함께 설명합니다.

1. 단순 라우팅

어느 날 김개발 씨가 첫 웹사이트를 AWS에 배포했습니다. 도메인을 연결하려고 Route 53을 열었는데, "라우팅 정책을 선택하세요"라는 문구가 보였습니다.

"라우팅 정책이 뭐지?" 선배 박시니어 씨에게 물었더니, "가장 기본은 단순 라우팅이야"라고 답했습니다.

단순 라우팅은 하나의 도메인을 하나의 리소스에 연결하는 가장 기본적인 방식입니다. 마치 전화번호부에서 이름 하나에 전화번호 하나를 매칭하는 것과 같습니다.

복잡한 설정 없이 빠르게 도메인을 연결할 수 있습니다.

다음 코드를 살펴봅시다.

// AWS SDK를 사용한 단순 라우팅 레코드 생성 예제
const AWS = require('aws-sdk');
const route53 = new AWS.Route53();

const params = {
  HostedZoneId: 'Z1234567890ABC',
  ChangeBatch: {
    Changes: [{
      Action: 'CREATE',
      ResourceRecordSet: {
        Name: 'www.example.com',
        Type: 'A',
        TTL: 300,
        // 단순 라우팅: 하나의 IP 주소로 연결
        ResourceRecords: [{ Value: '192.0.2.1' }]
      }
    }]
  }
};

route53.changeResourceRecordSets(params, (err, data) => {
  if (err) console.log(err);
  else console.log('레코드 생성 완료:', data);
});

김개발 씨는 AWS에 웹서버를 하나 띄웠습니다. EC2 인스턴스의 IP 주소는 192.0.2.1입니다.

이제 example.com이라는 도메인을 구매했으니, 이 도메인으로 접속하면 자신의 서버로 연결되게 하고 싶습니다. 어떻게 해야 할까요?

바로 여기서 Route 53의 단순 라우팅이 등장합니다. 단순 라우팅이란 무엇일까요? 쉽게 비유하자면, 단순 라우팅은 마치 우체국의 주소록과 같습니다.

"김개발"이라는 이름에 "서울시 강남구 123번지"라는 주소 하나만 적혀 있는 것처럼, 하나의 도메인 이름에 하나의 목적지만 지정하는 방식입니다. www.example.com이라는 도메인에 192.0.2.1이라는 IP 주소를 연결하면, 사용자가 브라우저에 www.example.com을 입력했을 때 자동으로 해당 IP로 연결됩니다.

왜 단순 라우팅이 필요할까요? 인터넷 초창기에는 모든 웹사이트가 숫자로 된 IP 주소로 접속해야 했습니다. 192.168.1.1 같은 숫자를 외워야 했죠.

하지만 사람이 숫자를 외우기는 쉽지 않았습니다. 더 큰 문제는 서버 IP가 바뀔 때마다 모든 사용자에게 새로운 주소를 알려야 한다는 것이었습니다.

매우 불편했습니다. 관리도 복잡했고, 실수하기도 쉬웠습니다.

DNS의 등장 바로 이런 문제를 해결하기 위해 DNS(Domain Name System)가 등장했습니다. 그리고 AWS에서 제공하는 DNS 서비스가 바로 Route 53입니다.

단순 라우팅을 사용하면 기억하기 쉬운 도메인 이름을 사용할 수 있습니다. 또한 나중에 서버 IP가 바뀌어도 Route 53 설정만 변경하면 됩니다.

사용자는 여전히 같은 도메인으로 접속하면 됩니다. 코드 분석 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 AWS SDK를 불러오고 Route53 객체를 생성합니다. HostedZoneId는 여러분이 관리하는 도메인의 고유 식별자입니다.

Route 53에서 도메인을 등록하면 자동으로 할당됩니다. ResourceRecordSet 부분이 핵심입니다.

Name에는 연결하려는 도메인을 입력합니다. Type은 'A'인데, 이는 도메인을 IPv4 주소로 연결한다는 의미입니다.

TTL은 300초로 설정했는데, 이는 DNS 정보를 5분간 캐시하라는 뜻입니다. 마지막으로 ResourceRecords에 실제 서버의 IP 주소를 입력합니다.

이렇게 하면 도메인과 IP가 연결됩니다. 실무 활용 사례 실제 현업에서는 어떻게 활용할까요?

예를 들어 개인 블로그를 만든다고 가정해봅시다. EC2 인스턴스 하나에 WordPress를 설치하고, myblog.com이라는 도메인을 연결하고 싶습니다.

이런 경우 단순 라우팅이 완벽한 선택입니다. 스타트업 초기 단계에서도 자주 사용됩니다.

서버가 하나뿐이고, 트래픽이 많지 않을 때는 굳이 복잡한 라우팅 정책이 필요 없습니다. 단순 라우팅으로 빠르게 서비스를 시작할 수 있습니다.

주의사항 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 단순 라우팅에 여러 개의 IP 주소를 등록하는 것입니다.

이렇게 해도 작동은 하지만, Route 53이 무작위로 하나의 IP를 반환합니다. 제대로 된 로드 밸런싱이 아닙니다.

따라서 서버가 여러 대라면 다른 라우팅 정책을 사용해야 합니다. 단순 라우팅은 말 그대로 서버 하나를 연결할 때만 사용하는 것이 좋습니다.

정리 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다.

"아, 그럼 지금은 서버가 하나니까 단순 라우팅을 쓰면 되겠네요!" 단순 라우팅을 제대로 이해하면 도메인과 서버를 빠르게 연결할 수 있습니다. 여러분도 첫 웹사이트를 배포할 때 단순 라우팅부터 시작해 보세요.

실전 팁

💡 - TTL 값은 개발 중에는 60초로 낮게 설정하고, 운영 환경에서는 300초 이상으로 설정하세요

A 레코드(IPv4) 외에도 AAAA 레코드(IPv6), CNAME 레코드(다른 도메인으로 연결) 등을 활용할 수 있습니다

2. 가중치 기반 라우팅

김개발 씨의 서비스가 인기를 끌기 시작했습니다. 새로운 버전을 배포하려는데, 모든 사용자에게 한 번에 적용하기가 두렵습니다.

"혹시 버그가 있으면 어떡하지?" 박시니어 씨가 말했습니다. "가중치 기반 라우팅을 써보세요.

10%만 새 버전으로 보낼 수 있어요."

가중치 기반 라우팅은 트래픽을 여러 서버에 비율로 나누어 전달하는 방식입니다. 마치 케이크를 여러 조각으로 나누어 나눠주는 것처럼, 전체 트래픽의 10%는 A 서버로, 90%는 B 서버로 보낼 수 있습니다.

A/B 테스트나 카나리 배포에 매우 유용합니다.

다음 코드를 살펴봅시다.

// 가중치 기반 라우팅 설정 예제
const createWeightedRecord = (name, ip, weight, setId) => ({
  Action: 'CREATE',
  ResourceRecordSet: {
    Name: name,
    Type: 'A',
    // SetIdentifier로 각 레코드를 구분합니다
    SetIdentifier: setId,
    // 가중치 설정 (10 = 10%, 90 = 90%)
    Weight: weight,
    TTL: 60,
    ResourceRecords: [{ Value: ip }]
  }
});

const params = {
  HostedZoneId: 'Z1234567890ABC',
  ChangeBatch: {
    Changes: [
      // 신규 버전: 10% 트래픽
      createWeightedRecord('www.example.com', '192.0.2.1', 10, 'new-version'),
      // 기존 버전: 90% 트래픽
      createWeightedRecord('www.example.com', '192.0.2.2', 90, 'old-version')
    ]
  }
};

김개발 씨는 고민에 빠졌습니다. 3개월간 열심히 개발한 새 기능을 드디어 배포할 때가 왔습니다.

하지만 테스트 환경에서는 완벽하게 작동했어도, 실제 운영 환경에서는 예상치 못한 문제가 발생할 수 있습니다. 모든 사용자를 한 번에 새 버전으로 보내면 혹시 큰 버그가 있을 때 서비스 전체가 마비될 수 있습니다.

어떻게 해야 안전하게 배포할 수 있을까요? 가중치 기반 라우팅이란 무엇일까요? 쉽게 비유하자면, 가중치 기반 라우팅은 마치 교통 경찰이 차량을 여러 도로로 나누어 보내는 것과 같습니다.

"10대 중 1대는 새 도로로, 9대는 기존 도로로 가세요"라고 안내하는 것처럼, Route 53도 사용자들을 비율에 따라 다른 서버로 보냅니다. www.example.com으로 접속하는 사용자 중 10%는 새 버전 서버로, 90%는 기존 버전 서버로 자동으로 연결됩니다.

개발자가 일일이 제어할 필요가 없습니다. 왜 가중치 기반 라우팅이 필요할까요? 예전에는 새 버전 배포가 매우 위험한 작업이었습니다.

야심차게 배포했다가 치명적인 버그가 발견되면, 서비스 전체가 먹통이 되었습니다. 긴급하게 롤백해야 했고, 사용자들은 불편을 겪었습니다.

더 큰 문제는 새로운 기능이 실제로 사용자들에게 인기가 있을지 알 수 없다는 것이었습니다. 개발팀이 좋다고 생각한 기능이 실제로는 불편할 수도 있습니다.

전체 사용자에게 배포한 후에야 이를 알게 되면 이미 늦습니다. 카나리 배포의 탄생 바로 이런 문제를 해결하기 위해 카나리 배포(Canary Deployment)가 등장했습니다.

탄광에서 유독 가스를 감지하기 위해 카나리아 새를 먼저 보낸 것에서 유래한 이름입니다. 가중치 기반 라우팅을 사용하면 소수의 사용자에게만 먼저 새 버전을 제공할 수 있습니다.

문제가 없으면 점차 비율을 늘려갑니다. 만약 버그가 발견되면 즉시 가중치를 0으로 바꾸면 됩니다.

또한 A/B 테스트도 가능해집니다. 50%는 파란색 버튼을, 50%는 빨간색 버튼을 보여주고 어느 쪽의 클릭률이 높은지 측정할 수 있습니다.

코드 분석 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 createWeightedRecord라는 헬퍼 함수를 만들었습니다.

같은 도메인에 대해 여러 개의 레코드를 만들 때는 SetIdentifier로 각각을 구분해야 합니다. 이것이 가중치 라우팅의 핵심입니다.

Weight 값이 10이면 10%, 90이면 90%를 의미합니다. 실제로는 전체 가중치의 합에서 차지하는 비율로 계산됩니다.

10과 90의 합은 100이므로, 각각 10%와 90%가 됩니다. 두 개의 레코드를 생성하는데, 하나는 새 버전 서버(192.0.2.1)로 10% 트래픽을 보내고, 다른 하나는 기존 버전 서버(192.0.2.2)로 90% 트래픽을 보냅니다.

같은 도메인이지만 다른 서버로 연결되는 것입니다. 실무 활용 사례 실제 현업에서는 어떻게 활용할까요?

Netflix는 새로운 추천 알고리즘을 배포할 때 항상 가중치 기반 라우팅을 사용합니다. 처음에는 1%의 사용자에게만 새 알고리즘을 적용합니다.

시청 시간, 만족도 등의 지표를 모니터링하면서 점차 비율을 늘려갑니다. 온라인 쇼핑몰에서도 많이 사용합니다.

새로운 결제 페이지 디자인을 10%의 사용자에게만 보여주고, 전환율을 측정합니다. 기존 디자인보다 좋으면 전체 적용하고, 나쁘면 롤백합니다.

실전 배포 전략 김개발 씨의 팀은 다음과 같은 단계로 배포했습니다. 1단계: 5% 트래픽으로 시작하여 1시간 모니터링합니다.

2단계: 문제가 없으면 25%로 늘리고 2시간 관찰합니다. 3단계: 50%, 75%로 점차 늘려갑니다.

4단계: 최종적으로 100% 새 버전으로 전환합니다. 이렇게 하면 혹시 문제가 생겨도 소수의 사용자만 영향을 받습니다.

빠르게 롤백할 수 있어 안전합니다. 주의사항 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 가중치를 자주 변경하는 것입니다. DNS에는 TTL(Time To Live)이 있어서, 설정을 바꿔도 즉시 반영되지 않습니다.

TTL이 300초라면 최대 5분이 걸릴 수 있습니다. 따라서 카나리 배포를 할 때는 TTL을 60초 정도로 낮게 설정하는 것이 좋습니다.

대신 DNS 쿼리 비용이 조금 늘어날 수 있습니다. 정리 다시 김개발 씨의 이야기로 돌아가 봅시다.

가중치 기반 라우팅으로 안전하게 배포한 김개발 씨는 이제 자신감이 생겼습니다. "이제 새 기능 배포가 무섭지 않아요!" 가중치 기반 라우팅을 제대로 이해하면 위험 없이 새로운 기능을 실험할 수 있습니다.

여러분도 다음 배포 때 꼭 활용해 보세요.

실전 팁

💡 - 카나리 배포 시 처음에는 5% 이하로 시작하여 점진적으로 늘리세요

CloudWatch 알람을 설정하여 에러율이 증가하면 자동으로 알림을 받도록 구성하세요
가중치 합계가 100일 필요는 없습니다. 10과 90 대신 1과 9를 써도 같은 비율입니다

3. 지연 시간 라우팅

김개발 씨의 서비스가 글로벌로 확장되었습니다. 한국 사용자는 서울 리전, 미국 사용자는 버지니아 리전의 서버를 사용하도록 하고 싶습니다.

하지만 사용자가 어느 나라에서 접속하는지 일일이 확인할 수는 없습니다. 박시니어 씨가 말했습니다.

"지연 시간 라우팅을 쓰면 Route 53이 자동으로 가장 빠른 서버로 연결해줘요."

지연 시간 라우팅은 사용자와 가장 가까운 리전의 서버로 자동 연결하는 방식입니다. 마치 가장 가까운 편의점을 찾아주는 내비게이션처럼, Route 53이 네트워크 지연 시간을 측정하여 가장 빠른 서버를 선택합니다.

글로벌 서비스에 필수적인 기능입니다.

다음 코드를 살펴봅시다.

// 지연 시간 기반 라우팅 설정 예제
const createLatencyRecord = (name, ip, region, setId) => ({
  Action: 'CREATE',
  ResourceRecordSet: {
    Name: name,
    Type: 'A',
    SetIdentifier: setId,
    // 리전 정보를 지정합니다
    Region: region,
    TTL: 60,
    ResourceRecords: [{ Value: ip }]
  }
});

const params = {
  HostedZoneId: 'Z1234567890ABC',
  ChangeBatch: {
    Changes: [
      // 서울 리전 서버
      createLatencyRecord('www.example.com', '192.0.2.1', 'ap-northeast-2', 'seoul-server'),
      // 버지니아 리전 서버
      createLatencyRecord('www.example.com', '192.0.2.2', 'us-east-1', 'virginia-server'),
      // 도쿄 리전 서버
      createLatencyRecord('www.example.com', '192.0.2.3', 'ap-northeast-1', 'tokyo-server')
    ]
  }
};

김개발 씨의 서비스는 이제 전 세계에서 사용됩니다. 한국, 일본, 미국에 각각 서버를 두었습니다.

하지만 문제가 생겼습니다. 미국 사용자가 한국 서버에 접속하면 페이지 로딩이 너무 느립니다.

지구 반대편까지 데이터가 이동해야 하기 때문입니다. 사용자들이 "왜 이렇게 느려요?"라고 불평하기 시작했습니다.

어떻게 하면 각 사용자를 가장 가까운 서버로 보낼 수 있을까요? 지연 시간 라우팅이란 무엇일까요? 쉽게 비유하자면, 지연 시간 라우팅은 마치 택시 배차 시스템과 같습니다.

손님이 앱으로 택시를 부르면, 시스템이 자동으로 가장 가까운 택시를 배정합니다. 손님은 어느 택시가 가까운지 몰라도 됩니다.

Route 53도 마찬가지입니다. 사용자가 www.example.com에 접속하면, Route 53이 자동으로 여러 서버와의 네트워크 지연 시간을 측정합니다.

그리고 가장 빠르게 응답할 수 있는 서버로 연결해줍니다. 왜 지연 시간 라우팅이 필요할까요? 인터넷 데이터는 빛의 속도로 전송되지만, 물리적 거리의 영향을 받습니다.

서울과 뉴욕 사이의 데이터 전송에는 약 150~200ms가 걸립니다. 이는 눈 깜빡일 시간처럼 짧아 보이지만, 웹 페이지에서는 체감할 수 있는 지연입니다.

예전에는 개발자가 사용자의 IP 주소를 보고 위치를 추정한 다음, 직접 가까운 서버로 리다이렉트해야 했습니다. 코드가 복잡했고, IP 주소 데이터베이스를 계속 업데이트해야 했습니다.

실수하기도 쉬웠습니다. 글로벌 서비스의 필수 요소 바로 이런 문제를 해결하기 위해 지연 시간 라우팅이 등장했습니다.

지연 시간 라우팅을 사용하면 Route 53이 모든 것을 자동으로 처리합니다. 서울의 사용자는 자동으로 서울 서버로, 뉴욕의 사용자는 자동으로 버지니아 서버로 연결됩니다.

개발자는 코드를 하나도 수정할 필요가 없습니다. 무엇보다 AWS가 전 세계의 네트워크 상황을 실시간으로 모니터링합니다.

만약 서울과 도쿄 사이의 네트워크에 문제가 생기면, 한국 사용자를 일시적으로 다른 리전으로 보낼 수도 있습니다. 코드 분석 위의 코드를 한 줄씩 살펴보겠습니다.

createLatencyRecord 함수에서 가장 중요한 부분은 Region 필드입니다. 각 서버가 위치한 AWS 리전을 지정합니다.

ap-northeast-2는 서울, us-east-1은 버지니아, ap-northeast-1은 도쿄를 의미합니다. SetIdentifier로 각 서버를 구분하는 것도 중요합니다.

'seoul-server', 'virginia-server' 같은 의미 있는 이름을 사용하면 나중에 관리하기 쉽습니다. 세 개의 레코드를 생성하면, Route 53이 사용자의 위치를 보고 자동으로 가장 빠른 서버를 선택합니다.

같은 도메인이지만, 접속하는 위치에 따라 다른 서버로 연결되는 것입니다. 실무 활용 사례 실제 현업에서는 어떻게 활용할까요?

YouTube는 전 세계에 수십 개의 데이터 센터를 운영합니다. 한국에서 영상을 재생하면 한국이나 일본의 서버에서 스트리밍됩니다.

만약 호주에서 같은 영상을 보면, 호주나 싱가포르의 서버에서 스트리밍됩니다. 이 모든 것이 지연 시간 라우팅 덕분에 가능합니다.

사용자는 어느 서버에 연결되는지 몰라도 됩니다. 그냥 빠른 스트리밍을 즐기면 됩니다.

게임 회사도 많이 사용합니다. 온라인 게임에서는 1초가 승패를 가릅니다.

지연 시간 라우팅으로 핑(Ping)을 최소화하면 사용자 경험이 크게 향상됩니다. 지리적 라우팅과의 차이 여기서 중요한 포인트가 있습니다.

지연 시간 라우팅과 지리적 라우팅은 다릅니다. 지리적 라우팅은 "한국 사용자는 무조건 서울 서버로"라고 고정합니다.

반면 지연 시간 라우팅은 실시간 네트워크 상황을 고려합니다. 만약 서울 서버에 장애가 생기면, 한국 사용자를 도쿄 서버로 보낼 수 있습니다.

어느 것이 더 좋을까요? 대부분의 경우 지연 시간 라우팅이 더 유연하고 성능이 좋습니다.

하지만 법적 규제로 인해 특정 국가의 데이터를 해외로 보낼 수 없다면, 지리적 라우팅을 사용해야 합니다. 주의사항 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 모든 리전에 서버를 두는 것입니다. AWS에는 20개 이상의 리전이 있지만, 처음에는 3~4개 정도로 충분합니다.

너무 많으면 관리가 복잡해지고 비용도 늘어납니다. 또한 각 리전의 서버가 동일한 데이터를 가지고 있어야 합니다.

데이터베이스 복제도 고려해야 합니다. 이는 별도의 아키텍처 설계가 필요한 부분입니다.

정리 다시 김개발 씨의 이야기로 돌아가 봅시다. 지연 시간 라우팅을 적용한 후, 전 세계 사용자의 페이지 로딩 속도가 평균 50% 빨라졌습니다.

"와, 정말 효과가 있네요!" 지연 시간 라우팅을 제대로 이해하면 글로벌 서비스의 성능을 크게 개선할 수 있습니다. 여러분도 여러 리전에 서버를 둔다면 꼭 활용해 보세요.

실전 팁

💡 - 처음에는 주요 대륙별로 1개씩 리전을 선택하세요 (아시아, 북미, 유럽)

CloudWatch로 각 리전별 응답 시간을 모니터링하여 병목 지점을 찾으세요
지연 시간 라우팅은 실제 AWS 리전에서만 작동합니다. 온프레미스 서버는 지리적 라우팅을 사용하세요

4. 장애 조치 라우팅

어느 날 밤 김개발 씨의 메인 서버에 장애가 발생했습니다. 새벽 2시에 긴급 호출을 받은 김개발 씨는 식은땀을 흘리며 서버를 재시작했습니다.

다음 날 박시니어 씨가 말했습니다. "장애 조치 라우팅을 설정해두면, 메인 서버가 죽어도 자동으로 백업 서버로 전환돼요.

새벽에 잠을 설칠 필요가 없죠."

장애 조치 라우팅은 메인 서버에 장애가 발생하면 자동으로 백업 서버로 전환하는 방식입니다. 마치 정전 시 자동으로 켜지는 비상 발전기처럼, Route 53이 서버 상태를 지속적으로 모니터링하다가 문제를 감지하면 즉시 백업으로 전환합니다.

고가용성이 필수인 서비스에 꼭 필요합니다.

다음 코드를 살펴봅시다.

// 장애 조치 라우팅 설정 예제
const createFailoverRecord = (name, ip, failoverType, healthCheckId, setId) => ({
  Action: 'CREATE',
  ResourceRecordSet: {
    Name: name,
    Type: 'A',
    SetIdentifier: setId,
    // PRIMARY(주 서버) 또는 SECONDARY(백업 서버)
    Failover: failoverType,
    // 헬스 체크 ID 연결
    HealthCheckId: healthCheckId,
    TTL: 60,
    ResourceRecords: [{ Value: ip }]
  }
});

const params = {
  HostedZoneId: 'Z1234567890ABC',
  ChangeBatch: {
    Changes: [
      // 주 서버 (메인)
      createFailoverRecord('www.example.com', '192.0.2.1', 'PRIMARY', 'health-check-123', 'primary-server'),
      // 백업 서버 (장애 시 사용)
      createFailoverRecord('www.example.com', '192.0.2.2', 'SECONDARY', null, 'secondary-server')
    ]
  }
};

김개발 씨는 트라우마가 생겼습니다. 지난주 새벽 2시, EC2 인스턴스가 갑자기 다운되었습니다.

알림을 받고 벌떡 일어나 노트북을 켜고, 손가락이 떨리는 상태로 서버를 재시작했습니다. 15분간 서비스가 중단되었고, 아침에 고객 불만이 쏟아졌습니다.

"이런 일을 어떻게 방지할 수 있을까?" 김개발 씨는 고민에 빠졌습니다. 서버는 언제든 고장날 수 있습니다.

하드웨어 문제, 소프트웨어 버그, 네트워크 장애 등 원인도 다양합니다. 장애 조치 라우팅이란 무엇일까요? 쉽게 비유하자면, 장애 조치 라우팅은 마치 호텔의 비상 발전기와 같습니다.

정전이 되면 자동으로 발전기가 켜져서 손님들은 불편을 느끼지 못합니다. 호텔 직원이 수동으로 스위치를 누를 필요가 없습니다.

Route 53도 마찬가지입니다. PRIMARY 서버를 지속적으로 모니터링하다가, 문제가 감지되면 자동으로 SECONDARY 서버로 트래픽을 전환합니다.

개발자가 새벽에 일어날 필요가 없습니다. 왜 장애 조치 라우팅이 필요할까요? 예전에는 서버 장애에 대응하려면 사람이 직접 개입해야 했습니다.

모니터링 시스템이 알림을 보내면, 엔지니어가 상황을 파악하고, 수동으로 DNS 설정을 변경하여 백업 서버로 전환했습니다. 이 과정에는 최소 10~30분이 걸렸습니다.

심야나 주말이면 더 오래 걸릴 수도 있었습니다. 그동안 서비스는 중단되고, 사용자들은 에러 페이지를 보았습니다.

매출 손실은 물론, 브랜드 신뢰도에도 타격을 입었습니다. 고가용성 아키텍처 바로 이런 문제를 해결하기 위해 장애 조치 라우팅이 등장했습니다.

장애 조치 라우팅을 사용하면 Route 53이 30초마다 메인 서버의 상태를 확인합니다. 이를 헬스 체크(Health Check)라고 합니다.

만약 연속으로 3번 응답이 없으면 서버가 다운된 것으로 판단하고, 즉시 백업 서버로 전환합니다. 전환 시간은 약 1~2분입니다.

TTL 설정에 따라 다르지만, 사람이 수동으로 하는 것보다 훨씬 빠릅니다. 무엇보다 새벽에 개발자를 깨울 필요가 없습니다.

코드 분석 위의 코드를 한 줄씩 살펴보겠습니다. createFailoverRecord 함수에서 가장 중요한 부분은 Failover 필드입니다.

'PRIMARY'는 평소에 사용할 메인 서버, 'SECONDARY'는 장애 시에만 사용할 백업 서버를 의미합니다. HealthCheckId도 매우 중요합니다.

PRIMARY 서버에만 헬스 체크를 연결합니다. Route 53이 이 헬스 체크를 통해 서버 상태를 모니터링합니다.

SECONDARY 서버에는 헬스 체크가 필요 없습니다. 무조건 백업이기 때문입니다.

두 개의 레코드를 생성하면, 평소에는 모든 트래픽이 PRIMARY로 갑니다. 하지만 PRIMARY가 다운되면 자동으로 SECONDARY로 전환됩니다.

메인 서버가 복구되면 다시 PRIMARY로 돌아옵니다. 실무 활용 사례 실제 현업에서는 어떻게 활용할까요?

온라인 뱅킹 시스템은 절대 중단될 수 없습니다. 은행들은 최소 2개 이상의 데이터 센터를 운영하며, 장애 조치 라우팅으로 연결합니다.

메인 센터에 화재나 지진이 발생해도, 백업 센터가 즉시 서비스를 이어받습니다. 이커머스 사이트도 마찬가지입니다.

특히 블랙프라이데이 같은 대목에는 트래픽이 평소의 10배 이상 몰립니다. 메인 서버가 과부하로 다운되더라도, 백업 서버가 있으면 매출 손실을 막을 수 있습니다.

다중 장애 조치 더 나아가, 여러 단계의 백업을 구성할 수도 있습니다. 서울 리전의 PRIMARY 서버, 도쿄 리전의 SECONDARY 서버, 싱가포르 리전의 TERTIARY 서버를 설정할 수 있습니다.

서울이 다운되면 도쿄로, 도쿄마저 다운되면 싱가포르로 자동 전환됩니다. 물론 이렇게 하려면 데이터 동기화도 고려해야 합니다.

각 서버가 동일한 데이터를 가지고 있어야 하니까요. RDS Multi-AZ나 S3 Cross-Region Replication을 함께 사용하면 됩니다.

주의사항 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 백업 서버를 방치하는 것입니다.

"어차피 메인이 안 죽을 거야"라고 생각하고 백업 서버를 업데이트하지 않습니다. 그러다 실제 장애가 발생하면, 백업 서버도 오래된 버전이라 제대로 작동하지 않습니다.

따라서 정기적으로 DR 훈련(Disaster Recovery Drill)을 해야 합니다. 일부러 메인 서버를 내리고, 백업 서버가 제대로 작동하는지 확인하세요.

분기에 한 번씩은 꼭 해야 합니다. 정리 다시 김개발 씨의 이야기로 돌아가 봅시다.

장애 조치 라우팅을 설정한 후, 김개발 씨는 안심하고 잠을 잘 수 있게 되었습니다. 실제로 다음 달 메인 서버에 또 장애가 발생했지만, 자동으로 백업 서버로 전환되어 서비스는 계속되었습니다.

장애 조치 라우팅을 제대로 이해하면 고가용성 시스템을 구축할 수 있습니다. 여러분도 중요한 서비스라면 꼭 백업 서버를 준비하고 장애 조치 라우팅을 설정하세요.

실전 팁

💡 - PRIMARY 서버의 TTL을 60초로 낮게 설정하면 장애 시 더 빠르게 전환됩니다

헬스 체크는 단순 Ping이 아니라 실제 애플리케이션 엔드포인트를 확인하도록 설정하세요
매월 DR 훈련을 캘린더에 등록하고, 백업 서버가 정상 작동하는지 꼭 확인하세요

5. 지리적 라우팅

김개발 씨의 회사가 유럽으로 사업을 확장했습니다. 그런데 유럽의 GDPR 규정 때문에 유럽 사용자의 데이터는 반드시 유럽 내 서버에 저장해야 합니다.

"지연 시간 라우팅을 쓰면 되지 않나요?" 박시니어 씨가 고개를 저었습니다. "아니요, 지리적 라우팅을 써야 해요.

특정 국가의 사용자를 강제로 특정 서버로 보낼 수 있거든요."

지리적 라우팅은 사용자의 지리적 위치에 따라 서로 다른 서버로 연결하는 방식입니다. 마치 우편물을 수신 국가별로 분류하는 것처럼, Route 53이 접속 국가를 파악하여 해당 국가에 맞는 서버로 보냅니다.

법적 규제 준수나 지역별 맞춤 콘텐츠 제공에 필수적입니다.

다음 코드를 살펴봅시다.

// 지리적 라우팅 설정 예제
const createGeolocationRecord = (name, ip, location, setId) => ({
  Action: 'CREATE',
  ResourceRecordSet: {
    Name: name,
    Type: 'A',
    SetIdentifier: setId,
    // 지리적 위치 설정
    GeoLocation: location,
    TTL: 60,
    ResourceRecords: [{ Value: ip }]
  }
});

const params = {
  HostedZoneId: 'Z1234567890ABC',
  ChangeBatch: {
    Changes: [
      // 한국 사용자 -> 서울 서버
      createGeolocationRecord('www.example.com', '192.0.2.1', { CountryCode: 'KR' }, 'korea-server'),
      // 일본 사용자 -> 도쿄 서버
      createGeolocationRecord('www.example.com', '192.0.2.2', { CountryCode: 'JP' }, 'japan-server'),
      // 유럽 사용자 -> 프랑크푸르트 서버
      createGeolocationRecord('www.example.com', '192.0.2.3', { ContinentCode: 'EU' }, 'europe-server'),
      // 기본값 (위 조건에 맞지 않는 모든 사용자)
      createGeolocationRecord('www.example.com', '192.0.2.4', { ContinentCode: '*' }, 'default-server')
    ]
  }
};

김개발 씨는 법무팀으로부터 긴급 이메일을 받았습니다. "유럽 GDPR 규정에 따라, EU 시민의 개인 데이터는 EU 내에서만 처리되어야 합니다." 만약 이를 위반하면 최대 2천만 유로의 벌금이 부과될 수 있다는 내용이었습니다.

지연 시간 라우팅을 사용하면 어떻게 될까요? 독일 사용자라도 네트워크 상황에 따라 미국 서버로 연결될 수 있습니다.

이는 GDPR 위반입니다. 어떻게 해야 할까요?

지리적 라우팅이란 무엇일까요? 쉽게 비유하자면, 지리적 라우팅은 마치 공항의 입국 심사와 같습니다. 여권을 보고 국적을 확인한 후, 자국민은 자동 게이트로, 외국인은 일반 게이트로 안내합니다.

선택권이 없습니다. 규칙에 따라 자동으로 분류됩니다.

Route 53도 마찬가지입니다. 사용자의 IP 주소를 보고 어느 국가에서 접속했는지 파악합니다.

그리고 미리 설정한 규칙에 따라 해당 국가의 서버로 강제로 연결합니다. 네트워크 속도는 고려하지 않습니다.

왜 지리적 라우팅이 필요할까요? 첫 번째 이유는 법적 규제 준수입니다. GDPR 외에도 중국의 사이버보안법, 러시아의 데이터 로컬라이제이션법 등 많은 국가가 데이터 국외 반출을 제한합니다.

이를 지키지 않으면 해당 국가에서 서비스를 할 수 없습니다. 두 번째 이유는 지역 맞춤 콘텐츠 제공입니다.

한국 사용자에게는 한국어 페이지를, 일본 사용자에게는 일본어 페이지를 보여주고 싶을 수 있습니다. 같은 도메인이지만 국가별로 다른 서버에서 다른 콘텐츠를 제공할 수 있습니다.

지연 시간 라우팅과의 차이 여기서 중요한 차이점을 다시 강조하겠습니다. 지연 시간 라우팅은 성능 최적화가 목적입니다.

"어느 서버가 가장 빠른가?"를 기준으로 선택합니다. 네트워크 상황에 따라 같은 국가의 사용자도 다른 서버로 갈 수 있습니다.

지리적 라우팅은 위치 기반 정책 적용이 목적입니다. "어느 국가에서 접속했는가?"를 기준으로 선택합니다.

느리더라도 규칙에 따라 특정 서버로만 연결됩니다. 코드 분석 위의 코드를 한 줄씩 살펴보겠습니다.

createGeolocationRecord 함수에서 가장 중요한 부분은 GeoLocation 필드입니다. 여기에 국가 코드나 대륙 코드를 지정합니다.

CountryCode: 'KR'은 한국, 'JP'는 일본을 의미합니다. 대륙 단위로도 설정할 수 있습니다.

ContinentCode: 'EU'는 유럽 전체를 의미합니다. 개별 국가를 일일이 설정할 필요 없이, 유럽의 모든 국가를 한 번에 처리할 수 있어 편리합니다.

기본값 설정도 중요합니다. ContinentCode: '*'는 앞의 조건에 맞지 않는 모든 사용자를 의미합니다.

이것을 설정하지 않으면, 규칙에 없는 국가의 사용자는 접속할 수 없습니다. 우선순위 Route 53은 가장 구체적인 규칙을 우선 적용합니다.

예를 들어 한국 사용자의 경우, CountryCode: 'KR' 규칙이 ContinentCode: 'AS'(아시아 전체) 규칙보다 우선합니다. 즉, 한국은 서울 서버로, 다른 아시아 국가는 싱가포르 서버로 보낼 수 있습니다.

실무 활용 사례 실제 현업에서는 어떻게 활용할까요? Netflix는 국가별로 다른 콘텐츠 라이브러리를 제공합니다.

이를 위해 지리적 라우팅을 사용합니다. 글로벌 이커머스도 마찬가지입니다.

한국 사용자에게는 원화 가격과 한국 배송 정보를, 일본 사용자에게는 엔화 가격과 일본 배송 정보를 보여줍니다. 같은 도메인이지만 국가별로 다른 서버에서 다른 데이터를 제공합니다.

라이선스 관리 소프트웨어 회사도 지리적 라우팅을 활용합니다. 특정 국가에는 라이선스를 판매하지 않거나, 제한된 기능만 제공할 수 있습니다.

미국 수출 규제 대상 국가의 사용자는 아예 접속을 차단하거나, 제한된 버전의 서비스로 연결할 수 있습니다. 주의사항 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 기본값을 설정하지 않는 것입니다. 한국, 일본, 미국만 설정하고 기본값이 없으면, 태국이나 인도 사용자는 접속할 수 없습니다.

에러가 발생합니다. 또한 IP 주소 기반 위치 파악이 100% 정확하지는 않습니다.

VPN을 사용하는 사용자는 실제 위치와 다른 서버로 연결될 수 있습니다. 이는 피할 수 없는 한계입니다.

복합 사용 더 나아가, 지리적 라우팅과 장애 조치 라우팅을 함께 사용할 수도 있습니다. 한국 사용자는 무조건 한국 서버로 보내되, 한국 서버가 다운되면 일본 서버로 장애 조치할 수 있습니다.

이렇게 하면 법적 규제를 지키면서도 고가용성을 확보할 수 있습니다. 정리 다시 김개발 씨의 이야기로 돌아가 봅시다.

지리적 라우팅을 설정한 후, 법무팀으로부터 GDPR 준수 인증을 받았습니다. "이제 안심하고 유럽 시장을 공략할 수 있어요!" 지리적 라우팅을 제대로 이해하면 글로벌 규제를 준수하면서도 효과적으로 서비스를 제공할 수 있습니다.

여러분도 여러 국가에 서비스한다면 꼭 검토해 보세요.

실전 팁

💡 - 반드시 기본값(ContinentCode: '*')을 설정하여 모든 국가의 사용자가 접속할 수 있도록 하세요

국가 코드는 ISO 3166-1 alpha-2 표준을 따릅니다 (KR, JP, US 등)
법적 규제가 있는 경우 법무팀과 상의하여 정확한 데이터 저장 위치를 결정하세요

6. 헬스 체크 설정

김개발 씨는 장애 조치 라우팅을 설정했지만, 아직 헬스 체크를 만들지 않았습니다. "헬스 체크 없이는 장애 조치가 작동하지 않아요." 박시니어 씨가 설명했습니다.

"Route 53이 서버 상태를 어떻게 알겠어요? 헬스 체크가 서버를 계속 모니터링하면서 살아있는지 확인하는 거예요."

헬스 체크는 Route 53이 서버의 상태를 지속적으로 모니터링하는 기능입니다. 마치 병원에서 환자의 심박수를 모니터링하는 것처럼, 일정 간격으로 서버에 요청을 보내 응답을 확인합니다.

서버가 응답하지 않으면 비정상으로 판단하여 트래픽을 차단하거나 백업 서버로 전환합니다.

다음 코드를 살펴봅시다.

// 헬스 체크 생성 예제
const createHealthCheck = async () => {
  const params = {
    Type: 'HTTPS',
    ResourcePath: '/health',
    FullyQualifiedDomainName: 'www.example.com',
    Port: 443,
    // 30초마다 체크
    RequestInterval: 30,
    // 3번 연속 실패 시 비정상 판정
    FailureThreshold: 3,
    // CloudWatch 알람 설정
    EnableSNI: true,
    HealthCheckConfig: {
      Type: 'HTTPS',
      ResourcePath: '/health',
      // 응답 내용 검증
      SearchString: '"status":"ok"'
    }
  };

  const healthCheck = await route53.createHealthCheck(params).promise();
  console.log('헬스 체크 생성:', healthCheck.HealthCheck.Id);

  // CloudWatch 알람과 연동
  const alarmParams = {
    ComparisonOperator: 'LessThanThreshold',
    EvaluationPeriods: 1,
    MetricName: 'HealthCheckStatus',
    Namespace: 'AWS/Route53',
    Period: 60,
    Statistic: 'Minimum',
    Threshold: 1.0,
    AlarmName: 'ServerDown-Alert'
  };
};

김개발 씨는 장애 조치 라우팅 설정을 완료했다고 생각했습니다. 하지만 테스트를 해보니 메인 서버를 내려도 백업 서버로 전환되지 않았습니다.

"왜 안 되지?" 한참을 헤매다가 깨달았습니다. 헬스 체크를 만들지 않았던 것입니다.

Route 53이 서버가 다운되었는지 어떻게 알 수 있을까요? 바로 헬스 체크가 필요합니다.

헬스 체크란 무엇일까요? 쉽게 비유하자면, 헬스 체크는 마치 보안 시스템의 센서와 같습니다. 집 안의 센서가 움직임을 감지하듯이, 헬스 체크는 서버의 생존 여부를 감지합니다.

일정 간격으로 "살아있니?"라고 물어보고, 응답이 없으면 "문제가 생겼다"고 판단합니다. Route 53은 전 세계 여러 지점에서 동시에 서버를 체크합니다.

한 지점에서만 실패했다면 네트워크 문제일 수 있지만, 여러 지점에서 실패하면 서버 자체에 문제가 있다고 확신할 수 있습니다. 헬스 체크의 작동 원리 헬스 체크는 설정된 간격(예: 30초)마다 서버에 HTTP 또는 HTTPS 요청을 보냅니다.

서버가 정상 응답(200 OK)을 반환하면 정상(Healthy)으로 판단합니다. 하지만 만약 응답이 없거나, 에러 코드(500, 503 등)를 반환하면 실패로 기록합니다.

FailureThreshold가 3이라면, 연속으로 3번 실패해야 비정상(Unhealthy)으로 판정합니다. 이렇게 하면 일시적인 네트워크 문제로 인한 오판을 방지할 수 있습니다.

왜 헬스 체크가 필요할까요? 예전에는 서버 모니터링을 위해 별도의 도구를 사용했습니다. Nagios, Zabbix 같은 모니터링 시스템을 설치하고, 복잡한 설정을 해야 했습니다.

관리가 어렵고, 비용도 많이 들었습니다. 더 큰 문제는 모니터링 시스템과 DNS가 분리되어 있다는 것이었습니다.

모니터링 시스템이 "서버가 다운되었다"고 알려줘도, DNS 설정을 수동으로 변경해야 했습니다. 자동화가 불가능했습니다.

통합 솔루션 바로 이런 문제를 해결하기 위해 Route 53에 헬스 체크가 통합되었습니다. 헬스 체크를 사용하면 모니터링과 라우팅이 자동으로 연동됩니다.

서버가 다운되면 헬스 체크가 감지하고, Route 53이 즉시 해당 서버로의 트래픽을 차단합니다. 장애 조치 라우팅과 함께 사용하면 자동으로 백업 서버로 전환됩니다.

또한 CloudWatch와도 연동됩니다. 헬스 체크가 실패하면 자동으로 알림을 보낼 수 있습니다.

SMS, 이메일, Slack 등 다양한 방법으로 즉시 통보받을 수 있습니다. 코드 분석 위의 코드를 한 줄씩 살펴보겠습니다.

Type은 'HTTPS'로 설정했습니다. HTTP보다 안전하고, 실제 프로덕션 환경에서는 HTTPS를 사용해야 합니다.

ResourcePath는 '/health'로 설정했는데, 이는 서버에 /health 엔드포인트가 있어야 한다는 의미입니다. RequestInterval은 30초로 설정했습니다.

10초 또는 30초 중 선택할 수 있는데, 10초는 더 빠른 감지가 가능하지만 비용이 더 듭니다. 대부분의 경우 30초면 충분합니다.

FailureThreshold는 3으로 설정했습니다. 연속 3번 실패해야 비정상으로 판정한다는 뜻입니다.

30초 간격이므로, 90초 동안 응답이 없으면 다운된 것으로 판단합니다. SearchString도 중요합니다.

단순히 200 OK 응답만 확인하는 것이 아니라, 응답 내용에 특정 문자열이 포함되어 있는지도 검증할 수 있습니다. 예를 들어 "status":"ok"가 있어야만 정상으로 인정합니다.

헬스 체크 엔드포인트 구현 서버 측에서도 헬스 체크 엔드포인트를 구현해야 합니다. javascript // Express.js 헬스 체크 엔드포인트 예제 app.get('/health', async (req, res) => { try { // 데이터베이스 연결 확인 await db.ping(); // Redis 연결 확인 await redis.ping(); // 모든 의존성이 정상이면 res.status(200).json({ status: 'ok' }); } catch (error) { // 하나라도 문제가 있으면 res.status(503).json({ status: 'error' }); } }); 이렇게 하면 단순히 서버가 켜져 있는지만 확인하는 것이 아니라, 데이터베이스나 Redis 같은 의존성도 함께 확인할 수 있습니다.

더 정확한 헬스 체크가 가능합니다. 실무 활용 사례 실제 현업에서는 어떻게 활용할까요?

대규모 서비스는 수백 개의 서버를 운영합니다. 각 서버에 헬스 체크를 설정하면, Route 53이 자동으로 문제 있는 서버를 트래픽에서 제외합니다.

자동 복구(Auto Healing)가 가능해집니다. 예를 들어 10대의 서버 중 1대에서 메모리 누수로 인한 문제가 발생했다고 가정해봅시다.

헬스 체크가 이를 감지하고 해당 서버를 자동으로 제외합니다. 나머지 9대가 트래픽을 처리하는 동안, 문제 있는 서버를 재시작할 수 있습니다.

CloudWatch 알람 연동 헬스 체크 실패 시 즉시 알림을 받으려면 CloudWatch 알람을 설정해야 합니다. AlarmName에 의미 있는 이름을 붙이고, SNS 토픽을 연결하면 SMS나 이메일로 알림을 받을 수 있습니다.

또는 Lambda 함수를 트리거하여 자동으로 서버를 재시작하거나, Slack에 메시지를 보낼 수도 있습니다. 주의사항 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 헬스 체크 엔드포인트를 너무 복잡하게 만드는 것입니다. 모든 비즈니스 로직을 검증하려고 하면, 헬스 체크 자체가 서버에 부담을 줄 수 있습니다.

헬스 체크는 가볍고 빠르게 유지해야 합니다. 핵심 의존성만 확인하고, 100ms 이내에 응답하도록 구현하세요.

30초마다 요청이 오므로, 무거운 로직은 피해야 합니다. 정리 다시 김개발 씨의 이야기로 돌아가 봅시다.

헬스 체크를 제대로 설정한 후, 테스트로 메인 서버를 내렸더니 90초 후 자동으로 백업 서버로 전환되었습니다. "드디어 완벽한 고가용성 시스템이 완성되었어요!" 헬스 체크를 제대로 이해하면 서버 장애를 자동으로 감지하고 대응할 수 있습니다.

여러분도 프로덕션 서버라면 반드시 헬스 체크를 설정하세요.

실전 팁

💡 - 헬스 체크 엔드포인트는 인증 없이 접근 가능하도록 설정하되, DDoS 방지를 위해 Rate Limiting을 적용하세요

FailureThreshold는 3이 적당합니다. 너무 낮으면 오탐이 많고, 너무 높으면 장애 감지가 늦어집니다
헬스 체크 비용을 절감하려면 RequestInterval을 30초로 설정하고, 꼭 필요한 서버에만 적용하세요

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

#AWS#Route53#DNS#LoadBalancing#HealthCheck

AWS Route 53 라우팅 정책 완벽 가이드

# AWS Route 53 라우팅 정책 완벽 가이드 AWS Route 53의 6가지 라우팅 정책을 실무 관점에서 완벽 정리합니다. 단순 라우팅부터 장애 조치까지, 초급 개발자도 쉽게 이해할 수 있도록 실전 예제와 함께 설명합니다. --- ## 목차 1. [단순_라우팅](#단순-라우팅) 2. [가중치_기반_라우팅](#가중치-기반-라우팅) 3. [지연_시간_라우팅](#지연-시간-라우팅) 4. [장애_조치_라우팅](#장애-조치-라우팅) 5. [지리적_라우팅](#지리적-라우팅) 6. [헬스_체크_설정](#헬스-체크-설정) --- ## 1. 단순_라우팅 어느 날 김개발 씨가 첫 웹사이트를 AWS에 배포했습니다. 도메인을 연결하려고 Route 53을 열었는데, "라우팅 정책을 선택하세요"라는 문구가 보였습니다. "라우팅 정책이 뭐지?" 선배 박시니어 씨에게 물었더니, "가장 기본은 단순 라우팅이야"라고 답했습니다. **단순 라우팅**은 하나의 도메인을 하나의 리소스에 연결하는 가장 기본적인 방식입니다. 마치 전화번호부에서 이름 하나에 전화번호 하나를 매칭하는 것과 같습니다. 복잡한 설정 없이 빠르게 도메인을 연결할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // AWS SDK를 사용한 단순 라우팅 레코드 생성 예제 const AWS = require('aws-sdk'); const route53 = new AWS.Route53(); const params = { HostedZoneId: 'Z1234567890ABC', ChangeBatch: { Changes: [{ Action: 'CREATE', ResourceRecordSet: { Name: 'www.example.com', Type: 'A', TTL: 300, // 단순 라우팅: 하나의 IP 주소로 연결 ResourceRecords: [{ Value: '192.0.2.1' }] } }] } }; route53.changeResourceRecordSets(params, (err, data) => { if (err) console.log(err); else console.log('레코드 생성 완료:', data); }); ``` 김개발 씨는 AWS에 웹서버를 하나 띄웠습니다. EC2 인스턴스의 IP 주소는 192.0.2.1입니다. 이제 example.com이라는 도메인을 구매했으니, 이 도메인으로 접속하면 자신의 서버로 연결되게 하고 싶습니다. 어떻게 해야 할까요? 바로 여기서 **Route 53의 단순 라우팅**이 등장합니다. **단순 라우팅이란 무엇일까요?** 쉽게 비유하자면, 단순 라우팅은 마치 우체국의 주소록과 같습니다. "김개발"이라는 이름에 "서울시 강남구 123번지"라는 주소 하나만 적혀 있는 것처럼, 하나의 도메인 이름에 하나의 목적지만 지정하는 방식입니다. www.example.com이라는 도메인에 192.0.2.1이라는 IP 주소를 연결하면, 사용자가 브라우저에 www.example.com을 입력했을 때 자동으로 해당 IP로 연결됩니다. **왜 단순 라우팅이 필요할까요?** 인터넷 초창기에는 모든 웹사이트가 숫자로 된 IP 주소로 접속해야 했습니다. 192.168.1.1 같은 숫자를 외워야 했죠. 하지만 사람이 숫자를 외우기는 쉽지 않았습니다. 더 큰 문제는 서버 IP가 바뀔 때마다 모든 사용자에게 새로운 주소를 알려야 한다는 것이었습니다. 매우 불편했습니다. 관리도 복잡했고, 실수하기도 쉬웠습니다. **DNS의 등장** 바로 이런 문제를 해결하기 위해 **DNS**(Domain Name System)가 등장했습니다. 그리고 AWS에서 제공하는 DNS 서비스가 바로 Route 53입니다. 단순 라우팅을 사용하면 기억하기 쉬운 도메인 이름을 사용할 수 있습니다. 또한 나중에 서버 IP가 바뀌어도 Route 53 설정만 변경하면 됩니다. 사용자는 여전히 같은 도메인으로 접속하면 됩니다. **코드 분석** 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 AWS SDK를 불러오고 Route53 객체를 생성합니다. HostedZoneId는 여러분이 관리하는 도메인의 고유 식별자입니다. Route 53에서 도메인을 등록하면 자동으로 할당됩니다. ResourceRecordSet 부분이 핵심입니다. Name에는 연결하려는 도메인을 입력합니다. Type은 'A'인데, 이는 도메인을 IPv4 주소로 연결한다는 의미입니다. TTL은 300초로 설정했는데, 이는 DNS 정보를 5분간 캐시하라는 뜻입니다. 마지막으로 ResourceRecords에 실제 서버의 IP 주소를 입력합니다. 이렇게 하면 도메인과 IP가 연결됩니다. **실무 활용 사례** 실제 현업에서는 어떻게 활용할까요? 예를 들어 개인 블로그를 만든다고 가정해봅시다. EC2 인스턴스 하나에 WordPress를 설치하고, myblog.com이라는 도메인을 연결하고 싶습니다. 이런 경우 단순 라우팅이 완벽한 선택입니다. 스타트업 초기 단계에서도 자주 사용됩니다. 서버가 하나뿐이고, 트래픽이 많지 않을 때는 굳이 복잡한 라우팅 정책이 필요 없습니다. 단순 라우팅으로 빠르게 서비스를 시작할 수 있습니다. **주의사항** 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 단순 라우팅에 여러 개의 IP 주소를 등록하는 것입니다. 이렇게 해도 작동은 하지만, Route 53이 무작위로 하나의 IP를 반환합니다. 제대로 된 로드 밸런싱이 아닙니다. 따라서 서버가 여러 대라면 다른 라우팅 정책을 사용해야 합니다. 단순 라우팅은 말 그대로 서버 하나를 연결할 때만 사용하는 것이 좋습니다. **정리** 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그럼 지금은 서버가 하나니까 단순 라우팅을 쓰면 되겠네요!" 단순 라우팅을 제대로 이해하면 도메인과 서버를 빠르게 연결할 수 있습니다. 여러분도 첫 웹사이트를 배포할 때 단순 라우팅부터 시작해 보세요. **실전 팁** 💡 - TTL 값은 개발 중에는 60초로 낮게 설정하고, 운영 환경에서는 300초 이상으로 설정하세요 - A 레코드(IPv4) 외에도 AAAA 레코드(IPv6), CNAME 레코드(다른 도메인으로 연결) 등을 활용할 수 있습니다 --- ## 2. 가중치_기반_라우팅 김개발 씨의 서비스가 인기를 끌기 시작했습니다. 새로운 버전을 배포하려는데, 모든 사용자에게 한 번에 적용하기가 두렵습니다. "혹시 버그가 있으면 어떡하지?" 박시니어 씨가 말했습니다. "가중치 기반 라우팅을 써보세요. 10%만 새 버전으로 보낼 수 있어요." **가중치 기반 라우팅**은 트래픽을 여러 서버에 비율로 나누어 전달하는 방식입니다. 마치 케이크를 여러 조각으로 나누어 나눠주는 것처럼, 전체 트래픽의 10%는 A 서버로, 90%는 B 서버로 보낼 수 있습니다. A/B 테스트나 카나리 배포에 매우 유용합니다. 다음 코드를 살펴봅시다. ```javascript // 가중치 기반 라우팅 설정 예제 const createWeightedRecord = (name, ip, weight, setId) => ({ Action: 'CREATE', ResourceRecordSet: { Name: name, Type: 'A', // SetIdentifier로 각 레코드를 구분합니다 SetIdentifier: setId, // 가중치 설정 (10 = 10%, 90 = 90%) Weight: weight, TTL: 60, ResourceRecords: [{ Value: ip }] } }); const params = { HostedZoneId: 'Z1234567890ABC', ChangeBatch: { Changes: [ // 신규 버전: 10% 트래픽 createWeightedRecord('www.example.com', '192.0.2.1', 10, 'new-version'), // 기존 버전: 90% 트래픽 createWeightedRecord('www.example.com', '192.0.2.2', 90, 'old-version') ] } }; ``` 김개발 씨는 고민에 빠졌습니다. 3개월간 열심히 개발한 새 기능을 드디어 배포할 때가 왔습니다. 하지만 테스트 환경에서는 완벽하게 작동했어도, 실제 운영 환경에서는 예상치 못한 문제가 발생할 수 있습니다. 모든 사용자를 한 번에 새 버전으로 보내면 혹시 큰 버그가 있을 때 서비스 전체가 마비될 수 있습니다. 어떻게 해야 안전하게 배포할 수 있을까요? **가중치 기반 라우팅이란 무엇일까요?** 쉽게 비유하자면, 가중치 기반 라우팅은 마치 교통 경찰이 차량을 여러 도로로 나누어 보내는 것과 같습니다. "10대 중 1대는 새 도로로, 9대는 기존 도로로 가세요"라고 안내하는 것처럼, Route 53도 사용자들을 비율에 따라 다른 서버로 보냅니다. www.example.com으로 접속하는 사용자 중 10%는 새 버전 서버로, 90%는 기존 버전 서버로 자동으로 연결됩니다. 개발자가 일일이 제어할 필요가 없습니다. **왜 가중치 기반 라우팅이 필요할까요?** 예전에는 새 버전 배포가 매우 위험한 작업이었습니다. 야심차게 배포했다가 치명적인 버그가 발견되면, 서비스 전체가 먹통이 되었습니다. 긴급하게 롤백해야 했고, 사용자들은 불편을 겪었습니다. 더 큰 문제는 새로운 기능이 실제로 사용자들에게 인기가 있을지 알 수 없다는 것이었습니다. 개발팀이 좋다고 생각한 기능이 실제로는 불편할 수도 있습니다. 전체 사용자에게 배포한 후에야 이를 알게 되면 이미 늦습니다. **카나리 배포의 탄생** 바로 이런 문제를 해결하기 위해 **카나리 배포**(Canary Deployment)가 등장했습니다. 탄광에서 유독 가스를 감지하기 위해 카나리아 새를 먼저 보낸 것에서 유래한 이름입니다. 가중치 기반 라우팅을 사용하면 소수의 사용자에게만 먼저 새 버전을 제공할 수 있습니다. 문제가 없으면 점차 비율을 늘려갑니다. 만약 버그가 발견되면 즉시 가중치를 0으로 바꾸면 됩니다. 또한 **A/B 테스트**도 가능해집니다. 50%는 파란색 버튼을, 50%는 빨간색 버튼을 보여주고 어느 쪽의 클릭률이 높은지 측정할 수 있습니다. **코드 분석** 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 createWeightedRecord라는 헬퍼 함수를 만들었습니다. 같은 도메인에 대해 여러 개의 레코드를 만들 때는 **SetIdentifier**로 각각을 구분해야 합니다. 이것이 가중치 라우팅의 핵심입니다. Weight 값이 10이면 10%, 90이면 90%를 의미합니다. 실제로는 전체 가중치의 합에서 차지하는 비율로 계산됩니다. 10과 90의 합은 100이므로, 각각 10%와 90%가 됩니다. 두 개의 레코드를 생성하는데, 하나는 새 버전 서버(192.0.2.1)로 10% 트래픽을 보내고, 다른 하나는 기존 버전 서버(192.0.2.2)로 90% 트래픽을 보냅니다. 같은 도메인이지만 다른 서버로 연결되는 것입니다. **실무 활용 사례** 실제 현업에서는 어떻게 활용할까요? Netflix는 새로운 추천 알고리즘을 배포할 때 항상 가중치 기반 라우팅을 사용합니다. 처음에는 1%의 사용자에게만 새 알고리즘을 적용합니다. 시청 시간, 만족도 등의 지표를 모니터링하면서 점차 비율을 늘려갑니다. 온라인 쇼핑몰에서도 많이 사용합니다. 새로운 결제 페이지 디자인을 10%의 사용자에게만 보여주고, 전환율을 측정합니다. 기존 디자인보다 좋으면 전체 적용하고, 나쁘면 롤백합니다. **실전 배포 전략** 김개발 씨의 팀은 다음과 같은 단계로 배포했습니다. 1단계: 5% 트래픽으로 시작하여 1시간 모니터링합니다. 2단계: 문제가 없으면 25%로 늘리고 2시간 관찰합니다. 3단계: 50%, 75%로 점차 늘려갑니다. 4단계: 최종적으로 100% 새 버전으로 전환합니다. 이렇게 하면 혹시 문제가 생겨도 소수의 사용자만 영향을 받습니다. 빠르게 롤백할 수 있어 안전합니다. **주의사항** 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 가중치를 자주 변경하는 것입니다. DNS에는 TTL(Time To Live)이 있어서, 설정을 바꿔도 즉시 반영되지 않습니다. TTL이 300초라면 최대 5분이 걸릴 수 있습니다. 따라서 카나리 배포를 할 때는 TTL을 60초 정도로 낮게 설정하는 것이 좋습니다. 대신 DNS 쿼리 비용이 조금 늘어날 수 있습니다. **정리** 다시 김개발 씨의 이야기로 돌아가 봅시다. 가중치 기반 라우팅으로 안전하게 배포한 김개발 씨는 이제 자신감이 생겼습니다. "이제 새 기능 배포가 무섭지 않아요!" 가중치 기반 라우팅을 제대로 이해하면 위험 없이 새로운 기능을 실험할 수 있습니다. 여러분도 다음 배포 때 꼭 활용해 보세요. **실전 팁** 💡 - 카나리 배포 시 처음에는 5% 이하로 시작하여 점진적으로 늘리세요 - CloudWatch 알람을 설정하여 에러율이 증가하면 자동으로 알림을 받도록 구성하세요 - 가중치 합계가 100일 필요는 없습니다. 10과 90 대신 1과 9를 써도 같은 비율입니다 --- ## 3. 지연_시간_라우팅 김개발 씨의 서비스가 글로벌로 확장되었습니다. 한국 사용자는 서울 리전, 미국 사용자는 버지니아 리전의 서버를 사용하도록 하고 싶습니다. 하지만 사용자가 어느 나라에서 접속하는지 일일이 확인할 수는 없습니다. 박시니어 씨가 말했습니다. "지연 시간 라우팅을 쓰면 Route 53이 자동으로 가장 빠른 서버로 연결해줘요." **지연 시간 라우팅**은 사용자와 가장 가까운 리전의 서버로 자동 연결하는 방식입니다. 마치 가장 가까운 편의점을 찾아주는 내비게이션처럼, Route 53이 네트워크 지연 시간을 측정하여 가장 빠른 서버를 선택합니다. 글로벌 서비스에 필수적인 기능입니다. 다음 코드를 살펴봅시다. ```javascript // 지연 시간 기반 라우팅 설정 예제 const createLatencyRecord = (name, ip, region, setId) => ({ Action: 'CREATE', ResourceRecordSet: { Name: name, Type: 'A', SetIdentifier: setId, // 리전 정보를 지정합니다 Region: region, TTL: 60, ResourceRecords: [{ Value: ip }] } }); const params = { HostedZoneId: 'Z1234567890ABC', ChangeBatch: { Changes: [ // 서울 리전 서버 createLatencyRecord('www.example.com', '192.0.2.1', 'ap-northeast-2', 'seoul-server'), // 버지니아 리전 서버 createLatencyRecord('www.example.com', '192.0.2.2', 'us-east-1', 'virginia-server'), // 도쿄 리전 서버 createLatencyRecord('www.example.com', '192.0.2.3', 'ap-northeast-1', 'tokyo-server') ] } }; ``` 김개발 씨의 서비스는 이제 전 세계에서 사용됩니다. 한국, 일본, 미국에 각각 서버를 두었습니다. 하지만 문제가 생겼습니다. 미국 사용자가 한국 서버에 접속하면 페이지 로딩이 너무 느립니다. 지구 반대편까지 데이터가 이동해야 하기 때문입니다. 사용자들이 "왜 이렇게 느려요?"라고 불평하기 시작했습니다. 어떻게 하면 각 사용자를 가장 가까운 서버로 보낼 수 있을까요? **지연 시간 라우팅이란 무엇일까요?** 쉽게 비유하자면, 지연 시간 라우팅은 마치 택시 배차 시스템과 같습니다. 손님이 앱으로 택시를 부르면, 시스템이 자동으로 가장 가까운 택시를 배정합니다. 손님은 어느 택시가 가까운지 몰라도 됩니다. Route 53도 마찬가지입니다. 사용자가 www.example.com에 접속하면, Route 53이 자동으로 여러 서버와의 **네트워크 지연 시간**을 측정합니다. 그리고 가장 빠르게 응답할 수 있는 서버로 연결해줍니다. **왜 지연 시간 라우팅이 필요할까요?** 인터넷 데이터는 빛의 속도로 전송되지만, 물리적 거리의 영향을 받습니다. 서울과 뉴욕 사이의 데이터 전송에는 약 150~200ms가 걸립니다. 이는 눈 깜빡일 시간처럼 짧아 보이지만, 웹 페이지에서는 체감할 수 있는 지연입니다. 예전에는 개발자가 사용자의 IP 주소를 보고 위치를 추정한 다음, 직접 가까운 서버로 리다이렉트해야 했습니다. 코드가 복잡했고, IP 주소 데이터베이스를 계속 업데이트해야 했습니다. 실수하기도 쉬웠습니다. **글로벌 서비스의 필수 요소** 바로 이런 문제를 해결하기 위해 **지연 시간 라우팅**이 등장했습니다. 지연 시간 라우팅을 사용하면 Route 53이 모든 것을 자동으로 처리합니다. 서울의 사용자는 자동으로 서울 서버로, 뉴욕의 사용자는 자동으로 버지니아 서버로 연결됩니다. 개발자는 코드를 하나도 수정할 필요가 없습니다. 무엇보다 AWS가 전 세계의 네트워크 상황을 실시간으로 모니터링합니다. 만약 서울과 도쿄 사이의 네트워크에 문제가 생기면, 한국 사용자를 일시적으로 다른 리전으로 보낼 수도 있습니다. **코드 분석** 위의 코드를 한 줄씩 살펴보겠습니다. createLatencyRecord 함수에서 가장 중요한 부분은 **Region** 필드입니다. 각 서버가 위치한 AWS 리전을 지정합니다. ap-northeast-2는 서울, us-east-1은 버지니아, ap-northeast-1은 도쿄를 의미합니다. SetIdentifier로 각 서버를 구분하는 것도 중요합니다. 'seoul-server', 'virginia-server' 같은 의미 있는 이름을 사용하면 나중에 관리하기 쉽습니다. 세 개의 레코드를 생성하면, Route 53이 사용자의 위치를 보고 자동으로 가장 빠른 서버를 선택합니다. 같은 도메인이지만, 접속하는 위치에 따라 다른 서버로 연결되는 것입니다. **실무 활용 사례** 실제 현업에서는 어떻게 활용할까요? YouTube는 전 세계에 수십 개의 데이터 센터를 운영합니다. 한국에서 영상을 재생하면 한국이나 일본의 서버에서 스트리밍됩니다. 만약 호주에서 같은 영상을 보면, 호주나 싱가포르의 서버에서 스트리밍됩니다. 이 모든 것이 지연 시간 라우팅 덕분에 가능합니다. 사용자는 어느 서버에 연결되는지 몰라도 됩니다. 그냥 빠른 스트리밍을 즐기면 됩니다. 게임 회사도 많이 사용합니다. 온라인 게임에서는 1초가 승패를 가릅니다. 지연 시간 라우팅으로 핑(Ping)을 최소화하면 사용자 경험이 크게 향상됩니다. **지리적 라우팅과의 차이** 여기서 중요한 포인트가 있습니다. 지연 시간 라우팅과 **지리적 라우팅**은 다릅니다. 지리적 라우팅은 "한국 사용자는 무조건 서울 서버로"라고 고정합니다. 반면 지연 시간 라우팅은 실시간 네트워크 상황을 고려합니다. 만약 서울 서버에 장애가 생기면, 한국 사용자를 도쿄 서버로 보낼 수 있습니다. 어느 것이 더 좋을까요? 대부분의 경우 지연 시간 라우팅이 더 유연하고 성능이 좋습니다. 하지만 법적 규제로 인해 특정 국가의 데이터를 해외로 보낼 수 없다면, 지리적 라우팅을 사용해야 합니다. **주의사항** 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 모든 리전에 서버를 두는 것입니다. AWS에는 20개 이상의 리전이 있지만, 처음에는 3~4개 정도로 충분합니다. 너무 많으면 관리가 복잡해지고 비용도 늘어납니다. 또한 각 리전의 서버가 동일한 데이터를 가지고 있어야 합니다. 데이터베이스 복제도 고려해야 합니다. 이는 별도의 아키텍처 설계가 필요한 부분입니다. **정리** 다시 김개발 씨의 이야기로 돌아가 봅시다. 지연 시간 라우팅을 적용한 후, 전 세계 사용자의 페이지 로딩 속도가 평균 50% 빨라졌습니다. "와, 정말 효과가 있네요!" 지연 시간 라우팅을 제대로 이해하면 글로벌 서비스의 성능을 크게 개선할 수 있습니다. 여러분도 여러 리전에 서버를 둔다면 꼭 활용해 보세요. **실전 팁** 💡 - 처음에는 주요 대륙별로 1개씩 리전을 선택하세요 (아시아, 북미, 유럽) - CloudWatch로 각 리전별 응답 시간을 모니터링하여 병목 지점을 찾으세요 - 지연 시간 라우팅은 실제 AWS 리전에서만 작동합니다. 온프레미스 서버는 지리적 라우팅을 사용하세요 --- ## 4. 장애_조치_라우팅 어느 날 밤 김개발 씨의 메인 서버에 장애가 발생했습니다. 새벽 2시에 긴급 호출을 받은 김개발 씨는 식은땀을 흘리며 서버를 재시작했습니다. 다음 날 박시니어 씨가 말했습니다. "장애 조치 라우팅을 설정해두면, 메인 서버가 죽어도 자동으로 백업 서버로 전환돼요. 새벽에 잠을 설칠 필요가 없죠." **장애 조치 라우팅**은 메인 서버에 장애가 발생하면 자동으로 백업 서버로 전환하는 방식입니다. 마치 정전 시 자동으로 켜지는 비상 발전기처럼, Route 53이 서버 상태를 지속적으로 모니터링하다가 문제를 감지하면 즉시 백업으로 전환합니다. 고가용성이 필수인 서비스에 꼭 필요합니다. 다음 코드를 살펴봅시다. ```javascript // 장애 조치 라우팅 설정 예제 const createFailoverRecord = (name, ip, failoverType, healthCheckId, setId) => ({ Action: 'CREATE', ResourceRecordSet: { Name: name, Type: 'A', SetIdentifier: setId, // PRIMARY(주 서버) 또는 SECONDARY(백업 서버) Failover: failoverType, // 헬스 체크 ID 연결 HealthCheckId: healthCheckId, TTL: 60, ResourceRecords: [{ Value: ip }] } }); const params = { HostedZoneId: 'Z1234567890ABC', ChangeBatch: { Changes: [ // 주 서버 (메인) createFailoverRecord('www.example.com', '192.0.2.1', 'PRIMARY', 'health-check-123', 'primary-server'), // 백업 서버 (장애 시 사용) createFailoverRecord('www.example.com', '192.0.2.2', 'SECONDARY', null, 'secondary-server') ] } }; ``` 김개발 씨는 트라우마가 생겼습니다. 지난주 새벽 2시, EC2 인스턴스가 갑자기 다운되었습니다. 알림을 받고 벌떡 일어나 노트북을 켜고, 손가락이 떨리는 상태로 서버를 재시작했습니다. 15분간 서비스가 중단되었고, 아침에 고객 불만이 쏟아졌습니다. "이런 일을 어떻게 방지할 수 있을까?" 김개발 씨는 고민에 빠졌습니다. 서버는 언제든 고장날 수 있습니다. 하드웨어 문제, 소프트웨어 버그, 네트워크 장애 등 원인도 다양합니다. **장애 조치 라우팅이란 무엇일까요?** 쉽게 비유하자면, 장애 조치 라우팅은 마치 호텔의 비상 발전기와 같습니다. 정전이 되면 자동으로 발전기가 켜져서 손님들은 불편을 느끼지 못합니다. 호텔 직원이 수동으로 스위치를 누를 필요가 없습니다. Route 53도 마찬가지입니다. **PRIMARY** 서버를 지속적으로 모니터링하다가, 문제가 감지되면 자동으로 **SECONDARY** 서버로 트래픽을 전환합니다. 개발자가 새벽에 일어날 필요가 없습니다. **왜 장애 조치 라우팅이 필요할까요?** 예전에는 서버 장애에 대응하려면 사람이 직접 개입해야 했습니다. 모니터링 시스템이 알림을 보내면, 엔지니어가 상황을 파악하고, 수동으로 DNS 설정을 변경하여 백업 서버로 전환했습니다. 이 과정에는 최소 10~30분이 걸렸습니다. 심야나 주말이면 더 오래 걸릴 수도 있었습니다. 그동안 서비스는 중단되고, 사용자들은 에러 페이지를 보았습니다. 매출 손실은 물론, 브랜드 신뢰도에도 타격을 입었습니다. **고가용성 아키텍처** 바로 이런 문제를 해결하기 위해 **장애 조치 라우팅**이 등장했습니다. 장애 조치 라우팅을 사용하면 Route 53이 30초마다 메인 서버의 상태를 확인합니다. 이를 **헬스 체크**(Health Check)라고 합니다. 만약 연속으로 3번 응답이 없으면 서버가 다운된 것으로 판단하고, 즉시 백업 서버로 전환합니다. 전환 시간은 약 1~2분입니다. TTL 설정에 따라 다르지만, 사람이 수동으로 하는 것보다 훨씬 빠릅니다. 무엇보다 새벽에 개발자를 깨울 필요가 없습니다. **코드 분석** 위의 코드를 한 줄씩 살펴보겠습니다. createFailoverRecord 함수에서 가장 중요한 부분은 **Failover** 필드입니다. 'PRIMARY'는 평소에 사용할 메인 서버, 'SECONDARY'는 장애 시에만 사용할 백업 서버를 의미합니다. **HealthCheckId**도 매우 중요합니다. PRIMARY 서버에만 헬스 체크를 연결합니다. Route 53이 이 헬스 체크를 통해 서버 상태를 모니터링합니다. SECONDARY 서버에는 헬스 체크가 필요 없습니다. 무조건 백업이기 때문입니다. 두 개의 레코드를 생성하면, 평소에는 모든 트래픽이 PRIMARY로 갑니다. 하지만 PRIMARY가 다운되면 자동으로 SECONDARY로 전환됩니다. 메인 서버가 복구되면 다시 PRIMARY로 돌아옵니다. **실무 활용 사례** 실제 현업에서는 어떻게 활용할까요? 온라인 뱅킹 시스템은 절대 중단될 수 없습니다. 은행들은 최소 2개 이상의 데이터 센터를 운영하며, 장애 조치 라우팅으로 연결합니다. 메인 센터에 화재나 지진이 발생해도, 백업 센터가 즉시 서비스를 이어받습니다. 이커머스 사이트도 마찬가지입니다. 특히 블랙프라이데이 같은 대목에는 트래픽이 평소의 10배 이상 몰립니다. 메인 서버가 과부하로 다운되더라도, 백업 서버가 있으면 매출 손실을 막을 수 있습니다. **다중 장애 조치** 더 나아가, 여러 단계의 백업을 구성할 수도 있습니다. 서울 리전의 PRIMARY 서버, 도쿄 리전의 SECONDARY 서버, 싱가포르 리전의 TERTIARY 서버를 설정할 수 있습니다. 서울이 다운되면 도쿄로, 도쿄마저 다운되면 싱가포르로 자동 전환됩니다. 물론 이렇게 하려면 데이터 동기화도 고려해야 합니다. 각 서버가 동일한 데이터를 가지고 있어야 하니까요. RDS Multi-AZ나 S3 Cross-Region Replication을 함께 사용하면 됩니다. **주의사항** 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 백업 서버를 방치하는 것입니다. "어차피 메인이 안 죽을 거야"라고 생각하고 백업 서버를 업데이트하지 않습니다. 그러다 실제 장애가 발생하면, 백업 서버도 오래된 버전이라 제대로 작동하지 않습니다. 따라서 정기적으로 **DR 훈련**(Disaster Recovery Drill)을 해야 합니다. 일부러 메인 서버를 내리고, 백업 서버가 제대로 작동하는지 확인하세요. 분기에 한 번씩은 꼭 해야 합니다. **정리** 다시 김개발 씨의 이야기로 돌아가 봅시다. 장애 조치 라우팅을 설정한 후, 김개발 씨는 안심하고 잠을 잘 수 있게 되었습니다. 실제로 다음 달 메인 서버에 또 장애가 발생했지만, 자동으로 백업 서버로 전환되어 서비스는 계속되었습니다. 장애 조치 라우팅을 제대로 이해하면 고가용성 시스템을 구축할 수 있습니다. 여러분도 중요한 서비스라면 꼭 백업 서버를 준비하고 장애 조치 라우팅을 설정하세요. **실전 팁** 💡 - PRIMARY 서버의 TTL을 60초로 낮게 설정하면 장애 시 더 빠르게 전환됩니다 - 헬스 체크는 단순 Ping이 아니라 실제 애플리케이션 엔드포인트를 확인하도록 설정하세요 - 매월 DR 훈련을 캘린더에 등록하고, 백업 서버가 정상 작동하는지 꼭 확인하세요 --- ## 5. 지리적_라우팅 김개발 씨의 회사가 유럽으로 사업을 확장했습니다. 그런데 유럽의 GDPR 규정 때문에 유럽 사용자의 데이터는 반드시 유럽 내 서버에 저장해야 합니다. "지연 시간 라우팅을 쓰면 되지 않나요?" 박시니어 씨가 고개를 저었습니다. "아니요, 지리적 라우팅을 써야 해요. 특정 국가의 사용자를 강제로 특정 서버로 보낼 수 있거든요." **지리적 라우팅**은 사용자의 지리적 위치에 따라 서로 다른 서버로 연결하는 방식입니다. 마치 우편물을 수신 국가별로 분류하는 것처럼, Route 53이 접속 국가를 파악하여 해당 국가에 맞는 서버로 보냅니다. 법적 규제 준수나 지역별 맞춤 콘텐츠 제공에 필수적입니다. 다음 코드를 살펴봅시다. ```javascript // 지리적 라우팅 설정 예제 const createGeolocationRecord = (name, ip, location, setId) => ({ Action: 'CREATE', ResourceRecordSet: { Name: name, Type: 'A', SetIdentifier: setId, // 지리적 위치 설정 GeoLocation: location, TTL: 60, ResourceRecords: [{ Value: ip }] } }); const params = { HostedZoneId: 'Z1234567890ABC', ChangeBatch: { Changes: [ // 한국 사용자 -> 서울 서버 createGeolocationRecord('www.example.com', '192.0.2.1', { CountryCode: 'KR' }, 'korea-server'), // 일본 사용자 -> 도쿄 서버 createGeolocationRecord('www.example.com', '192.0.2.2', { CountryCode: 'JP' }, 'japan-server'), // 유럽 사용자 -> 프랑크푸르트 서버 createGeolocationRecord('www.example.com', '192.0.2.3', { ContinentCode: 'EU' }, 'europe-server'), // 기본값 (위 조건에 맞지 않는 모든 사용자) createGeolocationRecord('www.example.com', '192.0.2.4', { ContinentCode: '*' }, 'default-server') ] } }; ``` 김개발 씨는 법무팀으로부터 긴급 이메일을 받았습니다. "유럽 GDPR 규정에 따라, EU 시민의 개인 데이터는 EU 내에서만 처리되어야 합니다." 만약 이를 위반하면 최대 2천만 유로의 벌금이 부과될 수 있다는 내용이었습니다. 지연 시간 라우팅을 사용하면 어떻게 될까요? 독일 사용자라도 네트워크 상황에 따라 미국 서버로 연결될 수 있습니다. 이는 GDPR 위반입니다. 어떻게 해야 할까요? **지리적 라우팅이란 무엇일까요?** 쉽게 비유하자면, 지리적 라우팅은 마치 공항의 입국 심사와 같습니다. 여권을 보고 국적을 확인한 후, 자국민은 자동 게이트로, 외국인은 일반 게이트로 안내합니다. 선택권이 없습니다. 규칙에 따라 자동으로 분류됩니다. Route 53도 마찬가지입니다. 사용자의 IP 주소를 보고 어느 국가에서 접속했는지 파악합니다. 그리고 미리 설정한 규칙에 따라 해당 국가의 서버로 **강제로** 연결합니다. 네트워크 속도는 고려하지 않습니다. **왜 지리적 라우팅이 필요할까요?** 첫 번째 이유는 **법적 규제** 준수입니다. GDPR 외에도 중국의 사이버보안법, 러시아의 데이터 로컬라이제이션법 등 많은 국가가 데이터 국외 반출을 제한합니다. 이를 지키지 않으면 해당 국가에서 서비스를 할 수 없습니다. 두 번째 이유는 **지역 맞춤 콘텐츠** 제공입니다. 한국 사용자에게는 한국어 페이지를, 일본 사용자에게는 일본어 페이지를 보여주고 싶을 수 있습니다. 같은 도메인이지만 국가별로 다른 서버에서 다른 콘텐츠를 제공할 수 있습니다. **지연 시간 라우팅과의 차이** 여기서 중요한 차이점을 다시 강조하겠습니다. **지연 시간 라우팅**은 성능 최적화가 목적입니다. "어느 서버가 가장 빠른가?"를 기준으로 선택합니다. 네트워크 상황에 따라 같은 국가의 사용자도 다른 서버로 갈 수 있습니다. **지리적 라우팅**은 위치 기반 정책 적용이 목적입니다. "어느 국가에서 접속했는가?"를 기준으로 선택합니다. 느리더라도 규칙에 따라 특정 서버로만 연결됩니다. **코드 분석** 위의 코드를 한 줄씩 살펴보겠습니다. createGeolocationRecord 함수에서 가장 중요한 부분은 **GeoLocation** 필드입니다. 여기에 국가 코드나 대륙 코드를 지정합니다. CountryCode: 'KR'은 한국, 'JP'는 일본을 의미합니다. 대륙 단위로도 설정할 수 있습니다. ContinentCode: 'EU'는 유럽 전체를 의미합니다. 개별 국가를 일일이 설정할 필요 없이, 유럽의 모든 국가를 한 번에 처리할 수 있어 편리합니다. **기본값** 설정도 중요합니다. ContinentCode: '*'는 앞의 조건에 맞지 않는 모든 사용자를 의미합니다. 이것을 설정하지 않으면, 규칙에 없는 국가의 사용자는 접속할 수 없습니다. **우선순위** Route 53은 가장 구체적인 규칙을 우선 적용합니다. 예를 들어 한국 사용자의 경우, CountryCode: 'KR' 규칙이 ContinentCode: 'AS'(아시아 전체) 규칙보다 우선합니다. 즉, 한국은 서울 서버로, 다른 아시아 국가는 싱가포르 서버로 보낼 수 있습니다. **실무 활용 사례** 실제 현업에서는 어떻게 활용할까요? Netflix는 국가별로 다른 콘텐츠 라이브러리를 제공합니다. 저작권 계약이 국가마다 다르기 때문입니다. 한국에서는 한국 드라마를, 미국에서는 미국 영화를 주로 보여줍니다. 이를 위해 지리적 라우팅을 사용합니다. 글로벌 이커머스도 마찬가지입니다. 한국 사용자에게는 원화 가격과 한국 배송 정보를, 일본 사용자에게는 엔화 가격과 일본 배송 정보를 보여줍니다. 같은 도메인이지만 국가별로 다른 서버에서 다른 데이터를 제공합니다. **라이선스 관리** 소프트웨어 회사도 지리적 라우팅을 활용합니다. 특정 국가에는 라이선스를 판매하지 않거나, 제한된 기능만 제공할 수 있습니다. 미국 수출 규제 대상 국가의 사용자는 아예 접속을 차단하거나, 제한된 버전의 서비스로 연결할 수 있습니다. **주의사항** 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **기본값을 설정하지 않는 것**입니다. 한국, 일본, 미국만 설정하고 기본값이 없으면, 태국이나 인도 사용자는 접속할 수 없습니다. 에러가 발생합니다. 또한 IP 주소 기반 위치 파악이 100% 정확하지는 않습니다. VPN을 사용하는 사용자는 실제 위치와 다른 서버로 연결될 수 있습니다. 이는 피할 수 없는 한계입니다. **복합 사용** 더 나아가, 지리적 라우팅과 장애 조치 라우팅을 함께 사용할 수도 있습니다. 한국 사용자는 무조건 한국 서버로 보내되, 한국 서버가 다운되면 일본 서버로 장애 조치할 수 있습니다. 이렇게 하면 법적 규제를 지키면서도 고가용성을 확보할 수 있습니다. **정리** 다시 김개발 씨의 이야기로 돌아가 봅시다. 지리적 라우팅을 설정한 후, 법무팀으로부터 GDPR 준수 인증을 받았습니다. "이제 안심하고 유럽 시장을 공략할 수 있어요!" 지리적 라우팅을 제대로 이해하면 글로벌 규제를 준수하면서도 효과적으로 서비스를 제공할 수 있습니다. 여러분도 여러 국가에 서비스한다면 꼭 검토해 보세요. **실전 팁** 💡 - 반드시 기본값(ContinentCode: '*')을 설정하여 모든 국가의 사용자가 접속할 수 있도록 하세요 - 국가 코드는 ISO 3166-1 alpha-2 표준을 따릅니다 (KR, JP, US 등) - 법적 규제가 있는 경우 법무팀과 상의하여 정확한 데이터 저장 위치를 결정하세요 --- ## 6. 헬스_체크_설정 김개발 씨는 장애 조치 라우팅을 설정했지만, 아직 헬스 체크를 만들지 않았습니다. "헬스 체크 없이는 장애 조치가 작동하지 않아요." 박시니어 씨가 설명했습니다. "Route 53이 서버 상태를 어떻게 알겠어요? 헬스 체크가 서버를 계속 모니터링하면서 살아있는지 확인하는 거예요." **헬스 체크**는 Route 53이 서버의 상태를 지속적으로 모니터링하는 기능입니다. 마치 병원에서 환자의 심박수를 모니터링하는 것처럼, 일정 간격으로 서버에 요청을 보내 응답을 확인합니다. 서버가 응답하지 않으면 비정상으로 판단하여 트래픽을 차단하거나 백업 서버로 전환합니다. 다음 코드를 살펴봅시다. ```javascript // 헬스 체크 생성 예제 const createHealthCheck = async () => { const params = { Type: 'HTTPS', ResourcePath: '/health', FullyQualifiedDomainName: 'www.example.com', Port: 443, // 30초마다 체크 RequestInterval: 30, // 3번 연속 실패 시 비정상 판정 FailureThreshold: 3, // CloudWatch 알람 설정 EnableSNI: true, HealthCheckConfig: { Type: 'HTTPS', ResourcePath: '/health', // 응답 내용 검증 SearchString: '"status":"ok"' } }; const healthCheck = await route53.createHealthCheck(params).promise(); console.log('헬스 체크 생성:', healthCheck.HealthCheck.Id); // CloudWatch 알람과 연동 const alarmParams = { ComparisonOperator: 'LessThanThreshold', EvaluationPeriods: 1, MetricName: 'HealthCheckStatus', Namespace: 'AWS/Route53', Period: 60, Statistic: 'Minimum', Threshold: 1.0, AlarmName: 'ServerDown-Alert' }; }; ``` 김개발 씨는 장애 조치 라우팅 설정을 완료했다고 생각했습니다. 하지만 테스트를 해보니 메인 서버를 내려도 백업 서버로 전환되지 않았습니다. "왜 안 되지?" 한참을 헤매다가 깨달았습니다. 헬스 체크를 만들지 않았던 것입니다. Route 53이 서버가 다운되었는지 어떻게 알 수 있을까요? 바로 **헬스 체크**가 필요합니다. **헬스 체크란 무엇일까요?** 쉽게 비유하자면, 헬스 체크는 마치 보안 시스템의 센서와 같습니다. 집 안의 센서가 움직임을 감지하듯이, 헬스 체크는 서버의 생존 여부를 감지합니다. 일정 간격으로 "살아있니?"라고 물어보고, 응답이 없으면 "문제가 생겼다"고 판단합니다. Route 53은 전 세계 여러 지점에서 동시에 서버를 체크합니다. 한 지점에서만 실패했다면 네트워크 문제일 수 있지만, 여러 지점에서 실패하면 서버 자체에 문제가 있다고 확신할 수 있습니다. **헬스 체크의 작동 원리** 헬스 체크는 설정된 간격(예: 30초)마다 서버에 HTTP 또는 HTTPS 요청을 보냅니다. 서버가 정상 응답(200 OK)을 반환하면 정상(Healthy)으로 판단합니다. 하지만 만약 응답이 없거나, 에러 코드(500, 503 등)를 반환하면 실패로 기록합니다. **FailureThreshold**가 3이라면, 연속으로 3번 실패해야 비정상(Unhealthy)으로 판정합니다. 이렇게 하면 일시적인 네트워크 문제로 인한 오판을 방지할 수 있습니다. **왜 헬스 체크가 필요할까요?** 예전에는 서버 모니터링을 위해 별도의 도구를 사용했습니다. Nagios, Zabbix 같은 모니터링 시스템을 설치하고, 복잡한 설정을 해야 했습니다. 관리가 어렵고, 비용도 많이 들었습니다. 더 큰 문제는 모니터링 시스템과 DNS가 분리되어 있다는 것이었습니다. 모니터링 시스템이 "서버가 다운되었다"고 알려줘도, DNS 설정을 수동으로 변경해야 했습니다. 자동화가 불가능했습니다. **통합 솔루션** 바로 이런 문제를 해결하기 위해 Route 53에 **헬스 체크**가 통합되었습니다. 헬스 체크를 사용하면 모니터링과 라우팅이 자동으로 연동됩니다. 서버가 다운되면 헬스 체크가 감지하고, Route 53이 즉시 해당 서버로의 트래픽을 차단합니다. 장애 조치 라우팅과 함께 사용하면 자동으로 백업 서버로 전환됩니다. 또한 CloudWatch와도 연동됩니다. 헬스 체크가 실패하면 자동으로 알림을 보낼 수 있습니다. SMS, 이메일, Slack 등 다양한 방법으로 즉시 통보받을 수 있습니다. **코드 분석** 위의 코드를 한 줄씩 살펴보겠습니다. Type은 'HTTPS'로 설정했습니다. HTTP보다 안전하고, 실제 프로덕션 환경에서는 HTTPS를 사용해야 합니다. ResourcePath는 '/health'로 설정했는데, 이는 서버에 /health 엔드포인트가 있어야 한다는 의미입니다. **RequestInterval**은 30초로 설정했습니다. 10초 또는 30초 중 선택할 수 있는데, 10초는 더 빠른 감지가 가능하지만 비용이 더 듭니다. 대부분의 경우 30초면 충분합니다. **FailureThreshold**는 3으로 설정했습니다. 연속 3번 실패해야 비정상으로 판정한다는 뜻입니다. 30초 간격이므로, 90초 동안 응답이 없으면 다운된 것으로 판단합니다. **SearchString**도 중요합니다. 단순히 200 OK 응답만 확인하는 것이 아니라, 응답 내용에 특정 문자열이 포함되어 있는지도 검증할 수 있습니다. 예를 들어 "status":"ok"가 있어야만 정상으로 인정합니다. **헬스 체크 엔드포인트 구현** 서버 측에서도 헬스 체크 엔드포인트를 구현해야 합니다. ```javascript // Express.js 헬스 체크 엔드포인트 예제 app.get('/health', async (req, res) => { try { // 데이터베이스 연결 확인 await db.ping(); // Redis 연결 확인 await redis.ping(); // 모든 의존성이 정상이면 res.status(200).json({ status: 'ok' }); } catch (error) { // 하나라도 문제가 있으면 res.status(503).json({ status: 'error' }); } }); ``` 이렇게 하면 단순히 서버가 켜져 있는지만 확인하는 것이 아니라, 데이터베이스나 Redis 같은 의존성도 함께 확인할 수 있습니다. 더 정확한 헬스 체크가 가능합니다. **실무 활용 사례** 실제 현업에서는 어떻게 활용할까요? 대규모 서비스는 수백 개의 서버를 운영합니다. 각 서버에 헬스 체크를 설정하면, Route 53이 자동으로 문제 있는 서버를 트래픽에서 제외합니다. 자동 복구(Auto Healing)가 가능해집니다. 예를 들어 10대의 서버 중 1대에서 메모리 누수로 인한 문제가 발생했다고 가정해봅시다. 헬스 체크가 이를 감지하고 해당 서버를 자동으로 제외합니다. 나머지 9대가 트래픽을 처리하는 동안, 문제 있는 서버를 재시작할 수 있습니다. **CloudWatch 알람 연동** 헬스 체크 실패 시 즉시 알림을 받으려면 CloudWatch 알람을 설정해야 합니다. AlarmName에 의미 있는 이름을 붙이고, SNS 토픽을 연결하면 SMS나 이메일로 알림을 받을 수 있습니다. 또는 Lambda 함수를 트리거하여 자동으로 서버를 재시작하거나, Slack에 메시지를 보낼 수도 있습니다. **주의사항** 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 헬스 체크 엔드포인트를 너무 복잡하게 만드는 것입니다. 모든 비즈니스 로직을 검증하려고 하면, 헬스 체크 자체가 서버에 부담을 줄 수 있습니다. 헬스 체크는 **가볍고 빠르게** 유지해야 합니다. 핵심 의존성만 확인하고, 100ms 이내에 응답하도록 구현하세요. 30초마다 요청이 오므로, 무거운 로직은 피해야 합니다. **정리** 다시 김개발 씨의 이야기로 돌아가 봅시다. 헬스 체크를 제대로 설정한 후, 테스트로 메인 서버를 내렸더니 90초 후 자동으로 백업 서버로 전환되었습니다. "드디어 완벽한 고가용성 시스템이 완성되었어요!" 헬스 체크를 제대로 이해하면 서버 장애를 자동으로 감지하고 대응할 수 있습니다. 여러분도 프로덕션 서버라면 반드시 헬스 체크를 설정하세요. **실전 팁** 💡 - 헬스 체크 엔드포인트는 인증 없이 접근 가능하도록 설정하되, DDoS 방지를 위해 Rate Limiting을 적용하세요 - FailureThreshold는 3이 적당합니다. 너무 낮으면 오탐이 많고, 너무 높으면 장애 감지가 늦어집니다 - 헬스 체크 비용을 절감하려면 RequestInterval을 30초로 설정하고, 꼭 필요한 서버에만 적용하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: JavaScript

태그: AWS, Route53, DNS, LoadBalancing, HealthCheck

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS Route 53 라우팅 정책 완벽 가이드

목차

1. 단순 라우팅

2. 가중치 기반 라우팅

3. 지연 시간 라우팅

4. 장애 조치 라우팅

5. 지리적 라우팅

6. 헬스 체크 설정

이 카드뉴스가 포함된 코스

AWS 네트워크와 보안

댓글 (0)

함께 보면 좋은 카드 뉴스

Orchestrator-Workers 패턴 완벽 가이드

Cron과 Webhooks 완벽 가이드

보안 모델 및 DM Pairing 완벽 가이드

Media Pipeline 완벽 가이드

Slack 통합 완벽 가이드 Bolt로 시작하는 기업용 메신저 봇 개발