Azure Container Apps

Azure Container Apps (ACA)는 Kubernetes와 KEDA(Kubernetes 이벤트 기반 자동 크기 조정)를 기반으로 구축된 완전 관리형 서버리스 컨테이너 호스팅 서비스입니다. AKS와 달리 제어 영역, 노드 풀 또는 Kubernetes 매니페스트를 직접 관리하지 않습니다. 대신 간단한 CLI 또는 YAML 정의를 사용하여 컨테이너를 배포하면 Azure가 모든 오케스트레이션을 처리합니다. ACA는 0까지 확장하는 기능을 포함하여 동적으로 확장해야 하는 마이크로서비스, API 백엔드, 이벤트 기반 작업자, 백그라운드 처리 작업에 적합합니다.

Container Apps 환경은 하나 이상의 Container Apps가 실행되는 격리된 경계입니다. 한 환경의 모든 앱은 동일한 가상 네트워크와 Log Analytics 작업 영역을 공유합니다. 환경은 지역과 리소스 그룹에 한정됩니다. 팀 또는 단계(프로덕션과 스테이징) 간 격리를 위해 여러 환경을 배포할 수 있습니다. 필요에 따라 환경을 자체 가상 네트워크에 VNet 주입하여 공용 인터넷을 거치지 않고 Container Apps와 다른 Azure 서비스 간의 비공개 통신을 허용할 수 있습니다.

Container App을 배포하려면 컨테이너 이미지(Azure Container Registry 또는 모든 공용 Registry에서 가져옴), 복제본 수, 환경 변수를 지정합니다. 외부 수신을 사용하도록 설정하면 자동으로 생성된 HTTPS URL을 통해 앱에 공개적으로 액세스할 수 있습니다. 수신 구성에는 대상 포트, 블루-그린 배포를 위한 트래픽 분할, HTTP만 허용할지 HTTPS만 허용할지가 포함됩니다. ACA는 배포 시 이미지를 가져오므로 환경에 Registry에 대한 가져오기 권한이 있어야 합니다.

Container Apps는 외부 메트릭을 기준으로 트리거되는 KEDA 스케일러를 사용하여 크기를 조정합니다. 기본 제공 KEDA 스케일러에는 HTTP 트래픽(복제본당 동시 요청 수), Azure Service Bus queue 깊이(대기 중인 메시지 수), Azure Storage Queue, Cron(시간 기반), CPU/Memory가 있습니다. 스케일러 메트릭이 0으로 떨어지고 minReplicas가 0으로 설정되면 Container Apps는 0으로 확장되어 새 요청이 도착할 때까지 컴퓨팅 비용이 발생하지 않습니다. 0으로 확장하는 기능은 작업량이 간헐적인 이벤트 기반 작업자에 매우 유용합니다.

Dapr(분산 애플리케이션 런타임)는 마이크로서비스 구축을 간소화하는 이식 가능한 이벤트 기반 런타임입니다. Container Apps는 기본 Dapr 통합을 제공하며 단일 플래그로 앱별로 사용하도록 설정할 수 있습니다. Dapr는 다음과 같은 구성 요소를 제공합니다. 서비스 호출(재시도 및 mTLS 포함), 게시/구독 메시징(Service Bus, Event Hubs 추상화), 상태 관리(Redis, Cosmos DB 추상화), 출력 바인딩입니다. Dapr를 사용하면 마이크로서비스가 기반 인프라의 세부 정보를 알 필요 없이 Dapr 사이드카를 통해 통신합니다.

Container App에 배포할 때마다 새 수정 버전이 생성됩니다. 다중 수정 버전 모드에서는 블루-그린 또는 카나리 배포를 위해 수정 버전 간에 트래픽을 분할할 수 있습니다. 예를 들어 새 수정 버전에 트래픽의 10%를 보내고 현재 안정적인 수정 버전에 90%를 보낼 수 있습니다. 새 수정 버전의 오류율과 지연 시간을 모니터링한 후 트래픽 비중을 100%로 늘리세요. 이전 수정 버전은 비활성화할 수 있지만 기록에 보존되므로 트래픽 비중을 다시 이동하여 즉시 롤백할 수 있습니다.

Container Apps는 구성을 주입하는 두 가지 방법을 지원합니다. 환경 변수(기능 플래그나 API URL과 같은 민감하지 않은 구성용)와 보안 값(연결 문자열과 같은 민감한 값용)입니다. 보안 값은 Container App 수준에 저장되며 환경 변수 또는 Dapr 구성 요소에서 참조합니다. 가장 안전하게 설정하려면 관리 ID를 사용하여 Azure Key Vault의 보안 값을 참조하세요. 이렇게 하면 런타임에 보안 값이 가져와지고 Container App의 구성 영역에는 저장되지 않습니다.

Container Apps Jobs는 플랫폼을 확장하여 실행 후 종료되는 워크로드를 지원합니다. 즉, 컨테이너가 시작되어 작업을 수행한 다음 종료됩니다. 작업은 세 가지 트리거 유형을 지원합니다. 수동(API 또는 CLI를 통해 트리거), 예약(크론 표현식), 이벤트 기반(KEDA 스케일러가 각 실행을 트리거)입니다. 작업에는 실제 실행 시간에 대해서만 요금이 부과되며, 주기적으로 또는 이벤트에 응답하여 실행되는 일괄 처리, 보고서 생성, 데이터베이스 마이그레이션, 기계 학습 추론 pipeline에 적합합니다.

Container Apps는 환경에 연결된 Log Analytics 작업 영역으로 시스템 로그(리비전 생성 및 크기 조정과 같은 플랫폼 이벤트)와 콘솔 로그(애플리케이션의 stdout/stderr)를 보냅니다. KQL로 로그를 Query할 수 있습니다: ContainerAppConsoleLogs_CL | where ContainerAppName_s == 'myapi' | project TimeGenerated, Log_s. 기본 제공되는 애저 모니터 메트릭에는 복제본 수, 요청 수, 요청 지연 시간, 복제본별 CPU/메모리 사용률이 포함되며, 추가 구성 없이 애저 포털에서 모두 사용할 수 있습니다.

적절한 애저 컨테이너 플랫폼을 선택할 때는 다음을 고려합니다. Container Apps는 클러스터를 관리하지 않고도 Kubernetes의 이점을 활용하려는 마이크로서비스, 이벤트 기반 작업자, API에 적합하며, 특히 0까지의 자동 축소가 중요한 경우에 유용합니다. AKS는 Kubernetes를 완전히 제어하거나, 사용자 지정 운영자 또는 특정 노드 구성(GPU, 대용량 메모리)이 필요할 때 적합합니다. App Service는 컨테이너 관리 오버헤드 없이 개발 팀이 간단한 PaaS 모델을 선호하는 전통적인 웹 애플리케이션과 API에 적합합니다. 세 서비스 모두 컨테이너를 지원하며, 차이는 관리 복잡도와 제어 수준에 있습니다.

Container Apps는 두 가지 수신 모드를 지원합니다. 외부 모드는 자동 TLS가 적용된 부하 분산 HTTPS 엔드포인트를 통해 인터넷에서 접근할 수 있으며, 내부 모드는 동일한 Container Apps 환경 내부 또는 VNet 피어링 리소스에서만 접근할 수 있습니다. 내부 수신은 인터넷에 절대 노출해서는 안 되는 백엔드 서비스에 사용됩니다. 동일한 환경의 앱은 자동으로 생성된 내부 DNS 이름 http://myapi을 사용하여 서로를 호출할 수 있으므로, API 게이트웨이를 배포하지 않고도 간단하게 서비스 간 통신을 구현할 수 있습니다.

이 단원에서 다룬 Microsoft 애저 기초(AZ-900) 개념에 대한 이해도를 확인해 보세요.

이 단원에서는 다음을 배웠습니다. 애저 Container Apps는 클러스터 관리 없이 Kubernetes와 KEDA를 기반으로 서버리스 컨테이너 호스팅을 제공하며, KEDA 스케일러는 큐 깊이, HTTP 트래픽 또는 크론 일정에 따라 0까지의 자동 축소를 지원합니다. 또한 Dapr 통합은 마이크로서비스 간 통신과 상태 관리를 간소화합니다. 다음 단원에서는 모든 요소를 완전한 엔드투엔드 개발자 워크플로로 연결합니다.