멀티 리전 기초 3: 워크로드 종속성 이해

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

3a: 서비스 AWS 

다중 지역 아키텍처를 설계할 때는 사용될 특정 AWS 서비스를 이해하는 것이 필요합니다. 첫 번째 측면은 멀티 리전을 지원하는 데 필요한 서비스의 기능과 멀티 리전 목표를 달성하기 위해 솔루션을 설계해야 하는지를 이해하는 것입니다. 예를 들어 Amazon Aurora와 Amazon DynamoDB의 경우 데이터를 스탠바이 리전에 비동기적으로 복제하는 기능이 있습니다. 모든 AWS 서비스 종속성은 워크로드가 실행될 모든 지역에서 사용할 수 있어야 합니다. 사용할 서비스를 원하는 지역에서 사용할 수 있는지 확인하려면 AWS 리전al Services List를 검토하세요. 

3b: 내부 및 타사 종속성

워크로드에 있는 내부 종속성의 경우 워크로드가 운영되는 지역 이외의 지역에서도 사용할 수 있는지 확인하세요. 예를 들어 워크로드가 여러 마이크로서비스로 구성된 경우 비즈니스 기능을 구성하는 모든 마이크로서비스에 대해 잘 알고 있어야 합니다. 거기에서 해당 마이크로서비스를 모두 워크로드가 운영되는 각 지역에 배포해야 합니다.

워크로드 내 마이크로서비스 간 지역 간 통화는 권장되지 않으며 지역별 격리를 유지해야 합니다. 지역 간 종속성을 만들면 상호 관련된 장애가 발생할 위험이 높아져 워크로드의 격리된 지역 구현으로 달성하려는 이점이 무효화되기 때문입니다. 온프레미스 종속성도 워크로드의 일부일 수 있으므로 기본 지역이 변경될 경우 이러한 통합의 특성이 어떻게 변경될 수 있는지 이해하는 것이 필수적입니다. 예를 들어 스탠바이 리전이 온프레미스 환경에서 더 멀리 떨어져 있는 경우 늘어난 지연 시간은 부정적인 영향을 미칩니다.

SaaS (Software as a Service) 솔루션, 소프트웨어 개발 키트 (SDK) 및 기타 타사 제품 종속성을 이해하고 이러한 종속성이 저하되거나 사용할 수 없는 시나리오를 실행할 수 있으면 다양한 장애 모드에서 시스템 체인이 어떻게 작동하고 작동하는지 더 잘 이해할 수 있습니다. 이러한 종속성은 AWS Secrets Manager 또는 타사 볼트 솔루션 (예: Hashicorp) 을 사용하여 외부에서 비밀을 관리하는 방법부터 페더레이션 로그인을 위해 IAM Identity Center에 종속되는 인증 시스템에 이르기까지 애플리케이션 코드 내에 있을 수 있습니다.

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

또한 워크로드와 해당 종속성 (예: 타사 애플리케이션) 간의 운명이 공유된다는 점도 염두에 두세요. 페일오버 후 보조 지역에서 종속성을 사용할 수 없는 경우 워크로드가 완전히 복구되지 않을 수 있습니다.

3c: 페일오버 메커니즘

도메인 이름 시스템 (DNS) 은 트래픽을 기본 지역에서 대기 지역으로 이동하는 장애 조치 메커니즘으로 일반적으로 사용됩니다. 페일오버 메커니즘이 취하는 모든 종속성을 비판적으로 검토하고 면밀히 조사하십시오. 예를 들어, 워크로드가 Amazon Route 53을 사용하는 경우 제어 플레인이 미국 동부-1에 호스팅된다는 점을 이해하면 해당 지역의 컨트롤 플레인에 대한 종속성을 갖게 됩니다. 기본 지역이 미국 동부 지역이기도 한 경우에는 장애 조치 메커니즘의 일부로 사용하지 않는 것이 좋습니다. 다른 페일오버 메커니즘을 사용하는 경우 예상대로 작동하지 않는 시나리오를 깊이 이해해야 합니다. 이러한 이해가 확립되면 비상 사태에 대비한 계획을 세우거나 필요한 경우 새로운 메커니즘을 개발하십시오. Amazon Route 53을 사용한 재해 복구 메커니즘 생성을 검토하여 장애 조치를 성공적으로 수행하는 데 사용할 수 있는 접근 방식에 대해 알아보십시오.

내부 종속성 섹션에서 설명한 바와 같이, 비즈니스 역량의 일부인 모든 마이크로서비스는 워크로드가 배포되는 각 지역에서 사용할 수 있어야 합니다. 장애 조치 전략의 일환으로 비즈니스 기능을 함께 페일오버하여 지역 간 통화가 발생할 가능성을 없애야 합니다. 또는 마이크로서비스가 독립적으로 페일오버되는 경우 마이크로서비스가 잠재적으로 지역 간 호출을 수행하는 바람직하지 않은 동작이 발생할 수 있으며, 이로 인해 지연 시간이 발생하고 클라이언트 시간 초과 시 워크로드를 사용할 수 없게 될 수 있습니다.

3d: 구성 종속성

인증서, 키, 암호 및 매개변수는 다중 지역용으로 설계할 때 필요한 종속성 분석의 일부입니다. 가능하면 이러한 구성 요소를 각 지역 내에서 현지화하여 이러한 종속성에 대해 지역 간에 운명이 공유되지 않도록 하는 것이 가장 좋습니다. 인증서의 경우 만료일은 각 지역마다 달라야 하며, 만료되는 인증서 (미리 알리도록 경보가 설정되어 있음) 가 여러 지역에 영향을 미치는 시나리오를 피하려면 가능하면 각 지역마다 만료일이 달라야 합니다.

암호화 키와 비밀도 지역별로 달라야 합니다. 이렇게 하면 키나 암호의 로테이션에 오류가 발생하는 경우 해당 영향이 특정 지역에만 제한됩니다.

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

주요 지침

• 다중 지역 아키텍처는 지역 간의 물리적 및 논리적 분리를 통해 이점을 얻습니다. 애플리케이션 계층에 지역 간 종속성을 도입하면 이러한 이점이 사라집니다. 이러한 종속성을 피하십시오.

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

• 지역 간 통화의 지연 시간 및 종속성 증가 가능성을 없애려면 비즈니스 역량에 맞게 장애 조치를 조정해야 합니다.