장애 조치 및 지리적 위치 라우팅

장애 조치 라우팅은 활성-수동 구성을 구현합니다. 하나의 레코드는 기본으로 지정되고 다른 레코드는 보조로 지정됩니다. Route 53은 기본 레코드의 상태 확인이 통과하는 동안 항상 기본 레코드를 반환합니다. 기본 레코드가 비정상 상태가 되면 Route 53은 자동으로 보조 레코드를 반환하도록 전환합니다.

장애 조치 라우팅은 프로덕션 환경(기본)과 기본 환경이 중단되었을 때만 트래픽을 수신해야 하는 대기 환경(보조)이 있는 재해 복구 시나리오에서 대표적으로 사용하는 패턴입니다.

장애 조치 라우팅을 설정하려면 DNS 이름이 동일한 레코드 두 개를 생성합니다. 하나에는 Failover=PRIMARY를 지정하고 다른 하나에는 Failover=SECONDARY를 지정합니다. 기본 레코드에 상태 확인을 연결합니다. 보조 레코드가 독립적으로 장애가 발생할 수 있는 리소스를 가리키는 경우에는 보조 레코드에도 상태 확인을 설정해야 합니다.

보조 레코드는 정적인 대체 대상으로 사용되며 S3 정적 웹 사이트, 유지 관리 페이지 또는 축소된 대기 환경을 가리킬 수 있습니다. 보조 레코드에 상태 확인이 없더라도 기본 레코드에 장애가 발생하면 Route 53은 항상 보조 레코드로 대체합니다.

장애 조치 라우팅은 활성-수동 구성을 만듭니다. 정상적으로 작동하는 동안에는 기본 레코드만 트래픽을 처리하고, 보조 레코드는 인계를 기다리며 유휴 상태로 있습니다. 따라서 대기 환경의 비용은 최소화되지만 복구 시간이 약간 더 길어집니다(DNS TTL이 만료되고 Route 53이 전환하는 데 걸리는 시간 때문입니다).

활성-활성 구성처럼 두 리소스가 동시에 트래픽을 처리하도록 하려면 가중치가 동일한 가중치 기반 라우팅 또는 지연 시간 기반 라우팅을 사용합니다. 한 리소스에 장애가 발생하면 해당 리소스의 상태 확인이 실패하고 Route 53이 자동으로 DNS 응답에서 해당 리소스를 제거하므로, 기본 제공 장애 조치 기능이 있는 활성-활성 구성을 구현할 수 있습니다.

지리적 위치 기반 라우팅은 DNS 확인자(일반적으로 사용자의 ISP 확인자 또는 AWS Route 53 Resolver)의 지리적 위치를 기준으로 DNS 쿼리를 라우팅합니다. 특정 대륙, 국가 또는 미국 주에 대한 레코드를 생성하면 Route 53은 쿼리 출처와 가장 구체적으로 일치하는 위치의 레코드를 반환합니다.

특정 위치의 레코드가 일치하지 않으면 Route 53은 기본 레코드가 구성된 경우 이를 반환합니다. 기본 레코드가 없으면 일치하지 않는 위치에서 온 쿼리에 NODATA가 반환됩니다. 명시적으로 구성하지 않은 위치의 사용자도 처리할 수 있도록 항상 기본 레코드를 생성해야 합니다.

지리적 위치 기반 라우팅의 주요 사용 사례는 다음과 같습니다.

• 언어별 콘텐츠: 프랑스어 사용자는 프랑스어 CDN 오리진으로, 독일어 사용자는 독일 오리진으로 라우팅합니다.
• 규정 준수: EU 사용자 데이터가 EU 리전에 유지되도록 하거나(GDPR), 특정 국가에서의 액세스를 차단합니다.
• 지역별 가격 또는 제공 여부: 지역별 가격을 표시하거나 지원되는 지역으로 서비스를 제한합니다.
• 지리적 차단: 제한된 위치의 사용자가 지리적 위치 레코드를 유지 관리 엔드포인트로 연결하도록 구성하여 차단 페이지 또는 빈 응답을 반환합니다.

Route 53은 가장 구체적인 지리적 위치를 기준으로 일치시킵니다. 주 수준 레코드가 국가 수준 레코드보다 우선하고, 국가 수준 레코드는 대륙 수준 레코드보다 우선하며, 대륙 수준 레코드는 기본값보다 우선합니다. 미국 주 수준의 지리적 위치는 미국에서만 사용할 수 있습니다.

기본 레코드를 생략하고 사용자의 위치와 일치하는 구성된 레코드가 없으면 Route 53은 NXDOMAIN 또는 NODATA를 반환합니다. 그러면 구성되지 않은 지역의 사용자가 아무런 안내 없이 액세스할 수 없게 됩니다. 이러한 자동 실패를 방지하려면 모든 위치를 포괄하는 기본 지리적 위치 레코드를 항상 추가해야 합니다.

지리적 근접성 기반 라우팅은 사용자와 리소스 사이의 물리적 지리적 거리를 기준으로 트래픽을 라우팅하며, 선택적으로 각 리소스의 유효 라우팅 반경을 넓히거나 좁히는 편향을 적용할 수 있습니다. 양수 편향은 리소스가 서비스를 제공하는 지리적 영역을 넓히고, 음수 편향은 이를 좁힙니다.

지리적 근접성 기반 라우팅은 Traffic Flow(Route 53의 시각적 라우팅 정책 편집기)를 통해서만 사용할 수 있습니다. 또한 Route 53이 좌표를 자동으로 알고 있는 AWS 리전과 위도 및 경도를 직접 제공하는 사용자 지정 리소스 위치를 모두 지원합니다.

Route 53 Traffic Flow은 트리 형태의 다이어그램에서 여러 라우팅 정책을 결합하여 복잡한 라우팅 논리를 구성할 수 있는 시각적 정책 편집기입니다. 예를 들어 먼저 지리적 위치 기반 라우팅을 적용하여 EU 트래픽을 분리한 다음, EU 내부에는 지연 시간 기반 라우팅을 적용하여 성능이 가장 좋은 리전을 선택하고, 마지막으로 각 리전 내부에서 가중치 기반 라우팅을 사용하여 블루-그린 배포를 수행할 수 있습니다.

Traffic Flow 정책은 버전으로 관리되므로 변경 사항을 안전하게 테스트할 수 있습니다. 하나 이상의 DNS 이름에 Traffic Flow 정책을 연결하면 개별 레코드를 다시 생성하지 않고도 정책 업데이트가 즉시 전파됩니다.

장애 조치 라우팅은 다른 정책 안에 중첩할 수 있습니다. 일반적인 패턴은 다음과 같습니다. 지연 시간 기반 라우팅으로 가장 가까운 리전을 선택하고, 각 리전 내부에서는 장애 조치 레코드를 사용하여 해당 리전의 기본 엔드포인트에 장애가 발생하면 트래픽이 같은 리전의 보조 엔드포인트로 자동 전환되도록 합니다.

또 다른 패턴은 기본 엔드포인트에 지연 시간 기반 라우팅을 사용하는 다중 리전 활성-수동 구성입니다. 기본 리전의 상태 확인이 실패하면 Route 53은 지연 시간이 다음으로 낮은 정상 리전으로 넘어가므로, 지연 시간 최적화와 DR 장애 조치를 사실상 결합할 수 있습니다.

장애 조치 라우팅이 올바르게 작동하려면 기본 레코드에 상태 확인이 반드시** 연결되어 있어야 합니다. 상태 확인이 없으면 Route 53은 기본 레코드를 항상 정상 상태로 간주하므로 보조 레코드로 전환하지 않습니다. 보조 레코드에는 자체 상태 확인을 선택적으로 설정할 수 있습니다. 보조 레코드도 실패하더라도 Route 53은 보조 레코드의 주소를 반환합니다(최후의 수단이기 때문입니다).

장애 조치에 사용할 수 있는 상태 확인 유형은 HTTP/HTTPS 엔드포인트 확인, TCP 확인 및 CloudWatch 경보 확인입니다. CloudWatch 경보 확인은 여러 지표를 결합한 복합 애플리케이션 상태 신호에 유용합니다.

이 차이는 SAA-C03 시험에 자주 출제됩니다.

• 지리적 위치 기반 라우팅: 사용자가 지리적으로 어디에 있는지를 기준으로 라우팅합니다. 성능과 관계없이 특정 국가나 대륙에는 항상 동일한 엔드포인트를 반환하며, 콘텐츠 현지화와 규정 준수에 사용됩니다.
• 지연 시간 기반 라우팅: 사용자까지의 네트워크 성능을 기준으로 라우팅합니다. 예를 들어 해당 시점에 eu-west-1보다 빠르다면 유럽의 사용자를 us-east-1로 라우팅할 수 있으며, 성능 최적화에 사용됩니다.

시험 문제의 키워드는 다음과 같습니다. '데이터 레지던시 준수', '국가별 콘텐츠', '특정 지역의 사용자 차단' → 지리적 위치 기반 라우팅. '가장 가까운 리전', '가장 낮은 지연 시간', '전 세계 사용자에게 최고의 성능' → 지연 시간 기반 라우팅.

이 강의에서는 다음을 학습했습니다. 장애 조치 라우팅은 기본 대상의 상태 확인에 실패하면 보조 대상으로 전환하여 액티브-패시브 HA를 구성하고, 지리적 위치 라우팅은 규정 준수와 현지화를 위해 사용자의 지리적 출처에 따라 사용자를 전달하며, 지리적 근접성 라우팅은 Traffic Flow를 통해 구성 가능한 편향과 물리적 거리를 사용합니다. 일치하지 않는 위치를 처리할 수 있도록 항상 기본 지리적 위치 레코드를 추가해야 합니다. 다음에는 상태 확인과 DNS 장애 조치를 자세히 살펴보겠습니다.