이 아키텍처는 대량의 데이터를 사용하는 웹 애플리케이션에 대한 고가용성 솔루션을 제공합니다. 애플리케이션과 데이터를 배포하여 사용자와 가깝게 유지하는 글로벌 솔루션을 제공할 수 있는 유연한 접근 방식입니다.
아키텍처에는 사용자 지정 복제 소프트웨어가 필요합니다. 애플리케이션 및 구성에 따라 만들기가 어려울 수 있습니다.
몇 가지 가능한 구성은 다음과 같습니다.
활성/수동: 일반적으로 모든 사용자에게 서비스를 제공하는 주 지역이 있습니다. 주 지역이 작동하지 않을 때 활성화되는 대기 지역도 있습니다. 주 시스템이 활성 상태이면 복제 서비스는 데이터베이스 변경 내용을 대기 지역에 복제합니다.
활성/활성: 일반적으로 활성 상태인 주 지역이 있어 주변 사용자에게 읽기 서비스를, 모든 사용자에게 쓰기 서비스를 제공합니다. 하나 이상의 다른 지역이 활성화되어 있으며 가까운 사용자에게 읽기 전용 서비스를 제공합니다. 쓰기는 항상 주 지역으로 전달되며 읽기는 항상 가장 가까운 활성 지역으로 전달됩니다.
활성/수동 구성과 마찬가지로 주 지역이 작동하지 않을 때 활성 상태가 되는 대기 지역이 있습니다. 주 시스템이 활성 상태이면 복제 서비스는 데이터베이스 변경 내용을 읽기 전용 지역 및 대기 지역으로 복제합니다. 대기 지역이 활성 상태이면 복제 서비스는 데이터베이스 변경 내용을 읽기 전용 지역에 복제합니다.
이 방법의 한 가지 단점은 쓰기 작업의 대기 시간이 높다는 것입니다.
다중 활성: 사용자에게 전체 서비스를 제공할 수 있는 여러 활성 지역이 있습니다. 사용자 활동은 항상 가장 가까운 활성 지역으로 전달됩니다.
다중 활성 구현은 매우 어렵고 전문가 디자인 및 구현이 필요할 수 있습니다.
복제는 사용자 지정 구현이므로 일관성 수준은 필요한 대로 설정할 수 있습니다.
이 아키텍처에서 중요한 고려 사항은 사용자 지정 복제 구현이 어려울 수 있다는 점과 시간이 얼마나 필요한지입니다.
참고
경우에 따라 애플리케이션에 여러 스토리지 계정이 필요할 수 있습니다. 자세한 내용은 고려 사항을 참조하세요.
잠재적인 사용 사례
아키텍처는 항상 사용할 수 있어야 하는 대량의 데이터를 사용하는 모든 애플리케이션에 적합할 수 있습니다. 예를 들어 다음과 같은 앱이 여기에 포함됩니다.
- 고객의 지출 습관과 쇼핑 행동을 추적합니다(소매 산업).
- 날씨를 예측합니다(농업, 환경 및 미디어/뉴스 산업).
- 스마트 교통 시스템을 제공 또는 구현하거나 스마트 기술을 사용해서 교통 상황을 모니터링합니다(자동차 및 운송 산업).
- 제조 IoT(사물 인터넷) 데이터를 분석합니다.
- 스마트 측정 데이터를 표시하거나 스마트 기술을 사용해서 측정 데이터를 모니터링합니다(에너지 산업).
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
데이터 흐름
- 클라이언트는 Microsoft Entra ID를 사용하여 인증하고 Azure 앱 Service에서 호스트되는 웹 애플리케이션에 대한 액세스 권한을 부여합니다.
- 방화벽 및 계층 7 부하 분산 장치인 Azure Front Door는 지역 가동 중단이 있는 경우 사용자 트래픽을 다른 Azure 지역으로 전환합니다.
- Azure App Service는 웹 사이트 및 RESTful 웹 API를 호스트합니다. 브라우저 클라이언트는 API를 사용하는 AJAX 애플리케이션을 실행합니다.
- 웹 API가 백그라운드 작업을 처리하도록 함수 앱을 위임합니다. 이 작업은 Azure Queue Storage 큐에 대기됩니다.
- Azure Functions에서 호스트되는 함수 앱이 큐에 대기된 메시지로 트리거되는 백그라운드 작업을 수행합니다.
- 사용자 지정 복제 소프트웨어는 테이블이 지역 간에 동일하게 유지되도록 합니다.
- Azure Cache for Redis는 함수 앱에 대한 테이블 데이터를 캐시합니다. 이렇게 하면 데이터베이스 활동이 오프로드되고 함수 앱 및 웹앱의 속도가 향상됩니다.
- Azure Table Storage는 웹 애플리케이션에서 사용한 데이터를 보유합니다.
구성 요소
- Microsoft Entra ID 는 온-프레미스 디렉터리와 동기화할 수 있는 다중 테넌트 ID 및 액세스 관리 서비스입니다. Azure DNS는 빠른 DNS 쿼리와 빠른 DNS 레코드 업데이트를 앱에 제공하는 DNS 도메인을 위한 고가용성 호스팅 서비스입니다. Azure DNS 관리는 다른 Azure 서비스 관리와 비슷하며 동일한 자격 증명, API, 도구 및 청구가 사용됩니다.
- Azure Front Door는 즉각적인 장애 조치(failover)를 사용하는 보안 CDN(콘텐츠 배달 네트워크) 및 부하 분산 장치입니다. 사용자에게 가까운 에지에서 작동하며 사이버 위협으로부터 앱, API 및 웹 사이트를 보호하면서 콘텐츠 전송을 가속화합니다.
- Azure App Service는 웹앱을 빌드, 배포 및 스케일링하기 위한 완전 관리형 서비스입니다. .NET, .NET Core, Node.js, Java, Python 또는 PHP를 사용하여 앱을 빌드할 수 있습니다. 앱은 컨테이너에서 실행하거나 Windows 또는 Linux에서 실행할 수 있습니다. 메인프레임 마이그레이션에서 프런트 엔드 화면 또는 웹 인터페이스를 HTTP 기반 REST API로 코딩할 수 있습니다. 분리될 수 있으며 마이크로 서비스 기반 시스템을 오케스트레이션하기 위해 상태 비저장일 수 있습니다. 웹 API에 대한 자세한 내용은 RESTful 웹 API 디자인을 참조하세요.
- Azure Functions는 애플리케이션 인프라를 설정하지 않고도 함수라는 작은 코드 조각을 실행할 수 있는 환경을 제공합니다. 이를 사용하여 대량 데이터를 처리하고, 시스템을 통합하고, IoT를 사용하고, 간단한 API와 마이크로 서비스를 빌드할 수 있습니다. 마이크로 서비스를 사용하면 Azure 서비스에 연결되고 항상 최신 상태인 서버를 만들 수 있습니다.
- Azure Storage는 대규모로 확장 가능하고 안전한 데이터, 앱 및 워크로드용 클라우드 서비스 세트입니다. 여기에는 Azure Files, Azure Table Storage 및 Azure Queue Storage가 포함됩니다. Azure Files는 메인프레임 워크로드를 마이그레이션할 수 있는 효과적인 도구인 경우가 많습니다.
- Azure Queue Storage는 대규모 워크로드를 위한 간단하고, 비용 효율적이고, 지속적인 메시지 큐 기능을 제공합니다.
- Azure Table Storage는 대규모 반구조화된 데이터 세트를 사용하는 신속한 개발을 위한 NoSQL 키-값 저장소입니다. 테이블은 스키마가 없으며 필요에 따라 쉽게 조정됩니다. 액세스는 많은 유형의 애플리케이션에 대해 빠르고 비용 효율적이며 일반적으로 다른 유형의 키 스토리지보다 비용이 적게 듭니다.
- Azure Cache for Redis는 컴퓨팅 리소스 간에 데이터와 상태를 공유하기 위한 완전 관리형 메모리 내 캐싱 서비스 및 메시지 broker입니다. 여기에는 오픈 소스 Redis 및 Redis Labs의 상업용 제품이 모두 관리되는 서비스로 포함되어 있습니다. Azure Cache for Redis 등의 메모리 내 데이터 저장소를 스케일링하고 사용하도록 디자인하여 처리량이 높은 온라인 트랜잭션 처리 애플리케이션의 성능을 향상할 수 있습니다.
대안
- Azure Traffic Manager는 선택한 트래픽 라우팅 방법에 따라 전 세계 Azure 지역에서 들어오는 DNS 요청을 전달합니다. 또한 자동 장애 조치(failover) 및 성능 라우팅을 제공합니다.
- Azure CDN(Content Delivery Network)은 빠른 응답을 위해 정적 콘텐츠를 에지 서버에 캐시하고 네트워크 최적화를 사용하여 동적 콘텐츠에 대한 응답을 개선합니다. CDN은 사용자 기반이 글로벌인 경우에 특히 유용합니다.
- AKS(Azure Kubernetes Service)는 컨테이너화된 애플리케이션을 배포하고 관리하기 위한 완전 관리형 Kubernetes 서비스입니다. 또한 이를 사용해서 해당 구성 요소가 필요에 따라 독립적으로 스케일링되는 마이크로 서비스 아키텍처를 구현할 수 있습니다.
- Azure Container Instances는 인프라를 관리할 필요 없이 빠르고 간단하게 작업을 실행할 수 있는 방법을 제공합니다. 개발 중이거나 예약되지 않은 작업을 수행할 때 유용합니다.
- Azure Service Bus는 간단한 하이브리드 통합을 위한 신뢰할 수 있는 클라우드 메시징 서비스입니다. 이 아키텍처에서는 Queue Storage를 대신할 수 있습니다. 자세한 내용은 Storage 큐 및 Service Bus 큐 - 비교 및 대조를 참조하세요.
고려 사항
아키텍처에는 사용자 지정 복제 소프트웨어가 필요합니다. 애플리케이션 및 구성에 따라 만들기가 어려울 수 있습니다. 이 아키텍처에서 중요한 고려 사항은 사용자 지정 복제 구현이 어려울 수 있다는 점과 시간이 얼마나 필요한지입니다.
복제는 사용자 지정 설계이므로 개발자는 데이터 일관성 전략을 유연하게 구현할 수 있습니다.
Table Storage에는 성능 제한이 있으며 스토리지 계정을 추가하여 극복할 수 있습니다. 다음 상황에서는 더 많은 계정이 필요할 수 있습니다.
- 여러 고객을 지원하도록 다중 테넌트를 구현하려는 경우
- 트랜잭션 속도가 더 높은 고객을 지원하려는 경우
- 큰 데이터 세트가 있는 고객을 지원하려는 경우
- 여러 스토리지 계정에 데이터를 분산하여 데이터 액세스 속도를 높이려는 경우
- 데이터를 핫, 콜드 및 보관 계층으로 분리하려는 경우
- 백업 및 보고 목적으로 데이터 복사본을 만들려는 경우
자세한 내용은 Table Storage의 확장성 및 성능 목표를 참조하세요.
애플리케이션에 이미 데이터가 포함된 경우 이전 데이터를 스토리지 계정에 복사하는 루틴을 작성해야 합니다. 데이터의 마이그레이션 진행률을 추적하기 위한 타임스탬프 및 복사 플래그가 있는지 확인합니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
- Nabil Siddiqui | 디지털 및 애플리케이션 혁신 클라우드 솔루션 설계자