Azure Container Apps에 마이크로 서비스 배포

이 시나리오는 원래 Kubernetes용으로 설계된 기존 워크로드를 보여 하며, 이 워크로드는 Azure Container Apps에서 실행되도록 다시 배치됩니다. Container Apps는 팀이 인프라 및 컨테이너 오케스트레이션을 간소화하려는 브라운필드 워크로드를 지원합니다.

워크로드 예제는 컨테이너화된 마이크로 서비스 애플리케이션입니다. AKS(Azure Kubernetes Service)의 마이크로 서비스 아키텍처에 정의된 것과 동일한 워크로드를 다시 사용합니다. 이 아키텍처는 Container Apps의 워크로드를 애플리케이션 플랫폼으로 다시 호스트합니다.

아키텍처

이 아키텍처의 Visio 파일을 다운로드합니다.

동일한 환경을 공유하는 서비스는 다음과 같은 방법으로 이점을 누릴 수 있습니다.

• 내부 수신 및 서비스 검색
• 런타임 로깅을 위한 단일 Log Analytics 작업 영역
• 비밀 및 인증서에 대한 보안 관리 방법

데이터 흐름

1. 수집 서비스: 클라이언트 요청을 수신하고 버퍼링한 다음 Azure Service Bus에 게시합니다. 워크로드로의 유일한 진입점입니다.

2. 워크플로 서비스: Service Bus의 메시지를 수신하여 관련 마이크로서비스로 디스패치합니다.

3. 패키지 서비스: 패키지를 관리합니다. 서비스는 Azure Cosmos DB에서 자체 상태를 유지 관리합니다.

4. 드론 스케줄러 서비스: 드론을 예약하고 이동 중인 드론을 모니터링합니다. 서비스는 Azure Cosmos DB에서 자체 상태를 유지 관리합니다.

5. 배달 서비스: 예약된 배달 또는 전송 중인 배달을 관리합니다. 서비스는 Azure Managed Redis에서 자체 상태를 유지 관리합니다.

6. 비밀 검색: 기존 워크로드이므로 일부 구성 요소만 Azure Key Vault에 액세스하여 런타임 비밀을 가져옵니다. 다른 서비스는 Container Apps 환경에서 이러한 비밀을 받습니다.

7. 로그 및 메트릭: 환경 및 모든 컨테이너 앱은 Azure Monitor에서 제공하는 로그 및 메트릭을 내보낸 다음 수집 및 시각화합니다.

8. 컨테이너 이미지: 컨테이너 이미지는 이전에 AKS에 사용되어 Container Apps 환경에 배포된 기존 Azure Container Registry에서 가져옵니다.

구성 요소

워크로드는 다음과 같은 Azure 서비스를 서로 조정하여 사용합니다.

• Container Apps 는 컨테이너 오케스트레이션 및 관리를 간소화하는 서버리스 컨테이너 플랫폼입니다. 이 아키텍처에서 Container Apps는 모든 마이크로 서비스에 대한 기본 호스팅 플랫폼 역할을 합니다.

  다음 기능은 이전 AKS 아키텍처의 많은 기능을 대체합니다.

  • 기본 제공 서비스 검색
  • 관리형 HTTP 및 HTTP/2 엔드포인트
  • 통합 부하 분산
  • 로깅 및 모니터링
  • KUbernetes 기반 KEDA(Event Driven Autoscaling)에서 제공하는 HTTP 트래픽 또는 이벤트를 기반으로 자동 크기 조정
  • 애플리케이션 업그레이드 및 버전 관리

• Container Registry 는 프라이빗 컨테이너 이미지를 저장하고 관리하기 위한 관리되는 레지스트리 서비스입니다. 이 아키텍처에서는 Container Apps 환경에 배포되는 모든 컨테이너 이미지의 원본입니다. 레지스트리는 AKS 구현에 사용되는 레지스트리와 동일합니다.

• Azure Cosmos DB 는 전역적으로 분산된 다중 모델 데이터베이스 서비스입니다. 이 아키텍처에서 드론 스케줄러 서비스는 Azure Cosmos DB를 데이터 저장소로 사용합니다.

• Azure DocumentDB 는 최신 애플리케이션을 빌드하기 위한 완전히 관리되는 MongoDB 호환 데이터베이스 서비스입니다. 이 아키텍처에서 패키지 서비스는 Azure DocumentDB를 데이터 저장소로 사용합니다.

• Service Bus 는 비동기 통신 기능 및 하이브리드 통합을 제공하는 클라우드 메시징 서비스입니다. 이 아키텍처에서는 수집 서비스와 작업 기반 워크플로 마이크로 서비스 간의 비동기 메시징을 처리합니다. 기존 애플리케이션의 나머지 서비스는 다른 서비스가 HTTP 요청으로 호출할 수 있도록 설계되었습니다.

• Azure Managed Redis 는 메모리 내 캐싱 서비스입니다. 이 아키텍처에서는 대기 시간을 줄이고 자주 액세스하는 드론 배달 데이터에 대한 처리량을 향상시킵니다.

• Key Vault 는 API 키, 암호 및 인증서와 같은 비밀을 안전하게 저장하고 액세스하기 위한 클라우드 서비스입니다. 이 아키텍처에서 드론 스케줄러 및 배달 서비스는 사용자 할당 관리 ID를 사용하여 Key Vault로 인증하고 런타임 요구 사항에 필요한 비밀을 검색합니다.

• Azure Monitor 는 원격 분석 데이터를 수집하고 분석하는 포괄적인 모니터링 솔루션입니다. 이 아키텍처에서는 Log Analytics 작업 영역을 통해 모든 애플리케이션 구성 요소에서 메트릭과 로그를 수집하고 저장합니다. 이 데이터를 사용하여 애플리케이션을 모니터링하고, 경고 및 대시보드를 설정하고, 오류의 근본 원인 분석을 수행합니다.

  • Application Insights 는 확장 가능한 모니터링 기능을 제공하는 애플리케이션 성능 관리 서비스입니다. 이 아키텍처에서 각 서비스는 Application Insights SDK를 사용하여 계측되어 애플리케이션 성능을 모니터링합니다.

대안

고급 AKS 마이크로 서비스 아키텍처는 Kubernetes를 사용하는 이 예제의 대체 시나리오를 설명합니다.

시나리오 정보

컨테이너화된 애플리케이션을 호스팅하기 위한 서버리스 환경인 Container Apps를 사용하여 마이크로 서비스 컨테이너의 배포 및 관리를 간소화할 수 있습니다.

가상의 회사인 Fabrikam, Inc.는 사용자가 배송을 위해 상품을 수령하기 위해 드론을 요청하는 드론 배달 워크로드를 구현합니다. 고객이 픽업을 예약할 때 백 엔드 시스템은 드론을 할당하고 예상 픽업 시간을 사용자에게 알깁니다.

마이크로 서비스 애플리케이션이 AKS 클러스터에 배포되었습니다. 그러나 Fabrikam 팀은 고급 또는 플랫폼별 AKS 기능을 활용하지 않았습니다. 애플리케이션을 Container Apps로 마이그레이션하여 다음 작업을 수행할 수 있도록 했습니다.

• 애플리케이션을 AKS에서 Container Apps로 이동할 때 최소한의 코드 변경을 사용합니다. 코드 변경은 Kubernetes 노드 정보를 사용하여 로그 및 메트릭을 보강하는 관찰 라이브러리와 관련이 있으며, 이는 새 환경에서는 관련이 없습니다.

• Bicep 템플릿을 사용하여 인프라와 워크로드를 모두 배포합니다. 애플리케이션 컨테이너를 배포하는 데 Kubernetes YAML 매니페스트가 필요하지 않았습니다.

• 관리되는 인그레스를 통해 애플리케이션을 노출합니다. 외부 HTTPS 기반 수신에 대한 기본 제공 지원으로 인해 수집 서비스를 노출하고 자체 수신을 구성할 필요가 없어졌습니다.

• Container Registry에서 컨테이너 이미지를 끌어오기. Container Apps는 사용 가능한 리포지토리에 저장된 모든 Linux 기본 이미지와 호환됩니다.

• 수정 기능을 사용하여 애플리케이션 수명 주기 요구 사항을 지원합니다. 특정 컨테이너 앱의 여러 수정 버전을 실행하고 A/B 테스트 또는 파란색/녹색 배포 시나리오에 대해 트래픽을 분할할 수 있습니다.

• 관리 ID를 사용하여 Key Vault 및 Container Registry로 인증합니다.

잠재적인 사용 사례

관리를 간소화하고 컨테이너 오케스트레이터 실행의 복잡성을 방지하기 위해 PaaS(Platform as a Service)에 브라운필드 마이크로 서비스 기반 애플리케이션을 배포합니다. 브라운필드 워크로드는 다음과 같은 이유로 Kubernetes 배포를 통해 이 아키텍처를 사용하여 비용을 절감했습니다.

• 워크로드 프로필 선택
• 운영 팀의 2일차 운영 작업에 소요되는 시간 감소
• 프로비저닝을 과도하게 방지할 수 있는 기능

Container Apps의 다른 일반적인 용도를 고려합니다.

• 서버리스 소비 기반 플랫폼에서 컨테이너화된 워크로드를 실행합니다.
• HTTP 또는 HTTPS 트래픽 및 KEDA에서 지원하는 이벤트 기반 트리거를 기반으로 애플리케이션을 자동 크기 조정합니다.
• 컨테이너화된 애플리케이션에 대한 유지 관리 오버헤드를 최소화합니다.
• API 엔드포인트를 배포합니다.
• 백그라운드 처리 애플리케이션을 호스트합니다.
• 이벤트 기반 처리를 처리합니다.

Optimizations

워크로드 팀의 목표는 최소한의 코드 변경으로 기존 워크로드를 Container Apps로 마이그레이션하는 것입니다. 그러나 마이그레이션 후 아키텍처 및 워크로드 구현을 개선하기 위해 몇 가지 최적화를 수행해야 합니다.

비밀 관리 개선

워크로드는 하이브리드 접근 방식을 사용하여 비밀을 관리합니다. 관리 ID는 관리 ID로 전환할 때 코드를 수정할 필요가 없는 서비스에만 적용됩니다. 드론 스케줄러 및 배달 서비스는 Key Vault와 함께 사용자 할당 관리 ID를 사용하여 저장된 비밀에 액세스합니다. 나머지 서비스는 관리 ID를 채택하기 위해 코드 변경이 필요하므로 해당 서비스는 Container Apps 환경에서 제공하는 비밀을 사용합니다.

더 나은 방법은 환경 제공 비밀 대신 앱 또는 작업 ID를 사용하여 관리 ID를 지원하도록 모든 코드를 업데이트하는 것입니다. 워크로드 ID에 대한 자세한 내용은 Container Apps의 관리 ID를 참조하세요.

단일 수정 모드가 필요한 디자인 방지

워크플로 서비스 컨테이너 앱은 단일 수정 모드에서 실행됩니다. 단일 수정 모드에서 앱에는 0개 이상의 복제본으로 지원되는 하나의 수정 버전이 있습니다. 복제본은 애플리케이션 컨테이너 및 필수 사이드카로 구성됩니다. 이 예제에서는 사이드카를 사용하지 않으므로 각 복제본은 단일 컨테이너입니다. 워크플로 서비스는 메시지 스키마와의 앞으로 호환성을 위해 설계되지 않았습니다. 서로 다른 두 버전의 서비스는 동시에 실행되어서는 안 됩니다.

Service Bus 메시지 스키마를 변경해야 하는 경우 새 워크플로 서비스 버전을 배포하기 전에 버스를 드레이닝해야 합니다. 더 나은 방법은 정방향 호환성을 위해 서비스 코드를 업데이트하고 다중 수정 모드를 사용하여 드레이닝 큐와 관련된 가동 중지 시간을 줄이는 것입니다.

작업 기반 작업 고려

워크플로 서비스는 장기 실행 컨테이너 앱으로 구현됩니다. 그러나 Container Apps에서 작업으로 실행할 수도 있습니다. 작업은 주문형으로 시작하여 사용 가능한 작업에 따라 완료까지 실행한 다음, 종료하고 리소스를 해제하는 컨테이너화된 애플리케이션입니다. 지속적으로 실행되는 복제본보다 작업이 더 경제적일 수 있습니다. 큐에서 사용할 수 있는 작업에 따라 Container Apps 작업으로 실행되도록 서비스를 마이그레이션하는 것이 실용적인 옵션일 수 있습니다. 일반적인 큐 볼륨과 워크플로 서비스를 얼마나 유한하고 병렬화할 수 있으며 리소스를 최적화했는지에 따라 달라집니다. 최상의 방법을 실험하고 확인합니다.

인그레스 제어 구현

워크로드는 컨테이너 앱의 기본 제공 외부 인그레스 기능을 사용하여 인제션 서비스를 노출합니다. 수신 제어 방법은 수신 지점을 WAF(웹 애플리케이션 방화벽) 뒤에 완전히 배치하거나 Azure DDoS Protection 계획에 포함할 수 있는 기능을 제공하지 않습니다. WAF를 사용하여 모든 웹 연결 워크로드를 전면에 배치해야 합니다. Container Apps 환경에서 이 구성을 수행하려면 기본 제공 공용 수신을 사용하지 않도록 설정하고 Application Gateway 또는 Azure Front Door를 추가해야 합니다.

Dapr을 사용하여 현대화

Dapr(분산 애플리케이션 런타임)과 통합하여 워크로드를 더욱 현대화할 수 있습니다. 워크로드 코드와 상태 저장소, 메시징 시스템 및 서비스 검색 메커니즘 간에 추상화가 추가됩니다. 자세한 내용은 Container Apps 및 Dapr을 사용하여 마이크로 서비스 배포를 참조하세요. Kubernetes의 워크로드에서 이미 Dapr 또는 일반 KEDA 스칼라를 사용하는 경우 Container Apps로 마이그레이션하는 것은 종종 직선이며 해당 기능을 유지할 수 있습니다.

사용자 인증 및 권한 부여로 마이그레이션

워크로드는 게이트웨이에 권한 부여를 위임하지 않습니다. 수집 서비스는 클라이언트의 권한 부여를 처리합니다. 더 나은 방법은 이 책임을 간편한 인증이라고도 하는 기본 제공 인증 및 권한 부여 기능으로 오프로드하는 것입니다. 이 변경은 플랫폼 기능을 활용하고 수집 마이크로 서비스의 사용자 지정 코드를 줄입니다.

고려 사항

다음 고려 사항은 워크로드의 품질을 개선하는 데 사용할 수 있는 지침 원칙 집합인 Microsoft Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Azure Well-Architected Framework를 참조하세요.

안정성

안정성은 애플리케이션이 고객에 대한 약정을 충족할 수 있도록 하는 데 도움이 됩니다. 자세한 내용은 안정성대한 디자인 검토 검사 목록을 참조하세요.

Container Apps를 사용하면 워크로드에서 애플리케이션을 배포, 관리, 유지 관리 및 모니터링할 수 있습니다. 핵심 권장 사항에 따라 안정성을 향상시킬 수 있습니다. 일부 권장 사항은 Kubernetes에서 마이그레이션하는 동안 구현됩니다.

• 수정 버전을 사용하면 가동 중지 시간이 0인 애플리케이션 업데이트를 배포할 수 있습니다. 수정 버전을 사용하여 애플리케이션 업데이트 배포를 관리하고 수정 버전 간에 트래픽을 분할하여 파란색/녹색 배포 및 A/B 테스트를 지원할 수 있습니다.

• Container Apps 관찰 기능을 사용하면 환경 내에서 실행되는 구성 요소에 대한 인사이트를 얻을 수 있습니다. Container Apps는 Application Insights 및 Log Analytics와 통합됩니다. 이 데이터를 사용하여 작업을 추적하고 관찰 가능성 시스템의 일부로 메트릭 및 이벤트를 기반으로 경고를 설정합니다.

  성능 모니터링은 부하 중인 애플리케이션을 평가하는 데 도움이 됩니다. 메트릭 및 로그는 추세를 인식하고, 오류를 조사하고, 근본 원인 분석을 수행하는 데이터를 제공합니다.

• 상태 및 준비 상태 프로브를 사용하여 느린 시작 컨테이너를 처리하고 준비가 되기 전에 트래픽을 보내지 않도록 합니다. Kubernetes 구현에는 이러한 엔드포인트가 포함됩니다. 효과적인 신호를 제공하는 경우 계속 사용합니다.

• 서비스가 예기치 않게 종료되면 Container Apps가 자동으로 다시 시작됩니다. 워크플로 서비스가 다운스트림 마이크로 서비스를 검색할 수 있도록 서비스 검색을 사용하도록 설정합니다. 복원력 정책을 사용하여 시간 제한을 처리하고 코드를 추가로 조정할 필요 없이 회로 차단기 논리를 도입합니다.

• 트래픽 및 워크로드가 증가함에 따라 수요를 충족하도록 자동 크기 조정 규칙을 사용하도록 설정합니다.

• Container Apps의 동적 부하 분산 및 크기 조정 기능을 사용하여 가용성을 향상시킵니다. 환경의 서브넷을 과도하게 프로비전하여 향후 복제본 또는 작업에 사용할 수 있는 IP 주소가 항상 충분합니다.

• 복제본이 종료되면 모든 상태가 손실되므로 Container Apps 환경 내에서 직접 상태를 저장하지 마세요. 각 마이크로 서비스에 대한 전용 상태 저장소로 상태를 외부화합니다. 이 아키텍처는 Azure Managed Redis, NoSQL용 Azure Cosmos DB 및 Azure DocumentDB의 세 가지 개별 저장소에 상태를 분산합니다.

• 다중 영역 토폴로지로를 사용하여 Container Apps를 포함한 모든 리소스를 배포합니다. 자세한 내용은 Container Apps의 가용성 영역 지원을 참조하세요.

  비전송 애플리케이션의 최소 복제본 수를 각 가용성 영역에 대해 하나 이상의 복제본으로 설정합니다. 일반적인 운영 조건에서 복제본은 지역의 가용성 영역에 걸쳐 신뢰성 있게 분산되고 균형을 이룹니다.

보안

보안은 의도적인 공격 및 중요한 데이터 및 시스템의 오용에 대한 보증을 제공합니다. 자세한 내용은 보안대한 디자인 검토 검사 목록을 참조하세요.

비밀

• 컨테이너 앱은 중요한 값을 비밀로 저장하고 검색할 수 있습니다. 컨테이너 앱에 대한 비밀을 정의한 후에는 애플리케이션 및 연결된 크기 조정 규칙에서 사용할 수 있습니다. 다중 수정 모드에서 실행하는 경우 모든 수정 버전이 동일한 비밀을 공유합니다. 비밀은 애플리케이션 범위 변경으로 간주되므로 비밀 값을 변경하는 경우 새 수정 버전이 만들어지지 않습니다. 그러나 새 비밀 값을 로드하려면 실행 중인 수정 버전을 다시 시작해야 합니다. 이 시나리오에서는 애플리케이션 및 환경 변수 값이 사용됩니다.

• 사전 공유된 비밀 대신 앱의 자체 관리 ID를 사용하여 종속성을 인증하도록 서비스 코드를 다시 작성합니다. 모든 종속성에는 관리 ID 인증을 지원하는 SDK가 있습니다.

• 애플리케이션 수준에서 환경 변수에 중요한 값을 안전하게 저장할 수 있습니다. 환경 변수가 변경되면 컨테이너 앱은 새 수정 버전을 만듭니다.

네트워크 보안

• 외부 액세스를 제한하기 위해 수집 서비스만 외부 수신에 대해 구성됩니다. 백 엔드 서비스는 Container Apps 환경의 내부 가상 네트워크를 통해서만 액세스할 수 있으며 내부 모드로 구성됩니다. 필요한 경우 인터넷에만 서비스를 노출합니다.

  이 아키텍처는 기본 제공 외부 수신 기능을 사용하므로 이 솔루션은 수신 지점을 WAF 뒤에 완전히 배치하거나 DDoS Protection 계획에 포함할 수 있는 기능을 제공하지 않습니다. 웹 애플리케이션 방화벽을 사용하여 모든 웹 연결 워크로드를 전면에 배치합니다. 인그레스 개선에 대한 자세한 내용은 인그레스 제어 구현을 확인하세요.

• 환경을 만들 때 사용자 지정 가상 네트워크를 제공할 수 있습니다. 그렇지 않으면 Microsoft는 가상 네트워크를 자동으로 생성하고 관리합니다. NSG(네트워크 보안 그룹)를 추가하거나 송신 방화벽에 트래픽을 강제로 터널링하는 등 Microsoft에서 관리하는 가상 네트워크를 조작할 수 없습니다. 이 예제에서는 자동으로 생성된 가상 네트워크를 사용하지만 사용자 지정 가상 네트워크는 보안 제어를 향상시킵니다. 사용자 지정 네트워크를 사용하면 Azure Firewall을 통해 NSG 및 UDR(사용자 정의 경로) 기반 라우팅을 적용할 수 있습니다.

네트워크 토폴로지 옵션에 대한 자세한 정보와 인그레스에 대한 프라이빗 엔드포인트 지원을 포함한 내용은 Container Apps의 네트워킹 아키텍처를 참조하십시오.

워크로드 ID

• Container Apps는 앱이 컨테이너 앱에서 자격 증명을 관리하지 않고도 Key Vault와 같은 Microsoft Entra ID로 보호되는 다른 리소스에 인증할 수 있도록 하는 Microsoft Entra 관리 ID를 지원합니다. 컨테이너 앱은 시스템 할당 ID, 사용자 할당 ID 또는 둘 다를 사용할 수 있습니다. Microsoft Entra ID 인증을 지원하지 않는 서비스의 경우 Key Vault에 비밀을 저장하고 관리 ID를 사용하여 비밀에 액세스합니다.

• Container Registry 액세스에 대해 하나의 전용 사용자 할당 관리 ID를 사용합니다. Container Apps는 컨테이너 레지스트리 액세스와는 다른 관리 ID를 워크로드 작업에 사용할 수 있도록 지원합니다. 이 방법은 세분화된 액세스 제어를 제공합니다. 워크로드에 여러 Container Apps 환경이 있는 경우 인스턴스 간에 ID를 공유하지 마세요.

• 워크로드 ID에 시스템 할당 관리 ID를 사용하여 ID 수명 주기를 워크로드 구성 요소 수명 주기에 연결합니다.

추가 보안 권장 사항

• 이 워크로드의 Kubernetes 구현은 컨테이너용 Microsoft Defender 기능을 사용하여 보호를 제공합니다. 이 아키텍처에서 Defender for Containers는 Container Registry에 있는 컨테이너의 취약성만 평가 합니다. Defender for Containers는 Container Apps에 대한 런타임 보호를 제공하지 않습니다. 런타임 보호가 요구 사항인 경우 타사 보안 솔루션으로 보완을 평가합니다.

• 공유 Container Apps 환경에서 워크로드를 실행하지 마세요. 이러한 마이크로 서비스에 액세스할 필요가 없는 다른 워크로드 또는 구성 요소에서 분할합니다. 별도의 Container Apps 환경을 만듭니다. Container Apps 환경에서 실행되는 앱과 작업은 내부 인그레스가 설정된 환경에서 실행되는 모든 서비스를 검색하고 연결할 수 있습니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 개선하는 방법에 중점을 둡니다. 자세한 내용은 비용 최적화대한 디자인 검토 검사 목록을 참조하세요.

• 워크로드에 대한 예제 가격 추정치를 검토합니다. Azure 가격 계산기를 사용합니다. 구성은 다양하므로 시나리오에 맞게 조정합니다.

• 이 시나리오에서는 Azure Cosmos DB, Azure Managed Redis 및 Service Bus Premium이 주요 비용 동인입니다.

• 일반적으로 낮은 CPU 및 메모리 양을 사용하는 컨테이너의 경우 먼저 사용량 워크로드 프로필을 평가합니다. 사용량에 따라 사용량 프로필의 비용을 예측하여 기준 비용 데이터를 수집하고 다른 프로필을 평가하는 데 도움이 됩니다. 예를 들어 예측 가능하고 안정적인 사용량이 있고 전용 노드를 공유할 수 있는 구성 요소에 전용 워크로드 프로필을 사용할 수 있습니다. 비용 최적화를 위해 각 전용 프로필에 대해 3개의 노드 중 여러 노드를 유지 관리하여 가용성 영역 간에 충분한 컴퓨팅 호스트 및 복제본 배포를 보장합니다.

• 구성 요소가 0으로 확장될 수 있도록 하여 비활성 기간 동안 컴퓨팅 비용을 제거하여 필요한 경우에만 비용을 지불합니다. 이 방법은 가변적이거나 자주 사용하는 앱에 대한 비용을 줄입니다. 상태 검사는 일반적으로 전체 규모를 0으로 방지합니다. 아키텍처에서 유휴 기간 동안 0으로 스케일 조정을 활용할 수 있도록 워크플로 서비스를 작업으로 재구현할 수 있습니다. 이 방법은 사용 계획을 사용할 수 있는 워크로드와 잘 결합됩니다.

• 지역 간 네트워크 요금을 방지하려면 상태 저장소 및 컨테이너 레지스트리와 같은 모든 구성 요소를 동일한 지역에 배포합니다.

운영 우수성

운영 우수성은 애플리케이션을 배포하고 프로덕션 환경에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성대한 디자인 검토 검사 목록을 참조하세요.

• GitHub Actions 또는 Azure Pipelines 통합을 사용하여 자동화된 CI/CD(연속 통합 및 지속적인 배포) 파이프라인을 설정합니다.

• 트래픽 분할과 함께 다중 수정 모드를 사용하여 워크로드 코드 및 크기 조정 규칙의 변경 내용을 테스트합니다.

• Application Insights 및 Log Analytics와 통합하여 워크로드에 대한 인사이트를 제공합니다. 워크로드의 나머지 구성 요소와 동일한 Log Analytics 작업 영역을 사용하여 모든 워크로드 인사이트를 함께 유지합니다.

• Bicep 또는 Terraform과 같은 IaC(Infrastructure as Code)를 사용하여 모든 인프라 배포를 관리합니다. 배포에는 Container Apps 환경, 컨테이너 레지스트리 및 마이크로 서비스 상태 저장소가 포함됩니다. 마이크로 서비스 배포 파이프라인은 종종 유사한 수명 주기를 공유하지 않으므로 인프라 파이프라인과 분리합니다. Azure 인프라에 대한 선언적 파이프라인은 컨테이너 앱 리소스를 제외한 모든 리소스를 배포해야 합니다.

• 환경에서 컨테이너 앱을 만들고, 업데이트하고, 제거하는 데 명령적 접근 방식을 사용합니다. 수정 버전 간에 트래픽 이동 논리를 동적으로 조정하는 경우 특히 중요합니다. 배포 워크플로에서 GitHub 작업 또는 Azure Pipelines 작업을 사용합니다. 이 명령적 접근 방식은 YAML 앱 정의를 기반으로 할 수 있습니다. 상태 검사 실패를 최소화하려면 컨테이너 앱을 배포하기 전에 항상 파이프라인이 컨테이너 레지스트리를 새 컨테이너 이미지로 채우는지 확인합니다.

  Kubernetes 구현에서의 중요한 변화는 Kubernetes 개체 정의를 포함한 Kubernetes 매니페스트 파일 관리를 중단하고 다른 방법으로 전환하는 것입니다. Kubernetes는 이 매니페스트 개체를 통해 마이크로서비스 배포에 대한 원자적 함께 성공 또는 함께 실패 접근 방식을 제공합니다. Container Apps에서 각 마이크로 서비스는 독립적으로 배포됩니다. 배포 파이프라인은 안전한 배포에 필요한 모든 시퀀싱 및 롤백 전략을 오케스트레이션하는 역할을 담당합니다.

성능 효율성

성능 효율성은 사용자 요구를 효율적으로 충족하기 위해 워크로드의 크기를 조정하는 기능을 의미합니다. 자세한 내용은 성능 효율성대한 디자인 검토 검사 목록을 참조하세요.

• 워크로드는 여러 마이크로 서비스 애플리케이션 간에 분산됩니다.

• 각 마이크로 서비스는 독립적이며 다른 마이크로 서비스와 상태를 공유하지 않으며, 이는 독립적인 크기 조정을 가능하게 합니다.

• 유한 프로세스 실행에 Container Apps 작업을 사용하여 일시적인 런타임을 구현하고 유휴 서비스에 대한 리소스 소비를 줄입니다. 작업을 시작하고 중지하는 것과 구성 요소를 항상 준비된 상태로 유지하는 것의 성능 영향을 평가합니다.

• 자동 크기 조정을 사용할 수 있습니다. 가능한 경우 메트릭 기반 크기 조정보다 이벤트 기반 크기 조정을 선호합니다. 예를 들어 워크플로 서비스를 지원하도록 설계된 경우 Service Bus 큐 깊이에 따라 확장할 수 있습니다. 기본 자동 크기 조정기는 HTTP 요청을 기반으로 합니다. 재플랫폼하는 동안 같은 확장 접근 방식으로 시작한 다음, 나중에 확장 최적화를 평가하는 것이 중요합니다.

• 요청은 수정 버전의 사용 가능한 복제본에 동적으로 부하가 분산됩니다.

• CPU, 메모리, 대역폭 정보 및 스토리지의 사용률을 포함한 메트릭은 Azure Monitor를 통해 사용할 수 있습니다.

시나리오 배포

Container Apps 예제 시나리오 리포지토리의 README.md 단계를 따릅니다.

참가자

Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.

참여자:

• Julien Strebler | 클라우드 솔루션 설계자
• Steve Caravajal | 클라우드 솔루션 설계자
• Simon Kurtz | 클라우드 솔루션 설계자

다음 단계

• Container Apps 설명서

관련 참고 자료

• 마이크로 서비스 아키텍처 스타일
• 마이크로 서비스 아키텍처 설계
• Azure Pipelines를 사용하여 AKS 앱용 CI/CD 파이프라인 빌드
• 고급 AKS 마이크로 서비스 아키텍처