다중 리전 기본 4: 운영 준비

다중 리전 워크로드 운영은 다중 리전 아키텍처와 관련된 운영 문제를 수반하는 복잡한 작업입니다. 여기에는 AWS 계정 관리, 재구성된 배포 프로세스, 다중 리전 관찰성 전략 생성, 복구 프로세스 생성 및 테스트, 비용 관리가 포함됩니다. 운영 준비 검토(ORR)는 팀이 단일 리전에서 실행하든 여러 리전에서 실행하든 관계없이 프로덕션을 위한 워크로드를 준비하는 데 도움이 될 수 있습니다.

4.a: AWS 계정 관리

워크로드를 배포하려면 리전 간 계정 내 모든 AWS 서비스 할당량에 걸쳐 패리티가 있는지 AWS 리전확인합니다. 먼저 아키텍처의 일부인 모든 AWS 서비스 항목을 식별하고 대기 리전에서 계획된 사용량을 확인한 다음 계획된 사용량을 현재 사용량과 비교합니다. 경우에 따라 대기 리전이 이전에 사용된 적이 없는 경우 기본 서비스 할당량을 참조하여 시작점을 이해할 수 있습니다. 그런 다음 사용할 모든 서비스에서 Service Quotas 콘솔(로그인 필요) 또는 APIs를 사용하여 할당량 증가를 요청합니다.

각 리전에서 AWS Identity and Access Management (IAM) 역할을 구성하여 운영자, 자동화 도구 및 대기 리전 내의 리소스 AWS 서비스 에 대한 적절한 권한을 부여합니다. 다중 리전 아키텍처에 대한 리전 격리를 달성하려면 리전별로 역할을 격리합니다. 대기 리전을 사용하기 전에 권한이 있는지 확인합니다.

4.b: 배포 사례

다중 리전 기능을 사용하면 워크로드를 여러 리전에 배포하는 것이 복잡해질 수 있습니다. 한 번에 한 리전에 배포해야 합니다. 예를 들어 액티브-패시브 접근 방식을 사용하는 경우 먼저 기본 리전에 배포한 다음 대기 리전에 배포해야 합니다.는 단일 또는 여러 리전에 인프라를 배포하는 데 AWS CloudFormation 도움이 되며 필요에 따라 조정할 수 있습니다.는 파이프라인이 있는 리전과 다른 리전에 배포를 허용하는 교차 리전 작업이 있는 지속적 통합/지속적 전달(CI/CD) 파이프라인을 구축하는 데 AWS CodePipeline 도움이 됩니다. 이를 블루/그린과 같은 강력한 배포 전략과 결합하면 가동 중지 시간 배포를 최소화할 수 있습니다.

그러나 애플리케이션 또는 데이터의 상태가 영구 저장소로 외부화되지 않으면 상태 저장 기능의 배포가 더 복잡해질 수 있습니다. 이러한 상황에서는 필요에 맞게 배포 프로세스를 신중하게 조정하세요. 여러 리전에 동시에 배포하는 대신 한 번에 한 리전에 배포하도록 배포 파이프라인과 프로세스를 설계합니다. 이렇게 하면 리전 간에 상관관계가 있는 장애가 발생할 가능성이 줄어듭니다. Amazon이 소프트웨어 배포를 자동화하는 데 사용하는 기법에 대해 알아보려면 AWS Builders' Library 문서 안전한 핸드오프 배포 자동화를 참조하세요.

4.c: 관찰성

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

다중 리전 아키텍처를 구축할 때는 대기 리전의 워크로드 성능도 관찰하는 것이 좋습니다. 여기에는 기본 리전의 상태에 대한 외부 보기를 제공하기 위해 대기 리전에서 상태 확인 및 canary(합성 테스트)를 실행하는 것이 포함됩니다. 또한 Amazon CloudWatch Internet Monitor를 사용하여 최종 사용자의 관점에서 외부 네트워크의 상태와 워크로드의 성능을 이해할 수 있습니다. 기본 리전은 대기 리전을 모니터링하기 위해 동일한 관찰성을 갖추어야 합니다.

대기 리전의 카나리아는 고객 경험 지표를 모니터링하여 워크로드의 전반적인 상태를 확인해야 합니다. 이는 기본 리전에 문제가 있는 경우 기본 리전의 관찰성이 손상될 수 있으며 워크로드의 상태를 평가하는 능력에 영향을 미칠 수 있기 때문에 필요합니다.

이 경우 해당 리전 외부에서 관찰하면 인사이트를 얻을 수 있습니다. 이러한 지표는 각 리전에서 사용할 수 있는 대시보드와 각 리전에서 생성된 경보로 롤업해야 합니다. CloudWatch는 리전 서비스이므로 두 리전 모두에 경보가 있어야 합니다. 이 모니터링 데이터는 기본 리전에서 대기 리전으로 장애 조치를 호출하는 데 사용됩니다.

4.d: 프로세스 및 절차

"언제 장애 조치를 취해야 합니까?"라는 질문에 답변하는 것이 가장 좋습니다. 는 필요하기 훨씬 전에 입니다. 문제 발생 전에 사람, 프로세스 및 기술을 포함하는 복구 계획을 정의하고 정기적으로 테스트합니다. 복구 결정 프레임워크를 결정합니다. 복구 프로세스가 잘 실행되고 복구 시간이 잘 이해된 경우 RTO 대상을 충족하는 장애 조치를 사용하여 복구 프로세스를 시작하도록 선택할 수 있습니다. 이 시점은 기본 리전의 애플리케이션 문제가 식별된 직후이거나 리전의 애플리케이션 내 복구 옵션이 소진된 경우 이벤트로 이어질 수 있습니다.

장애 조치 작업 자체는 100% 자동화되어야 하지만, 장애 조치 활성화 결정은 일반적으로 조직에서 미리 결정된 소수의 개인에 의해 이루어져야 합니다. 이러한 개인은 데이터 손실과 이벤트에 대한 정보를 고려해야 합니다. 또한 장애 조치 기준은 조직 내에서 명확하게 정의되고 전역적으로 이해되어야 합니다. 이러한 프로세스를 정의하고 완료하려면 전체 end-to-end 자동화를 지원하고 테스트 및 장애 조치 중에 실행 중인 프로세스의 일관성을 보장하는 AWS Systems Manager 런북을 사용할 수 있습니다.

장애 조치 또는 장애 복구 프로세스를 시작하려면 기본 및 대기 리전에서 이러한 실행서를 사용할 수 있어야 합니다. 이 자동화가 적용되면 정기적인 테스트 주기를 정의하고 따릅니다. 이렇게 하면 실제 이벤트가 있을 때 응답이 조직이 신뢰하는 잘 정의되고 연습된 프로세스를 따르게 됩니다. 데이터 조정 프로세스에 대해 설정된 허용치를 고려하는 것도 중요합니다. 제안된 프로세스가 설정된 RPO/RTO 요구 사항을 충족하는지 확인합니다.

4.e: 테스트

테스트되지 않은 복구 접근 방식을 사용하는 것은 복구 접근 방식을 사용하지 않는 것과 같습니다. 기본 테스트 수준은 복구 절차를 실행하여 애플리케이션의 운영 리전을 전환하는 것입니다. 이를 애플리케이션 교체 접근 방식이라고도 합니다. 리전을 정상 작동 상태로 전환하는 기능을 구축하는 것이 좋지만이 테스트만으로는 충분하지 않습니다.

복원력 테스트는 애플리케이션의 복구 접근 방식을 검증하는 데도 중요합니다. 여기에는 특정 장애 시나리오를 주입하고, 애플리케이션 및 복구 프로세스가 어떻게 반응하는지 이해한 다음, 테스트가 계획대로 진행되지 않은 경우 필요한 완화 조치를 구현하는 작업이 포함됩니다. 오류가 없는 상태에서 복구 절차를 테스트하면 오류가 발생할 때 애플리케이션이 전체적으로 어떻게 작동하는지 알 수 없습니다. 예상되는 장애 시나리오를 기준으로 복구를 테스트하기 위한 계획을 개발해야 합니다. AWS Fault Injection Service는 시작하는 https://docs.aws.amazon.com/fis/latest/userguide/scenario-library.html 데 도움이 되는 시나리오 목록을 제공합니다.

이는 비즈니스 연속성 목표를 충족하기 위해 엄격한 테스트가 필요한 고가용성 애플리케이션에 특히 중요합니다. 복구 기능을 사전 예방적으로 테스트하면 프로덕션 장애 위험이 줄어들어 애플리케이션이 원하는 제한 복구 시간을 달성할 수 있다는 확신이 구축됩니다. 또한 정기적인 테스트는 운영 전문 지식을 구축하여 중단 발생 시 팀이 빠르고 안정적으로 운영 중단으로부터 복구할 수 있도록 합니다. 복구 접근 방식의 인적 요소 또는 프로세스를 실행하는 것은 기술적 측면만큼 중요합니다.

4.f: 비용 및 복잡성

다중 리전 아키텍처의 비용 영향은 인프라 사용량, 운영 오버헤드 및 리소스 시간 증가로 인해 발생합니다. 앞서 언급했듯이 대기 리전의 인프라 비용은 사전 프로비저닝 시 기본 리전의 인프라 비용과 유사하므로 총 비용이 두 배가 됩니다. 일상적인 작업에 충분하지만 수요 급증을 견딜 수 있는 충분한 버퍼 용량을 여전히 예약하도록 용량을 프로비저닝합니다. 그런 다음 각 리전에서 동일한 제한을 구성합니다.

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

또한 팀은 이벤트 중에 사용될 런북에 익숙해지도록 일반적인 장애 조치 및 장애 복구 연습을 거쳐야 합니다. 이러한 연습은 다중 리전 투자에서 예상 결과를 얻는 데 중요하지만 기회 비용을 나타내며 다른 활동에서 벗어나 시간과 리소스를 사용합니다.

4.g: 조직 다중 리전 장애 조치 전략

AWS 리전 는 상관관계가 있는 장애를 방지하고 AWS 서비스 장애 발생 시 단일 리전에 미치는 영향을 포함하는 장애 격리 경계를 제공합니다. 이러한 장애 경계를 사용하여 각 리전에서 독립적인 장애 격리 복제본으로 구성된 다중 리전 애플리케이션을 구축하여 공유 운명 시나리오를 제한할 수 있습니다. 이를 통해 다중 리전 애플리케이션을 구축하고 백업 및 복원부터 파일럿 라이트, 액티브-액티브에 이르기까지 다양한 접근 방식을 사용하여 다중 리전 아키텍처를 구현할 수 있습니다. 그러나 애플리케이션은 일반적으로 독립적으로 작동하지 않으므로 장애 조치 전략의 일부로 사용할 구성 요소와 해당 종속성을 모두 고려하세요. 일반적으로 여러 애플리케이션이 함께 작동하여 소셜 미디어 앱에 사진과 캡션을 게시하거나 전자 상거래 사이트에서 체크아웃하는 등 최종 사용자에게 제공되는 특정 기능인 사용자 스토리를 지원합니다. 따라서 성공적인 접근 방식을 만드는 데 필요한 조정과 일관성을 제공하는 조직 다중 리전 장애 조치 전략을 개발해야 합니다.

조직이 다중 리전 접근 방식을 안내하기 위해 선택할 수 있는 4가지 상위 전략이 있습니다. 가장 세분화된 접근 방식부터 가장 광범위한 접근 방식까지 나열됩니다.

• 구성 요소 수준 장애 조치

• 개별 애플리케이션 장애 조치

• 종속성 그래프 장애 조치

• 전체 애플리케이션 포트폴리오 장애 조치

각 전략에는 장단점이 있으며 장애 조치 의사 결정의 유연성, 장애 조치 조합 테스트 기능, 모달 동작의 존재, 계획 및 구현에 대한 조직 투자 등 다양한 문제를 해결합니다. 각 전략을 자세히 알아보려면 AWS 블로그 게시물 조직 다중 리전 장애 조치 전략 생성을 참조하세요.

주요 지침

• 모든 AWS 서비스 할당량을 검토하여 워크로드가 운영될 모든 리전에서 동일한지 확인합니다.

• 배포 프로세스는 여러 리전을 동시에 포함하는 대신 한 번에 한 리전을 대상으로 해야 합니다.

• 복제 지연과 같은 추가 지표는 다중 리전 시나리오에 고유하며 모니터링해야 합니다.

• 워크로드에 대한 모니터링을 기본 리전 이상으로 확장합니다. 각 리전의 고객 경험 지표를 모니터링하고 워크로드가 실행 중인 각 리전 외부에서이 데이터를 측정합니다.

• 장애 조치 및 장애 복구를 정기적으로 테스트합니다. 장애 조치 및 장애 복구 프로세스를 위한 단일 런북을 구현하고 테스트 및 라이브 이벤트에 모두 사용합니다. 테스트용 런북과 라이브 이벤트용 런북은 다르지 않아야 합니다.

• 장애 조치 전략의 장단점을 이해합니다. 종속성 그래프 또는 전체 애플리케이션 포트폴리오 전략을 구현합니다.