세계화하다
- 3분
이전 단원에서는 컴퓨팅 크기를 조정하고 프로세스에서 더 많이 사용할 수 있도록 하는 것에 대해 설명했습니다. 또한 성능을 향상시키기 위해 Azure Cache for Redis를 추가하고 분할을 통해 Azure SQL 데이터베이스를 확장하는 것이 좋습니다.
비즈니스가 성장함에 따라 다음 단계는 전역으로 이동하는 것일 수 있습니다. 그러나 완전히 글로벌 아키텍처를 구현하기 전에 고려해야 할 몇 가지 사항이 있습니다.
질문할 질문
첫 번째 질문은 : 당신은 정말 글로벌 이동해야합니까?
이러한 작업을 수행하기 전에 고객이 겪는 고통을 이해하는 것이 중요하므로 몇 가지 질문을 더 하십시오.
- 콘텐츠 배달 네트워크를 통해 사용자에게 더 가까운 콘텐츠를 얻을 수 있나요?
- 이 특정 시스템을 두 개 이상의 지역에 걸쳐 확장해야 합니까? 예를 들어 미국의 사용자는 영국에서 정확히 동일한 계정을 가져야 합니까? 독립 시스템이 더 적합할까요? 이 패턴은 전자 상거래에서 일반적입니다.
- 실제로 전역적으로 분산된 시스템이 필요한 경우 데이터베이스에 어떤 일관성이 필요한가요? 전 세계의 강력한 일관성은 제대로 하기 어렵고, 말 그대로 빛의 속도로 인해 Cosmos DB와 같은 서비스에서 허용되지 않습니다.
데이터 일관성
데이터 일관성 문제를 좀 더 자세히 살펴보겠습니다.
데이터베이스 시스템의 일관성 은 지정된 데이터베이스 트랜잭션이 허용되는 방식으로만 영향을 받는 데이터를 변경해야 한다는 요구 사항을 나타냅니다. 분산 컴퓨팅에는 두 가지 일관성 모델이 사용됩니다.
강력한 일관성은 선형성을 보장합니다. 읽기는 항목의 커밋된 최신 버전을 반환하도록 보장됩니다.
그리고 결국에는 데이터베이스 또는 시스템이 시간이 지남에 따라 일관성을 유지할 것이라는 생각과 최종 일관성이 있습니다. 읽기에 대한 순서 지정 보장은 없습니다. 추가 쓰기가 없으면 복제본이 결과적으로 수렴합니다.
글로벌 시장 진출을 위한 도구
애플리케이션을 전역적으로 확장해야 하는 경우 이를 달성하는 데 도움이 되는 몇 가지 Azure 서비스가 있습니다. Azure Traffic Manager 및 Azure Front Door를 살펴보겠습니다.
- Azure Traffic Manager는 글로벌 DNS 기반 부하 분산 서비스입니다. DNS 및 상태 프로브를 사용하여 정의한 라우팅 정책에 따라 사용자를 최상의 정상 백 엔드로 라우팅합니다. 이 정의는 성능, 위치, 라운드 로빈 등을 기반으로 할 수 있습니다. 정상 백 엔드가 식별되면 클라이언트는 항상 백 엔드에 직접 연결합니다.
- Azure Front Door Service는 ADN(Application Delivery Network)으로, 애플리케이션에 대한 다양한 계층 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를 사용합니다.