데이터 영역 제어 대피

데이터 영역 전용 작업을 사용하여 가용 영역 제거를 수행하기 위해 구현할 수 있는 몇 가지 솔루션이 있습니다. 이 섹션에서는 이 중 세 가지 그리고 둘 중 하나를 선택할 수 있는 사용 사례에 대해 설명합니다.

이러한 솔루션 중 하나를 사용할 때는 다른 가용 영역의 부하를 처리할 수 있을 만큼 나머지 가용 영역에 충분한 용량이 있는지 확인해야 합니다. 가장 탄력적인 방법은 각 가용 영역에 필요한 용량을 미리 프로비저닝하는 것입니다. 세 개의 가용 영역을 사용하는 경우 각 가용 영역에 배포된 최대 부하를 처리하는 데 필요한 용량의 50% 가 필요하므로 단일 가용 영역이 손실되더라도 컨트롤 플레인에 의존하여 추가로 프로비저닝할 필요 없이 필요한 용량을 100% 유지할 수 있습니다.

또한 EC2 Auto Scaling을 사용하는 경우 근무 시간 중에 오토 스케일링(ASG)의 스케일 인을 하지 않도록 해야 합니다. 그래야 근무가 끝난 후에도 그룹에서 고객 트래픽을 처리할 수 있는 충분한 용량을 확보할 수 있습니다. ASG의 최소 희망 용량이 현재 고객 부하를 처리할 수 있도록 하면 됩니다. 또한 P90 또는 P99와 같은 특이 백분위수 지표와 달리 지표의 평균을 사용하여 실수로 ASG의 스케일 인을 방지할 수 있습니다.

근무 시간 중에는 더 이상 트래픽을 처리하지 않는 리소스의 사용률이 매우 낮아야 하지만 다른 리소스는 새 트래픽으로 사용률을 높여 평균을 상당히 일정하게 유지하므로 스케일 인 작업을 방지할 수 있습니다. 마지막으로 ALB 및 NLB의 대상 그룹 상태 설정을 사용하여 정상 호스트의 백분율 또는 수로 DNS 장애 조치를 지정할 수도 있습니다. 이렇게 하면 정상 호스트가 충분하지 않은 가용 영역으로 트래픽이 라우팅되는 것을 방지할 수 있습니다.

Route 53 Application Recovery Controller(ARC)의 영역 전환

가용 영역 대피를 위한 첫 번째 솔루션은 Route 53 ARC의 영역 전환을 사용합니다. 이 솔루션은 NLB 또는 ALB를 고객 트래픽의 수신 지점으로 사용하는 요청/응답 워크로드 내에서 사용할 수 있습니다.

가용 영역이 손상된 것을 감지하면 Route 53 ARC를 사용하여 영역 전환을 시작할 수 있습니다. 이 작업이 완료되고 기존의 캐시된 DNS 응답이 만료되면 모든 새 요청은 나머지 가용 영역의 리소스로만 라우팅됩니다. 다음 그림은 영역 전환 작동 방식을 보여 줍니다. 다음 그림에는 my-example-nlb-4e2d1f8bb2751e6a.elb.us-east-1.amazonaws.com 지점을 가리키는 www.example.com에 관한 Route 53 별칭 레코드가 있습니다. 영역 전환은 가용 영역 3에 대해 수행됩니다.

영역 전환

예제에서 기본 데이터베이스 인스턴스가 가용 영역 3에 없는 경우 영역 전환은 첫 번째 대피 결과를 얻기 위해 필요한 유일한 조치이며, 이는 영향을 받는 가용 영역에서 작업이 처리되지 않도록 합니다. 프라이머리 노드가 가용 영역 3에 있는 경우 Amazon RDS가 아직 자동 장애 조치를 수행하지 않았다면 영역 전환에 맞춰 수동으로 시작된 장애 조치(Amazon RDS 컨트롤 플레인에 의존)를 수행할 수 있습니다. 이는 이 섹션의 모든 데이터 영역 제어 솔루션에 해당됩니다.

대피를 시작하는 데 필요한 종속성을 최소화하려면 CLI 명령 또는 API를 사용하여 영역 전환을 시작해야 합니다. 대피 프로세스가 간단할수록 신뢰성이 높아집니다. 특정 명령은 대기 중인 엔지니어가 쉽게 액세스할 수 있는 로컬 런북에 저장할 수 있습니다. 영역 전환은 가용 영역을 제거할 때 가장 선호되며 간단한 솔루션입니다.

Route 53 ARC

두 번째 솔루션은 Route 53 ARC의 기능을 사용하여 특정 DNS 레코드의 상태를 수동으로 지정합니다. 이 솔루션은 가용성이 높은 Route 53 ARC 클러스터 데이터 영역을 사용하여 최대 두 개의 서로 다른 AWS 리전의 손상에 대한 복원력을 제공한다는 이점을 보입니다. 추가 비용이 드는 단점이 있으며 DNS 레코드를 추가로 구성해야 합니다. 이 패턴을 구현하려면 로드 밸런서(ALB 또는 NLB) 에서 제공하는 가용 영역별 DNS 이름에 대한 별칭 레코드를 만들어야 합니다. 이 내용은 다음 표와 같습니다.

표 3: 로드 밸런서의 영역 DNS 이름에 대해 구성된 Route 53 별칭 레코드

라우팅 정책: 가중치 적용 이름: www.example.com 유형: A(별칭) 값: us-east-1b.load-balancer-name.elb.us-east-1.amazonaws.com 가중치: 100 대상 상태 평가: 참

라우팅 정책: 가중치 적용 이름: www.example.com 유형: A(별칭) 값 us-east-1a.load-balancer-name.elb.us-east-1.amazonaws.com 가중치: 100 대상 상태 평가: true

라우팅 정책: 가중치 적용 이름: www.example.com 유형: A(별칭) 값: us-east-1c.load-balancer-name.elb.us-east-1.amazonaws.com 가중치: 100 대상 상태 평가: true

이러한 각 DNS 레코드에 대해 Route 53 ARC 라우팅 컨트롤과 연결된 Route 53 상태 확인을 구성합니다. 가용 영역 대피를 시작하려면 라우팅 제어 상태를 Off로 설정하십시오. AWS는 가용 영역 대피를 시작하는 데 필요한 종속성을 최소화하기 위해 CLI 또는 API를 사용하여 이 작업을 수행할 것을 권장합니다. 가장 좋은 방법은 Route 53 ARC 클러스터 엔드포인트의 로컬 사본을 보관하여 대피를 수행해야 할 때 ARC 컨트롤 플레인에서 해당 엔드포인트를 검색할 필요가 없도록 하는 것입니다.

이 접근 방식을 사용할 때 비용을 최소화하기 위해 단일 AWS 계정 내 Route 53 ARC 클러스터와 상태 확인을 한 번에 생성하고 조직 내 다른 AWS 계정와 상태 확인을 공유할 수 있습니다. 이 방법을 사용할 때는 라우팅 제어에 가용 영역 이름(예:us-east-1a) 대신 가용 영역 ID(AZ-ID)(예:use1-az1)를 사용해야 합니다. AWS에서 물리적 가용 영역은 각각의 AWS 계정 가용 영역 이름에 무작위로 매핑되므로 AZ-ID를 사용하면 동일한 물리적 위치를 일관되게 참조할 수 있습니다. 예를 들어 use1-az2에 대해 가용 영역 대피를 시작할 때는 각각 AWS 계정의 Route 53 레코드 세트가 AZ-ID 매핑을 사용하여 각 NLB 레코드에 대해 올바른 상태 확인을 구성하는지 확인해야 합니다.

예를 들어, ID가 0385ed2d-d65c-4f63-a19b-2412a31ef431이고 use1-az2에 대한 Route 53 ARC 라우팅 제어와 연결된 Route 53 상태 확인이 있다고 가정해 보겠습니다. 이 상태 확인을 사용하려는 다른 AWS 계정에서 us-east-1c가 use1-az2으로 매핑된 경우, 레코드 us-east-1c.load-balancer-name.elb.us-east-1.amazonaws.com에 대한 use1-az2 상태 확인을 사용해야 합니다. 해당 리소스 레코드 세트와 함께 상태 확인 ID 0385ed2d-d65c-4f63-a19b-2412a31ef431를 사용할 수 있습니다.

자체 관리형 HTTP 엔드포인트 사용

특정 가용 영역의 상태를 나타내는 자체 HTTP 엔드포인트를 관리하여 이 솔루션을 구현할 수도 있습니다. 이를 통해 HTTP 엔드포인트의 응답을 기반으로 가용 영역이 비정상인 경우를 수동으로 지정할 수 있습니다. 이 솔루션은 Route 53 ARC를 사용하는 것보다 비용이 적게 들지만 영역 전환보다 비용이 많이 들고 추가 인프라 관리가 필요합니다. 이는 다양한 시나리오에서 훨씬 더 유연하다는 이점이 있습니다.

패턴은 NLB 또는 ALB 아키텍처 및 Route 53 상태 확인과 함께 사용할 수 있습니다. 또한 워커 노드가 자체 상태 확인을 수행하는 서비스 검색 또는 대기열 처리 시스템과 같이 비-로드 밸런서 아키텍처에서도 사용할 수 있습니다. 이러한 시나리오에서 호스트는 백그라운드 스레드를 사용하여 주기적으로 AZ-ID를 사용하여 HTTP 엔드포인트에 요청을 보내고(이를 찾는 방법에 대한 자세한 내용은 부록 A — 가용 영역 ID 가져오기 참조) 가용 영역의 상태에 대한 응답을 다시 받을 수 있습니다.

가용 영역이 비정상으로 선언된 경우 가용 영역은 여러 가지 대응 방법을 선택할 수 있습니다. ELB, Route 53과 같은 소스의 외부 상태 점검 또는 서비스 검색 아키텍처의 사용자 지정 상태 확인에 실패하여 해당 서비스가 비정상으로 표시되도록 할 수도 있습니다. 또한 요청을 받으면 즉시 오류로 응답하여 클라이언트가 백오프하고 재시도할 수 있도록 할 수 있습니다. 이벤트 기반 아키텍처에서는 의도적으로 SQS 메시지를 대기열에 반환하는 등 노드가 의도적으로 작업을 처리하지 못할 수 있습니다. 중앙 서비스 스케줄이 특정 호스트에서 작동하는 업무용 라우터 아키텍처에서는 이 패턴을 사용할 수도 있습니다. 라우터는 작업자, 엔드포인트 또는 셀을 선택하기 전에 가용 영역의 상태를 확인할 수 있습니다. AWS Cloud Map를 사용하는 서비스 검색 아키텍처에서, 요청에 필터(예: AZ-ID)를 제공하여 엔드포인트 검색을 할 수 있습니다.

다음 그림은 이 접근 방식을 여러 유형의 워크로드에 사용할 수 있는 방법을 보여줍니다.

여러 워크로드 유형은 모두 HTTP 엔드포인트 솔루션을 사용할 수 있습니다

HTTP 엔드포인트 접근 방식을 구현하는 방법은 여러 가지가 있으며, 그 중 두 가지가 다음에 설명되어 있습니다.

Amazon S3 사용

이 패턴은 다중 리전 재해 복구에 관한 이 블로그 게시물에 처음 소개되었습니다. 가용 영역 대피에도 동일한 패턴을 사용할 수 있습니다.

이 시나리오에서는 위의 Route 53 ARC 시나리오와 마찬가지로 각 영역 DNS 레코드에 대해 Route 53 DNS 리소스 레코드 세트를 생성하고 관련 상태 확인을 생성합니다. 그러나 이 구현에서는 상태 확인을 Route 53 ARC 라우팅 제어와 연결하는 대신 HTTP 엔드포인트를 사용하도록 구성되며 실수로 대피를 유발하는 Amazon S3의 장애로부터 보호하기 위해 반전됩니다. 상태 확인은 객체가 없을 때는 정상으로 간주되고 객체가 있을 때는 비정상으로 간주됩니다. 이 설정은 다음 표와 같습니다.

표 4: 가용 영역별 Route 53 상태 확인을 사용하기 위한 DNS 레코드 구성

상태 확인 유형: 엔드포인트 모니터링 프로토콜: HTTPS ID: dddd-4444 URL: https://bucket-name.s3.us-east-1.amazonaws.com/use1-az1.txt	상태 확인 유형: 엔드포인트 모니터링 프로토콜: HTTPS ID: eeee-5555 URL: https://bucket-name.s3.us-east-1.amazonaws.com/use1-az3.txt	상태 확인 유형: 엔드포인트 모니터링 프로토콜: HTTPS ID: ffff-6666 URL: https://bucket-name.s3.us-east-1.amazonaws.com/use1-az2.txt	←	상태 확인
↑	↑	↑
라우팅 정책: 가중치 적용 이름: www.example.com 유형: A(별칭) 값: us-east-1b.load-balancer-name.elb.us-east-1.amazonaws.com 가중치: 100 대상 상태 평가: true	라우팅 정책: 가중치 적용 이름: www.example.com 유형: A(별칭) 값: us-east-1a.load-balancer-name.elb.us-east-1.amazonaws.com 가중치: 100 대상 상태 평가: true	라우팅 정책: 가중치 적용 이름: www.example.com 유형: A(별칭) 값: us-east-1c.load-balancer-name.elb.us-east-1.amazonaws.com 가중치: 100 대상 상태 평가: true	←	가중치가 균등한 최상위 별칭 A 레코드는 NLB AZ 전용 엔드포인트를 가리킵니다

가용 영역 대피를 수행하려는 워크로드가 있는 계정의 가용 영역 us-east-1a이 use1-az3에 매핑되어 있다고 가정해 보겠습니다. us-east-1a.load-balancer-name.elb.us-east-1.amazonaws.com에 대하여 생성된 리소스 레코드 세트의 경우 URL https://bucket-name.s3.us-east-1.amazonaws.com/use1-az3.txt를 테스트하는 상태 확인을 연결합니다. use1-az3에 대한 가용 영역 대피를 시작하려면 CLI 또는 API를 사용하여 use1-az3.txt라는 이름이 지정된 파일을 버킷에 업로드합니다. 파일은 콘텐츠를 포함할 필요는 없지만, Route 53 상태 확인이 파일에 액세스할 수 있으려면 공개 파일이어야 합니다. 다음 그림은 이 구현이 대피 use1-az3에 사용되는 것을 보여줍니다.

Amazon S3를 Route 53 상태 확인 대상으로 사용

API 게이트웨이 및 DynamoDB 사용

이 패턴의 두 번째 구현에서는 Amazon API Gateway REST API를 사용합니다. API는 사용 중인 각 가용 영역의 상태가 저장되는 Amazon DynamoDB에 대한 서비스 통합을 통해 구성됩니다. 이 구현은 Amazon S3 접근 방식보다 유연하지만 더 많은 인프라를 구축, 운영 및 모니터링해야 합니다. 또한 Route 53 상태 확인 및 개별 호스트가 수행하는 상태 확인과 함께 사용할 수도 있습니다.

이 솔루션을 NLB 또는 ALB 아키텍처와 함께 사용하는 경우, API 게이트웨이 엔드포인트를 사용하도록 상태 확인 경로를 변경하고 URL 경로 내 AZ-ID에 제공한다는 점을 제외하면 위의 Amazon S3 예제와 동일한 방식으로 DNS 레코드를 설정하십시오. 예를 들어, az-status.example.com의 사용자 지정 도메인을 API 게이트웨이로 구성한 경우 use1-az1에 대한 전체 요청은 https://az-status.example.com/status/use1-az1와 같습니다. 가용 영역 제거를 시작하려는 경우 CLI 또는 API를 사용하여 DynamoDB 항목을 생성하거나 업데이트할 수 있습니다. 항목은 AZ-ID를 프라이머리 키로 사용하고 API 게이트웨이 응답 방식을 나타내는 데 사용되는 Healthy라 불리는 Boolean 속성을 가집니다. 다음은 API 게이트웨이 구성에서 이러한 결정을 내리는 데 사용되는 예제 코드입니다.

#set($inputRoot = $input.path('$'))
#if ($inputRoot.Item.Healthy['BOOL'] == (false))
    #set($context.responseOverride.status = 500)
#end

속성이 true인 경우(또는 존재하지 않는 경우), API 게이트웨이는 HTTP 200으로 상태 확인에 응답하고, 속성이 거짓이면 HTTP 500으로 응답합니다. 방법은 다음 그림과 같습니다.

API 게이트웨이 및 DynamoDB를 Route 53 상태 확인의 대상으로 사용

이 솔루션에서는 DynamoDB 앞에 API 게이트웨이를 사용해야 엔드포인트에 공개적으로 액세스할 수 있을 뿐만 아니라 요청 URL을 DynamoDB GetItem 요청으로 조작할 수 있습니다. 이 솔루션은 요청에 추가 데이터를 포함하려는 경우에도 유연성을 제공합니다. 예를 들어 애플리케이션별로 더 세분화된 상태를 생성하려는 경우, 경로 또는 쿼리 문자열에 DynamoDB 항목과도 일치하는 애플리케이션 ID를 제공하도록 상태 확인 URL을 구성할 수 있습니다.

가용 영역 상태 엔드포인트를 중앙에 배포할 수 있으므로 AWS 계정 전체의 여러 상태 확인 리소스가 모두 가용 영역 상태에 대한 동일한 일관된 보기를 사용할 수 있고(API 게이트웨이 REST API 및 DynamoDB 테이블이 부하 처리에 맞게 확장되는지 확인) Route 53 상태 확인을 공유할 필요가 없습니다.

또한 이 솔루션은 Amazon DynamoDB 글로벌 테이블과 각 리전의 API 게이트웨이 REST API 사본을 사용하여 여러 AWS 리전으로 확장할 수도 있습니다. 이렇게 하면 이 솔루션이 단일 리전에 종속되지 않고 가용성이 향상됩니다. 3~5개 리전에 솔루션을 배포하고 대다수 엔드포인트의 결과를 사용하여 가용 영역 상태를 각 리전에 쿼리하여 쿼럼을 보장할 수 있습니다. 이를 통해 최종적으로 글로벌 테이블 전체에 일관되게 업데이트를 복제할 수 있을 뿐만 아니라 엔드포인트의 응답을 방해할 수 있는 장애도 완화할 수 있습니다. 예를 들어 5개 리전을 사용 중이고 3개 엔드포인트가 가용 영역을 비정상으로 보고하고, 한 엔드포인트는 가용 영역을 정상으로 보고하고, 한 엔드포인트는 응답하지 않는 경우 가용 영역을 비정상으로 처리하도록 선택할 수 있습니다. m of n 계산을 사용하여 Route 53의 계산된 상태 확인을 생성하여 이 로직을 수행하여 가용 영역 상태를 확인할 수도 있습니다.

개별 호스트가 AZ 상태를 확인하는 메커니즘으로 사용할 솔루션을 구축하려는 경우, 대안으로 상태 확인을 위한 풀 메커니즘을 제공하는 대신 푸시 알림을 사용할 수 있습니다. 이를 위한 한 가지 방법은 소비자가 구독하는 SNS 주제를 사용하는 것입니다. 회로 차단기를 트리거하려면 어떤 가용 영역이 손상되었는지 알려주는 메시지를 SNS 주제에 게시하십시오. 이 접근 방식은 전자와 절충점이 있습니다. 이를 통해 API 게이트웨이 인프라를 생성 및 운영하고 용량 관리를 수행할 필요가 없습니다. 또한 가용 영역 상태를 더 빠르게 통합할 수도 있습니다. 임시 쿼리를 수행하는 기능을 제거하고 SNS 전송 재시도 정책 사용하여 각 엔드포인트가 알림을 수신하도록 합니다. 또한 각 워크로드 또는 서비스가 SNS 알림을 수신하고 이에 대한 조치를 취하는 방법을 구축해야 합니다.

예를 들어, 새로 시작되는 각 EC2 인스턴스 또는 컨테이너는 부트스트랩 중에 HTTP 엔드포인트가 있는 주제를 구독해야 합니다. 그런 다음 각 인스턴스는 알림이 전달되는 이 엔드포인트에서 수신 대기하는 소프트웨어를 구현해야 합니다. 또한 인스턴스가 이벤트의 영향을 받는 경우 푸시 알림을 받지 못하고 작업을 계속할 수 있습니다. 반면 풀 알림을 사용하면 인스턴스가 끌어오기 요청에 실패하는지 알게 되고 이에 대응하여 취해야 할 조치를 선택할 수 있습니다.

푸시 알림을 보내는 두 번째 방법은 수명이 긴 WebSocket 연결을 사용하는 것입니다. Amazon API Gateway는 소비자가 백엔드에서 메시지를 전송할 때 연결하여 메시지를 수신할 수 있는 WebSocket API를 제공하는 데 사용할 수 있습니다. WebSocket을 사용하면 인스턴스가 주기적인 풀링을 수행하여 연결 상태를 유지하고 지연 시간이 짧은 푸시 알림을 수신할 수 있습니다.