기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
라우팅 제어에 대한 정보
라우팅 제어는 복구 그룹 내 셀의 최상위 리소스(예: Elastic Load Balancing 로드 밸런서)와 관련된 DNS 레코드로 구성된 Amazon Route 53의 상태 확인을 사용하여 트래픽을 리디렉션합니다. 예를 들어 라우팅 제어 상태를 Off(한 셀로의 트래픽 흐름 중지)로 업데이트하고 다른 라우팅 제어 상태를 On(다른 셀로의 트래픽 흐름 시작)로 업데이트하여 한 셀에서 다른 셀로 트래픽을 리디렉션할 수 있습니다. 트래픽 흐름을 변경하는 프로세스는 해당 라우팅 제어 상태에 따라 ARC가 정상 또는 비정상으로 업데이트한 후 라우팅 제어와 연결된 Route 53 상태 확인입니다.
라우팅 제어는 DNS 엔드포인트가 있는 모든 AWS서비스에서 장애 조치를 지원합니다. 재해 복구를 위해 또는 애플리케이션의 지연 시간 감소 또는 기타 문제가 감지될 때 트래픽을 장애 조치하도록 라우팅 제어 상태를 업데이트할 수 있습니다.
또한 라우팅 제어에 대한 안전 규칙을 구성하여 라우팅 제어를 통해 트래픽을 다시 라우팅해도 가용성이 저하되지 않도록 할 수 있습니다. 자세한 내용은 라우팅 제어에 대한 안전 규칙 생성 단원을 참조하십시오.
중요한 점은 라우팅 제어 자체가 엔드포인트의 기본 상태를 모니터링하는 상태 확인이 아니라는 점입니다. 예를 들어, Route 53 상태 확인과 달리 라우팅 제어는 응답 시간 또는 TCP 연결 시간을 모니터링하지 않습니다. 라우팅 제어는 상태 확인을 제어하는 간단한 온-오프 스위치입니다. 일반적으로 상태를 변경하여 트래픽을 리디렉션하고 해당 상태 변경으로 인해 트래픽이 전체 애플리케이션 스택의 특정 엔드포인트로 이동하거나 전체 애플리케이션 스택으로의 라우팅이 차단됩니다. 예를 들어 간단한 시나리오에서 라우팅 제어 상태를 On에서 Off로 변경하면 DNS 장애 조치 레코드에 연결한 Route 53 상태 확인이 업데이트되어 트래픽이 엔드포인트 외부로 이동합니다.
라우팅 제어를 사용하는 방법
트래픽을 다시 라우팅할 수 있도록 라우팅 제어 상태를 업데이트하려면 ARC의 클러스터 엔드포인트 중 하나에 연결해야 합니다. 연결하려는 엔드포인트를 사용할 수 없는 경우 다른 클러스터 엔드포인트로 상태를 변경해 보세요. 정기적인 유지 관리 및 업데이트를 위해 클러스터 엔드포인트가 사용 가능 상태와 사용 불가능 상태로 순환되므로 라우팅 제어 상태를 변경하는 프로세스에서는 각 엔드포인트를 번갈아 시도할 수 있도록 준비해야 합니다.
라우팅 제어를 생성할 때는 라우팅 제어 상태 확인을 각 애플리케이션 복제본의 앞에 있는 Route 53 DNS 이름과 연결하도록 DNS 레코드를 구성합니다. 예를 들어 두 리전에 각각 하나씩 있는 두 로드 밸런서의 트래픽 장애 조치를 제어하려면 두 라우팅 제어 상태 확인을 생성하고 이를 두 DNS 레코드(예: 각 로드 밸런서의 도메인 이름과 함께 장애 조치 라우팅 정책이 있는 별칭 레코드)에 연결합니다.
또한 가중치 기반 라우팅 정책이 적용된 DNS 레코드를 통해 ARC 라우팅 제어를 Route 53 상태 확인 및 DNS 레코드 세트와 함께 사용하여 더 복잡한 트래픽 장애 조치 시나리오를 설정할 수 있습니다. 자세한 예제를 보려면 다음 AWS블로그 게시물에서 사용자 트래픽 장애 조치에 대한 섹션을 참조하세요. Amazon Application Recovery Controller(ARC)를 사용하여 복원력이 뛰어난 애플리케이션 구축, 2부: 다중 리전 스택
라우팅 제어를 AWS 리전사용하여에 대한 장애 조치를 시작할 때 트래픽 흐름과 관련된 단계로 인해 트래픽이 리전 밖으로 즉시 이동하지 않을 수 있습니다. 또한 클라이언트 동작과 연결 재사용에 따라 리전에서 진행 중인 기존 연결이 완료되는 데 다소 시간이 걸릴 수 있습니다. DNS 설정 및 기타 요인에 따라 기존 연결이 몇 분 만에 완료되거나 더 오래 걸릴 수 있습니다. 자세한 내용은 트래픽 전환이 신속하게 완료되도록 하는 방법 섹션을 참조하세요.
라우팅 제어의 이점
ARC의 라우팅 제어는 기존 상태 확인을 사용하여 트래픽을 다시 라우팅하는 것보다 몇 가지 이점이 있습니다. 예제:
라우팅 제어를 사용하면 전체 애플리케이션 스택에 대해 장애 조치를 취할 수 있습니다. 이는 Amazon EC2 인스턴스처럼 리소스 수준 상태 확인을 기반으로 스택의 개별 구성 요소에 대해 장애가 발생하는 것과는 대조적입니다.
라우팅 제어를 사용하면 내부 모니터에서 문제가 감지되지 않을 때 트래픽을 이동하여 유지 관리를 수행하거나 장애 복구를 위해 사용할 수 있는 안전하고 간단한 수동 재정의 기능을 사용할 수 있습니다.
라우팅 제어를 안전 규칙과 함께 사용하면 장애 조치가 준비되지 않은 대기 인프라로 장애 조치하는 등 완전히 자동화된 상태 확인 기반 자동화에서 발생할 수 있는 일반적인 부작용을 방지할 수 있습니다.
다음은 라우팅 제어를 장애 조치 전략에 통합하여에서 애플리케이션의 복원력과 가용성을 개선하는 예입니다AWS.
리전 간에 여러(일반적으로 3개) 중복 복제본을 실행AWS하여에서 고가용성 AWS애플리케이션을 지원할 수 있습니다. 그런 다음 Amazon Route 53 라우팅 제어를 사용하여 적절한 복제본으로 트래픽을 라우팅할 수 있습니다.
예를 들어 하나의 애플리케이션 복제본이 활성 상태이고 애플리케이션 트래픽을 처리하도록 설정하고 다른 애플리케이션 복제본은 대기 복제본이 되도록 설정할 수 있습니다. 활성 복제본에 장애가 발생한 경우 사용자 트래픽을 해당 복제본으로 다시 라우팅하여 애플리케이션의 가용성을 복원할 수 있습니다. 모니터링 및 상태 확인 시스템의 정보를 기반으로 복제본에서 다른 곳으로 장애 조치할지 아니면 복제본으로 장애 조치할지 결정해야 합니다.
복구 속도를 높이려는 경우 아키텍처에 맞게 선택할 수 있는 또 다른 옵션은 활성-활성 구현입니다. 이 접근 방식을 사용하면 복제본이 동시에 활성화됩니다. 즉, 트래픽을 다른 활성 복제본으로 다시 라우팅하기만 하면 손상된 애플리케이션 복제본으로부터 사용자를 이동시켜 장애를 복구할 수 있습니다.
