AZ-104 시험에서 컨테이너와 App Service는 실무에서도 자주 쓰이는 중요한 주제입니다. 처음 보면 용어가 낯설게 느껴지지만, 실생활 비유로 접근하면 생각보다 훨씬 쉽게 이해할 수 있습니다.
컨테이너란 무엇인가요?
먼저 컨테이너의 개념을 잡고 시작하겠습니다.
컨테이너는 이사할 때 쓰는 포장 박스와 같습니다. 이사할 때 가구, 옷, 주방용품을 각각 박스에 담아서 옮기면, 새집에서도 박스를 열기만 하면 바로 사용할 수 있죠. 앱도 마찬가지입니다. 앱과 그 앱이 필요로 하는 라이브러리, 설정 파일을 모두 하나의 컨테이너 이미지에 담아두면, 어떤 서버에서 실행해도 똑같이 동작합니다. "내 컴퓨터에서는 잘 됐는데..."라는 문제가 사라지는 것입니다.
Azure에는 이 컨테이너를 다루는 서비스가 여러 가지 있습니다. 각각 어떤 상황에 쓰는지 함께 살펴봅시다.
---
Azure Container Registry (ACR)
ACR이란 무엇인가요?
ACR은 컨테이너 이미지를 보관하는 나만의 창고입니다.
쇼핑몰 창고를 생각해보세요. 물건을 만들면 창고에 보관했다가, 주문이 들어오면 창고에서 꺼내서 배송하죠. ACR도 똑같습니다. 개발팀이 앱을 컨테이너 이미지로 만들면, ACR에 보관해 두었다가 필요할 때마다 꺼내서 서버에 배포합니다.
왜 나만의 창고가 필요할까요? Docker Hub 같은 공개 저장소에 올리면 누구나 볼 수 있습니다. 회사 내부 앱이나 보안이 중요한 이미지는 외부에 노출되면 안 되겠죠. ACR은 프라이빗(비공개) 레지스트리이므로, 허가받은 사람만 이미지에 접근할 수 있습니다.
ACR SKU (등급) 비교
| 등급 | 특징 | 적합한 상황 | |------|------|------------| | Basic | 소용량 스토리지, 기본 기능 | 개발/테스트 환경 | | Standard | 더 큰 용량, 웹훅 지원 | 일반적인 프로덕션 | | Premium | 지역 복제, 프라이빗 엔드포인트 | 대규모 엔터프라이즈 |
Premium 등급의 지역 복제는 여러 Azure 지역에 이미지 사본을 두는 기능입니다. 한국에 있는 서버와 미국에 있는 서버 모두 가까운 곳에서 이미지를 빠르게 받아올 수 있습니다.
ACR 접근 권한 (RBAC)
창고에도 역할이 있죠. ACR도 마찬가지입니다.
AcrPull: 이미지를 가져오는(읽기) 권한. 배포 서버에 주로 부여합니다. AcrPush: 이미지를 올리는(쓰기) 권한. CI/CD 파이프라인이나 개발자에게 부여합니다. AcrDelete: 이미지를 삭제하는 권한. 관리자에게만 부여하는 것이 좋습니다.
시험 팁: "Docker 이미지를 프라이빗으로 저장해야 한다" → ACR을 떠올리세요.
---
Azure Container Instances (ACI)
ACI란 무엇인가요?
ACI는 컨테이너를 가장 빠르고 간단하게 실행하는 방법입니다.
택배 배달을 생각해보세요. 아주 가끔 짐을 옮길 일이 있을 때, 트럭을 사거나 물류창고를 빌리는 것은 낭비입니다. 그냥 퀵서비스를 부르면 됩니다. ACI도 마찬가지입니다. 복잡한 서버 설정이나 클러스터 관리 없이, 컨테이너 하나를 즉시 실행하고 싶을 때 사용합니다.
언제 ACI를 사용하나요?
배치 작업: 매일 새벽 2시에 데이터를 정리하는 작업. 평소에는 실행할 필요가 없고, 필요한 시간에만 컨테이너를 실행하고 종료합니다. 이벤트 기반 처리: 파일이 업로드될 때 이미지를 변환하는 작업처럼, 특정 이벤트가 발생했을 때만 잠깐 실행하는 경우. 간단한 테스트: 새로운 컨테이너 이미지를 빠르게 테스트해보고 싶을 때.
ACI의 장점과 제약
ACI는 CPU와 메모리를 직접 지정해서 필요한 만큼만 사용할 수 있습니다. 하지만 상시 운영되는 웹 서비스보다는 일회성 또는 단발성 작업에 더 적합합니다. 여러 컨테이너를 복잡하게 연결해야 하는 마이크로서비스 아키텍처에는 아래에서 소개할 서비스가 더 맞습니다.
시험 팁: "가장 빠르게 단일 컨테이너를 실행" 또는 "클러스터 관리 없이 컨테이너 실행" → ACI를 떠올리세요.
---
Azure Container Apps
Container Apps란 무엇인가요?
Container Apps는 서버리스 컨테이너 플랫폼입니다. 마이크로서비스처럼 여러 컨테이너가 서로 연결되어 동작하는 복잡한 앱을 관리하기에 적합합니다.
프랜차이즈 식당을 상상해보세요. 주방, 홀, 계산대가 각각 독립적으로 운영되지만 서로 협력합니다. 손님이 많은 점심시간에는 주방 인력을 늘리고, 한산한 시간에는 줄입니다. Container Apps가 바로 이런 역할을 합니다. 각 마이크로서비스(주방, 홀, 계산대)를 컨테이너로 운영하면서, 트래픽에 따라 자동으로 스케일을 조절합니다.
KEDA 기반 자동 스케일링
KEDA(Kubernetes Event-Driven Autoscaling)는 다양한 신호를 보고 컨테이너 수를 자동으로 조절합니다.
예를 들어, HTTP 요청이 몰리면 컨테이너를 더 만들고, 메시지 큐에 처리할 메시지가 쌓이면 추가 컨테이너를 띄워서 처리합니다. 트래픽이 없으면 컨테이너를 0개까지 줄여서 비용을 절약할 수도 있습니다. 이것이 "서버리스"의 의미입니다 — 서버가 없는 게 아니라, 서버를 신경 쓸 필요가 없다는 뜻입니다.
리비전 관리 (Blue/Green, Canary 배포)
새 버전을 배포할 때 100%의 트래픽을 한 번에 전환하면 문제가 생겼을 때 모든 사용자가 영향을 받습니다. Container Apps는 이를 안전하게 처리합니다.
Blue/Green 배포: 구 버전(Blue)과 신 버전(Green)을 동시에 운영하다가, 검증 후 트래픽을 한 번에 전환합니다. Canary 배포: 처음에는 트래픽의 5%만 신 버전으로 보내고, 문제없으면 점점 늘려갑니다. 카나리아 새가 광산에서 가스를 먼저 감지하는 것처럼, 소수 사용자로 먼저 테스트하는 방식입니다.
Dapr 통합
Dapr는 마이크로서비스 간 통신을 쉽게 만들어주는 도구입니다. 서비스 A가 서비스 B에 메시지를 보내거나, 공유 상태를 저장하고 읽는 기능을 표준화된 방식으로 제공합니다. 복잡한 분산 시스템 코드를 직접 작성하지 않아도 됩니다.
시험 팁: "서버리스 컨테이너", "KEDA 스케일링", "마이크로서비스" → Container Apps를 떠올리세요.
---
Azure App Service
App Service란 무엇인가요?
App Service는 웹 앱, REST API, 모바일 백엔드를 쉽게 호스팅할 수 있는 PaaS(Platform as a Service)입니다.
임대 아파트를 생각해보세요. 아파트를 직접 짓지 않아도, 입주하면 전기·수도·난방이 모두 준비되어 있습니다. App Service도 마찬가지입니다. 서버 운영체제 설치, 보안 패치, 부하 분산 같은 인프라 걱정 없이, 코드만 올리면 바로 웹 서비스를 운영할 수 있습니다. Node.js, Python, .NET, Java, PHP 등 다양한 언어를 지원합니다.
App Service Plan
App Service Plan은 앱이 실행되는 컴퓨팅 리소스(CPU, 메모리)를 정의하는 요금제입니다. 아파트로 비유하면 원룸, 투룸, 복층 같은 평수 구분입니다.
| 등급 | 특징 | 적합한 상황 | |------|------|------------| | Free/Shared | 무료 또는 공유 환경, 커스텀 도메인 없음 | 개발·학습용 | | Basic | 소규모 앱, 자동 스케일링 없음 | 소규모 프로덕션 | | Standard | 자동 스케일링 + 배포 슬롯 제공 | 일반 프로덕션 | | Premium | 고성능, VNet 통합 | 고트래픽 또는 네트워크 격리 필요 시 | | Isolated (ASE) | 전용 격리 환경, App Service Environment | 금융·의료 등 완전한 격리가 필요한 경우 |
중요한 점은 자동 스케일링과 배포 슬롯은 Standard 이상에서만 사용할 수 있다는 것입니다. 시험에 자주 나오는 내용입니다.
배포 슬롯 (Deployment Slots)
배포 슬롯은 프로덕션 앱 옆에 스테이징(준비) 환경을 만들어 두는 기능입니다.
레스토랑 주방을 생각해보세요. 메뉴를 바꿀 때 영업 중인 주방에서 바로 테스트하면 손님에게 영향을 줍니다. 대신 별도 테스트 주방에서 새 메뉴를 완성한 다음, 괜찮으면 기존 메뉴와 교체(스왑)합니다.
배포 슬롯도 똑같이 작동합니다. 스테이징 슬롯에 새 버전을 배포합니다. 스테이징에서 충분히 테스트합니다. 문제없으면 스테이징과 프로덕션을 스왑(교체)합니다. 서비스 중단 없이 새 버전이 배포됩니다. 만약 문제가 생기면, 다시 스왑해서 즉시 롤백합니다.