기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 자습서 이 섹션은 다음 자습서를 다룹니다. **하위 도메인의 DNS 서비스로 Route 53 사용** Route 53를 새 하위 도메인 또는 기존 하위 도메인의 DNS 서비스로 사용하면서 상위 도메인에는 다른 DNS 서비스를 사용하는 방법을 알아봅니다. **지연 시간 기반 라우팅으로 전환** Route 53에서 표준 라우팅에서 지연 시간 기반 라우팅으로 점진적으로 마이그레이션하여 사용자를 사용 가능한 최저 지연 시간 AWS 엔드포인트로 전달하는 방법을 알아봅니다. 가중치 기반 레코드 및 지연 시간 레코드를 결합하여 전체 제어 및 롤백 기능과 함께 원활하고 위험이 낮은 전환을 수행합니다. **지연 시간 기반 라우팅에 다른 리전 추가** 새 AWS 리전을 추가하고 트래픽을 새 리전으로 점진적으로 이동하여 지연 시간 기반 라우팅 설정을 확장합니다. **리전의 여러 Amazon EC2 인스턴스로 트래픽 라우팅** 지연 시간 레코드 및 가중치 기반 레코드를 함께 사용하여 트래픽을 특정 AWS 리전내의 여러 Amazon EC2 인스턴스로 라우팅합니다. **100건이 넘는 가중치 적용 레코드 관리** 가중치 기반 별칭 레코드 및 가중치 기반 레코드의 트리를 생성하여 트래픽을 100개 이상의 엔드포인트로 보내는 방법을 알아봅니다. **내결함성 멀티 레코드 응답 가중치 부여** 여러 레코드가 포함된 DNS 응답의 가중치를 지정하여 여러 엔드포인트에서 내결함성과 로드 밸런싱을 제공하는 방법을 이해합니다. 이 자습서에서는 다양한 사용 사례와 시나리오를 다루므로 Route 53의 라우팅 정책, 가중치 기반 레코드, 지연 시간 기반 라우팅을 효과적으로 활용하여 DNS 관리 및 트래픽 라우팅을 최적화하는 데 도움이 됩니다. **Topics** + [상위 도메인을 마이그레이션하지 않고 Amazon Route 53를 하위 도메인에 대한 DNS 서비스로 사용](creating-migrating.md) + [Transitioning to latency-based routing in Amazon Route 53](TutorialTransitionToLBR.md) + [Amazon Route 53의 지연 시간 기반 라우팅에 다른 리전 추가](TutorialAddingLBRRegion.md) + [Amazon Route 53의 지연 시간 및 가중치 기반 레코드를 사용하여 한 리전의 여러 Amazon EC2 인스턴스로 트래픽 라우팅](TutorialLBRMultipleEC2InRegion.md) + [Amazon Route 53에서 100개 이상의 가중치 기반 레코드 관리](TutorialManagingOver100WRR.md) + [Amazon Route 53에서 내결함성 멀티 레코드 응답 가중치 부여](TutorialWeightedFTMR.md) # 상위 도메인을 마이그레이션하지 않고 Amazon Route 53를 하위 도메인에 대한 DNS 서비스로 사용 Amazon Route 53는 하위 도메인에 대한 DNS를 유연하게 관리하므로 전체 상위 도메인을 마이그레이션할 필요 없이 해당 기능을 활용할 수 있습니다. 상위 도메인을 다른 DNS 서비스 공급자와 호스팅된 상태로 유지하면서 새 하위 도메인을 생성하거나 기존 하위 도메인을 Route 53으로 마이그레이션할 수 있습니다. **Route 53를 사용하여 새 하위 도메인 생성:** 1. 새 하위 도메인에 대한 호스팅 영역을 생성합니다. 1. 하위 도메인에 대해 원하는 DNS 레코드(예: A, CNAME, MX)를 호스팅 영역에 추가합니다. 1. 호스팅 영역에 할당된 Route 53 이름 서버를 가져옵니다. 1. 하위 도메인의 NS(이름 서버) 레코드를 추가하여 Route 53 이름 서버를 가리키도록 상위 도메인의 DNS 구성을 업데이트합니다. **기존 하위 도메인을 Route 53으로 마이그레이션:** 1. 하위 도메인에 대한 호스팅 영역을 생성합니다. 1. 기존 DNS 서비스 공급자로부터 하위 도메인에 대한 현재 DNS 구성을 가져옵니다. 1. 호스팅 영역에 해당 DNS 레코드를 추가합니다. 1. 호스팅 영역에 할당된 Route 53 이름 서버를 가져옵니다. 1. 하위 도메인의 NS 레코드를 추가하여 Route 53 이름 서버를 가리키도록 상위 도메인의 DNS 구성을 업데이트합니다. 다음 단계에 따라 하위 도메인에 대해 상태 확인, 라우팅 정책, 트래픽 흐름 관리와 같은 Route 53의 고급 기능을 활용하는 동시에 기존 공급자와 상위 도메인의 DNS 구성을 유지할 수 있습니다. **Topics** + [상위 도메인을 마이그레이션하지 않고 Amazon Route 53을 DNS 서비스로 사용하는 하위 도메인 생성하기](CreatingNewSubdomain.md) + [상위 도메인을 마이그레이션하지 않고 하위 도메인에 대한 DNS 서비스를 Amazon Route 53으로 마이그레이션](MigratingSubdomain.md) # 상위 도메인을 마이그레이션하지 않고 Amazon Route 53을 DNS 서비스로 사용하는 하위 도메인 생성하기 다른 DNS 서비스로부터 상위 도메인을 마이그레이션하지 않고 Amazon Route 53을 DNS 서비스로 사용하는 하위 도메인을 생성할 수 있습니다. 이 프로세스는 다음과 같은 기본 단계로 이루어집니다. 1. 이 절차를 사용해야 할지 여부를 [파악](#decide-procedure-create-subdomain)합니다. 1. [하위 도메인에 대한 Route 53 호스팅 영역을 생성합니다](#CreateZoneNewSubdomain). 1. 새로운 하위 도메인에 대한 Route 53 호스팅 영역에 [레코드를 추가](#AddNewSubdomainRecords)합니다. 1. *API 전용:* 모든 Route 53 DNS 서버에 [변경 사항이 전파되었는지 확인합니다](#CheckStatusNewSubdomain). **참고** 현재 변경 사항의 전파 여부를 확인하는 유일한 방법은 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API 작업을 사용하는 것입니다. 변경 사항은 일반적으로 60초 이내에 모든 Route 53 이름의 서버로 전파됩니다. 1. [하위 도메인의 이름 서버 레코드를 추가하여 상위 도메인에 대한 DNS 서비스를 업데이트합니다](#UpdateDNSParentDomain). ## 하위 도메인 생성에 사용할 절차 결정 이 주제에 나오는 절차에서는 일반적이지 않은 작업을 수행하는 방법을 설명합니다. Route 53을 도메인의 DNS 서비스로 이미 사용하는 경우 하위 도메인(예: www.example.com)의 트래픽을 리소스(예: EC2 인스턴스에서 실행되는 웹 서버)로 라우팅하려면 [하위 도메인에 대한 트래픽 라우팅](dns-routing-traffic-for-subdomains.md) 섹션을 참조하세요. 도메인(예: example.com)의 다른 DNS 서비스를 사용하고 해당 도메인의 새 하위 도메인(예: www.example.com)의 DNS 서비스로 Route 53을 사용하려는 경우에*만* 이 절차를 사용합니다. ## 새 하위 도메인에 대한 호스팅 영역 생성 상위 도메인을 마이그레이션하지 않고 Amazon Route 53을 새 하위 도메인의 DNS 서비스로 사용하려면 먼저 하위 도메인에 대한 호스팅 영역을 생성합니다. Route 53은 호스팅 영역에 하위 도메인에 대한 정보를 저장합니다. Route 53 콘솔을 사용하여 호스팅 영역을 생성하는 방법에 대한 자세한 내용은 [퍼블릭 호스팅 영역 생성](CreatingHostedZone.md) 섹션을 참조하세요. ## 레코드 생성 Amazon Route 53 콘솔 또는 Route 53 API를 사용하여 레코드를 생성할 수 있습니다. [DNS 서비스를 하위 도메인에 대한 이름 서버 레코드로 업데이트](#UpdateDNSParentDomain)의 설명에 따라 프로세스 후반부에 하위 도메인에 대한 책임을 Route 53에 위임한 후에는 Route 53에서 생성하는 레코드가 DNS에서 사용하는 레코드가 됩니다. **중요** Route 53 호스팅 영역에서 이름 서버(NS) 또는 권한 시작(SOA) 레코드를 추가로 생성하지 말고, 기존 NS 및 SOA 레코드를 삭제하지 마세요. Route 53 콘솔을 사용하여 레코드를 생성하려면 [레코드 작업](rrsets-working-with.md) 섹션을 참조하세요. Route 53 API를 사용하여 레코드를 생성하려면 `ChangeResourceRecordSets` 섹션을 참조하세요. 자세한 내용은 *[Amazon Route 53 API 참조](https://docs.aws.amazon.com/Route53/latest/APIReference/)*의 [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)를 참조하세요. ## 변경 상태 확인(API만 해당) 새 호스팅 영역을 생성하고 레코드를 변경하면 Route 53 DNS 서버로 전파되기까지 시간이 걸립니다. [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)를 사용하여 레코드를 생성하면 `GetChange` 작업을 사용하여 변경 사항이 전파되었는지 확인할 수 있습니다. `ChangeResourceRecordSets`에서 `ChangeId`의 값을 반환하면 후속 `GetChange` 요청에 포함할 수 있습니다. 콘솔을 사용하여 레코드를 생성한 경우 `ChangeId`를 사용할 수 없습니다. 자세한 내용은 *Amazon Route 53 API 참조*의 [GET GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)를 참조하세요. **참고** 변경 사항은 일반적으로 60초 이내에 모든 Route 53 이름의 서버로 전파됩니다. ## DNS 서비스를 하위 도메인에 대한 이름 서버 레코드로 업데이트 Amazon Route 53 레코드에 대한 변경 사항이 전파된 후([변경 상태 확인(API만 해당)](#CheckStatusNewSubdomain) 참조) 하위 도메인의 NS 레코드를 추가하여 상위 도메인에 대한 DNS 서비스를 업데이트합니다. 이것을 하위 도메인에 대한 책임을 Route 53에 위임한다고 합니다. 예를 들어 상위 도메인인 example.com을 다른 DNS 서비스에서 호스팅하고 하위 도메인인 test.example.com을 Route 53에서 생성한 경우, example.com의 DNS 서비스를 test.example.com에 대한 새 NS 레코드로 업데이트해야 합니다. 다음 절차를 수행합니다. 1. DNS 서비스에서 제공하는 방법을 사용하여 상위 도메인에 대한 영역 파일을 백업하십시오. 1. Route 53 콘솔에서 Route 53 호스팅 영역에 대한 이름 서버를 가져옵니다. 1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)에서 Route 53 콘솔을 엽니다. 1. 탐색 창에서 **호스팅 영역(Hosted Zones)**을 클릭합니다. 1. **호스팅 영역(Hosted zones)** 페이지에서 호스팅 영역의 (이름 대신) 라디오 버튼을 선택한 다음 **세부 정보 보기(View details)**를 선택합니다. 1. 호스팅 영역에 대한 세부 정보 페이지에서 **호스팅 영역 세부 정보(Hosted zone details)**를 선택합니다. 1. **이름 서버(Name servers)**에 나열된 서버 4개의 이름을 기록합니다. 또는 `GetHostedZone` 작업을 사용할 수 있습니다. 자세한 내용은 *Amazon Route 53 API 참조*의 [GetHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetHostedZone.html)을 참조하세요. 1. 상위 도메인의 DNS 서비스에서 제공하는 방법을 사용하여 하위 도메인의 NS 레코드를 상위 도메인의 영역 파일에 추가합니다. 이 NS 레코드에서 1단계에서 생성한 호스팅 영역과 연결된 Route 53 이름 서버 4개를 지정합니다. **중요** SOA(권한 시작) 레코드를 상위 도메인의 영역 파일에 추가하지 마십시오. 하위 도메인은 Route 53을 사용하기 때문에 상위 도메인에 대한 DNS 서비스는 하위 도메인에 대한 권한이 없습니다. DNS 서비스가 자동으로 하위 도메인의 SOA 레코드에 추가된 경우, 하위 도메인의 레코드를 삭제하십시오. 단, 상위 도메인에 대한 SOA 레코드는 삭제하지 마십시오. # 상위 도메인을 마이그레이션하지 않고 하위 도메인에 대한 DNS 서비스를 Amazon Route 53으로 마이그레이션 상위 도메인을 다른 DNS 서비스에서 마이그레이션하지 않고 Amazon Route 53을 DNS 서비스로 사용하도록 하위 도메인을 마이그레이션할 수 있습니다. 이 프로세스는 다음과 같은 기본 단계로 이루어집니다. 1. 이 절차를 사용해야 할지 여부를 [파악](#decide-procedure-migrate-subdomain)합니다. 1. [하위 도메인에 대한 Route 53 호스팅 영역을 생성합니다](#CreateZoneMigratedSubdomain). 1. [현재 DNS 서비스 공급자로부터 상위 도메인에 대한 현재 DNS 구성을 가져옵니다](#GetParentDomainResourceRecords). 1. 새로운 하위 도메인에 대한 Route 53 호스팅 영역에 [레코드를 추가합니다](#AddMigratedSubdomainRecords). 1. *API 전용:* 모든 Route 53 DNS 서버에 [변경 사항이 전파되었는지 확인합니다](#MigratingSubdomainCheckStatus). **참고** 현재 변경 사항의 전파 여부를 확인하는 유일한 방법은 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API 작업을 사용하는 것입니다. 변경 사항은 일반적으로 60초 이내에 모든 Route 53 이름의 서버로 전파됩니다. 1. [하위 도메인의 이름 서버 레코드를 추가하여 상위 도메인에 대한 DNS 서비스 공급자로 DNS 구성을 업데이트합니다](#UpdateOldDNS). ## 하위 도메인 생성에 사용할 절차 결정 이 주제에 나오는 절차에서는 일반적이지 않은 작업을 수행하는 방법을 설명합니다. Route 53을 도메인의 DNS 서비스로 이미 사용하는 경우 하위 도메인(예: www.example.com)의 트래픽을 리소스(예: EC2 인스턴스에서 실행되는 웹 서버)로 라우팅하려면 [하위 도메인에 대한 트래픽 라우팅](dns-routing-traffic-for-subdomains.md) 섹션을 참조하세요. 도메인(예: example.com)의 다른 DNS 서비스를 사용하고 해당 도메인의 기존 하위 도메인(예: www.example.com)의 DNS 서비스로 Route 53을 사용하려는 경우에*만* 이 절차를 사용합니다. ## 하위 도메인에 대한 호스팅 영역 생성 상위 도메인은 마이그레이션하지 않고 하위 도메인을 다른 DNS 서비스에서 Amazon Route 53으로 마이그레이션하려면 먼저 하위 도메인에 대한 호스팅 영역을 생성합니다. Route 53은 호스팅 영역에 하위 도메인에 대한 정보를 저장합니다. Route 53 콘솔을 사용하여 호스팅 영역을 생성하는 방법에 대한 자세한 내용은 [퍼블릭 호스팅 영역 생성](CreatingHostedZone.md) 섹션을 참조하세요. ## DNS 서비스 공급자로부터 현재 DNS 구성 가져오기 기존 하위 도메인을 Route 53으로 간편하게 마이그레이션하려면 현재 도메인을 서비스하는 DNS 서비스 공급자로부터 도메인에 대한 현재 DNS 구성을 가져옵니다. 이 정보를 토대로 Route 53을 하위 도메인의 DNS 서비스로 구성할 수 있습니다. 요청하는 내용과 형식은 현재 이용 중인 DNS 서비스 공급자에 따라 달라집니다. 현재 구성의 모든 레코드에 대한 정보가 포함된 영역 파일을 해당 회사에서 제공하는 것이 가장 좋습니다. (레코드에서 도메인 및 하위 도메인의 트래픽을 라우팅하려는 방법에 대해 DNS에 설명합니다. 예를 들어, 웹 브라우저에 도메인 이름을 입력하는 경우 그 트래픽이 데이터 센터의 웹 서버, Amazon EC2 인스턴스, CloudFront 배포 또는 다른 위치로 라우팅되도록 하고 싶습니까?) 현재 DNS 서비스 공급자로부터 영역 파일을 가져올 수 있는 경우, 영역 파일을 편집하여 Amazon Route 53으로 마이그레이션하지 않을 레코드를 제거할 수 있습니다. 그런 다음 Route 53 호스팅 영역으로 나머지 레코드를 가져오면 프로세스가 대폭 간소해집니다. 현재 DNS 서비스 공급자에게 *영역 파일* 또는 *레코드 목록*을 얻는 방법을 문의하십시오. ## 레코드 생성 현재 DNS 서비스 공급자로부터 받은 레코드를 발판 삼아, 하위 도메인용으로 만든 Amazon Route 53 호스팅 영역에서 해당하는 레코드를 생성합니다. [DNS 서비스를 하위 도메인에 대한 이름 서버 레코드로 업데이트](#UpdateOldDNS)의 설명에 따라 프로세스 후반부에 하위 도메인에 대한 책임을 Route 53에 위임한 후에는 Route 53에서 생성하는 레코드가 DNS에서 사용하는 레코드가 됩니다. **중요** Route 53 호스팅 영역에서 이름 서버(NS) 또는 권한 시작(SOA) 레코드를 추가로 생성하지 말고, 기존 NS 및 SOA 레코드를 삭제하지 마세요. Route 53 콘솔을 사용하여 레코드를 생성하려면 [레코드 작업](rrsets-working-with.md) 섹션을 참조하세요. Route 53 API를 사용하여 레코드를 생성하려면 `ChangeResourceRecordSets` 섹션을 참조하세요. 자세한 내용은 *[Amazon Route 53 API 참조](https://docs.aws.amazon.com/Route53/latest/APIReference/)*의 [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)를 참조하세요. ## 변경 상태 확인(API만 해당) 새 호스팅 영역을 생성하고 레코드를 변경하면 Route 53 DNS 서버로 전파되기까지 시간이 걸립니다. [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)를 사용하여 레코드를 생성하면 `GetChange` 작업을 사용하여 변경 사항이 전파되었는지 확인할 수 있습니다. `ChangeResourceRecordSets`에서 `ChangeId`의 값을 반환하면 후속 `GetChange` 요청에 포함할 수 있습니다. 콘솔을 사용하여 레코드를 생성한 경우 `ChangeId`를 사용할 수 없습니다. 자세한 내용은 *Amazon Route 53 API 참조*의 [GET GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)를 참조하세요. **참고** 변경 사항은 일반적으로 60초 이내에 모든 Route 53 이름의 서버로 전파됩니다. ## DNS 서비스를 하위 도메인에 대한 이름 서버 레코드로 업데이트 Amazon Route 53 레코드에 대한 변경 사항이 전파된 후([변경 상태 확인(API만 해당)](#MigratingSubdomainCheckStatus) 참조) 하위 도메인의 NS 레코드를 추가하여 상위 도메인에 대한 DNS 서비스를 업데이트합니다. 이것을 하위 도메인에 대한 책임을 Route 53에 위임한다고 합니다. 예를 들어, 상위 도메인인 example.com을 다른 DNS 서비스에서 호스팅하고 하위 도메인인 test.example.com을 Route 53으로 마이그레이션한다고 가정하겠습니다. test.example.com에 대한 호스팅 영역을 생성하고, Route 53에서 test.example.com에 대한 새 호스팅 영역에 할당한 NS 레코드로 example.com의 DNS 서비스를 업데이트해야 합니다. 다음 절차를 수행합니다. 1. DNS 서비스에서 제공하는 방법을 사용하여 상위 도메인에 대한 영역 파일을 백업하십시오. 1. 도메인의 이전 DNS 서비스 공급자에게 이름 서버의 TTL 설정을 변경할 방법이 있는 경우, 설정을 900초로 변경하는 것이 좋습니다. 이렇게 하면 클라이언트 요청에서 폐기된 이름 서버를 사용하여 도메인 이름을 해석하려고 시도하는 시간이 제한됩니다. 현재 TTL이 기본 설정인 172,800초(2일)인 경우, 해석기 및 클라이언트가 이전 TTL을 사용하여 DNS 레코드를 캐시하지 않게 되려면 이틀을 기다려야 합니다. TTL 설정이 만료된 후에는 이전 공급자에 저장된 레코드를 안전하게 삭제할 수 있으며 Route 53으로만 변경 가능합니다. 1. Route 53 콘솔에서 Route 53 호스팅 영역에 대한 이름 서버를 가져옵니다. 1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)에서 Route 53 콘솔을 엽니다. 1. 탐색 창에서 **호스팅 영역(Hosted Zones)**을 클릭합니다. 1. **호스팅 영역(Hosted zones)** 페이지에서 호스팅 영역의 (이름 대신) 라디오 버튼을 선택한 다음 **세부 정보 보기(View details)**를 선택합니다. 1. 호스팅 영역에 대한 세부 정보 페이지에서 **호스팅 영역 세부 정보(Hosted zone details)**를 선택합니다. 1. **이름 서버(Name servers)**에 나열된 서버 4개의 이름을 기록합니다. 또는 `GetHostedZone` 작업을 사용할 수 있습니다. 자세한 내용은 *Amazon Route 53 API 참조*의 [GetHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetHostedZone.html)을 참조하세요. 1. 상위 도메인의 DNS 서비스에서 제공하는 방법을 사용하여 하위 도메인의 NS 레코드를 상위 도메인의 영역 파일에 추가합니다. NS 레코드에 하위 도메인과 같은 이름을 지정합니다. NS 레코드 값에는 2단계에서 생성한 호스팅 영역과 연결된 네 개 Route 53 이름 서버를 지정합니다. 다른 DNS 서비스에서는 다른 용어를 사용하므로 주의하십시오. 이 단계의 수행 방법을 배우기 위해 DNS 서비스에 기술 지원을 문의해야 할 수도 있습니다. **중요** SOA(권한 시작) 레코드를 상위 도메인의 영역 파일에 추가하지 마십시오. 하위 도메인은 Route 53을 사용하기 때문에 상위 도메인에 대한 DNS 서비스는 하위 도메인에 대한 권한이 없습니다. DNS 서비스가 자동으로 하위 도메인의 SOA 레코드에 추가된 경우, 하위 도메인의 레코드를 삭제하십시오. 단, 상위 도메인에 대한 SOA 레코드는 삭제하지 마십시오. 상위 도메인의 이름 서버에 대한 TTL 설정에 따라, 변경 사항이 DNS 해석기에 전파되기까지 48시간 이상이 걸릴 수 있습니다. 이 기간 동안 DNS 해석기는 계속 상위 도메인의 DNS 서비스에 대한 이름 서버로 요청에 답할 수 있습니다. 또한 클라이언트 컴퓨터는 하위 도메인에 대한 이전 이름 서버를 캐시에 계속 보관할 수 있습니다. 1. 도메인의 등록자 TTL 설정이 완료된 후(2단계 참조), 상위 도메인 영역 파일에서 다음의 레코드를 삭제합니다. + [레코드 생성](#AddMigratedSubdomainRecords)에서 설명한 것과 같이 Route 53에 추가한 레코드입니다. + DNS 서비스의 NS 레코드입니다. NS 레코드 삭제를 완료하면 4단계에서 생성한 NS 레코드만 영역 파일에 남게 됩니다. # Transitioning to latency-based routing in Amazon Route 53 지연 시간 기반 라우팅을 사용하면 Amazon Route 53에서 사용 가능한 지연 시간이 가장 짧은 AWS 엔드포인트로 사용자를 안내할 수 있습니다. 예를 들어 `www.example.com`과 같은 DNS 이름을 ELB Classic, Application 또는 Network Load Balancer나 Amazon EC2 인스턴스 또는 미국 동부(오하이오) 및 유럽(아일랜드) 리전에서 호스팅하는 탄력적 IP 주소와 연결할 수 있습니다. Route 53 DNS 서버는 지난 몇 주간의 네트워크 조건에 따라 특정 사용자에게 제공할 리전 및 해당 리전의 인스턴스를 결정합니다. 런던의 사용자를 유럽(아일랜드) 인스턴스로, 시카고의 사용자를 미국 동부(오하이오) 인스턴스로 보낼 가능성이 있습니다. Route 53는 A, AAAA, TXT 및 CNAME 레코드에 대한 지연 시간 기반 라우팅은 물론 A 및 AAAAA 레코드에 대한 별칭도 지원합니다. **참고** 사용자와 리소스 간의 지연 시간에 대한 데이터는 전적으로 사용자와 AWS 데이터 센터 간의 트래픽을 기반으로 합니다. AWS 리전에서 리소스를 사용하지 않는 경우 사용자와 리소스 간의 실제 지연 시간은 AWS 지연 시간 데이터와 크게 다를 수 있습니다. 리소스가 AWS 리전과 동일한 도시에 있더라도 마찬가지입니다. 유연하고 위험 부담이 낮은 전환을 위해 가중치 기반 레코드와 지연 시간 레코드를 결합하여 스탠다드 라우팅에서 지연 시간 기반 라우팅으로 점차 마이그레이션하면서 각 단계에 완벽한 제어 및 롤백 기능을 적용할 수 있습니다. 미국 동부(오하이오) 리전의 Amazon EC2 인스턴스에서 호스팅 중인 `www.example.com`의 예를 살펴보겠습니다. 이 인스턴스에는 엘라스틱 IP 주소 `W.W.W.W`가 있습니다. 사용자를 미국 서부(캘리포니아 북부) 리전(탄력적 IP `X.X.X.X`) 및 유럽(아일랜드) 리전(탄력적 IP `Y.Y.Y.Y`)의 추가 Amazon EC2 인스턴스로 보내는 한편, 가능하면 미국 동부(오하이오) 리전으로 트래픽을 계속 라우팅하려 한다고 가정합시다. `example.com`에 대한 Route 53 호스팅 영역은 이미 **유형(Type)**이 A이고 **값(Value)**(IP 주소)이 `W.W.W.W`인 `www.example.com`에 대한 레코드가 있습니다. 다음 예를 완료하면 두 개의 가중치 기반 별칭 레코드가 구성됩니다. + `www.example.com`에 대한 기존의 레코드를 가중치 기반 별칭 레코드로 변환하여 대부분의 트래픽을 미국 동부(오하이오) 리전에서 기존의 Amazon EC2 인스턴스로 계속 보냅니다. + 처음에는 트래픽의 일부분만 지연 시간 레코드로 보내는 가중치 기반 별칭 레코드를 하나 더 생성하여 트래픽을 세 리전 모두로 라우팅합니다. 이러한 가중치 기반 별칭 레코드의 가중치를 업데이트하여 미국 동부(오하이오) 리전으로만 트래픽을 라우팅하는 것에서 Amazon EC2 인스턴스가 있는 세 리전 모두로 트래픽을 라우팅하도록 점차 바꿀 수 있습니다. **지연 시간 기반 라우팅으로 전환하려면** 1. `copy-www.example.com`과 같은 새로운 도메인 이름을 사용하여 `www.example.com`의 레코드를 복사합니다. 새 레코드에 `www.example.com`의 레코드와 동일한 **유형(Type)**(A) 및 **값(Value)**(`W.W.W.W`)을 지정합니다. 1. `www.example.com`에 대한 기존의 A 레코드를 업데이트하여 가중치 기반 별칭 레코드로 만듭니다. + **값/트래픽 라우팅 대상(Value/Route traffic to)**은 **이 호스팅 영역의 다른 레코드에 대한 별칭**을 선택하고 `copy-www.example.com`을 지정합니다. + **가중치(Weight)**는 100을 지정합니다. 업데이트가 완료되면 Route 53는 이 레코드를 사용하여 `W.W.W.W`의 IP 주소가 있는 리소스로 모든 트래픽을 라우팅합니다. 1. Amazon EC2 인스턴스별로 다음과 같은 지연 시간 레코드를 생성합니다. + 미국 동부(오하이오), 탄력적 IP 주소(`W.W.W.W`) + 미국 서부(캘리포니아 북부), 탄력적 IP 주소(`X.X.X.X`) + 유럽(아일랜드), 탄력적 IP 주소(`Y.Y.Y.Y`) 모든 지연 시간 레코드에 `www-lbr.example.com` 등 동일한 도메인 이름과 동일한 유형 A를 지정합니다. 지연 시간 레코드가 생성되면 Route 53는 2단계에서 업데이트한 레코드를 사용하여 트래픽을 계속 라우팅합니다. 각 엔드포인트가 요청을 수락하도록 하는 등 확인 테스트에 `www-lbr.example.com`을 사용할 수 있습니다. 1. `www-lbr.example.com` 지연 시간 레코드를 `www.example.com` 가중치 기반 레코드에 추가한 다음 제한된 트래픽을 해당하는 Amazon EC2 인스턴스로 라우팅하기 시작합니다. 이로써 미국 동부(오하이오) 리전의 Amazon EC2 인스턴스는 양쪽의 가중치 기반 레코드로부터 트래픽을 가져오게 됩니다. `www.example.com`에 대한 가중치 기반 별칭 레코드를 하나 더 생성: + **값/트래픽 라우팅 대상(Value/Route traffic to)**은 **이 호스팅 영역의 다른 레코드에 대한 별칭**을 선택하고 `www-lbr.example.com.`을 지정합니다. + **가중치(Weight)**는 1을 지정합니다. 작업을 마치고 변경 사항이 Route 53 서버로 동기화된 후, Route 53는 3단계에서 지연 시간 레코드를 생성한 Amazon EC2 인스턴스로 작은 트래픽 조각(1/101)을 라우팅하기 시작합니다. 1. 엔드포인트가 수신 트래픽에 알맞게 적절히 확장된다는 확신이 생기면 그에 따라 가중치를 조정하십시오. 예를 들어 요청의 10%를 지연 시간 기반 라우팅으로 보내려면 가중치를 각각 90 및 10으로 변경합니다. 지연 시간 레코드 생성에 대한 자세한 내용은 [Amazon Route 53 콘솔을 사용하여 레코드 생성](resource-record-sets-creating.md) 단원을 참조하십시오. # Amazon Route 53의 지연 시간 기반 라우팅에 다른 리전 추가 지연 시간 기반 라우팅을 사용 중이고 새로운 리전에 인스턴스를 추가하려는 경우, [Transitioning to latency-based routing in Amazon Route 53](TutorialTransitionToLBR.md)에서 트래픽을 점차 지연 시간 기반 라우팅으로 바꾼 것과 같은 방식으로 트래픽을 새로운 리전으로 보낼 수 있습니다. 예를 들어, 지연 시간 기반 라우팅을 사용하여`www.example.com`의 트래픽을 라우팅하고 있으며, 아시아 태평양(도쿄)의 Amazon EC2 인스턴스를 미국 동부(오하이오), 미국 서부(캘리포니아 북부) 및 유럽(아일랜드)의 인스턴스에 추가하려 한다고 가정합시다. 다음 예시 절차는 다른 리전에 인스턴스를 추가하는 한 가지 방식을 설명하고 있습니다. 이 예제의 경우 `example.com`의 Amazon Route 53 호스팅 영역에는 이미 `www-lbr.example.com`에 대한 지연 시간 기반 레코드로 트래픽을 라우팅하는 `www.example.com`의 가중치 기반 별칭 레코드가 있습니다. + 미국 동부(오하이오), 탄력적 IP 주소(`W.W.W.W`) + 미국 서부(캘리포니아 북부), 탄력적 IP 주소(`X.X.X.X`) + 유럽(아일랜드), 탄력적 IP 주소(`Y.Y.Y.Y`) 가중치 기반 별칭 레코드에는 100의 가중치가 있습니다. 지연 시간 기반 라우팅으로 전환한 후, 전환할 때 사용한 다른 가중치 기반 레코드를 삭제했다고 가정하겠습니다. **Route 53의 지연 시간 기반 라우팅에 다른 리전을 추가하려면** 1. 원본 리전 세 개와 트래픽을 라우팅할 새 리전을 포함하여 새로운 지연 시간 기반 레코드 네 개를 생성합니다. + 미국 동부(오하이오), 탄력적 IP 주소(`W.W.W.W`) + 미국 서부(캘리포니아 북부), 탄력적 IP 주소(`X.X.X.X`) + 유럽(아일랜드), 탄력적 IP 주소(`Y.Y.Y.Y`) + 아시아 태평양(도쿄), 탄력적 IP 주소(`Z.Z.Z.Z`) 모든 지연 시간 레코드에 `www-lbr-2012-04-30.example.com` 등 동일한 새 도메인 이름과 동일한 유형 A를 지정합니다. 지연 시간 레코드가 생성되면 Route 53는 원래의 가중치 기반 별칭 레코드(`www.example.com`) 및 지연 시간 레코드(`www-lbr.example.com`)를 사용하여 트래픽을 계속 라우팅합니다. 각 엔드포인트가 요청을 수락하도록 하는 등 확인 테스트에 `www-lbr-2012-04-30.example.com` 레코드를 사용할 수 있습니다. 1. 새로운 지연 시간 레코드에 대한 가중치 기반 별칭 레코드를 생성: + 기존의 가중치 기반 별칭 레코드 이름인 `www.example.com`을 도메인 이름으로 지정합니다. + **값/트래픽 라우팅 대상(Value/Route traffic to)**은 **이 호스팅 영역의 다른 레코드에 대한 별칭**을 선택하고 `www-lbr-2012-04-30.example.com`을 지정합니다. + **가중치(Weight)**는 1을 지정합니다. 완료 후, Route 53는 1단계에서 `www-lbr-2012-04-30.example.com` 지연 시간 레코드를 생성한 Amazon EC2 인스턴스로 작은 트래픽 조각(1/101)을 라우팅하기 시작합니다. 트래픽의 나머지 부분은 아시아 태평양(도쿄) 리전에 Amazon EC2 인스턴스가 없는 `www-lbr.example.com` 지연 시간 레코드로 계속 라우팅됩니다. 1. 엔드포인트가 수신 트래픽에 알맞게 적절히 확장된다는 확신이 생기면 그에 따라 가중치를 조정하십시오. 예를 들어 요청의 10%를 도쿄 리전이 포함된 지연 시간 레코드로 라우팅하려면 `www-lbr.example.com`의 가중치를 100에서 90으로, `www-lbr-2012-04-30.example.com`의 가중치를 1에서 10으로 변경합니다. 레코드 생성에 대한 자세한 내용은 [Amazon Route 53 콘솔을 사용하여 레코드 생성](resource-record-sets-creating.md) 단원을 참조하십시오. # Amazon Route 53의 지연 시간 및 가중치 기반 레코드를 사용하여 한 리전의 여러 Amazon EC2 인스턴스로 트래픽 라우팅 Amazon EC2 리전 둘 이상의 Amazon EC2 인스턴스에서 애플리케이션을 실행 중이고 하나 이상의 리전에 둘 이상의 Amazon EC2 인스턴스가 있는 경우, 지연 시간 기반 라우팅을 사용하여 정확한 리전으로 트래픽을 라우팅할 수 있습니다. 그런 다음 가중 레코드를 사용하여 지정한 가중치에 따라 리전 내 인스턴스로 트래픽을 라우팅합니다. 예를 들어, 미국 동부(오하이오) 리전에 탄력적 IP 주소의 Amazon EC2 인스턴스가 세 개 있고 미국 동부(오하이오) 리전에 속하는 사용자를 위해 세 IP 모두에 균등하게 요청을 배포하려 한다고 가정합시다. 한 번에 여러 리전에 같은 기술을 적용할 수 있지만, 다른 리전에서는 Amazon EC2 인스턴스 하나면 충분합니다. **Amazon Route 53의 지연 시간 및 가중치 기반 레코드를 사용하여 한 리전의 여러 Amazon EC2 인스턴스로 트래픽 라우팅하려면** 1. 리전에서 Amazon EC2 인스턴스에 대한 가중치 기반 레코드 그룹을 생성합니다. 다음 사항에 유의하세요. + 각 가중치 기반 레코드에 **이름(Name)**(예: `us-east.example.com`) 및 **유형(Type)**과 같은 값을 지정합니다. + **값/트래픽 라우팅 대상**은 **IP 주소 또는 레코드 유형에 따라 다른 값**을 선택하고, 탄력적 IP 주소 중 하나의 값을 지정합니다. + Amazon EC2 인스턴스에 동등하게 가중치를 주려는 경우, **가중치(Weight)**에 대한 값을 지정합니다. + 각 레코드에 대한 [**Set ID**]의 고유 값을 지정합니다. 가중치 기반 레코드에 대한 자세한 내용은 [가중치 기반 라우팅](routing-policy-weighted.md) 단원을 참조하십시오. 1. 다른 리전에 여러 Amazon EC2 인스턴스가 있는 경우, 해당 리전에 대한 1단계를 반복합니다. 각 리전에서 [**Name**]에 대한 다른 값을 지정합니다. 1. 여러 Amazon EC2 인스턴스가 있는 각 리전에 대해(예: 미국 동부(오하이오)) 지연 시간 별칭 레코드를 생성합니다. **값/트래픽 라우팅 대상**에 **이 호스팅 영역의 다른 레코드에 대한 별칭**을 선택하고, 해당 리전의 가중 레코드에 할당한 **레코드 이름** 필드(예: `us-east.example.com`)의 값을 지정합니다. 1. Amazon EC2 인스턴스 한 개가 있는 각 리전에 대해 지연 시간 레코드를 생성합니다. **레코드 이름(Record name)**은 3단계에서 생성한 지연 시간 별칭 레코드와 동일한 값을 지정합니다. **값/트래픽 라우팅 대상(Value/Route traffic to)**은 **IP 주소 또는 레코드 유형에 따라 다른 값(IP address or another value depending on the record type)**을 선택하고, 해당 리전에 있는 Amazon EC2 인스턴스의 탄력적 IP 주소를 지정합니다. Amazon EC2 인스턴스의 별칭 레코드 추가에 대한 자세한 내용은 [Amazon EC2 인스턴스로 트래픽 라우팅](routing-to-ec2-instance.md) 단원을 참조하십시오. 레코드 생성에 대한 자세한 내용은 [Amazon Route 53 콘솔을 사용하여 레코드 생성](resource-record-sets-creating.md) 단원을 참조하십시오. # Amazon Route 53에서 100개 이상의 가중치 기반 레코드 관리 Amazon Route 53를 통해 가중치 기반 레코드를 구성할 수 있습니다. 주어진 이름 및 유형(예: `www.example.com`, 유형 A)에 각각 가중치가 있는 최대 100개의 대체 응답을 구성할 수 있습니다. `www.example.com`에 대한 쿼리에 응답할 때 Route 53 DNS 서버는 DNS 해석기에 반환하기 위한 임의 가중치 기반 응답을 선택합니다. 2의 가중치가 있는 가중치 기반 레코드 값은 평균적으로 1의 가중치가 있는 가중치 기반 레코드 값과 마찬가지로 두 번 반환됩니다. 100개 이상의 엔드포인트로 트래픽을 보내려면 가중치 기반 별칭 레코드 및 가중치 기반 레코드의 트리를 사용할 수 있습니다. 예를 들어, 트리의 첫 번째 “수준”은 최대 100개의 가중치 기반 별칭 레코드일 수 있으며, 별칭 레코드 각각은 최대 100개의 가중치 기반 레코드를 차례로 가리킬 수 있습니다. Route 53에서는 최대 3가지 수준의 재귀를 허용하므로 최대 1,000,000개의 고유한 가중치 기반 엔드포인트를 관리할 수 있습니다. 간단한 2단계 트리의 모습은 다음과 같습니다. **가중치 기반 별칭 레코드** + 가중치 1의 `www-a.example.com`에 대한 `www.example.com` 별칭 + 가중치 1의 `www-b.example.com`에 대한 `www.example.com` 별칭 **가중치 기반 레코드** + `www-a.example.com`, 유형 A, 값 192.0.2.1, 가중치 1 + `www-a.example.com`, 유형 A, 값 192.0.2.2, 가중치 1 + `www-b.example.com`, 유형 A, 값 192.0.2.3, 가중치 1 + `www-b.example.com`, 유형 A, 값 192.0.2.4, 가중치 1 레코드 생성에 대한 자세한 내용은 [레코드 작업](rrsets-working-with.md) 단원을 참조하십시오. # Amazon Route 53에서 내결함성 멀티 레코드 응답 가중치 부여 **참고** 다중 응답 라우팅 정책을 사용하는 레코드는 이 자습서에서 설명하는 구성과 거의 비슷하게 동작합니다. 주된 차이점은 자습서 구성에서는 가중치를 지정할 수 있다는 점입니다. 이는 엔드포인트 용량이 서로 다를 때 유용할 수 있습니다. 자세한 내용은 [다중값 응답 라우팅](routing-policy-multivalue.md) 단원을 참조하십시오. Amazon Route 53 가중치 기반 레코드는 오직 하나의 레코드와 연결할 수 있습니다. 즉, 이름 하나(예: `example.com`)와 레코드 유형 하나(예: A)만 조합할 수 있습니다. 그러나 여러 레코드가 포함된 DNS 응답에 가중치를 부여하는 것이 바람직한 경우가 많습니다. 예를 들어, 서비스의 탄력적 IP 엔드포인트 또는 Amazon EC2 인스턴스가 여덟 개 있을 수 있습니다. 해당 서비스의 클라이언트가 일반적인 브라우저와 같이 연결 재시도를 지원하는 경우, DNS 응답에 IP 주소 여러 개를 제시하면 특정 엔드포인트에 장애가 있을 때 그러한 클라이언트에게 대체 엔드포인트를 제시할 수 있습니다. 둘 이상의 가용 영역에서 호스팅하는 IP 조합을 넣어 응답을 구성하는 경우, 가용 영역의 장애까지 대비할 수 있습니다. 멀티 레코드 응답은 다수의 클라이언트(예: 모바일 웹 애플리케이션)가 작은 DNS 캐시 세트를 공유할 때도 유용합니다. 이 경우, 클라이언트는 공유 캐시에서 일반적인 DNS 응답을 받았더라도 멀티 레코드 응답을 토대로 요청을 여러 엔드포인트로 보낼 수 있습니다. 이러한 유형의 가중치 기반 멀티 레코드 응답은 레코드와 가중치 기반 별칭 레코드의 조합을 사용하여 얻을 수 있습니다. 엔드포인트 여덟 개를 각각 IP 주소 네 개를 포함하는 레코드 세트 두 그룹으로 나눌 수 있습니다. 다음 값을 가진 `endpoint-a.example.com`, 유형 A + 192.0.2.1 + 192.0.2.2 + 192.0.2.128 + 192.0.2.129 다음 값을 가진 `endpoint-b.example.com`, 유형 A + 192.0.2.3 + 192.0.2.4 + 192.0.2.130 + 192.0.2.131 그런 다음 각 그룹을 가리키는 가중치 기반 별칭 레코드를 생성할 수 있습니다. + `endpoint-a.example.com`에 대한 `www.example.com` 별칭, 유형 A, 가중치 1 + `endpoint-b.example.com`에 대한 `www.example.com` 별칭, 유형 A, 가중치 1 레코드 생성에 대한 자세한 내용은 [레코드 작업](rrsets-working-with.md) 단원을 참조하십시오.