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

REL11-BP04 복구 중 제어 영역이 아닌 데이터 영역에 의존

제어 영역은 (CRUDL) 리소스를 생성, 읽기 및 설명, 업데이트, 삭제 및 나열하는 데 APIs 사용되는 관리 기능을 제공하는 반면 데이터 영역은 서비스 트래픽을 처리합니다 day-to-day. 복원력에 영향을 미칠 수 있는 이벤트에 대한 복구 또는 완화 대응을 구현할 때는 최소한의 컨트롤 플레인 작업을 사용하여 서비스를 복구, 재조정, 복원, 복구 또는 장애 조치하는 데 집중합니다. 데이터 영역 작업은 이러한 성능 저하 이벤트가 발생하는 동안의 모든 활동을 대체해야 합니다.

예를 들어, 새 컴퓨팅 인스턴스 시작, 블록 스토리지 생성, 대기열 서비스 설명 등은 모두 컨트롤 플레인 작업입니다. 컴퓨팅 인스턴스를 시작할 때 컨트롤 플레인은 용량이 있는 물리적 호스트 찾기, 네트워크 인터페이스 할당, 로컬 블록 스토리지 볼륨 준비, 자격 증명 생성, 보안 규칙 추가와 같은 여러 작업을 수행해야 합니다. 컨트롤 플레인은 복잡한 오케스트레이션이 필요한 경우가 많습니다.

원하는 성과: 리소스가 손상된 상태가 되면 시스템은 트래픽을 손상된 리소스에서 정상 리소스로 전환하여 자동 또는 수동으로 복구할 수 있습니다.

일반적인 안티 패턴:

이 모범 사례 확립의 이점: 자동화된 문제 해결의 성공률이 높아지면 평균 시간이 단축되고 워크로드의 가용성이 향상됩니다.

이 모범 사례가 확립되지 않은 경우 노출되는 위험 수준: 중간: 특정 유형의 서비스 성능 저하에서는 컨트롤 플레인이 영향을 받습니다. 수정을 위해 제어 영역을 광범위하게 사용하는 것에 의존하면 복구 시간(RTO)과 평균 복구 시간()이 늘어날 수 있습니다MTTR.

구현 가이드

데이터 영역 작업을 제한하려면 서비스를 복원하는 데 필요한 조치가 무엇인지 각 서비스를 평가하세요.

Amazon Application Recovery Controller를 활용하여 DNS 트래픽을 전환합니다. 이러한 기능은 장애로부터 복구할 수 있는 애플리케이션의 기능을 지속적으로 모니터링하고 여러 AWS 리전, 가용 영역 및 온프레미스에서 애플리케이션 복구를 제어할 수 있도록 합니다.

Route 53 라우팅 정책은 컨트롤 플레인을 사용하므로 복구 시 컨트롤 플레인을 사용하지 마세요. Route 53 데이터 플레인은 DNS 쿼리에 응답하고 상태 확인을 수행하고 평가합니다. 전 세계에 분산되어 있으며 100% 가용성 서비스 수준 계약(SLA)을 위해 설계되었습니다.

를 관리할 때 필요한 강력한 일관성과 내구성을 우선시하도록 설계된 제어 영역에서 실행되는 Route 53 리소스를 생성, 업데이트 및 삭제하는 Route 53 관리 및 APIs 콘솔입니다DNS. 이를 위해 컨트롤 플레인은 하나의 리전(미국 동부, 버지니아 북부)에 위치합니다. 두 시스템 모두 매우 안정적으로 구축되었지만 제어 평면은 에 포함되지 않습니다SLA. 데이터 영역의 복원력 높은 설계가 컨트롤 플레인과 달리 가용성을 유지하는 상황이 드물게 있을 수 있습니다. 재해 복구 및 장애 조치 메커니즘에는 데이터 영역 기능을 사용하여 가능한 한 최고 수준의 신뢰성을 제공합니다.

인시던트 중에 제어 영역을 사용하지 않도록 컴퓨팅 인프라를 정적으로 안정적으로 설계합니다. 예를 들어 Amazon EC2 인스턴스를 사용하는 경우 새 인스턴스를 수동으로 프로비저닝하거나 Auto Scaling Groups에 응답으로 인스턴스를 추가하도록 지시하지 마십시오. 최고 수준의 복원력을 얻으려면 장애 조치에 사용되는 클러스터에 충분한 용량을 프로비저닝하세요. 이 용량 임계값을 제한해야 하는 경우 제한된 리소스 세트에 도달하는 총 트래픽을 안전하게 제한하도록 전체 end-to-end 시스템에서 스로틀을 설정합니다.

Amazon DynamoDB, Amazon Gateway, 로드 밸런서 및 AWS Lambda 서버리스와 같은 서비스의 경우 해당 서비스를 사용하면 데이터 영역이 활용됩니다. API 그러나 새 함수, 로드 밸런서, API 게이트웨이 또는 DynamoDB 테이블을 생성하는 것은 제어 영역 작업이며 이벤트 준비 및 장애 조치 리허설로 성능 저하 전에 완료해야 합니다. Amazon RDS의 경우 데이터 영역 작업을 통해 데이터에 액세스할 수 있습니다.

데이터 영역, 제어 영역 및 가 고가용성 목표를 충족하는 서비스를 AWS 빌드하는 방법에 대한 자세한 내용은 가용 영역을 사용한 정적 안정성을 참조하세요.

데이터 영역을 사용할 작업과 컨트롤 플레인을 사용할 작업을 파악합니다.

구현 단계

성능 저하 이벤트 후 복원해야 하는 각 워크로드에 대해 장애 조치 런북, 고가용성 설계, 자동 복구 설계 또는 HA 리소스 복원 계획을 평가하세요. 컨트롤 플레인 작업으로 간주될 수 있는 각 작업을 식별하세요.

컨트롤 작업을 데이터 영역 작업으로 변경하는 것을 고려해 보세요.

데이터 영역 작업이 동일한 문제 해결에 영향을 줄 수 있는 다른 접근 방식을 고려해 보세요.

서비스가 업무상 중요한 경우 영향을 받지 않는 리전에서 더 많은 컨트롤 플레인 및 데이터 영역 작업을 수행할 수 있도록 보조 리전의 일부 서비스를 고려해 보세요.

리소스

관련 모범 사례:

관련 문서:

관련 비디오:

관련 예제:

관련 도구: