적합한 컴퓨팅 서비스 선택

Azure는 다양한 컴퓨팅 서비스를 제공하며, 각 서비스는 서로 다른 유형의 작업, 제어 수준 및 운영 모델에 맞게 설계되었습니다. 잘못된 컴퓨팅 서비스를 선택하면 불필요하게 복잡해지거나(너무 낮은 수준) 제어 기능이 부족해질 수 있습니다(추상화 수준이 너무 높음). 핵심 질문은 다음과 같습니다. 기반 인프라 중 어느 정도를 직접 관리해야 하는가? 이 단원에서는 주요 컴퓨팅 옵션과 각 시나리오에 적합한 선택을 안내하는 기준을 살펴봅니다.

Azure Virtual Machines를 사용하면 OS, 런타임 및 애플리케이션 스택을 완전히 제어할 수 있습니다. 특정 OS 버전이나 커널 설정이 필요한 레거시 애플리케이션을 실행하거나, 수정 없이 온-프레미스 작업을 리프트 앤 시프트 마이그레이션하거나, 시스템 수준에서 사용자 지정 소프트웨어를 설치하거나, 예측 가능한 고정 구성으로 24시간 실행되는 영구 컴퓨팅이 필요할 때 VM을 사용합니다. 그 대신 운영 부담이 가장 큽니다. OS 계층의 패치 적용, 보안 강화 및 모니터링을 직접 담당해야 합니다.

Virtual Machine Scale Sets는 VM이 필요하면서 수요에 따라 자동으로 확장해야 할 때 적합합니다. 작업이 상태 비저장 방식이고(웹 서버, API 백엔드, 일괄 처리 작업자), 모든 인스턴스에서 동일하게 실행되며, 수요가 변동한다면 VMSS가 자연스러운 선택입니다. VM 수준의 제어 기능과 자동 수평 확장을 결합할 수 있습니다. 독립 실행형 VM과 VMSS 중에서 선택할 때 일반적으로 결정적인 요소는 작업을 단일 인스턴스 이상으로 확장해야 하는지 여부입니다.

Azure App Service는 웹 애플리케이션, REST API 및 모바일 백엔드를 호스팅하기 위한 PaaS 플랫폼입니다. 코드를(Node.js, Python, Java, .NET, PHP, Ruby 또는 컨테이너로) 배포하면 Azure가 런타임, OS, 패치 적용, 부하 분산 및 확장을 관리합니다. 인프라를 관리하지 않고 코드를 빠르게 출시하려는 경우, 애플리케이션이 표준 웹 앱 패턴을 따르는 경우, OS 수준의 사용자 지정이 필요하지 않은 경우에 App Service를 사용합니다. App Service는 강력한 기능과 간편한 사용의 균형 덕분에 가장 인기 있는 Azure 서비스 중 하나입니다.

Azure Container Instances(ACI)를 사용하면 인프라를 관리하지 않고 클라우드에서 Docker 컨테이너를 실행할 수 있습니다. VM이나 오케스트레이터가 필요하지 않습니다. ACI는 예약된 일괄 처리 작업, CI/CD 파이프라인 작업, 데이터 처리 스크립트 또는 개발 환경과 같은 단기간 실행되는 주문형 컨테이너 작업에 적합합니다. 컨테이너는 몇 초 안에 시작되며 사용한 CPU와 메모리만큼 초 단위로 비용을 지불합니다. ACI는 Kubernetes가 제공하는 서비스 검색, 순차 배포 또는 상태 기반 재시작 같은 기능을 제공하지 않으며, 단일 컨테이너 또는 컨테이너 그룹을 실행하는 환경입니다.

Azure Kubernetes Service(AKS)는 컨테이너화된 애플리케이션을 대규모로 오케스트레이션하기 위한 관리형 Kubernetes 환경입니다. 서비스 검색, 순차 배포, 자동 복구 및 정교한 확장이 필요한 여러 마이크로서비스가 있을 때 AKS를 사용합니다. AKS는 Kubernetes 컨트롤 플레인(API 서버, etcd, 스케줄러)을 무료 PaaS 구성 요소로 관리하고, 사용자는 작업자 노드 VM을 관리합니다. AKS는 컨테이너 옵션 중 운영 부담이 가장 크지만 프로덕션 마이크로서비스 아키텍처에 가장 강력하고 유연한 기능을 제공합니다.

Azure Functions는 이벤트 기반 서버리스 컴퓨팅 옵션으로, HTTP 요청, 타이머 일정, 큐에 도착한 메시지 또는 다른 Azure 서비스의 이벤트와 같은 트리거에 응답하여 실행되는 개별 함수를 작성합니다. 실행 횟수에 따라 비용을 지불하며(월간 최초 100만 회 실행은 무료), 플랫폼이 동시 실행 수를 0에서 수천 개까지 자동으로 확장합니다. 이벤트 기반 자동화, 웹후크, 데이터 변환 파이프라인 및 본질적으로 단기간 실행되며 트리거에 기반한 모든 작업에 Functions를 사용합니다.

다음과 같은 간단한 의사 결정 트리를 사용해 보세요. 전체 OS 제어가 필요한가요? → VM 또는 VMSS. 대규모 컨테이너화 작업인가요? → AKS. 단일 컨테이너이며 단기간 실행되나요? → ACI. OS 관리가 필요 없는 웹 앱 또는 API인가요? → App Service. 이벤트 기반의 단기간 실행 코드인가요? → Azure Functions. 이 목록에서 아래로 내려갈수록 관리해야 하는 인프라는 줄어들고 더 빠르게 배포할 수 있지만, 실행 환경에 대한 제어 권한도 줄어듭니다. 요구 사항을 충족하는 가장 높은 수준의 추상화를 선택하세요.

실제 아키텍처에서는 여러 컴퓨팅 옵션을 함께 사용하는 경우가 많습니다. 예를 들어 한 회사가 고객용 웹 애플리케이션에는 App Service를, 이벤트 기반 주문 처리에는 Azure Functions를, 내부 마이크로서비스 플랫폼에는 AKS를, 리팩터링할 수 없는 레거시 ERP 시스템에는 VM을 사용할 수 있습니다. Azure의 통합 관리 도구인 포털, CLI, ARM 템플릿 및 Azure Monitor는 모든 컴퓨팅 서비스에서 일관되게 작동하므로, 여러 컴퓨팅 서비스를 사용하는 아키텍처도 하나의 컨트롤 플레인에서 관리할 수 있습니다.

컴퓨팅 옵션에 따라 비용이 크게 달라집니다. VM — 유휴 상태일 때도 VM 크기에 따라 시간당 요금이 부과됩니다(할당 해제된 경우 제외). 애저 애플리케이션 서비스 — 애플리케이션 서비스 요금제 SKU에 따라 시간당 요금이 부과되지만, 여러 애플리케이션이 하나의 요금제를 추가 비용 없이 공유할 수 있습니다. ACI — 실제로 사용한 CPU 및 메모리 사용량에 따라 초당 요금이 부과되며, 유휴 비용은 없습니다. 애저 함수(소비 요금제) — 실행 횟수와 실행 시간(초)에 따라 요금이 부과되며, 무료 사용량이 매우 넉넉합니다. 사용량이 급증하는 작업에는 서버리스 옵션이 거의 항상 가장 비용 효율적이며, 지속적으로 항상 실행되는 작업에는 예약 VM 또는 애플리케이션 서비스 요금제가 더 저렴할 수 있습니다.

컴퓨팅 서비스마다 제공하는 SLA 보장이 다릅니다. 단일 VM(Premium SSD): 99.9%. 가용성 집합의 VM: 99.95%. 가용성 영역에 분산된 VM: 99.99%. 애저 애플리케이션 서비스(Standard 계층 이상): 99.95%. 애저 함수(소비 요금제): 99.95%. AKS: API 서버 가동 시간 99.95%(유료 계층 사용 시). 여러 구성 요소로 이루어진 아키텍처의 종합 SLA는 각 SLA를 곱하여 계산합니다. 예를 들어 애저 SQL(99.99%)에 연결된 애플리케이션 서비스(99.95%)의 종합 SLA는 약 99.94%입니다.

이 단원에서 다룬 Microsoft Azure Fundamentals(AZ-900) 개념을 얼마나 이해했는지 테스트해 보십시오.

이 단원에서는 다음을 학습했습니다. 애저는 VM, VMSS, 애플리케이션 서비스, ACI, AKS, 함수 등 여러 컴퓨팅 옵션을 제공하며, 각 옵션은 서로 다른 작업 부하 특성과 제어 요구 사항에 적합합니다. 또한 일반적으로 요구 사항을 충족하는 가장 높은 추상화 수준을 선택하여 운영 부담을 최소화해야 합니다. 그리고 실제 아키텍처에서는 애저의 통합 관리 계층을 통해 오케스트레이션되는 여러 컴퓨팅 서비스를 함께 사용하는 경우가 많습니다. 다음으로는 Storage Accounts부터 시작하여 애저 스토리지 서비스를 살펴보겠습니다.