Azure Container Apps로 클라우드 네이티브 앱 배포하기 — 관리 ID 인증부터 리비전 롤백까지

본문

Azure Container Apps는 특정한 간극을 메우는 서비스라고 글은 설명합니다. AKS보다 관리되는 영역이 넓어 패치할 노드도 운영할 클러스터도 없지만, Kubernetes 사용자에게 익숙한 동일한 프리미티브 — 이벤트 기반 오토스케일링을 위한 KEDA, 서비스 간 패턴을 위한 Dapr, 그리고 어디에나 배포 가능한 동일한 컨테이너 이미지 — 위에 구축되어 있습니다. Kubernetes식 스케일링 동작을 원하면서 컨트롤 플레인을 직접 운영하고 싶지 않을 때 적합한 대상입니다.

사전에 알아둘 세 가지 개념

Container Apps Environment는 여러 컨테이너 앱이 공유하는 경계로, 네트워킹·로깅·(선택적으로) Dapr 구성을 함께 가집니다. 같은 환경의 앱은 이름으로 서로 통신할 수 있고, 다른 환경의 앱은 기본적으로 네트워크 격리됩니다. Kubernetes 네임스페이스와 공유 네트워킹에 대응하지만 그 아래 클러스터를 운영할 필요가 없다는 차이가 있습니다. Revision은 배포마다 생성되는 불변의 배포 단위입니다. 단일 리비전 모드에서는 트래픽이 최신 리비전으로 완전히 전환되고, 다중 리비전 모드에서는 여러 리비전이 동시에 실행되며 트래픽을 나눠 받습니다 — 재배포 없이 카나리 롤아웃과 즉시 롤백이 가능한 이유입니다. Scale rule은 KEDA 기반으로, 레플리카 수를 결정하기 위해 평가하는 조건입니다. HTTP 규칙은 동시 요청 수를, 큐 기반 규칙은 대기 중인 메시지 수를 세어, CPU 같은 대리 지표가 아닌 실제 수요를 반영하는 신호로 스케일링한다는 원칙을 따릅니다.

비밀번호 없는 ACR 인증

az acr create 시 --admin-enabled false는 의도적인 선택입니다. 관리자 계정은 레지스트리 전체에 공유되는 단일 장기 자격 증명이므로, 대신 컨테이너 앱에 시스템 할당 관리 ID(system-assigned managed identity)를 부여하고 AcrPull 역할 하나만 해당 레지스트리 범위로 제한해 할당합니다. 결과적으로 이미지 풀만 가능하고, 로테이션하거나 유출될 자격 증명 자체가 존재하지 않습니다.

환경 생성과 앱 배포

az containerapp env create로 환경을 만든 뒤 az containerapp create로 앱을 배포합니다. --ingress external은 내장 로드 밸런서와 TLS 종단을 통해 앱을 인터넷에 노출하며, 같은 환경의 다른 앱만 접근해야 하는 백엔드에는 internal을 씁니다. 예시는 target-port 8080, cpu 0.5, memory 1.0Gi, min-replicas 1, max-replicas 10으로 설정합니다.

KEDA 기반 스케일 규칙

HTTP 규칙은 레플리카당 동시 요청 50건을 기준으로 스케일 아웃하도록 설정합니다. 큐 규칙은 azure-queue 타입으로 queueLength=5, queueName=work-items 같은 메타데이터를 지정하고 스토리지 연결은 시크릿으로 인증합니다. 여기서 주목할 세부는 --min-replicas 0입니다. 큐가 비면 워커가 0까지 축소되어 유휴 비용이 없고, 메시지가 도착하는 순간 KEDA가 다시 확장합니다.

Azure Pipelines로 지속적 배포

main 브랜치 푸시가 트리거되면 BuildAndPush 스테이지에서 Docker@2 태스크가 이미지를 빌드해 ACR에 푸시하고, Deploy 스테이지에서 AzureCLI@2 태스크가 az containerapp update로 새 이미지를 적용합니다. 이미지 태그로 latest가 아닌 $(Build.BuildId)를 쓰는 것이 포인트로, 모든 배포를 그것을 만들어낸 정확한 파이프라인 실행까지 추적할 수 있습니다.

리비전 관리와 롤백

기본은 단일 리비전 모드이며, az containerapp revision set-mode --mode Multiple로 다중 리비전 모드로 바꾸면 컷오버를 명시적으로 제어할 수 있습니다. revision list로 현재·이전 리비전과 트래픽 가중치를 확인하고, 새 리비전에 문제가 있으면 az containerapp ingress traffic set으로 이전 리비전에 가중치 100을 주는 것만으로 롤백됩니다 — 재배포도 리빌드도 없는 트래픽 가중치 변경 한 번입니다. 또는 revision copy로 알려진 정상 리비전을 새 리비전으로 복사할 수도 있습니다. 장애 상황에서 '이전 정상 상태로 되돌리기'가 소스 재빌드가 아닌 단일 명령이어야 한다는, ArgoCD 롤백과 같은 원칙이라고 글은 짚습니다.

비용 모델과 정리

Container Apps는 프로비저닝된 인스턴스-시간이 아니라 실제 소비한 vCPU-초·GiB-초 단위로 과금됩니다. 위 큐 워커처럼 0까지 축소되는 워크로드는 유휴 시 비용이 0이며, 일이 없어도 계속 켜져 있는 상시 가동 VM이나 AKS 노드 풀과는 의미 있게 다른 비용 구조입니다. 글은 여기 나온 개별 요소 — 레지스트리, 스케일 규칙, 파이프라인, 리비전 정책 — 하나하나는 특별하지 않지만, 비밀번호 대신 ID 기반 레지스트리 인증, 실제 수요 신호 기반 스케일링, 재배포가 아닌 명령 하나로 끝나는 롤백 경로라는 규율이 프로덕션 준비도를 만든다고 정리합니다. ACR 설정, Bicep, 파이프라인 YAML, 리비전 관리 스크립트는 GitHub 리포지토리(azure-container-apps-cicd-lab)에 공개되어 있으며, 2026년 9월 기준 최신 Azure CLI로 검증되었다고 명시합니다.

원문: dev.to / 번역·요약: Trawling