상태 확인이 복잡한 Amazon Route 53 구성에서 작동하는 방식 - Amazon Route 53

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

상태 확인이 복잡한 Amazon Route 53 구성에서 작동하는 방식

복잡한 구성에서 리소스의 상태를 확인하는 것은 단순한 구성에 이루어지는 방식과 상당 부분 같습니다. 그러나 복잡한 구성에서는 별칭 레코드(가중치 기반 별칭, 장애 조치 별칭 등)와 비 별칭 레코드의 조합을 사용하여 Route 53가 요청에 응답하는 방식을 더 잘 제어할 수 있게 해주는 판단 트리를 구축합니다.

예를 들어 지연 시간 별칭 레코드를 사용하여 사용자에게 가까운 리전을 선택하고 각 리전 내의 둘 이상의 리소스에 대한 가중치 기반 레코드를 사용하여 단일 엔드포인트 또는 가용 영역의 실패를 방지할 수 있습니다. 다음 다이어그램은 이 구성을 보여줍니다.


				지연 시간 별칭 레코드와 가중치 기반 별칭 레코드를 포함하는 DNS 구성.

Amazon EC2 및 Route 53가 구성되는 방법은 다음과 같습니다. 트리의 하단에서 시작합니다. 레코드를 생성하는 순서이기 때문입니다.

  • us-east-1 및 ap-southeast-2의 두 리전 각각에서 2개의 EC2 인스턴스를 갖습니다. Route 53가 정상 여부를 기반으로 EC2 인스턴스로 트래픽을 라우팅하고자 하는 경우 각 인스턴스에 대해 상태 확인을 생성합니다. 각 상태 확인을 구성하여 상태 확인 요청을 해당 인스턴스의 탄력적 IP 주소에 있는 해당 인스턴스로 전송합니다.

    Route 53는 전역 서비스이므로 상태 확인을 생성하고자 하는 리전을 지정하지 않습니다.

  • 인스턴스 유형을 기반으로 각 리전에 있는 2개의 인스턴스로 트래픽을 라우팅하고자 하는 경우 각 인스턴스에 대한 가중치 기반 레코드를 생성하고 각 레코드에 가중치를 부여합니다. (이후 가중치를 변경하여 인스턴스로의 트래픽 라우팅을 늘리거나 줄일 수 있습니다.) 또한 해당 상태 확인을 각 인스턴스와 연결합니다.

    레코드를 생성할 때 us-east-1-www.example.com 및 ap-southeast-2-www.example.com과 같은 이름을 사용합니다. 레코드에 사용자가 웹 사이트 또는 웹 애플리케이션에 액세스하는 데 사용하는 이름(예: example.com)을 지정하려면 트리 상단으로 이동할 때까지 기다립니다.

  • 사용자에 대해 가장 낮은 지연 시간을 제공하는 리전으로 트래픽을 라우팅하고자 하는 경우 트리 상단에서 레코드에 대한 지연 시간 라우팅 정책을 선택합니다.

    직접 각 리전의 리소스가 아니라 각 리전의 레코드로 트래픽을 라우팅하고자 합니다(이미 가중치 기반 레코드가 이를 수행하고 있음). 그 결과 지연 시간 별칭 레코드를 생성합니다.

    별칭 레코드를 생성할 때 사용자가 웹 사이트 또는 웹 애플리케이션에 액세스하는 데 사용하는 이름(예: example.com)을 지정합니다. 별칭 레코드는 example.com에 대한 트래픽을 us-east-1-www.example.com 및 ap-southeast-2-www.example.com 레코드로 라우팅합니다.

    지연 시간 별칭 레코드 모두에 대해 [Evaluate Target Health]의 값을 [Yes]로 설정합니다. 이렇게 하면 Route 53는 트래픽 라우팅을 시도하기 전에 리전에 정상 리소스가 있는지 여부를 확인합니다. 정상 리소스가 없는 경우 Route 53는 다른 리전의 정상 리소스를 선택합니다.


				지연 시간 별칭 레코드와 가중치 기반 별칭 레코드를 포함하는 DNS 구성.

앞의 다이어그램에서는 이벤트들의 순서를 다음과 같이 보여줍니다.

  1. Route 53는 example.com에 대한 쿼리를 수신합니다. Route 53는 요청을 보내는 사용자의 지연 시간을 기반으로 us-east-1 리전에 대한 지연 시간 별칭 레코드를 선택합니다.

  2. Route 53는 가중치를 기반으로 가중치 기반 레코드를 선택합니다. 대상 상태 평가(Evaluate Target Health)는 지연 시간 별칭 레코드에 대해 예(Yes)이므로 Route 53는 선택한 가중치 기반 레코드의 상태를 확인합니다.

  3. 상태 확인이 실패했으므로 Route 53는 가중치를 기반으로 다른 가중치 기반 레코드를 선택하여 그 상태를 확인합니다. 해당 레코드 역시 비정상입니다.

  4. Route 53는 트리의 가지를 포기하고 차선의 지연 시간을 지닌 지연 시간 별칭 레코드를 찾아 ap-southeast-2에 대한 레코드를 선택합니다.

  5. Route 53는 다시 가중치를 기반으로 레코드를 선택한 다음 선택한 리소스의 상태를 확인합니다. 리소스가 정상이므로 Route 53는 쿼리에 응답해 해당하는 값을 반환합니다.

상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?

[Evaluate Target Health]의 값을 [Yes]로 설정하는 작업 대신 또는 이 작업 외에 상태 확인을 별칭 레코드와 연결할 수 있습니다. 그러나 Route 53가 기본 리소스(별칭 레코드가 참조하는 HTTP 서버, 데이터베이스 서버, 및 기타 리소스)의 상태에 따라 쿼리에 반응한다면 대개의 경우 더 유용합니다. 예를 들어, 다음과 같은 구성을 가정해 봅시다.

  • 별칭 대상이 가중치 기반 레코드의 그룹인 지연 시간 별칭 레코드에 상태 확인을 할당합니다.

  • 지연 시간 별칭 레코드에 대해 [Evaluate Target Health]의 값을 [Yes]로 설정합니다.

이 구성에서는 Route 53가 가중치 기반 레코드에 해당하는 값을 반환하기 전에 다음 두 가지가 모두 참이어야 합니다.

  • 지연 시간 별칭 레코드와 연결된 상태 확인이 통과되어야 합니다.

  • 통과하는 상태 확인과 연결되어 있거나 상태 확인과 연결되어 있지 않기 때문에 한 개 이상의 가중치 기반 레코드가 정상 상태로 간주되어야 합니다. 후자의 경우 Route 53는 항상 가중치 기반 레코드를 정상 상태로 간주합니다.

다음 그림에서 왼쪽 상단에 있는 지연 시간 별칭 레코드에 대한 상태 확인이 실패했습니다. 그 결과 Route 53는 가중치 기반 레코드가 모두 정상인 경우에도 지연 시간 별칭 레코드가 참조하는 가중치 기반 레코드를 사용하여 쿼리에 응답하는 것을 중단합니다. Route 53는 지연 시간 별칭 레코드에 대한 상태 확인이 다시 정상인 경우에만 이러한 가중치 기반 레코드를 다시 고려하기 시작합니다. (예외 사항은 상태 확인 구성 시 Amazon Route 53의 레코드 선택 방식 단원을 참조하십시오.)


					두 Evaluate Target Health(대상 상태 평가)가 모두 예로 설정되어 있는 별칭 레코드와 별칭 레코드에 대한 상태 확인을 포함하는 DNS 구성.

상태 확인을 생략하면 어떻게 됩니까?

복잡한 구성에서는 상태 확인을 비 별칭 레코드 전체에 연결하는 것이 중요합니다. 다음 예제에서 us-east-1 리전에서 가중치 기반 레코드 중 하나에 대한 상태 확인이 누락되었습니다.


					실패한 상태 확인 1개와 상태 확인이 없는 레코드 1개를 포함하는 DNS 구성.

이 구성에서 비 별칭 레코드에 대한 상태 확인을 생략할 때 발생하는 일은 다음과 같습니다.

  1. Route 53는 example.com에 대한 쿼리를 수신합니다. Route 53는 요청을 보내는 사용자의 지연 시간을 기반으로 us-east-1 리전에 대한 지연 시간 별칭 레코드를 선택합니다.

  2. Route 53는 지연 시간 별칭 레코드에 대한 별칭 대상을 찾아서 해당 상태 확인의 상태를 확인합니다. 한 개의 가중치 기반 레코드에 대한 상태 확인이 실패했으므로 레코드는 고려 대상에서 생략됩니다.

  3. us-east-1 리전에 대한 별칭 대상에서 기타 가중치 기반 레코드에는 상태 확인이 없습니다. 해당 리소스는 정상이거나 비정상이겠지만, 상태 확인이 없으면 Route 53는 알 방법이 없습니다. 리소스가 정상으로 가정하여 Route 53는 쿼리에 응답해 해당하는 값을 반환합니다.

[Evaluate Target Health]를 [No]로 설정하면 어떻게 됩니까?

일반적으로 트리의 모든 별칭 레코드에 대해 [Evaluate Target Health]를 [Yes]로 설정해야 합니다. 대상 상태 평가(Evaluate Target Health)아니요(No)로 설정한 경우 레코드에 대한 상태 확인이 실패하는 경우에도 Route 53는 계속해서 별칭 레코드가 참조하는 레코드로 트래픽을 라우팅합니다.

다음 예제에서는 가중치 기반 레코드 전체가 상태 확인과 연결되었지만 us-east-1 리전의 지연 시간 별칭 레코드에 대해 [Evaluate Target Health]가 [No]로 설정되어 있습니다.


					Evaluate Target Health(대상 상태 평가)가 아니요로 설정된 별칭 레코드를 포함하는 DNS 구성.

이 구성에서 별칭 레코드에 대해 [Evaluate Target Health]를 [No]로 설정할 때 발생하는 일은 다음과 같습니다.

  1. Route 53는 example.com에 대한 쿼리를 수신합니다. Route 53는 요청을 보내는 사용자의 지연 시간을 기반으로 us-east-1 리전에 대한 지연 시간 별칭 레코드를 선택합니다.

  2. Route 53는 지연 시간 별칭 레코드에 대한 별칭 대상이 무엇인지 판단하여 해당 상태 확인을 확인합니다. 둘 다 실패합니다.

  3. us-east-1 리전의 지연 시간 별칭 레코드에 대해 대상 상태 평가(Evaluate Target Health)의 값이 아니요(No)로 설정되어 있으므로 Route 53는 가지를 포기하고 ap-southeast-2 리전의 정상적인 레코드를 찾는 대신 이 가지에서 하나의 레코드를 선택해야 합니다.