더 단순해진 쿠버네티스··· MS '애저 컨테이너 앱스' 살펴보기

마이크로소프트의 ‘애저 컨테이너 앱스(Azure Container Apps; ACA)’은 확장(scailing)을 관리하는 서버리스 쿠버네티스 서비스다. 실행할 준비가 된 애플리케이션의 컨테이너를 가져오기만 하면 된다.
 
애저 쿠버네티스 서비스(Azure Kubernetes Service; AKS) 등의 관리형 환경을 사용하더라도 클라우드에서 쿠버네티스 인프라를 구축하고 관리하는 것은 어려울 수 있다. 
 

가령 클라우드 네이티브 애플리케이션을 설계한다면 기본 가상 인프라를 고려하고, 워크로드에 적합한 서버 클래스와 예상되는 확장을 지원하기 위한 적절한 수의 서버를 프로비저닝해야 한다. 그리고 네트워킹 및 보안을 처리하기 위한 서비스 메시도 빌드하고 관리해야 한다.

물리 또는 가상 인프라, 애플리케이션 및 관련 서비스, 애플리케이션 플랫폼 관리 등을 위해 쿠버네티스이든 다른 오케스트레이션이든 또는 컨테이너 관리 계층이든 여러 새로운 데브옵스 계층을 추가하려면 많은 작업이 필요하다. 

이는 하이퍼스케일 클라우드 업체로 이전할 때의 많은 이점을 무효화하는 중요한 문제다. 쿠버네티스를 관리할 예산이 없다면 이러한 기술을 대부분 활용할 수 없다.

클라우드 네이티브는 어려울 수 있다
애저 앱 서비스(Azure App Service) 등의 서비스형 백엔드 기술을 기반으로 구축하는 대안이 있다. 여기서 빌트인 런타임 대신 컨테이너를 사용해 애저의 관리형 환경을 사용자 영역으로 대체할 수 있다. 

하지만 이런 도구는 웹 및 모바일 앱을 지원하는 서비스 구축 및 실행에 중점을 둔다. 다시 말해, 사물인터넷 또는 다른 이벤트 기반 시스템과 호환되는 데 필요한 메시징 기반의 확장 가능한 환경이 아니다. 

애저 펑션(Azure Functions) 등의 서버리스 기술을 사용할 수 있지만 애플리케이션의 모든 요소를 패키징하거나 네트워킹 및 보안 서비스와 호환되는 기능은 없다.

필요한 것은 기본 서버 또는 가상 인프라 운영을 클라우드 업체에 넘길 수 있는 서버리스 방식으로 쿠버네티스 서비스를 제공하는 방법이다. 클라우드 업체의 인프라 전문 지식을 바탕으로 애플리케이션 서비스와 기본 가상 서비스 및 서버를 관리할 수 있다. 

기존에 YAML을 구축하고 쿠버네티스를 구성하는 데 많은 시간을 투자했었다면 이제는 클라우드 업체의 자동화를 활용해 애플리케이션 구축에 집중해야 할 때다. 

‘애저 컨테이너 앱스’란?
이그나이트에서 마이크로소프트는 새 애저 플랫폼 서비스 ‘애저 컨테이너 앱스(Azure Container Apps; ACA)’를 선보였다. 현재 프리뷰 상태다. 이는 확장을 관리하는 서버리스 컨테이너 서비스를 제공한다. 이제 사용자는 실행할 수 있도록 패키징된 컨테이너를 가져오기만 하면 된다. 

ACA는 AKS 서비스를 기반으로 구축됐으며, KEDA(Kubernetes-based Event-Driven Autoscaling) 및 인보이(Envoy) 서비스 메시를 지원한다. 애플리케이션은 분산 애플리케이션 런타임(Distributed Application Runtime; Dapr)을 활용하여 애플리케이션 컨테이너가 기존 쿠버네티스 인프라뿐만 아니라 새로운 서비스에서도 실행될 수 있는 공통 코드 대상을 제공한다. 

마이크로소프트에 따르면 ACA가 적합할 수 있는 4가지 시나리오는 다음과 같다. 

• HTTP 기반 API 처리
• 백그라운드 처리 실행
• 모든 KEDA 호환 소스의 이벤트 트리거
• 확장 가능한 마이크로서비스 아키텍처 실행

특히, 마지막 옵션은 ACA를 유연한 도구로 만들어주며, 자주 사용하지 않을 수 있는 애플리케이션 구성 요소를 감안해 사용한 만큼만(scale-to-zero, pay-as-you-go) 지불하는 도구를 제공한다. 여러 애저 서비스에서 애플리케이션을 호스팅할 수 있으며, ACA 서비스가 필요할 때 호출할 수 있다(사용하지 않을 때는 비용을 발생시키지 않는다). 

프리뷰의 비용은 저렴한 편이다. 美 동부 2 지역에서의 비용 옵션은 아래와 같다. 

• 요청 비용: 매월 실행된 총 요청 수 기준 100만 개당 0.40달러(매달 첫 200만 개는 무료)
• vCPU 비용: 활성 상태는 초당 0.000024달러, 유휴 상태는 초당 0.000003달러
• 메모리: 활성 및 유휴 컨테이너 모두 초당 0.000003달러(초당 GB당 가격 책정)
• 매월 첫 180,000 vCPU-초 및 360,000 GB-초는 무료 

ACA를 쓰려면 컨테이너에 패키징된 애플리케이션이 필요하다. 이는 모든 애플리케이션 종속성을 설치하도록 구성되고, 스테이트리스 상태로 실행하도록 설계된 컨테이너를 사용해 쿠버네티스를 실행하는 것과 거의 유사하다. 

스테이트가 필요하다면 AKS를 사용하는 베스트 프랙티스에 따라 애플리케이션 상태를 유지하고 관리하는 애저 스토리지 또는 데이터베이스 환경을 구성해야 한다. 쿠버네티스 API에 액세스할 수 없으며, 모든 것은 플랫폼에서 관리한다. 

애저 펑션과 비슷한 부분도 있지만 스케일-투-제로 서버리스 옵션을 갖춘 ACA는 펑션을 대체하지 않는다. 대신에 더 복잡한 애플리케이션을 위한 홈으로 생각하는 게 가장 좋다. ACA 컨테이너는 수명이 제한돼 있지 않기 때문에 이를 장기간 실행되는 복잡한 애플리케이션이나 백그라운드 애플리케이션을 호스팅하는 데 사용할 수 있다. 

ACA 시작하기
ACA를 시작하는 방법은 비교적 간단하다. 애저 포털(Azure Portal)을 사용하거나, ARM 템플릿을 활용하거나, 애저 CLI(Azure CLI)를 통해 프로그래밍 방식으로 작업하면 된다. 

애저 포털을 살펴보자면 애저 리소스 그룹에 앱 환경과 연결된 모니터링 및 스토리지를 설정해 시작할 수 있다. 이 앱 환경은 서비스의 격리 경계이며, 배포된 컨테이너에 로컬 네트워크를 자동으로 구성한다. 그다음 사용자 환경에 관한 로그 애널리틱스 작업 공간을 생성한다.

컨테이너에는 0.25개의 코어와 컨테이너당 0.5GB의 메모리부터 시작해 최대 2개의 코어와 4GB 메모리가 할당된다. 부분 코어는 공유 테넌트를 사용한 결과다. 이를 통해 마이크로소프트는 고밀도 ACA 환경을 실행할 수 있어 소규모 이벤트 기반 컨테이너에 애저 리소스를 효율적으로 사용할 수 있다고 설명했다. 

컨테이너는 애저 컨테이너 레지스트리(Azure Container Registry) 또는 도커 허브(Docker Hub)를 포함한 기타 퍼블릭 레지스트리에서 로드된다. 이 접근법을 사용하면 기존 CI/CD 파이프라인에서 ACA를 대상으로 지정하여, 패키징된 컨테이너를 ACA에서 바로 사용할 수 있는 레지스트리에 제공할 수 있다. 

현재는 리눅스 기반 컨테이너만 지원하지만 닷넷, 노드닷제이에스, 파이썬을 지원하므로 앱이나 서비스를 ACA 지원 컨테이너로 빠르게 이식할 수 있으리라 예상된다.

컨테이너를 선택하면 HTTPS 연결을 위해 외부 액세스를 허용할 수 있다. VNets 또는 로드 밸런서 등의 애저 네트워킹 기능을 추가하고 구성할 필요가 없다. 필요한 경우 서비스에서 자동으로 추가된다. 

애저 CLI를 사용하여 Dapr 작업 및 확장하기
Dapr을 사용해 구축된 복잡한 애플리케이션은 애저 CLI를 통해 구성해야 한다. CLI로 작업하려면 확장 기능을 추가하여 새로운 네임스페이스를 활성화해야 한다. 

이 서비스는 아직 프리뷰 상태이기 때문에 마이크로소프트 애저 블롭(Microsoft Azure Blob)에서 CLI 확장 기능을 로드해야 한다. 포털과 마찬가지로 ACA 환경과 로그 애널리틱스 작업 공간을 생성한다. 

먼저 애플리케이션에 적합한 구성 YAML 파일과 함께, 서비스에 배포된 Dapr 앱에 대해 애저 블록 스토리지(Azure Blob Storage) 계정에 상태 저장소를 설정한다. 여기에는 애플리케이션 상태를 관리하는 Dapr 사이드카에 대한 포인터와 애플리케이션 컨테이너의 세부사항이 포함돼야 한다.

이제 한 줄의 코드를 사용해 원격 레지스트리에서 애플리케이션 컨테이너를 배포하여 리소스 그룹에 추가하고, 모든 Dapr 기능을 활성화할 수 있다. 이와 동시에 서비스가 앱을 확장하는 방법을 관리할 수 있도록 최소 및 최대 복제본 수를 구성할 수 있다. 

현재 최대 25개의 복제본으로 제한되며, 0으로 조정하는 옵션도 있다. 주의해야 할 점은 새 복제본을 실행할 때 시작 시간이 있다는 것이다. 따라서 항상 단일 복제본을 실행하는 게 좋다. 하지만 그렇게 되면 ACA의 유휴 요금으로 해당 리소스 사용 비용이 청구된다.

그다음 확장 트리거를 JSON 구성 파일에서 규칙으로 정의할 수 있다. HTTP 요청(예: REST API 마이크로서비스를 실행할 때 등)의 경우 인스턴스가 처리할 수 있는 동시 요청 수를 선택할 수 있다. 해당 제한을 초과하는 즉시 ACA가 사전 설정된 제한에 도달할 때까지 새 컨테이너 복제본을 시작한다. 이벤트 기반 확장은 KEDA 메타데이터를 사용하여 적용할 규칙을 결정한다.

애플리케이션을 확장하는 데 사용되는 이벤트의 이름, 사용 중인 서비스 유형, 확장에 사용된 메타데이터 및 트리거를 선택한다. 예를 들어 메시지 대기열이 최대 대기열 길이에 도달하면 새 컨테이너 복제본이 시작돼 대기열에 연결된다. 

다른 확장 옵션을 사용하면 표준 쿠버네티스 기능을 바탕으로 CPU 및 메모리 사용량을 활용해 확장할 수 있다. 이는 스케일 아웃 시스템이며, 컨테이너에 할당된 리소스는 변경할 수 없다.

더 ‘단순’해진 쿠버네티스
이는 장점이 많다. ACA는 쿠버네티스 애플리케이션 구성 및 관리를 단순화한다. 컨테이너를 기본 애플리케이션 단위로 간주하고, Dapr 등의 기술을 활용하여 표준 쿠버네티스 환경과 ACA에서 모두 실행되는 애플리케이션을 구축할 수 있다. 

구성도 간단하다. 애플리케이션과 확장 방법에 관한 기본적인 정의를 통해 완전한 데브옵스(DevOps) 팀 없이 확장 가능한 클라우드 네이티브 애플리케이션을 신속하게 제공할 수 있다.

애저는 서비스형 플랫폼 도구를 위한 호스트로 개발됐으며, ACA는 이러한 비전의 최신 인스턴스화다. 본래 애저 앱 서비스가 특정 API 및 런타임으로 제한됐다면 ACA는 훨씬 더 넓은 범위를 지원해 코드를 컨테이너에 넣는 것만큼이나 간단하게 클라우드 네이티브로 전환할 수 있는 프레임워크를 제공한다. ciokr@idg.co.kr