Azure 서비스에 eShopOnContainers 매핑

필수는 아니지만 프로젝트가 클라우드 네이티브 애플리케이션으로 빌드되었기 때문에 Azure는 eShopOnContainers를 지원하는 데 적합합니다. 애플리케이션은 .NET을 사용하여 빌드되므로 Docker 호스트에 따라 Linux 또는 Windows 컨테이너에서 실행할 수 있습니다. 애플리케이션은 각각 자체 데이터가 있는 여러 자율 마이크로 서비스로 구성됩니다. 다양한 마이크로 서비스는 간단한 CRUD 작업에서 더 복잡한 DDD 및 CQRS 패턴에 이르기까지 다양한 접근 방식을 보여 줍니다. 마이크로서비스는 HTTP를 통해 클라이언트와 통신하고, 메시지 기반 통신을 통해 서로 간에 소통합니다. 애플리케이션은 HTTP를 표준 통신 프로토콜로 채택하고 Android, iOS 및 Windows 플랫폼에서 실행되는 ASP.NET Core 및 Xamarin 모바일 앱을 포함하므로 클라이언트에 대한 여러 플랫폼을 지원합니다. (Xamarin은 2024년 5월 현재 지원되지 않습니다.)

애플리케이션의 아키텍처는 그림 2-5에 나와 있습니다. 왼쪽에는 모바일, 기존 웹 및 SPA(웹 단일 페이지 애플리케이션) 버전으로 구분된 클라이언트 앱이 있습니다. 오른쪽에는 시스템을 구성하는 서버 쪽 구성 요소가 있으며, 각 구성 요소는 Docker 컨테이너 및 Kubernetes 클러스터에서 호스트될 수 있습니다. 기존 웹앱은 노란색으로 표시된 ASP.NET Core MVC 애플리케이션에 의해 구동됩니다. 이 앱과 모바일 및 웹 SPA 애플리케이션은 하나 이상의 API 게이트웨이를 통해 개별 마이크로 서비스와 통신합니다. API 게이트웨이는 "프런트 엔드에 대한 백 엔드"(BFF) 패턴을 따릅니다. 즉, 각 게이트웨이는 지정된 프런트 엔드 클라이언트를 지원하도록 설계되었습니다. 개별 마이크로 서비스는 API 게이트웨이의 오른쪽에 나열되며 비즈니스 논리와 일종의 지속성 저장소를 모두 포함합니다. 다양한 서비스는 SQL Server 데이터베이스, Redis 캐시 인스턴스 및 MongoDB/CosmosDB 저장소를 사용합니다. 맨 오른쪽에는 마이크로 서비스 간의 통신에 사용되는 시스템의 Event Bus가 있습니다.

그림 2-5. eShopOnContainers 아키텍처입니다.

이 아키텍처의 서버 쪽 구성 요소는 모두 Azure 서비스에 쉽게 매핑됩니다.

컨테이너 오케스트레이션 및 클러스터링

ASP.NET Core MVC 앱에서 개별 카탈로그 및 주문 마이크로 서비스에 이르는 애플리케이션의 컨테이너 호스팅 서비스는 AKS(Azure Kubernetes Service)에서 호스트 및 관리할 수 있습니다. 애플리케이션은 Docker 및 Kubernetes에서 로컬로 실행할 수 있으며, 동일한 컨테이너를 AKS에서 호스트되는 스테이징 및 프로덕션 환경에 배포할 수 있습니다. 이 프로세스는 다음 섹션에서 볼 수 있듯이 자동화할 수 있습니다.

AKS는 컨테이너의 개별 클러스터에 대한 관리 서비스를 제공합니다. 애플리케이션은 위의 아키텍처 다이어그램에 표시된 것처럼 AKS 클러스터의 각 마이크로 서비스에 대해 별도의 컨테이너를 배포합니다. 이 방법을 사용하면 각 개별 서비스가 리소스 요구에 따라 독립적으로 확장할 수 있습니다. 각 마이크로 서비스는 독립적으로 배포할 수도 있으며, 이상적으로는 이러한 배포에 시스템 가동 중지 시간이 발생하지 않습니다.

API 게이트웨이

eShopOnContainers 애플리케이션에는 여러 프런트 엔드 클라이언트와 여러 개의 다른 백 엔드 서비스가 있습니다. 클라이언트 애플리케이션과 클라이언트 애플리케이션을 지원하는 마이크로 서비스 간에는 일대일 대응이 없습니다. 이러한 시나리오에서는 클라이언트 소프트웨어를 작성하여 다양한 백 엔드 서비스와 안전한 방식으로 인터페이스할 때 많은 복잡성이 있을 수 있습니다. 각 클라이언트는 이러한 복잡성을 자체적으로 해결해야 하므로 중복되고 서비스가 변경되거나 새 정책이 구현될 때 업데이트를 수행할 수 있는 많은 장소가 생성됩니다.

APIM(Azure API Management)을 사용하면 조직에서 일관되고 관리하기 쉬운 방식으로 API를 게시할 수 있습니다. APIM은 API 게이트웨이, 관리 포털(Azure Portal) 및 개발자 포털의 세 가지 구성 요소로 구성됩니다.

API 게이트웨이는 API 호출을 수락하고 적절한 백 엔드 API로 라우팅합니다. 또한 코드 수정 없이 API 키 확인 또는 JWT 토큰 및 API 변환과 같은 추가 서비스를 즉시 제공할 수 있습니다(예: 이전 인터페이스를 기대하는 클라이언트를 수용하기 위해).

Azure Portal에서는 API 스키마를 정의하고 다양한 API를 제품에 패키지합니다. 또한 사용자 액세스를 구성하고, 보고서를 보고, 할당량 또는 변환에 대한 정책을 구성합니다.

개발자 포털은 개발자를 위한 기본 리소스 역할을 합니다. 개발자에게 API 설명서, 대화형 테스트 콘솔 및 자체 사용량에 대한 보고서를 제공합니다. 또한 개발자는 포털을 사용하여 구독 및 API 키 지원을 포함하여 자체 계정을 만들고 관리합니다.

APIM을 사용하여 애플리케이션은 각각 특정 프런트 엔드 클라이언트에 대한 백 엔드를 제공하는 여러 서비스 그룹을 노출할 수 있습니다. 복잡한 시나리오에는 APIM을 사용하는 것이 좋습니다. 더 간단한 요구 사항을 위해 간단한 API 게이트웨이 Ocelot을 사용할 수 있습니다. eShopOnContainers 앱은 단순성 때문에 Ocelot을 사용하고 애플리케이션 자체와 동일한 애플리케이션 환경에 배포할 수 있기 때문입니다. eShopOnContainers, APIM 및 Ocelot에 대해 자세히 알아봅니다.

애플리케이션이 AKS를 사용하는 경우, 또 다른 옵션으로 AKS 클러스터 내에서 Azure 게이트웨이 수신 컨트롤러를 Pod로 배포하는 것입니다. 이 방법을 사용하면 클러스터가 Azure Application Gateway와 통합되어 게이트웨이가 AKS Pod로 트래픽 부하를 분산할 수 있습니다. AKS용 Azure Gateway 인그레스 컨트롤러에 대해 자세히 알아보세요.

데이터

eShopOnContainers에서 사용하는 다양한 백 엔드 서비스에는 다른 스토리지 요구 사항이 있습니다. 여러 마이크로 서비스에서 SQL Server 데이터베이스를 사용합니다. Basket 마이크로 서비스는 지속성을 위해 Redis 캐시를 활용합니다. 위치 마이크로 서비스는 데이터에 대한 MongoDB API를 예상합니다. Azure는 이러한 각 데이터 형식을 지원합니다.

SQL Server 데이터베이스 지원을 위해 Azure에는 단일 데이터베이스부터 확장성이 뛰어난 SQL Database 탄력적 풀에 이르는 모든 항목에 대한 제품이 있습니다. 개별 마이크로 서비스는 고유한 개별 SQL Server 데이터베이스와 빠르고 쉽게 통신하도록 구성할 수 있습니다. 이러한 데이터베이스는 필요에 따라 각 개별 마이크로 서비스를 지원하기 위해 필요에 따라 크기를 조정할 수 있습니다.

eShopOnContainers 애플리케이션은 요청 사이에 사용자의 현재 장바구니를 저장합니다. 이 측면은 Redis 캐시에 데이터를 저장하는 Basket 마이크로 서비스에서 관리됩니다. 개발 중에는 이 캐시를 컨테이너에 배포할 수 있지만 프로덕션 환경에서는 Azure Cache for Redis를 활용할 수 있습니다. Azure Cache for Redis는 Redis 인스턴스 또는 컨테이너를 직접 배포하고 관리할 필요 없이 고성능 및 안정성을 제공하는 완전 관리형 서비스입니다.

위치 마이크로 서비스는 지속성을 위해 MongoDB NoSQL 데이터베이스를 사용합니다. 개발 중에 데이터베이스를 자체 컨테이너에 배포할 수 있지만 프로덕션 환경에서는 서비스가 Azure Cosmos DB의 MongoDB API를 활용할 수 있습니다. Azure Cosmos DB의 이점 중 하나는 SQL API 및 MongoDB, Cassandra, Gremlin 및 Azure Table Storage를 비롯한 일반적인 NoSQL API를 비롯한 여러 통신 프로토콜을 활용하는 기능입니다. Azure Cosmos DB는 완전히 관리되고 전역적으로 분산된 데이터베이스를 서비스로 제공하여 이를 사용하는 서비스의 요구 사항을 충족하도록 확장할 수 있습니다.

클라우드 네이티브 애플리케이션의 분산 데이터는 5장에서 자세히 설명합니다.

이벤트 버스

애플리케이션은 이벤트를 사용하여 서로 다른 서비스 간의 변경 내용을 전달합니다. 이 기능은 다양한 구현으로 구현할 수 있으며, 로컬에서 eShopOnContainers 애플리케이션은 RabbitMQ를 사용합니다. Azure에서 호스팅되는 경우 애플리케이션은 메시징에 Azure Service Bus 를 활용합니다. Azure Service Bus는 애플리케이션과 서비스가 분리되고 신뢰할 수 있는 비동기 방식으로 서로 통신할 수 있도록 하는 완전 관리형 통합 메시지 브로커입니다. Azure Service Bus는 개별 큐와 별도의 항목을 지원하여 게시자-구독자 시나리오를 지원합니다. eShopOnContainers 애플리케이션은 Azure Service Bus와 함께 토픽을 활용하여 한 마이크로 서비스에서 지정된 메시지에 대응하는 데 필요한 다른 마이크로 서비스로 메시지를 배포할 수 있도록 지원합니다.

탄력성

프로덕션 환경에 배포된 eShopOnContainers 애플리케이션은 복원력을 향상시키기 위해 사용할 수 있는 여러 Azure 서비스를 활용할 수 있습니다. 애플리케이션은 앱의 가용성에 따라 보고 및 경고를 제공하기 위해 Application Insights와 통합할 수 있는 상태 검사를 게시합니다. 또한 Azure 리소스는 버그 및 성능 문제를 식별하고 수정하는 데 사용할 수 있는 진단 로그를 제공합니다. 리소스 로그는 애플리케이션에서 다른 Azure 리소스를 사용하는 시기와 방법에 대한 자세한 정보를 제공합니다. 6장에서 클라우드 네이티브 복원력 기능에 대해 자세히 알아봅니다.