Microsoft AZ-204: Azure 컨테이너 솔루션 — 학습 가이드

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

다음의 일부입니다: Microsoft Azure Developer Associate AZ-204 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

Azure는 단일 컨테이너 실행, 오케스트레이션된 클러스터, 안전한 엔터프라이즈급 이미지 공급망에 이르는 광범위한 컨테이너 옵션을 제공합니다. Azure Container Instances (ACI)는 서버 관리 없이 Linux 또는 Windows 컨테이너를 실행하는 가장 빠른 방법입니다. Azure Kubernetes Service (AKS)는 고급 스케줄링, 네트워킹, 보안 및 DevOps 통합을 통해 마이크로서비스를 확장하는 관리형 Kubernetes 컨트롤 플레인입니다. Azure Container Registry (ACR)는 빌드, 태그, 푸시/풀 및 Helm 배포 흐름의 중심이 되는 프라이빗 지역 복제 레지스트리입니다. Docker 이미지 구성 및 수명 주기 관리를 마스터하는 것은 이러한 모든 플랫폼에서 안정적인 배포를 위한 기본입니다. 이 섹션에서는 YAML 기반 배포, Helm 패키징, 서비스 노출, ID/보안 패턴을 포함하여 각 요소가 어떻게 결합되는지에 대한 실용적인 개발자 중심의 관점을 제시합니다.

Docker 및 Azure Container Registry (ACR)

안정적인 컨테이너 제공은 탄탄한 Docker 기본 지식에서 시작됩니다. 각 이미지는 Dockerfile 명령어에 의해 형성된 레이어로 구성되며, 레이어 재사용과 캐시 히트는 빠른 빌드에 매우 중요합니다.

• 일반적인 Dockerfile 명령어 및 지침:
  • FROM은 베이스 이미지를 정의합니다. 공격 표면과 크기를 줄이기 위해 최소한의 이미지(예: distroless, 경우에 따라 alpine)를 선호하세요.
  • RUN은 종속성을 설치하기 위해 명령을 실행합니다. 관련 명령을 결합하여 레이어 수를 줄이되, 실패를 파악하기 어렵게 만드는 단일 RUN 라인은 피하세요.
  • COPY와 ADD는 애플리케이션 아티팩트를 배치합니다. .dockerignore를 사용하여 컨텍스트가 비대해지는 것을 방지하고, COPY는 명시적인 경로로 고정하세요.
  • WORKDIR는 작업 디렉터리를 설정합니다. RUN에서 cd를 체이닝하는 대신 사용하세요.
  • EXPOSE는 의도된 리스닝 포트를 문서화합니다(방화벽이 아님).
  • ENV와 ARG는 환경 변수와 빌드 시간 변수를 구성합니다. ARG 기본값을 고정하거나 명시적인 값을 전달하여 빌드 시간의 결정성을 높이세요.
  • ENTRYPOINT는 메인 실행 파일을 정의합니다. 기본 인자에는 CMD를 사용하세요. 정상적인 종료를 위한 신호 처리를 보존하기 위해 exec 형식(JSON 배열)을 선호하세요.
  • HEALTHCHECK는 오케스트레이터가 대응할 수 있도록 활성 상태 평가를 활성화합니다.
• 다단계 빌드는 빌드 단계와 런타임 단계를 분리하여 필요한 아티팩트만 깨끗한 런타임 이미지로 복사함으로써 크기와 CVE 공간을 크게 줄입니다. 예를 들어, SDK로 빌드하고 바이너리를 게시한 다음 런타임 베이스로 복사합니다.
• 이미지 레이어는 불변(immutable)이며 콘텐츠 주소 지정(content-addressed) 방식입니다. 명령어 순서를 바꾸면 캐싱에 영향을 줍니다. 자주 변경되는 명령어(예: COPY 소스)는 Dockerfile의 뒷부분에 배치하여 캐시 히트율을 극대화하세요.

ACR을 사용하여 이미지와 Helm 차트를 비공개로 저장하고 배포합니다:

• 리포지토리 및 태그 지정: 이미지를 <registry>.azurecr.io/<repo>:<tag> 형식으로 푸시합니다. 시맨틱 또는 Git 기반 태그(예: 1.4.0, 빌드 SHA)를 선호하고, 프로덕션 배포에서는 반복성을 위해 불변 다이제스트를 사용하세요.
• 푸시 및 풀:
  • az acr login -n <acr-name> 또는 Azure AD 토큰으로 docker login을 사용하여 ACR에 인증합니다. 프로덕션 환경에서는 ACR 관리자 사용자를 활성화하지 마세요.
  • 태그 지정 및 푸시: docker tag app:1.0 <acr>.azurecr.io/apps/app:1.0; docker push <acr>.azurecr.io/apps/app:1.0. docker pull 또는 Kubernetes 이미지 참조를 통해 풀합니다.
  • 업스트림 이미지를 ACR로 가져와 공급망을 제어합니다: az acr import -n <acr> --source docker.io/library/nginx:1.25 --image base/nginx:1.25.
• ACR Tasks: Azure 내에서 네이티브하게 이미지를 빌드, 테스트 및 패치합니다. 온디맨드 빌드에는 az acr build -r <acr> -t apps/app:1.0 .를 사용하고, az acr task create로 업데이트를 자동화하여 Git 커밋 또는 베이스 이미지 업데이트에서 트리거함으로써 앱 코드 변경 없이 CVE 수정이 가능하게 합니다.
• 지역 복제(Premium SKU)는 다중 리전 풀 로컬리티와 복원력을 제공합니다. AKS 클러스터와 가까운 리전에 복제본을 구성하여 풀 지연 시간과 리전 간 이그레스(egress)를 줄이세요.
• 액세스 제어:
  • Azure AD와 통합하고 AKS kubelet ID에는 AcrPull, CI 파이프라인에는 AcrPush와 같은 기본 제공 역할을 할당하세요. 세분화된 제어를 위해 토큰 및 범위 맵을 통해 리포지토리 범위 권한을 사용할 수 있습니다.
  • 프라이빗 엔드포인트, 서비스 엔드포인트 및 방화벽 규칙으로 네트워크 액세스를 제한하세요. 프로덕션 환경에서는 프라이빗 엔드포인트를 선호하세요.
  • az aks update --attach-acr <acr>로 ACR을 AKS에 연결하여 AcrPull 역할 할당을 단순화하세요.

Azure Container Instances (ACI)

ACI는 클러스터 관리 없이 온디맨드로 컨테이너를 실행합니다. 기본 단위는 컨테이너 그룹으로, 동일한 호스트 OS 커널, 수명 주기, IP 및 볼륨을 공유하는 함께 스케줄링된 컨테이너 집합입니다. 컨테이너 그룹을 사용하여 사이드카 패턴(예: 로그 수집기, 프록시)을 구현하거나 메인 프로세스를 헬퍼와 결합하세요.

• 다중 컨테이너 그룹은 네트워크 네임스페이스를 공유하여 localhost를 통한 컨테이너 간 통신을 가능하게 합니다. 또한 마운트된 볼륨(Azure Files, emptyDir)과 수명 주기를 공유하므로, 긴밀한 결합이 필요한 응집력 있는 일회성 작업에 적합합니다.
• 다시 시작 정책은 실행 의미를 제어합니다:
  • Always는 컨테이너가 종료될 때 항상 다시 시작합니다. 장기 실행 서비스에 가장 적합합니다.
  • OnFailure는 0이 아닌 종료 코드로 종료될 때만 다시 시작합니다. 실패 시 재시도해야 하는 배치 작업에 적합합니다.
  • Never는 컨테이너를 한 번 실행하고 다시 시작하지 않으므로 멱등성(idempotent) 작업에 이상적입니다.
• 네트워킹 통합에는 DNS 레이블이 있는 공용 IP, 위임된 Azure VNet 서브넷의 개인 IP, NAT 또는 방화벽을 통한 보안 이그레스가 포함됩니다. VNet에 주입된 ACI는 공개 노출 없이 서비스(데이터베이스, 스토리지)에 대한 프라이빗 액세스를 가능하게 합니다.
• 운영 고려 사항:
  • 보안 환경 변수를 사용하거나 Azure Files를 마운트하여 시크릿을 주입하세요. 더 강력한 보안 상태를 위해 런타임에 관리 ID를 통해 Key Vault에서 시크릿을 검색하세요.
  • az container logs 및 az container attach로 관찰하고, az container exec로 대화형 명령을 실행하세요.
  • 요금은 vCPU 및 GiB 메모리에 대해 초 단위로 청구됩니다. 컨테이너는 빠르게 시작되며, Kubernetes 오버헤드가 불필요한 버스트성 워크로드, CI 헬퍼 작업, 통합 테스트 및 큐 트리거 작업에 적합합니다.

Azure Kubernetes Service (AKS)

AKS는 노드 풀, 자동 스케일링, 심층적인 네트워킹/ID 옵션을 갖춘 관리형 컨트롤 플레인을 제공합니다.

노드 풀은 용량과 워크로드 배치를 구조화합니다. 시스템 노드 풀은 핵심 서비스를 실행하고, 사용자 노드 풀은 애플리케이션 파드를 실행합니다. 여러 풀을 사용하여 CPU/메모리/GPU 요구 사항, OS(Linux/Windows), VM 크기, 가용성 영역별로 워크로드를 분리하세요. taint/toleration을 사용하여 시스템 풀을 보호하고, 레이블을 사용하여 선택하며, 클러스터 오토스케일러를 사용하여 보류 중인 파드에 따라 노드를 추가/제거하세요. 크기를 정할 때 노드당 maxPods와 파드 밀도를 고려하세요.

파드 스케줄링은 리소스 요청/제한, QoS 클래스(Guaranteed/Burstable/BestEffort), 제약 조건에 따라 결정됩니다. nodeSelector/affinity 및 anti-affinity를 사용하여 파드를 적절한 풀로 보내고, 복제본을 여러 영역과 장애 도메인에 분산시키세요. Topology spread constraints는 균등한 분산을 개선합니다. 중요 서비스의 경우, PodDisruptionBudgets와 PriorityClasses를 정의하여 자발적 중단 및 선점 동작을 제어하세요. DaemonSet은 노드별 에이전트(로깅, 모니터링)를 배치하고, CronJob은 주기적인 작업을 위해 컨테이너를 스케줄링합니다.

AKS에서의 배포는 선언적입니다. YAML 매니페스트는 Deployments, StatefulSets, Jobs, Services, Ingress에 대한 apiVersion, kind, metadata, spec을 정의합니다. 매니페스트를 소스 컨트롤에 보관하고, Kustomize 오버레이로 환경별 차이를 매개변수화하며, kubectl apply -f로 적용하세요. 서버 측 적용(Server-side apply)과 적절한 레이블/어노테이션은 소유권 및 드리프트 감지에 도움이 됩니다. 재사용 가능한 앱을 패키징하려면 Helm 3가 템플릿과 값을 번들로 제공합니다. Helm 차트를 ACR에 OCI 아티팩트로 호스팅하고 helm upgrade --install oci://.azurecr.io/helm/ -f values.yaml 명령어로 설치하세요. 환경별로 values 파일을 사용하고, 차트 버전을 추적하며, 빠른 복구를 위해 helm rollback을 사용하세요.

매일 사용하게 될 kubectl 명령어:

• 클러스터 컨텍스트에 액세스: az aks get-credentials -g '<rg>' -n '<cluster>'는 kubeconfig를 병합합니다. Azure AD에 가입된 머신에서 kubectl을 사용하는 것만으로 충분하며, 매니페스트를 배포하는 데 Docker는 필요하지 않습니다.
• 검사 및 운영: kubectl get nodes,pods,deploy,svc -A; kubectl describe pod '<name>'; kubectl logs -f '<pod>'; kubectl exec -it '<pod>' -- sh; kubectl rollout status deploy/'<name>'; kubectl set image deploy/'<name>' container='<image>':'<tag>'; kubectl top pods; 유지보수를 위해 kubectl cordon/drain nodes; RBAC 확인을 위해 kubectl auth can-i.
• 적용/패치: kubectl apply -f k8s/; kubectl patch deploy '<name>' --type merge -p '{...}'.

AKS의 네트워킹은 명확한 책임 분담을 통해 파드와 서비스를 노출합니다:

• ClusterIP는 서비스 검색을 위해 내부 전용, 클러스터 범위의 가상 IP와 DNS를 제공합니다. 이는 마이크로서비스 간의 east-west 트래픽에 대한 기본값입니다.
• NodePort는 각 노드에서 동일한 포트를 엽니다. 직접 사용하기보다는 Ingress나 외부 LB 뒤에서 사용하는 것이 가장 좋습니다.
• LoadBalancer는 NodePort를 대상으로 하는 Azure Load Balancer 프런트엔드를 프로비저닝합니다. service.beta.kubernetes.io/azure-load-balancer-internal: "true" 어노테이션을 추가하여 서비스를 내부용으로 표시하거나, 안정적인 DNS를 위해 고정 공인 IP를 할당할 수 있습니다.
• Ingress 컨트롤러는 L7 라우팅, TLS 종료, 경로/호스트 규칙을 제공합니다. NGINX Ingress Controller는 풍부한 어노테이션을 갖춘 다목적 기본 컨트롤러입니다. Application Gateway Ingress Controller(AGIC)는 Azure Application Gateway와 통합되어 WAF, 자동 스케일링, 엔터프라이즈급 L7 기능을 제공하면서 Kubernetes 네이티브 매니페스트를 유지합니다. cert-manager를 사용하여 ACME로 TLS를 자동화하거나, CSI Secret Store를 사용하여 Key Vault 인증서를 Kubernetes 시크릿으로 동기화하세요.

ID 및 권한 부여는 클러스터 내 시크릿 없이 Azure AD와 통합됩니다:

• AKS용 관리 ID는 클러스터/컨트롤 플레인 ID와 kubelet ID로 구성됩니다. 노드가 이미지를 안전하게 풀링할 수 있도록 kubelet에 ACR에 대한 AcrPull 권한을 부여하세요(az aks update --attach-acr '<acr>').
• Workload identity를 사용하면 파드가 Kubernetes 서비스 계정에 매핑된 페더레이션 Azure AD 자격 증명을 사용하여 Azure 리소스에 액세스할 수 있습니다. 노드 수준 자격 증명이나 사이드카가 필요 없습니다. 클러스터에서 OIDC issuer를 활성화하고, 사용자 할당 관리 ID를 생성하며, 서비스 계정/네임스페이스에 대한 FederatedIdentityCredential을 구성하고, 앱에서 Azure Identity SDK를 사용하세요. 이는 이전의 AAD Pod Identity 모델을 대체하며 개방형 표준에 부합합니다.
• RBAC는 Kubernetes API 권한을 관리합니다. AKS가 Azure AD와 통합된 경우, RoleBindings/ClusterRoleBindings를 통해 Kubernetes Roles/ClusterRoles를 Azure AD 사용자 또는 그룹에 바인딩하세요. 또는 Kubernetes 권한 부여를 위한 Azure RBAC를 활성화하여 Azure Kubernetes Service RBAC Reader, Writer, Admin과 같은 Azure RBAC 역할을 통해 액세스를 관리할 수 있습니다. 최소 권한 원칙을 따르고, 팀이나 워크로드별로 네임스페이스를 분리하며, 그룹 기반 바인딩을 통해 프로덕션 환경 접근을 제어하세요.

AKS로의 엔드투엔드 이미지 흐름은 간단하고 안전합니다. 다단계 이미지를 빌드하고, 불변 버전으로 태그를 지정하며, ACR에 푸시한 다음, 매니페스트나 Helm을 사용하여 AKS에 배포합니다. AKS는 kubelet 관리 ID를 사용하여 ACR에서 이미지를 풀링하고, 파드는 workload identity를 통해 Azure 리소스를 사용합니다. 서비스는 ClusterIP/LoadBalancer를 통해 노출되고, TLS와 라우팅을 중앙에서 관리하는 인그레스 컨트롤러로 구체화됩니다.

실제 문제 시나리오

Adobe의 Creative Cloud 팀은 모놀리식 미디어 처리 서비스를 마이크로서비스로 분해하여, 짧은 지연 시간의 글로벌 전송과 강화된 공급망을 목표로 하고 있습니다.

1. CI에서 다단계 Dockerfile을 사용하여 이미지 빌드 및 저장

• Docker 다단계 빌드를 사용하여 미디어 코덱을 컴파일하고 런타임 바이너리만 슬림한 기본 이미지에 복사하여 크기와 CVE를 최소화합니다. 이미지를 <acr>.azurecr.io/processing/encoder:<git-sha>로 ACR에 푸시합니다. 이를 통해 배포 피닝을 위한 불변 다이제스트를 가진 재현 가능하고 안전한 아티팩트를 보장합니다.

2. 레지스트리 강화 및 패치 자동화

• AKS를 호스팅하는 각 가상 네트워크에 프라이빗 엔드포인트가 있는 ACR Premium 레지스트리를 생성합니다. 이미지 풀링을 로컬에서 처리하기 위해 북유럽과 미국 동부에 지역 복제를 활성화합니다. 업스트림 기본 이미지 업데이트 시 재빌드를 트리거하도록 ACR Tasks를 구성하여 패치된 레이어를 자동으로 전파합니다. 이는 성능과 보안의 균형을 맞추고 이그레스 트래픽을 줄입니다.

3. 분리된 노드 풀과 ID로 AKS 구축

• Azure CNI와 시스템/사용자 노드 풀을 사용하여 AKS를 배포합니다. 컨트롤 플레인 애드온을 위한 작은 시스템 풀, 트랜스코딩을 위한 GPU 지원 사용자 풀, API를 위한 범용 풀을 구성합니다. Azure AD 통합, OIDC issuer, workload identity를 활성화합니다. az aks update --attach-acr를 통해 kubelet ID에 AcrPull을 할당합니다. 이는 워크로드를 격리하고, 효율적으로 확장하며, 시크릿 기반의 이미지 풀링을 제거합니다.

4. 선언적 배포 및 패키징 정의

• Deployments, 영속성이 필요한 경우 StatefulSets, Services, HorizontalPodAutoscaler, PodDisruptionBudgets에 대한 Kubernetes YAML을 작성합니다. 인코더 서비스와 API 게이트웨이를 Helm 차트로 패키징하고, 이를 OCI 아티팩트로 ACR에 게시하며, 환경별 values를 사용하여 helm upgrade --install로 배포합니다. 이는 일관성 있고 버전 관리되는 릴리스와 간단한 롤백을 제공합니다.

5. 서비스 노출 및 L7 보안 적용

• 내부 마이크로서비스에는 ClusterIP를 사용하고, 공용 API에는 Application Gateway Ingress Controller와 함께 LoadBalancer 서비스를 사용합니다. WAF 정책을 적용하여 Application Gateway에서 TLS를 종료하고, ACME 챌린지를 위해 Azure DNS와 통합된 cert-manager를 사용하여 인증서를 관리하며, 호스트/경로에 따라 백엔드로 라우팅합니다. 이는 Kubernetes 네이티브 구성으로 엔터프라이즈급 L7 보안을 제공합니다.

6. Azure 리소스에 대한 안전한 워크로드 액세스 구현

• Blob Storage에 쓰고 시크릿을 읽는 썸네일링 서비스의 경우, 사용자 할당 관리 ID를 생성하고, workload identity를 통해 서비스 계정과 페더레이션하며, Storage Blob 데이터 기여자 및 Key Vault 비밀 사용자 역할을 부여합니다. 파드는 Azure AD로 인증하여 시크릿 마운트를 제거하고 세분화된 감사 가능한 액세스를 가능하게 합니다.

7. ACI로 배치 오버플로 운영

• 산발적이고 우선순위가 높은 배치 오버플로의 경우, VNet에 주입된 서브넷 내에서 restartPolicy: Never로 설정된 ACI 다중 컨테이너 그룹(인코더 + 사이드카 메트릭 수집기)을 트리거합니다. 이는 AKS를 피크 수준까지 확장하지 않고도 급증하는 트래픽을 흡수하며 스토리지 계정으로의 프라이빗 데이터 경로를 유지합니다.

각 선택은 Adobe의 목표를 직접적으로 지원합니다. 지역 복제 및 프라이빗 엔드포인트가 있는 ACR Premium은 이미지 풀링을 안전하고 빠르게 합니다. 특화된 노드 풀과 workload identity를 갖춘 AKS는 격리 및 최소 권한 액세스를 강제합니다. Helm과 선언적 YAML은 배포 및 롤백을 표준화합니다. WAF가 포함된 AGIC는 탄력적이고 안전한 L7 인그레스를 제공합니다. 그리고 ACI는 영구적인 클러스터 비용 없이 폭발적인 배치 처리를 처리합니다.

← Azure Cosmos DB · 모든 도메인 · Azure 인증 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Microsoft 찾아보기 →