다중 리전 기본 3: 워크로드 종속성 이해

특정 워크로드에는 사용, 내부 종속성, 타사 종속성, 네트워크 종속성, 인증서, 키, 보안 암호 및 파라미터와 같은 AWS 서비스 리전의 여러 종속성이 있을 수 있습니다. 장애 시나리오 중에 워크로드를 작동하려면 기본 리전과 대기 리전 간에 종속성이 없어야 하며, 각 리전은 서로 독립적으로 작동할 수 있어야 합니다. 이를 위해 워크로드의 모든 종속성을 조사하여 각 리전 내에서 사용할 수 있는지 확인합니다. 이는 기본 리전의 장애가 대기 리전에 영향을 미치지 않아야 하기 때문에 필요합니다. 또한 종속성이 저하된 상태이거나 완전히 사용할 수 없을 때 워크로드가 작동하는 방식을 이해해야 이를 적절하게 처리할 수 있는 솔루션을 엔지니어링할 수 있습니다.

3.a: AWS 서비스

다중 리전 아키텍처를 설계할 때는 AWS 서비스 사용할 , 해당 서비스의 다중 리전 기능, 다중 리전 목표를 달성하기 위해 엔지니어링해야 하는 솔루션을 이해하는 것이 중요합니다. 예를 들어 Amazon Aurora와 Amazon DynamoDB는 데이터를 대기 리전에 비동기식으로 복제할 수 있습니다. 워크로드가 실행될 모든 리전에서 모든 AWS 서비스 종속성을 사용할 수 있어야 합니다. 사용 중인 서비스를 원하는 리전에서 사용할 수 있는지 확인하려면 AWS 서비스 리전별 목록을 검토합니다.

3.b: 내부 및 타사 종속성

워크로드가 운영되는 리전에서 모든 워크로드의 내부 종속성을 사용할 수 있는지 확인합니다. 예를 들어 워크로드가 여러 마이크로서비스로 구성된 경우 비즈니스 기능을 구성하는 모든 마이크로서비스를 식별하고 해당 마이크로서비스가 워크로드가 운영되는 각 리전에 배포되었는지 확인합니다. 또는 사용할 수 없게 되는 마이크로서비스를 정상적으로 처리하기 위한 전략을 정의합니다.

워크로드 내의 마이크로서비스 간 리전 간 호출은 권장되지 않으며 리전 격리를 유지해야 합니다. 이는 교차 리전 종속성을 생성하면 상관관계가 있는 장애 위험이 추가되어 워크로드의 격리된 리전 구현의 이점을 상쇄하기 때문입니다. 온프레미스 종속성도 워크로드의 일부일 수 있으므로 기본 리전이 변경될 경우 이러한 통합의 특성이 어떻게 변경될 수 있는지 이해하는 것이 중요합니다. 예를 들어 대기 리전이 온프레미스 환경에서 더 멀리 있는 경우 지연 시간이 증가하면 부정적인 영향을 미칠 수 있습니다.

서비스형 소프트웨어(SaaS) 솔루션, 소프트웨어 개발 키트(SDKs) 및 기타 타사 제품 종속성을 이해하고 이러한 종속성이 저하되거나 사용할 수 없는 시나리오를 실행할 수 있으면 시스템 체인이 다양한 장애 모드에서 어떻게 작동하고 작동하는지 더 잘 파악할 수 있습니다. 이러한 종속성은를 사용하여 외부에서 보안 암호를 관리하는 등 애플리케이션 코드 내에 AWS Secrets Manager있거나, 타사 볼트 솔루션(예: HashiCorp) 또는 페더레이션 로그인에 AWS IAM Identity Center 대한 종속성이 있는 인증 시스템을 포함할 수 있습니다.

종속성과 관련하여 중복성이 있으면 복원력이 향상될 수 있습니다. SaaS 솔루션 또는 타사 종속성이 워크로드 AWS 리전 와 동일한 기본를 사용하는 경우 공급업체와 협력하여 복원력 태세가 워크로드 요구 사항과 일치하는지 확인합니다.

또한 워크로드와 타사 애플리케이션과 같은 종속성 간의 공유 운명에 유의하세요. 장애 조치 후 보조 리전에서(또는 보조 리전에서) 종속성을 사용할 수 없는 경우 워크로드가 완전히 복구되지 않을 수 있습니다.

3.c: 장애 조치 메커니즘

DNS는 일반적으로 트래픽을 기본 리전에서 대기 리전으로 이동하는 장애 조치 메커니즘으로 사용됩니다. 장애 조치 메커니즘이 취하는 모든 종속성을 비판적으로 검토하고 검사합니다. 예를 들어 워크로드가 Amazon Route 53을 사용하는 경우 컨트롤 플레인이에서 호스팅된다는 것을 이해us-east-1하면 해당 특정 리전의 컨트롤 플레인에 종속성을 갖게 됩니다. 기본 리전도 장애 지점 하나를 생성us-east-1하므로 장애 조치 메커니즘의 일부로 권장되지 않습니다. 다른 장애 조치 메커니즘을 사용하는 경우 장애 조치가 예상대로 작동하지 않는 시나리오를 깊이 이해하고 필요한 경우 비상을 계획하거나 새 메커니즘을 개발해야 합니다. 블로그 게시물 Amazon Route 53을 사용하여 재해 복구 메커니즘 생성에서 장애 조치를 성공적으로 수행하는 데 사용할 수 있는 접근 방식에 대해 알아봅니다.

이전 섹션에서 설명한 대로 워크로드가 배포된 각 리전에서 비즈니스 기능의 일부인 모든 마이크로서비스를 사용할 수 있어야 합니다. 장애 조치 전략의 일환으로 비즈니스 기능의 일부인 모든 마이크로서비스가 함께 장애 조치되어 리전 간 호출 가능성을 제거해야 합니다. 또는 마이크로서비스가 독립적으로 장애 조치되는 경우 교차 리전 호출을 수행할 수 있는 마이크로서비스와 같은 원치 않는 동작이 발생할 수 있습니다. 이로 인해 지연 시간이 발생하고 클라이언트 제한 시간 동안 워크로드를 사용할 수 없게 될 수 있습니다.

3.d: 구성 종속성

인증서, 키, 보안 암호, Amazon Machine Image(AMIs), 컨테이너 이미지 및 파라미터는 다중 리전 아키텍처를 설계할 때 필요한 종속성 분석의 일부입니다. 가능한 경우 이러한 종속성에 대해 리전 간에 공유 운명이 없도록 각 리전 내에서 이러한 구성 요소를 현지화하는 것이 가장 좋습니다. 예를 들어 인증서의 만료 날짜를 변경하여 만료되는 인증서(경보가 "사전 알림"으로 설정된 경우)가 여러 리전에 영향을 미치는 시나리오를 방지해야 합니다.

암호화 키와 보안 암호도 리전별로 달라야 합니다. 이렇게 하면 키 또는 보안 암호 교체에 오류가 있는 경우 영향이 특정 리전으로 제한됩니다.

마지막으로 워크로드가 특정 리전에서 검색할 수 있도록 워크로드 파라미터를 로컬에 저장해야 합니다.

주요 지침

• 다중 리전 아키텍처는 리전 간 물리적 및 논리적 분리의 이점을 누릴 수 있습니다. 애플리케이션 계층에 교차 리전 종속성을 도입하면 이러한 이점이 깨집니다. 이러한 종속성을 피합니다.

• 장애 조치 제어는 기본 리전에 대한 종속성 없이 작동해야 합니다.

• 장애 조치는 사용자 여정 전체에서 조정하여 리전 간 호출의 지연 시간과 종속성이 증가할 가능성을 제거해야 합니다.