전역으로 전환
이전 단원에서 컴퓨팅 스케일링과 프로세스에서 이를 더 많이 사용할 수 있게 하는 방법을 설명했습니다. Azure Cache for Redis를 추가하여 성능을 향상하고 분할을 통해 Azure SQL 데이터베이스를 스케일 아웃하는 방법도 제안했습니다.
비즈니스가 성장한다면 다음 단계는 전역으로 전환하는 것입니다. 그러나 전체적으로 전역 아키텍처를 구현하기 전에 고려해야 할 사항이 있습니다.
질문
첫 번째 질문: 꼭 전역으로 전환해야 하나요?
이러한 작업을 수행하기 전에 다음 질문을 통해 고객의 고충을 이해하는 것이 중요합니다.
- 콘텐츠 배달 네트워크를 통해 사용자에게 콘텐츠를 더 가까이 제공할 수 있나요?
- 이 특정 시스템을 둘 이상의 지역에 걸쳐 확장해야 하나요? 예를 들어 미국에 있는 사용자의 계정이 영국의 계정과 정확히 동일해야 하나요? 독립적인 시스템이 더 적합한가요? 이 패턴은 전자 상거래에서 일반적입니다.
- 시스템을 꼭 전역적으로 배포해야 한다면 데이터베이스에 필요한 일관성은 무엇인가요? 전역적으로 강력한 일관성을 유지하는 것은 어려우며 말 그대로 빛의 속도로 인해 Cusmos DB와 같은 서비스에서는 허용되지 않습니다.
데이터 일관성
데이터 일관성 문제를 더 자세히 살펴보겠습니다.
데이터베이스 시스템의 일관성은 지정된 데이터베이스 트랜잭션이 허용되는 방식으로만 영향받는 데이터를 변경해야 한다는 요구 사항을 의미합니다. 분산 컴퓨팅에는 두 가지 일관성 모델이 사용됩니다.
강력한 일관성은 선형화 가능성을 보장합니다. 읽기를 통해 항목의 최신 커밋된 버전 반환이 보장됩니다.
그리고 데이터베이스 또는 시스템이 시간이 지남에 따라 결국에는 일관적인 상태가 될 것이라는 개념인 최종 일관성이 있습니다. 읽기의 순서는 보장되지 않습니다. 추가 쓰기가 없으면 복제본이 결과적으로 수렴합니다.
전역 전환 도구
애플리케이션을 전역적으로 확장해야 하는 경우에는 이를 수행하는 데 도움이 되는 몇 가지 Azure 서비스가 있습니다. Azure Traffic Manager 및 Azure Front Door를 살펴보겠습니다.
- Azure Traffic Manager는 전역 DNS 기반 부하 분산 서비스입니다. 이것은 DNS 및 상태 프로브를 사용하여 정의한 라우팅 정책에 따라 최고 정상 상태의 백 엔드로 사용자를 라우팅합니다. 이 정의는 성능, 위치, 라운드 로빈 등을 기반으로 할 수 있습니다. 정상적인 백 엔드가 식별된 후 클라이언트는 항상 백 엔드에 직접 연결됩니다.
- Azure Front Door Service는 ADN(애플리케이션 전달 네트워크) 서비스로, 애플리케이션에 대해 7개의 다양한 부하 분산 기능을 제공합니다. 근 실시간 장애 조치(failover)를 통해 전역 부하 분산과 함께 DSA(동적 사이트 가속)를 제공합니다. 이것은 Azure에서 완전히 관리하는 고가용성 및 확장 가능한 서비스입니다.
Azure Front Door가 기본적으로 전역 HTTP 기반 부하 분산 장치입니다. 클라이언트는 Front Door 자체를 사용하여 연결하므로 Front Door가 사용자 요청의 프록시를 사용하고 있습니다. 요청한 항목이 캐시에 없으면 올바른 라우팅 규칙이 식별됩니다. 그런 다음 관련 백 엔드의 상태 프로브를 확인하고 모두 정상이라고 가정하면 라우팅 방법에 따라 사용자 요청을 최상의 백 엔드로 전달합니다.
Azure Front Door에서 연결의 프록시를 사용하므로 스케일링에 유용한 캐싱과 웹 애플리케이션 방화벽 실행과 같은 몇 가지 고급 기능을 수행할 수 있습니다. Traffic Manager로는 이러한 기능을 수행할 수 없습니다.
다이어그램은 두 가지를 함께 사용할 수 있는 방법을 보여줍니다.
이 설정은 스토리지 계정의 정적 자산으로 간단한 DNS 기반 부하 분산을 위해 Traffic Manager를 사용합니다. 또한 App Service 및 VM에서 웹 애플리케이션의 경로 기반 라우팅에 Front Door를 사용합니다.