컴퓨팅과 서버리스 아키텍처 선택 기준 완벽 정리

VM부터 AKS까지, AZ-305 시험에서 자주 나오는 컴퓨팅 서비스 선택 기준을 실제 문제 패턴과 함께 정리합니다. 서비스별 차이와 마이그레이션 도구 선택법도 함께 다룹니다.

AZ-305 Solutions Architect Expert 시험에서 컴퓨팅 설계 도메인은 서비스 암기만으로 풀 수 없는 문제들이 집중 출제됩니다. "코드 변경 없이 이전하고 싶다", "Kubernetes 관리 부담을 없애고 싶다", "서버 없이 이벤트를 처리하고 싶다"처럼 요구사항 조합으로 정답이 갈리기 때문입니다. 이 글은 실제 AZ-305 시험 문제 49개에서 추출한 패턴 기반으로 각 서비스의 선택 기준과 흔한 오답 함정을 정리합니다.

---

 

VM과 가상 머신 확장 집합 (VMSS)

VM을 선택해야 하는 핵심 신호는 레거시 의존성입니다. COM 구성 요소, COM+, ActiveX처럼 Windows OS 런타임 수준의 컴포넌트가 등장하면 PaaS로 이전이 불가능합니다. 고가용성 요구사항이 함께 나오면 Availability Sets와 Availability Zones 중에서 선택합니다.

Availability Sets: 동일 데이터센터 내 장애 도메인(최대 3개)과 업데이트 도메인(최대 20개)에 VM을 분산합니다. 99.95% SLA, 추가 비용 없음. Availability Zones: 리전 내 물리적으로 분리된 데이터센터에 VM을 배포합니다. 99.99% SLA, 데이터센터 전체 장애 대응.

VM 시리즈 선택도 출제됩니다. 비정기 피크가 있는 개발·테스트 환경이면 Bsv2(버스터블) — CPU 크레딧 축적·소모 방식으로 비용이 현저히 낮습니다. SQL Server처럼 메모리 비율이 높아야 하는 워크로드에는 Ev5(메모리 최적화) — SR-IOV 가속 네트워킹을 기본 지원하고 SQL Server 라이선스 비용도 절감됩니다. 규정 준수 하드웨어 격리가 필요하면 Azure Dedicated Host를 VMSS, Availability Zones와 조합합니다.

VMSS는 CPU 사용률 등 메트릭 기반으로 동일 VM을 자동 확장·축소하며 표준 플랜 기준 최대 1,000개 인스턴스를 지원합니다.

---

 

App Service와 웹 워크로드

App Service의 선택 신호는 세 가지입니다: 코드 변경 없이 이전, OS 관리를 Azure에 위임, 자동 확장 필요. 세 키워드가 함께 나오면 대부분 App Service입니다. Java, Python, .NET, Node.js 런타임을 기본 지원하고 로컬 임시 스토리지(Windows: , Linux: )도 제공하므로 임시 파일을 사용하는 온프레미스 앱도 코드 수정 없이 이전 가능합니다.

멀티리전 배포에서는 App Service Plan이 특정 Azure 리전에 귀속된다는 점을 기억하세요. 유럽, 북미, APAC에 독립 배포하려면 리전별 별도 Plan이 필요합니다. 완전 격리와 VNet 전용 서브넷이 필요한 규제 환경이라면 App Service Environment(ASE v3)를 고려하지만 빈 환경에도 월 1,000달러 이상의 기본 요금이 발생합니다.

Deployment Slots 스왑은 무중단 즉시 전환이 핵심입니다. 스테이징 슬롯을 프로덕션과 동일 환경에서 검증한 뒤 스왑하면 워밍업된 인스턴스가 수 초 내에 트래픽을 수신합니다. Standard 티어 이상에서만 사용 가능하며, 점진적 카나리 배포가 필요하면 슬롯 트래픽 비율을 조정하거나 Traffic Manager를 활용합니다.

---

 

서버리스: Functions와 Logic Apps

Azure Functions 호스팅 플랜 선택은 AZ-305 단골 주제입니다.

Consumption 플랜: 실행 횟수 × 시간 과금, 월 100만 회 무료. 유휴 시 비용 없음. 단, 최대 10분 실행 제한, 콜드 스타트 발생, VNet 통합 불가. Premium 플랜: 사전 워밍 인스턴스로 콜드 스타트 제거. 실행 시간 무제한 설정 가능. VNet 통합 지원. "콜드 스타트 없음 + 10분 초과 실행 + VNet 통합" 세 조건이 나오면 Premium입니다. Dedicated 플랜: App Service Plan 위에서 실행. 서버 관리 부담은 있으나 기존 Plan 자원을 공유 가능.

HTTP 트리거의 인증 수준도 출제됩니다. anonymous는 키 없이 누구나 호출 가능하여 공개 데이터 API에 적합합니다. function은 함수 키, admin은 마스터 키가 필요합니다. 배열로 허용 HTTP 메서드를 제한할 수 있으며, 지정되지 않은 메서드는 자동으로 405를 반환합니다.

---

 

컨테이너 워크로드: Container Apps와 AKS

Container Apps vs AKS

핵심 기준은 Kubernetes 제어 수준입니다. "Kubernetes 관리 없이 컨테이너 실행 + 운영 오버헤드 최소화"이면 Azure Container Apps, Kubernetes를 직접 제어해야 하면 AKS를 선택합니다.

Container Apps는 KEDA 기반 자동 확장과 Dapr 통합이 기본 제공되며 노드 풀, kubectl, 클러스터 업그레이드가 완전 추상화됩니다. AKS는 Istio 서비스 메시, 네트워크 정책, 커스텀 런타임이 필요한 고급 시나리오에 사용합니다.

AKS 관련 심화 주제들도 자주 출제됩니다.

KEDA: Azure Queue Storage, Event Hubs, Service Bus 등 50개 이상 스케일러를 지원하는 Kubernetes 네이티브 자동 확장 도구. 큐에 메시지가 없을 때 파드를 0으로 축소하는 scale to zero가 핵심으로, HPA 단독으로는 최소 1개 파드를 유지해야 하지만 KEDA는 0이 가능합니다. Virtual Node + ACI: AKS에서 VM 프로비저닝 없이 즉각 버스트 확장이 필요할 때 사용합니다. ACI를 가상 노드로 연결하면 수십 초 내에 컨테이너가 기동됩니다. Linux 컨테이너만 지원. Istio 서비스 메시: 카나리 배포(트래픽 가중치), 헤더 기반 라우팅, mTLS 서비스 간 암호화를 동시에 만족해야 할 때 선택합니다. Dapr: State Management API로 Redis, Cosmos DB, Azure Table Storage를 동일한 API로 접근하고, Pub/Sub API로 메시지 브로커를 추상화합니다. YAML 설정만 교체하면 코드 변경 없이 저장소·브로커 교체가 가능합니다. ACR Geo-replication: Premium 티어 ACR에서만 지원. 멀티리전 AKS에서 이미지 복제를 자동화하고 각 리전이 가장 가까운 복제본에서 이미지를 가져오도록 합니다.

!Container Apps vs AKS

서비스 비교표

| 서비스 | 비용 모델 | 스케일링 | 운영 복잡도 | 주요 선택 신호 | |--------|---------|---------|-----------|-------------| | VM | 인스턴스 시간 | 수동 또는 VMSS | 높음 | COM/ActiveX 레거시, 하드웨어 격리 | | VMSS | 인스턴스 시간 | 자동 (메트릭) | 중간 | 동일 VM 자동 확장·축소 | | App Service | 플랜 시간 | 자동 (인스턴스 수) | 낮음 | 코드 변경 없는 웹앱 리프트앤시프트 | | Container Apps | 실행 시간·요청 수 | KEDA 자동 (0 포함) | 낮음 | K8s 관리 없이 컨테이너 실행 | | AKS | 노드 VM 시간 | HPA/KEDA/Cluster Autoscaler | 높음 | K8s 직접 제어, 서비스 메시 | | Functions (Consumption) | 실행 횟수 × 시간 | 자동 (서버리스) | 매우 낮음 | 불규칙 이벤트, 짧은 실행 | | Functions (Premium) | 최소 인스턴스 + 사용량 | 자동 (사전 워밍) | 낮음 | 콜드 스타트 없음, VNet 통합 |

---

 

시험에서 자주 헷갈리는 선택 기준

대규모 병렬 처리

수천 개의 독립적인 태스크를 병렬 처리해야 하는 3D 렌더링, 유전체 분석, 금융 시뮬레이션은 Azure Batch가 정답입니다. 태스크 큐잉·스케줄링·VM 풀 자동 확장이 내장되어 있고 사용 후 0으로 축소됩니다. 서드파티 HPC 잡 스케줄러(PBS Pro, Slurm, LSF)와 통합해야 한다면 Azure CycleCloud를 선택합니다. Batch 노드 유형은 중단 허용 개발 워크로드에 Spot VM(최대 90% 절감), 장기 실행 프로덕션에 Dedicated VM을 사용합니다.

마이그레이션 도구

Azure Migrate: 온프레미스 → Azure 검색·평가·마이그레이션 통합 플랫폼. VMware 어플라이언스로 에이전트 없이 VM 성능을 수집하고 적정 SKU와 예상 비용을 계산합니다. Azure Resource Mover: Azure 내 구독 간 또는 리전 간 기존 리소스를 이전할 때 사용합니다. 온프레미스 이전과 혼동하지 마세요. Azure DMS(온라인 모드): SQL Server → Azure SQL MI를 CDC 방식으로 지속 동기화하여 전환 다운타임을 수 분 이내로 제한합니다. DMA + DMS 조합: SQL 스키마 호환성 사전 평가(DMA) → 실제 데이터 이전(DMS). Azure Data Factory: SQL Server → Cosmos DB(NoSQL)처럼 이기종 데이터 소스 간 이전에 사용합니다. DMS는 관계형 → 관계형 전용입니다.

하이브리드 마이크로서비스

온프레미스와 Azure를 동시에 운영하면서 초저지연이 필요한 마이크로서비스 플랫폼이라면 Azure Service Fabric이 정답입니다. 온프레미스 데이터센터와 Azure 클라우드 양쪽에 동일 클러스터를 배포할 수 있고 수백만 인스턴스를 밀리초 단위로 처리합니다.

---

 

실무 적용 팁

워크로드 패턴으로 서비스를 분류하면 빠릅니다. OS 수준 접근 필요 → VM, PaaS 웹앱 → App Service, 컨테이너이지만 K8s 관리 싫음 → Container Apps, K8s 완전 제어 → AKS, 짧고 불규칙한 이벤트 → Functions.

비용 최적화 패턴도 기억하세요. 낮은 평균 CPU + 비정기 피크 → Bsv2 버스터블, 중단 허용 배치 → Spot VM(최대 90% 절감), 불규칙 HPC → Azure Batch, 이벤트 없을 때 비용 없음 → Functions Consumption.

고가용성은 하나의 서비스로 해결되지 않습니다. 하드웨어 격리 → Dedicated Host, 데이터센터 수준 내결함성 → Availability Zones, 동일 데이터센터 내 분산 → Availability Sets. 세 가지는 서로 배타적이지 않고 조합 가능합니다.

---

 

정리

AZ-305 컴퓨팅 설계 도메인의 핵심 선택 키워드를 정리합니다.

COM/ActiveX, 레거시 의존성 → IaaS VM 필수 코드 변경 없이 + OS 관리 위임 + 자동 확장 → App Service 무중단 즉시 배포 전환 → Deployment Slots 스왑 공개 API + 키 없이 접근 → Functions HTTP Trigger, authLevel: anonymous 콜드 스타트 없음 + 10분 초과 + VNet 통합 → Functions Premium 플랜 K8s 관리 없이 컨테이너 → Container Apps K8s 직접 제어, 서비스 메시 → AKS Queue 기반 자동 확장 + scale to zero → KEDA AKS 즉각 버스트 → Virtual Node + ACI 대규모 병렬 독립 태스크 → Azure Batch 서드파티 HPC 스케줄러 통합 → Azure CycleCloud 하이브리드 + 초저지연 마이크로서비스 → Service Fabric 온프레미스 → Azure 마이그레이션 평가 → Azure Migrate Azure 내 리전·구독 간 이동 → Azure Resource Mover SQL Server → Azure SQL MI 최소 다운타임 → DMS 온라인 모드

블로그 목록으로 돌아가기