연습 - 디자인을 여러 지역으로 확장
Contoso Shoes에서는 지역 가동 중단에 대응하기 위한 방법을 모색하고 있습니다. 현재 스탬프를 활성-활성, 공유 상태 및 다중 지역 토폴로지로 배포하려고 합니다. 아키텍처는 지역에 장애가 발생할 경우 트래픽을 다른 지역으로 리디렉션하도록 설계되어야 합니다.
현재 상태 및 문제
단일 지역으로도 애플리케이션을 운영하는 데 어려움이 없었습니다. 그러나 최근 지역 가동 중단은 네트워킹에 영향을 주었고, 그로 인해 최종 사용자 관점에서 시스템이 오프라인 상태가 되는 사건이 발생했습니다. 지역 내에서 수평적 스케일링을 실행하거나 해당 지역에 새 스탬프를 배포하더라도 애플리케이션이 실패한 상태에서 복구되지 않았을 것입니다.
api.contososhoes.com에 대한 DNS는 기존 등록 기관에서 보유합니다. DNS 레코드는 TTL(Time-to-Live) 기간이 2일인 백 엔드 App Services 엔드포인트(apicontososhoes.azurewebsites.net)로 확인됩니다. 솔루션이 여러 지역에 배포되면 DNS를 마이그레이션해야 합니다.
규격
- 활성-활성 다중 지역 토폴로지에서 작동하도록 아키텍처를 확장합니다.
- 두 지역에 걸쳐 하드 코딩된 리소스 목록 대신 필요에 따라 지역을 동적으로 추가하고 제거할 수 있는 배포 스탬프 모델을 수정합니다.
- 지역 오류가 있는 경우 오류가 없는 지역에 이미 있는 클라이언트에 주목할 만한 영향을 주지 않고 트래픽을 오류 없는 지역으로 라우팅해야 합니다.
- 클라이언트는 지역에 고정되어서는 안 됩니다.
- 클라이언트는 API에 연결하기 위해 URL을 변경할 필요가 없습니다. DNS는 전역 라우터로 마이그레이션해야 합니다.
권장 접근 방식
디자인을 시작하려면 다음 단계를 수행하는 것이 좋습니다.
1 - 다중 지역 토폴로지
지역 가동 중단을 방지하려면 아키텍처를 둘 이상의 Azure 지역에 배포해야 합니다. 지역을 선택할 때 다음 요소를 고려합니다.
- 지역은 해당 지역의 데이터 센터 가동 중단을 견딜 수 있어야 합니다.
- 아키텍처에 사용되는 Azure 서비스 및 기능은 지역에서 지원되어야 합니다.
- 네트워크 대기 시간을 최소화하려면 지역에 배포된 지역 및 리소스가 최종 사용자 및 종속 시스템과 근접해야 합니다.
실패 시나리오를 생각해 봅니다. 지역 1에서 트래픽의 75%를 가져오고 추가한 지역 2에서 나머지를 가져옵니다. 둘 다 해당 부하를 처리하기 위해 적절하게 스케일링됩니다. 지역 1에 지역 가동 중단이 발생하고 모든 트래픽이 이제 지역 2로 라우팅됩니다. 해당 전환을 원활하게 진행할 수 있습니까? 지역 2에서 트래픽 부하 증가를 지원할 수 있습니까?
진행 상황 확인: 전역 배포
2 - 전역 라우팅
클라이언트가 두 작동 지역 중 한 곳으로 투명하게 라우팅되도록 하려면 전역 부하 분산 장치를 추가합니다. 이전 연습에서 추가한 상태 검사는 부하 분산 장치에서 스탬프가 정상인지 여부를 확인하는 데 사용해야 합니다. 백 엔드에 도달하지 않고도 유사한 요청을 지속적으로 이행하는 방법이 있습니까?
- 기존 아키텍처와 통합되고 신속하게 장애 조치(failover)를 수행할 수 있는 네이티브 Azure 서비스를 선택합니다.
- 네트워크 수신 경로에 권한 없는 트래픽을 거부하는 제어 장치가 있는지 확인합니다.
- 에지 캐시에서 최종 사용자에게 서비스를 제공하여 네트워크 대기 시간을 최소화합니다.
- 기존 클라이언트에 영향을 주지 않고 기존 DNS를 마이그레이션합니다.
- 트래픽이 결함이 있는 지역으로 라우팅되지 않도록 지역 오류를 알리는 자동화된 방법을 구축합니다. 또한 부하 분산 장치가 해당 지역으로의 라우팅을 다시 시작할 수 있도록 지역이 준비되었을 때 알림을 받습니다.
진행 상황 확인: 전역 트래픽 라우팅
3 - 배포 스탬프 변경
이상적인 상태는 수동 장애 조치(failover)가 필요하지 않은 활성-활성 구성이며 모든 지역에서 클라이언트 요청을 처리할 수 있습니다. 이것이 아키텍처에 어떤 의미인지 생각해 봅니다. 예를 들어 지역 스탬프에 저장된 상태가 있나요?
현재 아키텍처의 특정 서비스에는 지역 복제 기능이 있습니다. 서비스를 서로 다른 스탬프로 분리하는 것이 좋습니다. 즉, 전역 리소스를 포함하는 스탬프 한 개와, 전역 스탬프와 리소스를 공유하는 또 다른 지역 스탬프로 분리합니다. 결정 요소 중 하나는 해당 리소스의 수명 주기여야 합니다. 아키텍처의 다른 리소스와 비교하여 해당 리소스의 예상 수명은 어떻게 되나요? 리소스가 전체 시스템 또는 지역과 수명이 같거나 더 길어야 하나요? 혹은 일시적인 리소스인가요?
아키텍처에 사용되는 Azure 서비스의 안정성 기능을 살펴봅니다. 이와 같은 기능으로 시작하여 안정성을 최대화하기 위해 추가로 검색할 수 있습니다.
| Azure 서비스 | 기능 |
|---|---|
| Azure Cosmos DB | 다중 지역 쓰기 |
| Azure Container Registry | 지역에서 복제 |
| Azure App Service 계획 | 가용성 영역 지원 |
진행 상황 확인: 애플리케이션 플랫폼 | 데이터 플랫폼
작업 확인
유사한 아키텍처에 대한 애플리케이션 및 데이터 디자인 선택 항목은 다음과 같습니다. 디자인의 모든 측면을 다루셨나요?
- 다중 지역 토폴로지에서 선택한 다른 Azure 지역은 어디이며 그 이유는 어떻게 되나요?
- 데이터 센터 가동 중단으로부터 보호하기 위해 각 Azure 지역에서 둘 이상의 Azure 가용성 영역을 사용하도록 설정했나요?
- 수신 트래픽을 제어하는 Web Application Firewall을 포함했나요? 어떤 라우팅 규칙을 마련했고 그 이유는 무엇인가요?
- 부하 분산 장치는 기존 DNS 레코드를 어떻게 지원하나요?
- 이전 연습에서 상태 검사 API를 어떻게 사용했나요?
- DDoS 공격으로부터 애플리케이션을 보호했나요? 특히 악의적인 클라이언트가 부하 분산 장치를 우회하고 지역 인스턴스에 도달하지 못하도록 방지했나요?
- DNS 마이그레이션에 어떻게 접근했나요?
- 다중 지역 토폴로지를 지원하기 위해 기존 구성 요소에 대한 SKU를 변경했나요?
- 어떤 Azure 서비스를 singleton으로 남겨 두셨나요? 각 서비스에 대한 선택을 어떻게 정당화했나요? 구성을 변경했나요?
- 리소스를 로깅하고 있나요? 전체 시스템에 대한 로그를 검사하는 기능에 영향을 줄 것으로 생각하나요?