멀티 리전 기본 4: 운영 준비

다중 지역 워크로드를 운영하는 것은 복잡한 작업이며 다중 지역에서만 발생하는 운영상의 문제가 수반됩니다. 여기에는 AWS 계정 관리, 재편된 배포 프로세스, 다중 지역 관찰 가능성 전략 수립, 페일오버 및 페일백 런북 생성 및 테스트, 비용 관리 등이 포함됩니다. 운영 준비 검토 (ORR) 는 팀이 단일 지역에서 실행하든 여러 지역에서 실행하든 관계없이 프로덕션에 사용할 워크로드를 준비하는 데 도움이 될 수 있습니다.

4a: 관리 AWS 계정

워크로드를 여러 지역에 배포하려면 계정 내 모든 AWS서비스 할당량이 지역 간에 AWS 리전 동일하게 적용되도록 해야 합니다. 먼저 아키텍처의 일부인 모든 AWS 서비스를 알아보고 대기 지역의 계획된 사용량을 살펴본 다음 현재 사용량과 비교하십시오. 경우에 따라 이전에 스탠바이 리전을 사용한 적이 없는 경우 기본 서비스 할당량을 참조하여 시작점을 이해할 수 있습니다. 그런 다음 사용할 모든 서비스에 대해 Service Quotas 콘솔 (로그인 필요) 또는 API를 사용하여 할당량 증가를 요청하세요.

AWS운영자, 자동화 도구 및 AWS 서비스가 대기 지역 내의 리소스에 대한 적절한 권한을 갖도록 하려면 각 지역에서 Identity and Access Management (IAM) 역할을 구성해야 합니다. 역할을 지역적으로 격리하면 다중 지역 아키텍처에서 우리가 추구하는 지역적 격리가 달성됩니다. 스탠바이 리전을 활성화하기 전에 이러한 권한이 제대로 적용되었는지 확인하세요.

4b: 배포 사례

다중 지역 기능을 사용하면 여러 지역에 워크로드를 배포하는 것이 복잡할 수 있습니다. AWS CloudFormation단일 또는 여러 지역에 인프라를 배포하는 데 도움이 되며 필요에 따라 조정할 수 있습니다. AWS CodePipeline거의 지속적인 통합/지속적 전달 (CI/CD) 파이프라인을 제공하는 데 도움이 됩니다. 이 파이프라인에는 파이프라인이 속한 지역과 다른 지역에 배포할 수 있는 지역 간 작업이 포함됩니다. 이를 블루/그린과 같은 강력한 배포 전략과 결합하면 다운타임이 전혀 없는 배포가 가능합니다.

그러나 애플리케이션 또는 데이터의 상태가 영구 저장소로 외부화되지 않는 경우 상태 저장 기능을 배포하는 것이 더 복잡할 수 있습니다. 이러한 상황에서는 필요에 맞게 배포 프로세스를 신중하게 조정하십시오. 여러 지역에 동시에 배포하는 대신 한 번에 한 지역에 배포하도록 배포 파이프라인과 프로세스를 설계하세요. 이렇게 하면 지역 간에 장애가 상호 연관될 가능성이 줄어듭니다. Amazon에서 소프트웨어 배포를 자동화하는 데 사용하는 기술에 대해 알아보려면 빌더 라이브러리 기사 안전한 수동 배포 자동화를 읽어보세요.

4c: 옵저버빌리티

여러 지역을 대상으로 설계할 때는 각 지역의 모든 구성 요소 상태를 모니터링하여 지역 건전성을 전체적으로 파악하는 방법을 고려하세요. 여기에는 단일 지역 워크로드에 대한 고려 사항이 아닌 복제 지연에 대한 모니터링 지표가 포함될 수 있습니다.

멀티 리전 아키텍처를 구축할 때는 스탠바이 리전의 워크로드 성능도 관찰해 보세요. 여기에는 스탠바이 리전에서 상태 점검 및 카나리아 (합성 테스트) 를 실행하여 프라이머리 리전의 상태를 외부에서 볼 수 있게 하는 것이 포함됩니다. 또한 Amazon CloudWatch Internet Monitor를 사용하여 최종 사용자 관점에서 외부 네트워크 상태와 워크로드 성능을 이해할 수 있습니다. 마찬가지로, 기본 지역에도 대기 지역을 모니터링할 수 있는 동일한 관찰 기능이 있어야 합니다. 이러한 카나리아는 고객 경험 지표를 모니터링하여 워크로드의 전반적인 상태를 파악해야 합니다. 이는 기본 지역에 문제가 발생할 경우 기본 지역의 관찰 가능성이 손상되어 워크로드 상태를 평가하는 능력에 영향을 미칠 수 있기 때문에 필요합니다.

이 경우 해당 지역 밖에서 관찰하면 통찰력을 얻을 수 있습니다. 이러한 지표를 각 지역에서 사용할 수 있는 대시보드와 각 지역에서 생성된 경보에 통합해야 합니다. CloudWatchAmazon은 지역 서비스이므로 두 지역 모두에 서비스를 제공하는 것이 필수입니다. 이 모니터링 데이터는 기본 지역에서 대기 지역으로의 장애 조치를 호출하는 데 사용됩니다.

4d: 프로세스, 절차 및 테스트

'언제 페일오버를 해야 할까요? '라는 질문에 답하기 가장 좋은 시기입니다. 필요하기까지는 훨씬 더 오래 걸렸습니다. 사람, 프로세스, 기술을 포함하는 비즈니스 연속성 계획은 모두 문제가 발생하기 전에 미리 정의하고 정기적으로 테스트해야 합니다. 복구 결정 프레임워크를 결정하십시오. 잘 실행된 복구 프로세스가 있고 복구 시간을 잘 이해하고 있는 경우 페일오버를 통해 RTO 목표를 충족하는 복구 프로세스를 시작할 시점을 선택할 수 있습니다. 이 시점은 기본 지역의 애플리케이션에 문제가 발견된 직후일 수도 있고, 지역 내 애플리케이션 내의 복구 옵션이 모두 사용되어 RTO를 충족하기 위해 이제 페일오버를 시작해야 하는 상황이 더 진행되었을 수도 있습니다.

페일오버 작업 자체는 100% 자동화되어야 하지만 페일오버를 활성화하는 결정은 사람 (일반적으로 조직 내에서 미리 결정된 소수의 개인) 이 내려야 합니다. 또한 페일오버를 결정하는 기준을 명확하게 정의하고 조직과 함께 전 세계적으로 이해해야 합니다. 이러한 프로세스는 AWSSystem Manager 런북을 사용하여 정의하고 완료할 수 있으며, 이를 통해 완전한 end-to-end 자동화가 가능하고 테스트 및 페일오버 중에 실행되는 프로세스의 일관성을 보장할 수 있습니다.

페일오버 또는 페일백 프로세스를 시작하려면 기본 및 스탠바이 리전에서 이러한 런북을 사용할 수 있어야 합니다. 이 자동화가 적용되면 정기적인 테스트 케이던스를 정의하고 준수해야 합니다. 이렇게 하면 실제 이벤트가 발생했을 때 조직이 신뢰할 수 있는 잘 정의되고 실행된 프로세스에 따라 대응이 실행될 수 있습니다. 또한 데이터 조정 프로세스에 대해 설정된 허용 오차를 염두에 두는 것도 중요합니다. 설정된 RPO/RTO 요구 사항이 제안된 프로세스와 일치하는지 확인하십시오.

4e: 비용 및 복잡성

멀티 리전 아키텍처가 비용에 미치는 영향은 인프라 사용량, 운영 오버헤드 및 리소스 시간의 증가에 의해 좌우됩니다. 앞서 언급했듯이 스탠바이 리전의 인프라 비용은 사전 프로비저닝 시 프라이머리 리전의 인프라 비용과 비슷하므로 비용이 2배 더 비쌉니다. 일일 운영에 충분하도록 용량을 프로비저닝하면서도 수요 급증을 견딜 수 있을 만큼 충분한 버퍼 용량을 확보하고 각 지역에 동일한 제한을 구성하십시오.

또한 액티브-액티브 아키텍처를 채택하는 경우 멀티 리전 아키텍처에서 성공적으로 실행하려면 애플리케이션 수준의 변경이 필요할 수 있습니다. 이 경우 설계 및 운영에 시간과 리소스가 많이 소요될 수 있습니다. 조직은 최소한 각 지역의 기술 및 비즈니스 종속성을 이해하고 페일오버 및 페일백 프로세스를 설계하는 데 시간을 할애해야 합니다.

또한 팀은 일반적인 페일오버 및 페일백 연습을 거쳐야 이벤트 중에 사용할 런북에 익숙해질 수 있습니다. 여러 지역에 투자하여 기대되는 결과를 얻는 데 매우 중요하고 중요하기는 하지만, 이러한 연습은 기회 비용을 초래하고 다른 활동에 소요되는 시간과 자원을 낭비합니다.

주요 지침

• AWS워크로드가 운영될 모든 지역에서 서비스 할당량을 검토하고 동등하게 검토해야 합니다.

• 배포 프로세스는 여러 지역을 동시에 대상으로 하는 것이 아니라 한 번에 하나의 지역을 대상으로 해야 합니다.

• 복제 지연과 같은 추가 지표를 모니터링해야 하며, 이는 다중 지역 시나리오에만 해당됩니다.

• 워크로드에 대한 모니터링을 기본 지역 이상으로 확장하십시오. 고객 경험 지표는 지역별로 모니터링하고 워크로드가 실행되는 각 지역 외부에서 측정해야 합니다.

• 페일오버와 페일백은 정기적으로 테스트해야 합니다. 테스트와 라이브 이벤트 모두에서 사용되는 페일오버 및 페일백 프로세스를 위한 단일 런북을 구현해야 합니다. 테스트용 런북과 라이브 이벤트용 런북은 다를 수 없습니다.