Share via

Azure 컨테이너 서비스 선택에 대한 일반적인 아키텍처 고려 사항

  • 아티클

이 문서에서는 Azure 컨테이너 서비스를 선택하는 프로세스를 안내합니다. 일부 워크로드에 일반적이고 중요한 기능 수준 고려 사항에 대한 개요를 제공합니다. 워크로드가 안정성, 보안, 비용 최적화, 운영 우수성 및 성능 효율성에 대한 요구 사항을 충족하는지 확인하는 데 도움이 될 수 있습니다.

참고 항목

이 문서는 Azure 컨테이너 서비스 선택으로 시작하는 시리즈의 2부입니다. 이러한 아키텍처 고려 사항에 대한 컨텍스트를 얻으려면 먼저 해당 개요 문서를 읽는 것이 좋습니다.

개요

이 문서의 고려 사항은 다음 네 가지 범주로 나뉩니다.

아키텍처 및 네트워크 고려 사항

  • 운영 체제 지원
  • 네트워크 주소 공간
  • 트래픽 흐름 이해
  • 서브넷 계획
  • 사용 가능한 수신 IP 수
  • 사용자 정의 경로 및 NAT 게이트웨이 지원
  • 프라이빗 네트워킹 통합
  • 프로토콜 검사
  • 부하 분산
  • 서비스 검색
  • 사용자 지정 do기본 및 관리형 TLS
  • 상호 TLS
  • 특정 Azure 서비스에 대한 네트워킹 개념

보안 고려 사항

  • 네트워크 정책을 사용하여 클러스터 내 트래픽에 대한 보안 제공
  • 네트워크 보안 그룹
  • Azure Key Vault 통합
  • 관리 ID 지원
  • Defender for Containers를 사용하여 위협 방지 및 취약성 평가
  • 보안 기준
  • Azure Well-Architected Framework for Security

운영 고려 사항

  • 업데이트 및 패치
  • 컨테이너 이미지 업데이트
  • 수직 인프라 확장성
  • 수평 인프라 확장성
  • 애플리케이션 확장성
  • 가시성
  • 운영 우수성을 위한 잘 설계된 프레임워크

안정성 고려 사항

  • 서비스 수준 약정
  • 가용성 영역을 통한 중복성
  • 상태 검사 및 자가 치유
  • 가동 중지 시간 애플리케이션 배포 0개
  • 리소스 한계
  • 안정성을 위한 잘 설계된 프레임워크

이 문서에서는 웹 애플리케이션 및 API, 네트워킹, 관찰 가능성, 개발자 도구 및 작업에 대한 완성도 높은 기능 집합인 AKS(Azure Kubernetes Service), Azure Container Apps 및 Web App for Containers를 제공하는 Azure 컨테이너 서비스의 하위 집합에 중점을 둡니다. 모든 Azure 컨테이너 서비스의 전체 목록은 컨테이너 서비스 제품 범주 페이지를 참조 하세요.

참고 항목

이 가이드에서 워크로드라는 용어는 비즈니스 목표 또는 비즈니스 프로세스 실행을 지원하는 애플리케이션 리소스 컬렉션을 나타냅니다. 워크로드는 API 및 데이터 저장소와 같은 여러 구성 요소를 사용하여 특정 엔드투엔드 기능을 제공합니다.

아키텍처 고려 사항

이 섹션에서는 상당한 가동 중지 시간 또는 다시 배포 없이는 되돌리거나 수정하기 어려운 아키텍처 결정에 대해 설명합니다. 특히 네트워킹 및 보안과 같은 기본 구성 요소에 대해 이 고려 사항을 염두에 두어야 합니다.

이러한 고려 사항은 잘 설계된 프레임워크 핵심 요소에만 국한되지 않습니다. 그러나 Azure 컨테이너 서비스를 선택할 때 비즈니스 요구 사항에 대해 추가 조사 및 평가를 받을 자격이 있습니다.

운영 체제 지원

대부분의 컨테이너화된 애플리케이션은 모든 Azure 컨테이너 서비스에서 지원되는 Linux 컨테이너에서 실행됩니다. Windows 컨테이너가 필요한 워크로드 구성 요소에 대한 옵션은 더 제한적입니다.

Container Apps AKS Web App for Containers
Linux 지원 ✅ ✅ ✅
Windows 지원 ❌ ✅ ✅
혼합 OS 지원 ❌ ✅ ❌*

*Web App for Containers에 대한 혼합 OS 지원에는 Windows 및 Linux에 대한 별도의 Azure 앱 Service 계획이 필요합니다.

네트워킹 고려 사항

보안 및 규정 준수 제약 조건 및 부과된 지침으로 인해 계획 프로세스 초기에 네트워킹 디자인을 이해하는 것이 중요합니다. 일반적으로 이 가이드에서 다루는 Azure 서비스 간의 주요 차이점은 기본 설정에 따라 달라집니다.

  • Container Apps는 서비스 검색 및 내부 관리되는 작업기본 같은 많은 Azure 관리 네트워킹 기능을 제공하는 PaaS 제품입니다. 좀 더 구성이 필요한 워크로드 팀은 네트워킹 옵션을 최대화하는 대안을 고려하기 전에 워크로드/전용 프로필을 사용할 수 있습니다.
  • AKS 는 세 가지 서비스 중 가장 구성 가능한 서비스이며 네트워크 흐름을 가장 많이 제어합니다. 예를 들어 Kubernetes 네트워크 정책을 통해 사용자 지정 수신 컨트롤러 및 클러스터 내 트래픽 제어를 제공합니다. 워크로드 팀은 다양한 Azure 관리 형 네트워킹 추가 기능을 활용할 뿐만 아니라 광범위한 Kubernetes 에코시스템에서 모든 추가 기능을 설치하고 운영할 수 있습니다.
  • 컨테이너용 웹앱은 App Service의 기능입니다. 따라서 네트워킹 개념, 특히 프라이빗 네트워킹 통합은 App Service와 매우 관련이 있습니다. 이 서비스는 이미 App Service를 사용하는 워크로드 팀에 익숙할 것입니다. App Service에 대한 경험이 없고 더 친숙한 Azure 가상 네트워크 통합을 원하는 팀은 Container Apps를 고려하는 것이 좋습니다.

네트워킹은 기본 인프라 계층입니다. 워크로드를 다시 배포하지 않고 디자인을 변경하기 어려서 가동 중지 시간이 발생할 수 있습니다. 따라서 워크로드에 특정 네트워킹 요구 사항이 있는 경우 Azure 컨테이너 서비스 선택 범위를 좁히기 전에 이 섹션을 주의 깊게 검토하세요.

네트워크 주소 공간

애플리케이션을 가상 네트워크에 통합하는 경우 컨테이너 인스턴스에 충분한 IP 주소를 사용할 수 있도록 일부 IP 주소 계획을 수행해야 합니다. 이 프로세스 중에 추가 IP 주소를 사용하는 추가 인스턴스가 배포되는 업데이트, 파란색/녹색 배포 및 유사한 상황에 대한 추가 주소를 계획합니다.

Container Apps AKS Web App for Containers
전용 서브넷 소비 계획: 선택 사항
전용 플랜: 필수		 Required 선택 사항
IP 주소 요구 사항 소비 계획: 소비 전용 환경을 참조하세요.
전용 계획: 워크로드 프로필 환경을 참조 하세요.		 AKS용 Azure 가상 네트워크를 참조하세요. App Service 서브넷 요구 사항을 참조 하세요.

AKS 요구 사항은 선택한 네트워크 플러그 인에 따라 달라집니다. AKS용 일부 네트워크 플러그 인에는 더 광범위한 IP 예약이 필요합니다. 세부 정보는 이 문서의 범위를 벗어납니다. 자세한 내용은 AKS에 대한 네트워킹 개념을 참조하세요.

트래픽 흐름 이해

솔루션에 필요한 트래픽 흐름 유형은 네트워크 디자인에 영향을 줄 수 있습니다.

다음 섹션에서는 다양한 네트워킹 제약 조건에 대한 정보를 제공합니다. 이러한 제약 조건은 필요한지 여부에 따라 추가 서브넷을 배포해야 하는 필요성에 영향을 줍니다.

  • 여러 공동 배치된 워크로드.
  • 프라이빗 및/또는 공용 수신입니다.
  • 클러스터(Container Apps 및 AKS의 경우) 또는 가상 네트워크 내에서(모든 Azure 컨테이너 서비스의 경우) 동서 트래픽의 액세스 제어 흐름입니다.

서브넷 계획

워크로드에 애플리케이션 인스턴스를 포함할 수 있을 만큼 큰 서브넷이 있는지 확인하는 것만이 이러한 애플리케이션이 배포되는 네트워크 공간을 결정하는 유일한 요소는 아닙니다.

Container Apps AKS Web App for Containers
서브넷 내에서 공동 배치된 워크로드에 대한 지원* ❌* ✅ N/A*

*기술적인 제한이 아닌 모범 사례를 설명합니다.

Container Apps의 경우 서브넷 통합은 단일 Container Apps 환경에만 적용됩니다. 각 Container Apps 환경은 단일 수신 IP, 공용 또는 프라이빗으로 제한됩니다.

각 Container Apps 환경은 종속 애플리케이션이 공동 배치되는 단일 워크로드에만 사용됩니다. 따라서 공용 및 프라이빗 수신이 모두 필요한 경우 수신 부하 분산을 위해 추가 Azure 네트워킹 어플라이언스 도입해야 합니다. 예로는 Azure 애플리케이션 게이트웨이 및 Azure Front Door가 있습니다. 또한 분리해야 하는 워크로드가 여러 개 있는 경우 추가 Container Apps 환경이 필요하므로 각 환경에 대해 추가 서브넷을 할당해야 합니다.

AKS는 Kubernetes 네트워크 정책의 형태로 클러스터 내에서 세분화된 동서 네트워크 흐름 제어를 제공합니다. 이 흐름 제어를 사용하면 동일한 클러스터 내에서 서로 다른 네트워크 보안 경계를 사용하여 여러 워크로드를 분할할 수 있습니다.

컨테이너용 웹앱의 경우 서브넷이 충분히 크면 단일 서브넷과 통합할 수 있는 앱 수에 대한 제약 조건이 없습니다. 동일한 가상 네트워크에 있는 웹앱 간의 액세스 제어에 대한 모범 사례는 없습니다. 각 웹앱은 각각 가상 네트워크 또는 인터넷에서 동서 또는 남북 트래픽에 대한 액세스 제어를 독립적으로 관리합니다.

참고 항목

리소스가 배포된 서브넷의 크기는 조정할 수 없습니다. 전체 워크로드 구성 요소를 다시 배포할 필요가 없도록 네트워크를 계획할 때는 주의해야 합니다. 이로 인해 가동 중지 시간이 발생할 수 있습니다.

사용 가능한 수신 IP 수

다음 표에서는 이전 서브넷 계획 섹션을 고려하여 Azure 컨테이너 서비스의 단일 배포에서 호스트되는 임의 수의 애플리케이션에 대해 노출될 수 있는 IP 수를 정의합니다.

Container Apps AKS Web App for Containers
수신 IP 수 하나 많은 App Service Environment: 1
App Service Environment 없음: 다

Container Apps는 환경, 퍼블릭 또는 프라이빗당 하나의 IP를 허용합니다. AKS는 개수에 관계없이 공용 또는 프라이빗 IP를 허용합니다. App Service Environment 외부의 컨테이너용 웹앱은 App Service 계획 내의 모든 앱에 대해 하나의 공용 IP와 Azure 프라이빗 엔드포인트를 사용하는 여러 개인 IP를 허용합니다.

App Service Environment에 통합된 웹앱은 퍼블릭이든 프라이빗이든 App Service Environment와 연결된 단일 수신 IP를 통해서만 트래픽을 수신한다는 점에 유의해야 합니다.

사용자 정의 경로 및 NAT 게이트웨이 지원

워크로드에 세분화된 네트워킹 제어를 위한 UDR(사용자 정의 경로) 및 NAT 게이트웨이 기능이 필요한 경우 Container Apps는 워크로드 프로필을 사용해야 합니다. ACA에 대한 사용 전용 계획에서는 UDR 및 NAT 게이트웨이 호환성을 사용할 수 없습니다.

AKS 및 Web App for Containers는 각각 표준 가상 네트워크 기능 또는 가상 네트워크 통합을 통해 이러한 두 네트워킹 기능을 구현합니다. 자세히 설명하면 App Service Environment의 AKS 노드 풀 및 Web App for Containers는 이미 가상 네트워크 리소스를 직접 제공합니다. App Service Environment에 없는 컨테이너용 웹앱은 가상 네트워크 통합을 통해 UDR 및 NAT 게이트웨이를 지원합니다. 가상 네트워크 통합을 통해 리소스는 기술적으로 가상 네트워크에 직접 상주하지 않지만 모든 아웃바운드 액세스는 가상 네트워크를 통해 흐르며 네트워크의 연결된 규칙은 예상대로 트래픽에 영향을 줍니다.

Container Apps AKS Web App for Containers
UDR 지원 사용량 전용 플랜: ❌
워크로드 프로필 계획: ✅		 ✅ ✅
NAT 게이트웨이 지원 사용량 전용 플랜: ❌
워크로드 프로필 계획: ✅		 ✅ ✅

프라이빗 네트워킹 통합

수신 및 송신 모두에 엄격한 계층 4 프라이빗 네트워킹이 필요한 워크로드의 경우 워크로드가 자체 관리형 가상 네트워크에 배포되는 Container Apps, AKS 및 단일 테넌트 App Service Environment SKU를 고려하여 사용자 지정 세분화된 프라이빗 네트워킹 컨트롤을 제공해야 합니다.

Container Apps AKS Web App for Containers
가상 네트워크로의 프라이빗 수신 ✅ ✅ 프라이빗 엔드포인트를 통해
가상 네트워크에서 프라이빗 송신 ✅ ✅ 가상 네트워크 통합을 통해
완전히 표시되지 않는 퍼블릭 엔드포인트 ✅ ✅ App Service Environment만
Web App for Containers를 사용하는 프라이빗 네트워킹

Web App for Containers는 이 문서에 설명된 다른 Azure 서비스와 동일한 방식으로 표시되지 않는 추가 네트워킹 기능을 제공합니다. 엄격한 프라이빗 네트워킹 요구 사항을 구현하기 위해 워크로드 팀은 이러한 네트워킹 개념을 숙지해야 합니다. 다음 네트워킹 기능을 신중하게 검토합니다.

PaaS 솔루션을 원하고 여러 Azure 솔루션에서 공유되는 네트워킹 개념을 선호하는 경우 Container Apps를 고려해야 합니다.

프로토콜 검사

호스팅 플랫폼의 중요한 고려 사항은 들어오는 애플리케이션 요청(수신)에 대해 지원되는 네트워킹 프로토콜입니다. 컨테이너용 웹앱은 HTTP 및 HTTPS만 지원하는 가장 엄격한 옵션입니다. 컨테이너 앱은 들어오는 TCP 연결을 추가로 허용합니다. AKS는 자체 선택한 포트에서 TCP 및 UDP의 무제한 사용을 지원하는 가장 유연합니다.

Container Apps AKS Web App for Containers
프로토콜 및 포트 지원 HTTP(포트 80)*
HTTPS(포트 443)*
TCP(포트 1-65535( 80 및 443 제외)		 TCP(모든 포트)
UDP(모든 포트)		 HTTP(포트 80)
HTTPS(포트 443)
WebSocket 지원 ✅ ✅ ✅
HTTP/2 지원 ✅ ✅ ✅

*Container Apps 환경에서 는 클러스터 내 통신을 위해 모든 포트 에 HTTP/S를 노출할 수 있습니다. 이 시나리오에서는 CORS 및 세션 선호도와 같은 기본 제공 Container Apps HTTP 기능이 적용되지 않습니다.

Container Apps와 Web App for Containers는 모두 기본 제공 HTTPS 수신에 대해 TLS 1.2를 지원합니다.

부하 분산

Container Apps 및 Web App for Containers를 사용하면 Azure는 계층 4 및 계층 7 부하 분산 장치를 완전히 추상화합니다.

반면 AKS는 Azure가 Kubernetes API와 상호 작용하여 워크로드 팀이 구성하는 기본 Azure 인프라를 관리하는 공유 책임 모델을 사용합니다. AKS의 계층 7 부하 분산의 경우 AKS 관리형 애플리케이션 라우팅 추가 기능 또는 컨테이너용 Application Gateway와 같은 Azure 관리형 옵션을 선택하거나 원하는 수신 컨트롤러를 배포하고 자체 관리할 수 있습니다.

Container Apps AKS Web App for Containers
계층 4 부하 분산 장치 Azure 관리형 공동 책임 Azure 관리형
계층 7 부하 분산 장치 Azure 관리형 공유 또는 자체 관리 Azure 관리형

서비스 검색

클라우드 아키텍처에서는 리소스의 균형을 다시 조정하기 위해 언제든지 런타임을 제거하고 다시 만들 수 있으므로 인스턴스 IP 주소가 정기적으로 변경됩니다. 이러한 아키텍처는 안정적이고 일관된 통신을 위해 FQDN(정규화된 do기본 이름)을 사용합니다.

Container Apps AKS Web App for Containers
서비스 검색 Azure 관리형 FQDN Kubernetes 구성 가능 Azure 관리형 FQDN

Web Apps for Containers는 공용 수신(남북 통신) FQDN을 기본으로 제공합니다. 추가 DNS 구성이 필요하지 않습니다. 그러나 다른 앱 간의 트래픽을 용이하게 하거나 제한하는 기본 제공 메커니즘은 없습니다(동서 통신).

또한 Container Apps는 공용 수신 FQDN을 제공합니다. 그러나 Container Apps는 앱 FQDN이 노출되도록 허용하고 환경 내에서만 트래픽을 제한하여 더욱 발전합니다. 이 기능을 사용하면 보다 쉽게 동서 통신을 관리하고 Dapr과 같은 구성 요소를 사용하도록 설정할 수 있습니다.

Kubernetes 배포는 클러스터 내부 또는 외부에서 처음에 검색할 수 없습니다. Kubernetes API에서 정의한 대로 Kubernetes 서비스를 만든 다음 주소 지정 가능한 방식으로 네트워크에 애플리케이션을 노출해야 합니다.

Important

Container Apps 및 AKS만 해당 환경 내에서 내부 DNS 체계를 통해 서비스 검색을 제공합니다. 이 기능은 개발/테스트 및 프로덕션 환경에서 DNS 구성을 간소화할 수 있습니다. 예를 들어 환경 또는 클러스터 내에서만 고유해야 하는 임의의 서비스 이름을 사용하여 이러한 환경을 만들 수 있으므로 개발/테스트 및 프로덕션에서 동일할 수 있습니다. Web App for Containers를 사용하면 Azure DNS와의 충돌을 방지하려면 여러 환경에서 서비스 이름이 고유해야 합니다.

사용자 지정 do기본 및 관리형 TLS

Container Apps와 Web App for Containers는 모두 사용자 지정 작업기본 및 인증서 관리를 위한 기본 제공 솔루션을 제공합니다.

Container Apps AKS Web App for Containers
사용자 지정 do기본s 구성 기본 제공 Byo 기본 제공
Azure FQDN용 관리되는 TLS 기본 제공 해당 없음 기본 제공
사용자 지정 do기본s에 대한 관리형 TLS 미리 보기 상태 Byo 기본 제공 또는 BYO

AKS 사용자는 사용자 지정 작업에 대한 DNS, 클러스터 구성 및 TLS 인증서를 관리할 책임이 기본. AKS는 관리형 TLS를 제공하지 않지만, 고객은 Kubernetes 에코시스템의 소프트웨어(예: 인기 있는 인증서 관리자 )를 활용하여 TLS 인증서를 관리할 수 있습니다.

상호 TLS

들어오는 트래픽을 제한하는 또 다른 대안은 mTLS(상호 TLS)입니다. 상호 TLS는 통신 중인 클라이언트와 서버가 모두 인증되도록 하는 보안 프로토콜입니다. 인증을 수행하기 위해 두 당사자는 데이터를 전송하기 전에 인증서를 교환하고 확인합니다.

Web App for Containers는 들어오는 클라이언트 연결에 대한 기본 제공 mTLS 지원을 제공합니다. 그러나 애플리케이션은 App Service 플랫폼이 전달하는 HTTP 헤더에 X-ARR-ClientCert 액세스하여 인증서의 유효성을 검사해야 합니다.

Container Apps는 mTLS에 대한 기본 제공 지원도 제공합니다. 클라이언트 인증서를 HTTP 헤더 X-Forwarded-Client-Cert의 애플리케이션에 전달합니다. 또한 단일 환경에서 앱 간의 내부 통신에 자동 mTLS를 쉽게 사용하도록 설정할 수 있습니다.

AKS의 상호 TLS는 Istio 기반 서비스 메시를 통해 들어오는 클라이언트 연결 및 서비스 간 클러스터 내 통신에 대한 mTLS 기능을 포함하는 관리되는 추가 기능으로 구현할 수 있습니다. 워크로드 팀은 Kubernetes 에코시스템에서 다른 서비스 메시 제품을 설치하고 관리하도록 선택할 수도 있습니다. 이러한 옵션은 Kubernetes에서 mTLS 구현을 가장 유연하게 만듭니다.

서비스별 네트워킹 개념

앞의 섹션에서는 고려해야 할 가장 일반적인 고려 사항 중 일부를 설명합니다. 자세한 내용 및 개별 Azure 컨테이너 서비스와 관련된 네트워킹 기능에 대한 자세한 내용은 다음 문서를 참조하세요.

이전 섹션에서는 네트워크 디자인에 초점을 맞춥니다. 네트워킹 보안 및 네트워크 트래픽 보안에 대해 자세히 알아보려면 다음 섹션을 계속 진행하세요.

보안 고려 사항

보안 위험을 해결하지 못하면 무단 액세스, 데이터 위반 또는 중요한 정보가 유출될 수 있습니다. 컨테이너는 애플리케이션에 캡슐화된 환경을 제공합니다. 그러나 호스팅 시스템과 기본 네트워크 오버레이에는 추가 가드레일이 필요합니다. 선택한 Azure 컨테이너 서비스는 각 애플리케이션을 개별적으로 보호하기 위한 특정 요구 사항을 지원하고 무단 액세스를 방지하고 공격 위험을 완화하기 위한 적절한 보안 조치를 제공해야 합니다.

보안 비교 개요

Container Apps, AKS 및 Web App for Containers를 비롯한 대부분의 Azure 서비스는 Key Vault 및 관리 ID를 비롯한 주요 보안 제품과 통합됩니다.

이 가이드의 서비스 중 AKS는 구성 옵션을 통해 보안을 설정할 수 있는 기본 구성 요소를 표시하여 가장 구성성 및 확장성을 부분적으로 제공합니다. 예를 들어 고객은 Kubernetes API 서버에 대한 로컬 계정을 사용하지 않도록 설정하거나 구성 옵션을 통해 기본 노드에 대한 자동 업데이트를 설정할 수 있습니다.

자세한 비교를 위해 다음 고려 사항을 주의 깊게 검토하여 워크로드 보안 요구 사항을 충족할 수 있는지 확인합니다.

Kubernetes 컨트롤 플레인 보안

AKS는 컨테이너 오케스트레이션을 사용자 지정할 수 있도록 Kubernetes API에 대한 모든 권한을 제공하여 이 문서에서 고려한 세 가지 옵션 중 가장 유연하게 사용할 수 있습니다. 그러나 Kubernetes API에 대한 이 액세스는 중요한 공격 표면을 나타내며 이를 보호해야 합니다.

Important

이 섹션은 Azure Resource Manager API를 컨트롤 플레인으로 사용하는 Web App for Containers와는 관련이 없습니다.

ID 기반 보안

고객은 API에 대한 ID 기반 액세스를 보호해야 합니다. Kubernetes는 액세스 제어로 보호해야 하는 자체 인증 및 권한 부여 관리 시스템을 제공합니다.

Azure에서 ID 및 액세스 관리를 위해 단일 유리 평면을 활용하려면 Kubernetes 특정 로컬 계정을 사용하지 않도록 설정하고 대신 Kubernetes용 Azure RBAC와 AKS 관리형 Microsoft Entra 통합을 구현하는 것이 좋습니다. 이 모범 사례를 구현하는 경우 관리자는 여러 플랫폼에서 ID 및 액세스 관리를 수행할 필요가 없습니다.

Container Apps AKS
Kubernetes API 액세스 제어 권한 없음 모든 권한

Container Apps를 사용하는 고객은 Kubernetes API에 액세스할 수 없습니다. Microsoft는 이 API에 대한 보안을 제공합니다.

네트워크 기반 보안

Kubernetes 컨트롤 플레인에 대한 네트워크 액세스를 제한하려면 두 가지 옵션을 제공하는 AKS를 사용해야 합니다. 첫 번째 옵션은 API 서버의 프라이빗 네트워크와 AKS 클러스터의 프라이빗 네트워크 간에 Azure Private Link를 사용하는 프라이빗 AKS 클러스터를 사용하는 것입니다. 두 번째 옵션은 API 서버 VNet 통합(미리 보기)입니다. 여기서 API 서버는 위임된 서브넷에 통합됩니다. 자세한 내용은 설명서를 참조하세요.

Kubernetes API에 대한 네트워크 제한 액세스를 구현하는 데는 결과가 있습니다. 특히 프라이빗 네트워크 내에서만 관리를 수행할 수 있습니다. 일반적으로 Azure DevOps 또는 GitHub Actions에 대한 자체 호스팅 에이전트를 배포해야 합니다. 다른 제한 사항에 대한 자세한 내용은 제품별 설명서를 참조하세요.

Container Apps AKS
Kubernetes API 네트워크 보안 PaaS에서 구성할 수 없음 구성 가능: 공용 IP 또는 개인 IP

이러한 고려 사항은 Container Apps에 적용되지 않습니다. PaaS이므로 Microsoft는 기본 인프라를 추상화합니다.

데이터 평면 네트워크 보안

다음 네트워킹 기능을 사용하여 워크로드에 대한 액세스, 시작 및 내 액세스를 제어할 수 있습니다.

네트워크 정책을 사용하여 클러스터 내 트래픽에 대한 보안 제공

일부 보안 태세는 다중 테넌트 환경을 사용하여 여러 또는 다중 계층 애플리케이션을 호스트하는 경우와 같이 환경 내에서 네트워크 트래픽을 분리해야 합니다. 이러한 시나리오에서는 AKS를 선택하고 Kubernetes 클러스터 내에서 계층 4 네트워킹의 세분화된 구성을 가능하게 하는 클라우드 네이티브 기술인 네트워크 정책을 구현해야 합니다.

Container Apps AKS Web App for Containers
네트워크 정책 소비 계획: ❌
전용 플랜: ❌		 ✅ ❌

이 문서에 설명된 세 가지 Azure 서비스 중 AKS는 클러스터 내에서 추가 워크로드 격리를 지원하는 유일한 서비스입니다. 컨테이너 앱 또는 Web App for Containers에서는 네트워크 정책이 지원되지 않습니다.

네트워크 보안 그룹

모든 시나리오에서 네트워크 보안 그룹을 사용하여 더 넓은 가상 네트워크 내에서 네트워킹 통신을 규제할 수 있으며, 이를 통해 가상 네트워크 수준에서 수신 및 송신을 규제하는 계층 4 트래픽 규칙을 사용할 수 있습니다.

Container Apps AKS Web App for Containers
네트워크 보안 그룹 소비 계획: ✅
전용 플랜: ✅		 ✅ ✅ VNet 통합 앱: 송신 전용

수신에 대한 IP 제한 사항

일반적으로 네트워크 트래픽 제한은 위에서 설명한 계층 4 규칙을 통해 적용됩니다. 그러나 가상 네트워크 통합이 없는 애플리케이션의 PaaS 시나리오에서는 애플리케이션 계층에서 트래픽을 제한하는 것이 유용할 수 있습니다.

Container Apps 및 Web App for Containers는 개별 애플리케이션의 수신 트래픽에 대한 기본 제공 원본 IP 제한을 제공합니다.

Container Apps AKS Web App for Containers
애플리케이션 계층에 대한 수신 IP 제한 기본 제공 자체 관리형 또는 관리되는 추가 기능을 통해 기본 제공
리소스 사용량 - 클러스터 리소스 사용 -

AKS 워크로드의 경우 구현은 선택한 수신 컨트롤러에 따라 달라집니다. 자체 관리형 및 Azure 관리 형 애플리케이션 라우팅 추가 기능 모두 클러스터 리소스를 사용합니다.

애플리케이션 수준 보안

네트워크 및 인프라 수준뿐만 아니라 워크로드 및 애플리케이션 수준에서도 워크로드를 보호해야 합니다. Azure 컨테이너 솔루션은 Azure 보안 제품과 통합되어 애플리케이션에 대한 보안 구현 및 제어를 표준화하는 데 도움이 됩니다.

Key Vault 통합

이러한 구성 요소에 대한 향상된 보안을 제공하는 Key Vault와 같은 키 관리 솔루션에 비밀, 키 및 인증서를 저장하고 관리하는 것이 가장 좋습니다. 코드 또는 Azure 컴퓨팅 서비스에 비밀을 저장하고 구성하는 대신 모든 애플리케이션이 Key Vault와 통합되어야 합니다.

Key Vault 통합을 사용하면 애플리케이션 개발자가 애플리케이션 코드에 집중할 수 있습니다. 이 문서에 설명된 세 가지 Azure 컨테이너 서비스는 모두 Key Vault 서비스의 비밀을 자동으로 동기화하고 애플리케이션에 제공할 수 있습니다(일반적으로 환경 변수 또는 탑재된 파일).

Container Apps AKS Web App for Containers
Key Vault 통합 ✅ ✅ ✅

자세한 내용은 다음을 참조하세요.

관리 ID 지원

할당된 관리 ID가 있는 애플리케이션은 암호 없이 Azure 리소스에 액세스할 수 있습니다. 이 가이드에 멘션 모든 컨테이너 서비스는 관리 ID를 지원합니다.

Container Apps AKS Web App for Containers
관리 ID 지원 ✅ ✅ ✅

자세한 내용은 다음을 참조하세요.

Defender for Containers를 사용하여 위협 방지 및 취약성 평가

취약성에 대한 위협 방지도 중요합니다. Defender for Containers를 사용하는 것이 가장 좋습니다. 취약성 평가는 Azure 컨테이너 레지스트리에서 지원되므로 이 문서에 설명된 것뿐만 아니라 모든 Azure 컨테이너 서비스에서 사용할 수 있습니다. 그러나 Defender for Containers 런타임 보호는 AKS에만 사용할 수 있습니다.

AKS는 네이티브 Kubernetes API를 노출하므로 Kubernetes 에코시스템의 Kubernetes 특정 보안 도구를 사용하여 클러스터 보안을 평가할 수도 있습니다.

Container Apps AKS Web App for Containers
런타임 위협 방지 ❌ ✅ ❌

자세한 내용은 클라우드용 Defender의 컨테이너 지원 매트릭스를 참조하세요.

컨테이너 이미지 취약성 평가는 실시간 검사가 아닙니다. Azure 컨테이너 레지스트리는 정기적으로 검사됩니다.

보안 기준

일반적으로 대부분의 Azure 컨테이너 서비스는 Azure 보안 제품을 통합합니다. 전반적으로 보안 기능 집합은 클라우드 보안을 구현하는 데 작은 부분일 뿐입니다. 컨테이너 서비스에 대한 보안을 구현하는 방법에 대한 자세한 내용은 다음 서비스별 보안 기준을 참조하세요.

보안 기준은 이 문서의 범위를 벗어난 하드웨어 암호화 및 로깅을 포함한 다른 Azure 통합을 다룹니다.

보안에 대한 잘 설계된 프레임워크

이 문서에서는 여기에 설명된 컨테이너 서비스 기능 간의 기본 차이점에 중점을 둡니다.

AKS에 대한 자세한 보안 지침은 잘 설계된 프레임워크 검토 - AKS를 참조 하세요.

운영상의 고려 사항

프로덕션 환경에서 워크로드를 성공적으로 실행하려면 팀은 중앙 집중식 로깅, 모니터링, 확장성, 정기적인 업데이트 및 패치, 이미지 관리를 비롯한 운영 우수성 사례를 구현해야 합니다.

업데이트 및 패치

애플리케이션의 기본 OS를 업데이트하고 정기적으로 패치하는 것이 중요합니다. 그러나 모든 업데이트에 실패할 위험이 있음을 명심하세요. 이 섹션과 다음 섹션에서는 고객과 플랫폼 간의 공동 책임과 관련하여 세 가지 컨테이너 서비스에 대한 기본 고려 사항을 설명합니다.

관리되는 Kubernetes 서비스인 AKS는 노드 OS 및 컨트롤 플레인 구성 요소에 대해 업데이트된 이미지를 제공합니다. 그러나 워크로드 팀은 클러스터에 업데이트를 적용할 책임이 있습니다. 수동으로 업데이트를 트리거하거나 클러스터 자동 업그레이드 채널 기능을 활용하여 클러스터가 최신 상태인지 확인할 수 있습니다. AKS 클러스터의 패치 및 업그레이드에 대한 자세한 내용은 AKS 2일차 작업 가이드를 참조하세요.

컨테이너 앱 및 Web App for Containers는 PaaS 솔루션입니다. Azure는 업데이트 및 패치를 관리하므로 고객은 AKS 업그레이드 관리의 복잡성을 방지할 수 있습니다.

Container Apps AKS Web App for Containers
컨트롤 플레인 업데이트 플랫폼 고객 플랫폼
호스트 업데이트 및 패치 플랫폼 고객 플랫폼
컨테이너 이미지 업데이트 및 패치 고객 고객 고객

컨테이너 이미지 업데이트

Azure 컨테이너 솔루션에 관계없이 고객은 항상 자체 컨테이너 이미지를 담당합니다. 컨테이너 기본 이미지에 대한 보안 패치가 있는 경우 이미지를 다시 빌드해야 합니다. 이러한 취약성에 대한 경고를 받으려면 Container Registry에서 호스트되는 컨테이너에 Defender for Containers를 사용합니다.

확장성

크기 조정은 수요를 충족하도록 리소스 용량을 조정하는 데 사용되며, 성능을 보장하기 위해 더 많은 용량을 추가하고 사용하지 않는 용량을 제거하여 비용을 절감합니다. 컨테이너 솔루션을 선택할 때 인프라 제약 조건 및 크기 조정 전략을 고려해야 합니다.

수직 인프라 확장성

수직적 크기 조정 은 기존 인프라, 즉 CPU 및 메모리를 계산하는 기능을 의미합니다. 워크로드가 다르면 컴퓨팅 리소스의 양이 다릅니다. Azure 컨테이너 솔루션을 선택하는 경우 특정 Azure 서비스에 사용할 수 있는 하드웨어 SKU 제품을 알고 있어야 합니다. 이는 다양하며 추가 제약 조건을 적용할 수 있습니다.

AKS의 경우 Azure 설명서의 가상 머신 크기 및 지역별 AKS 제한을 검토합니다.

다음 문서에서는 다른 두 서비스에 대한 SKU 제품에 대한 세부 정보를 제공합니다.

수평 인프라 확장성

수평적 크기 조정 은 VM 노드와 같은 새로운 인프라를 통해 용량을 늘리거나 줄이는 기능을 의미합니다. 크기 조정이 증가하거나 감소하는 동안 Container Apps 사용 계층은 기본 가상 머신을 추상화합니다. Azure 컨테이너 서비스를 다시 기본 표준 Azure Resource Manager API를 사용하여 수평 크기 조정 전략을 관리합니다.

규모 확장 및 축소에는 인스턴스의 다시 분산이 포함되므로 가동 중지 시간 위험도 발생합니다. 위험은 수직적 크기 조정의 해당 위험보다 작습니다. 그럼에도 불구하고 워크로드 팀은 항상 애플리케이션이 오류를 처리할 수 있도록 하고 가동 중지 시간을 방지하기 위해 애플리케이션의 정상적인 시작 및 종료를 구현할 책임이 있습니다.

Container Apps AKS Web App for Containers
인프라 규모 감축 및 축소 소비 계획: 해당 사항
전용 계획: 구성 가능		 구성 가능 여부 구성 가능 여부
유연한 하드웨어 프로비전 소비 계획: 해당 사항
전용 계획: 워크로드 프로필을 사용하여 추상화됨		 모든 VM SKU 추상. App Service 계획을 참조하세요.

Important

Container Apps 전용 계획(워크로드 프로필) 및 Web App for Containers(App Service 계획)를 통해 사용할 수 있는 하드웨어 프로비저닝 옵션은 AKS만큼 유연하지 않습니다. 요구 사항이 충족되도록 각 서비스에서 사용할 수 있는 SKU를 숙지해야 합니다.

애플리케이션 확장성

인프라 및 애플리케이션의 크기 조정을 트리거하는 일반적인 측정값은 리소스 사용량(CPU 및 메모리)입니다. 일부 컨테이너 솔루션은 HTTP 요청과 같은 애플리케이션별 컨텍스트를 사용하여 메트릭에서 컨테이너 인스턴스 수를 조정할 수 있습니다. 예를 들어 AKS 및 Container Apps는 KEDA를 통한 메시지 큐 및 해당 스칼라를 통해 다른 많은 메트릭을 기반으로 컨테이너 인스턴스의 크기를 조정할 수 있습니다. 이러한 기능은 애플리케이션에 대한 확장성 전략을 선택할 때 유연성을 제공합니다. Web App for Containers는 Azure에서 제공하는 확장성 옵션에 의존합니다. (다음 표를 참조하세요.) Web App for Containers는 KEDA와 같은 사용자 지정 스케일러 구성을 지원하지 않습니다.

Container Apps AKS Web App for Containers
컨테이너 스케일 아웃 HTTP, TCP 또는 메트릭 기반(CPU, 메모리, 이벤트 기반). 메트릭 기반(CPU, 메모리 또는 사용자 지정). 수동, 메트릭 기반 또는 자동(미리 보기).
이벤트 기반 확장성 예. 클라우드 네이티브. 예. 클라우드 네이티브. 추가 구성이 필요합니다. 예. Azure 리소스 관련.

가시성

워크로드 계측

복잡하거나 다중 계층화된 애플리케이션에 대한 메트릭을 수집하는 것은 어려울 수 있습니다. 메트릭을 얻으려면 다음 두 가지 방법으로 컨테이너화된 워크로드를 Azure Monitor와 통합할 수 있습니다.

  • 자동 계측. 코드 변경이 필요 없습니다.
  • 수동 계측. SDK 및/또는 클라이언트를 통합하고 구성하는 데 필요한 최소한의 코드 변경 내용입니다.
Container Apps AKS Web App for Containers
플랫폼을 통한 자동 계측 ❌ ❌ 부분 지원*
에이전트를 통한 자동 계측 ❌ 부분 지원* 해당 없음
수동 계측 SDK 또는 OpenTelemetry를 통해 SDK 또는 OpenTelemetry를 통해 SDK 또는 OpenTelemetry를 통해

*AKS 및 Web App for Containers는 애플리케이션 언어에 따라 Linux 및 Windows 워크로드의 특정 구성에 대한 자동 계측을 지원합니다. 자세한 내용은 다음 문서를 참조하세요.

애플리케이션 코드 내의 계측은 애플리케이션 개발자의 책임이므로 Azure 컨테이너 솔루션과는 독립적입니다. 워크로드는 다음과 같은 솔루션을 사용할 수 있습니다.

로그

모든 Azure 컨테이너 서비스는 애플리케이션 및 플랫폼 로그 기능을 제공합니다. 애플리케이션 로그는 워크로드에 의해 생성되는 콘솔 로그입니다. 플랫폼 로그는 크기 조정 및 배포와 같이 애플리케이션 범위 외부의 플랫폼 수준에서 발생하는 이벤트를 캡처합니다.

컨테이너 서비스에 대한 로깅 기능 간의 기본 차이점은 플랫폼 로깅과 관련이 있습니다. 기록되는 항목 및 로그가 내부적으로 구성되는 방식. Azure Monitor는 이러한 서비스와 통합되는 Azure의 기본 로깅 서비스입니다. Monitor는 리소스 로그를 사용하여 다른 원본에서 오는 로그를 범주로 구분합니다. 각 Azure 서비스에서 사용할 수 있는 로그를 확인하는 한 가지 방법은 각 서비스에 사용할 수 있는 리소스 로그 범주를 확인하는 것입니다.

Container Apps AKS Web App for Containers
로그 스트리밍 지원(실시간 스트리밍) ✅ ✅ ✅
Azure Monitor 지원 ✅ ✅ ✅
Azure Monitor 리소스 로그 콘솔 및 시스템 Kubernetes API 서버, 감사, 스케줄러, 클러스터 자동 크기 조정기 등 ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs 등

테이블의 각 리소스 로그에 대한 자세한 설명을 보려면 테이블의 링크를 선택합니다.

컨테이너 서비스의 로깅 기능에 대한 간단한 요약은 다음과 같습니다.

  • Container Apps 는 모든 내부 Kubernetes 로그를 두 가지 범주로 추상화합니다. 콘솔 로그라고 하는 로그에는 워크로드 컨테이너 로그가 포함됩니다. 두 번째 시스템 범주에는 모든 플랫폼 관련 로그가 포함됩니다.
  • AKS 는 모든 Kubernetes 관련 로그와 로깅할 수 있는 항목에 대한 세부적인 제어를 제공합니다. 또한 kubectl과 같은 로그 스트리밍을 위한 Kubernetes 클라이언트 도구와의 완전한 호환성을 유지합니다.
  • Web App for Containers는 플랫폼(App Service)이 컨테이너 워크로드 전용이 아니므로 많은 범주의 리소스 로그를 제공합니다. 내부 Docker 플랫폼을 관리하는 컨테이너별 작업의 경우 AppServicePlatformLogs 로그 범주를 제공합니다. 또 다른 중요한 범주는 크기 조정 및 구성 변경과 같은 이벤트를 기록하는 AppServiceEnvironmentPlatformLogs입니다.

운영 우수성을 위한 잘 설계된 프레임워크

이 문서에서는 여기에 설명된 컨테이너 서비스 기능 간의 기본 차이점에 중점을 둡니다. 다음 서비스에 대한 전체 운영 우수성 지침을 검토하려면 다음 문서를 참조하세요.

안정성

안정성은 시스템이 오류에 대응하고 완전히 작동하는 기본 기능을 의미합니다. 애플리케이션 소프트웨어 수준에서 워크로드는 캐싱, 재시도, 회로 차단기 패턴 및 상태 검사 같은 모범 사례를 구현해야 합니다. 인프라 수준에서 Azure는 데이터 센터에서 하드웨어 오류 및 정전과 같은 물리적 오류를 처리합니다. 오류는 여전히 발생할 수 있습니다. 워크로드 팀은 적절한 Azure 서비스 계층을 선택하고 필요한 최소 인스턴스 구성을 적용하여 가용성 영역 간에 자동 장애 조치(failover)를 구현해야 합니다.

적절한 서비스 계층을 선택하려면 SLA(서비스 수준 계약) 및 가용성 영역의 작동 방식을 이해해야 합니다.

서비스 수준 약정

안정성은 일반적으로 SLA와 같은 비즈니스 기반 메트릭 또는 RTO(복구 시간 목표)와 같은 복구 메트릭에 의해 측정됩니다.

Azure에는 특정 서비스에 대한 많은 SLA가 있습니다. 오류는 항상 소프트웨어와 하드웨어, 그리고 자연에서 발생할 수 있기 때문에 100% 서비스 수준과 같은 것은 없습니다( 예: 폭풍과 지진). SLA는 보장이 아니라 재정적으로 지원되는 서비스 가용성 계약입니다.

최신 SLA 및 세부 정보는 Microsoft 라이선스 웹 사이트에서 Microsoft Online Services용 최신 SLA 문서를 다운로드합니다.

무료 및 유료 계층

일반적으로 Azure 서비스의 무료 계층은 SLA를 제공하지 않으므로 비프로덕션 환경에서 비용 효율적인 선택을 할 수 있습니다. 그러나 프로덕션 환경의 경우 SLA가 있는 유료 계층을 선택하는 것이 가장 좋습니다.

AKS에 대한 추가 요소

AKS에는 다양한 구성 요소 및 구성에 대해 서로 다른 SLA가 있습니다.

  • 컨트롤 플레인. Kubernetes API 서버에는 별도의 SLA가 있습니다.
  • 데이터 평면. 노드 풀은 기본 VM SKU SLA를 사용합니다.
  • 가용성 영역. AKS 클러스터에 가용성 영역이 활성화되어 있고 가용성 영역에서 여러 인스턴스를 실행하는지에 따라 두 평면에 대해 서로 다른 SLA가 있습니다.

여러 Azure 서비스를 사용하는 경우 복합 SLA는 개별 서비스 SLA 와 다르고 낮을 수 있습니다.

가용성 영역의 중복성

가용성 영역은 단일 지역 내에서 독립적인 전력, 냉각 등을 포함하는 고유한 데이터 센터입니다. 이로 인해 다중 지역 아키텍처를 구현할 필요 없이 오류 허용 오차가 증가합니다.

Azure에는 Azure가 데이터 센터 지역을 운영하는 모든 국가/지역에 가용성 영역이 있습니다. 여러 컨테이너 인스턴스가 가용성 영역을 교차하도록 허용하려면 가용성 영역 지원을 제공하는 SKU, 서비스 계층 및 지역을 선택해야 합니다.

기능 Container Apps AKS Web App for Containers
가용성 영역 지원 전체 전체 전체

예를 들어 하드웨어가 호스트되는 가용성 영역에서 문제가 발생하면 단일 인스턴스를 실행하도록 구성된 애플리케이션 또는 인프라를 사용할 수 없게 됩니다. 가용성 영역 지원을 완전히 사용하려면 영역에 분산된 컨테이너 인스턴스 3개로 구성된 최소 구성으로 워크로드를 배포해야 합니다.

상태 검사 및 자가 치유

상태 검사 엔드포인트는 신뢰할 수 있는 워크로드에 매우 중요합니다. 그러나 이러한 엔드포인트를 구축하는 것은 솔루션의 절반에 불과합니다. 나머지 절반은 호스팅 플랫폼이 수행하는 작업과 실패 시 방법을 제어합니다.

상태 프로브 유형을 더 잘 구분하려면 Kubernetes의 기본 제공 프로브 유형을 살펴보세요.

  • 시작. 애플리케이션이 성공적으로 시작되었는지 여부를 확인합니다.
  • 준비 상태. 애플리케이션이 들어오는 요청을 처리할 준비가 되었는지 여부를 확인합니다.
  • 활기. 애플리케이션이 여전히 실행 중이고 응답성이 있는지 확인합니다.

또 다른 중요한 고려 사항은 해당 상태 검사 애플리케이션에서 요청되는 빈도(내부 세분성)입니다. 이러한 요청 사이에 긴 간격이 있는 경우 인스턴스가 비정상으로 간주될 때까지 트래픽을 계속 제공할 수 있습니다.

대부분의 애플리케이션은 HTTP(S) 프로토콜을 통해 상태 검사 지원합니다. 그러나 이러한 검사 수행하려면 TCP 또는 gRPC와 같은 다른 프로토콜이 필요할 수 있습니다. 상태 검사 시스템을 디자인할 때 이 점을 염두에 두어야 합니다.

Container Apps AKS Web App for Containers
시작 프로브 ✅ ✅ 부분 지원
준비 상태 프로브 ✅ ✅ ❌
활동성 프로브 ✅ ✅ ✅
간격 세분성 초 초 1분
프로토콜 지원. HTTP
TCP		 HTTP
TCP
gRPC		 HTTP

상태 검사 Web App for Containers에서 구현하는 것이 가장 쉽습니다. 몇 가지 중요한 고려 사항이 있습니다.

  • 시작 프로브는 기본 제공되며 변경할 수 없습니다. HTTP 요청을 컨테이너의 시작 포트로 보냅니다. 애플리케이션의 모든 응답은 성공적인 시작으로 간주됩니다.
  • 준비 프로브는 지원하지 않습니다. 시작 프로브가 성공하면 컨테이너 인스턴스가 정상 인스턴스 풀에 추가됩니다.
  • 1분 간격으로 상태 검사 보냅니다. 간격을 변경할 수 없습니다.
  • 내부 부하 분산 메커니즘에서 비정상 인스턴스를 제거할 수 있도록 설정할 수 있는 최소 임계값은 2분입니다. 비정상 인스턴스는 상태 검사 실패한 후 최소 2분 동안 트래픽을 가져옵니다. 이 설정의 기본값은 10분입니다.

반면 Container Apps 및 AKS는 훨씬 더 유연하며 비슷한 옵션을 제공합니다. 특정 차이점의 관점에서 AKS는 Container Apps에서 사용할 수 없는 상태 검사 수행하기 위한 다음 옵션을 제공합니다.

자동 복구

잘못된 컨테이너 인스턴스를 식별하고 트래픽 전송을 중지하는 것이 시작입니다. 다음 단계는 자동 복구를 구현하는 것입니다. 자동 복구 는 비정상 상태에서 복구하기 위해 애플리케이션을 다시 시작하는 프로세스입니다. 세 가지 컨테이너 서비스를 비교하는 방법은 다음과 같습니다.

  • Web App for Containers에서는 상태 검사 실패한 직후 컨테이너 인스턴스를 다시 시작할 수 있는 옵션이 없습니다. 인스턴스가 1시간 동안 계속 실패하면 새 인스턴스로 대체됩니다. 인스턴스를 모니터링하고 다시 시작하는 자동 복구라는 또 다른 기능이 있습니다. 그것은 건강 검사 직접 관련이 없습니다. 메모리 제한, HTTP 요청 기간 및 상태 코드와 같은 다양한 애플리케이션 메트릭을 사용합니다.
  • 활동성 프로브가 정의된 실패 임계값에 도달하면 Container Apps 및 AKS에서 컨테이너 인스턴스를 자동으로 다시 시작하려고 합니다.

가동 중지 시간 애플리케이션 배포 0개

사용자에게 가동 중지 시간을 발생하지 않고 애플리케이션을 배포하고 교체하는 기능은 신뢰할 수 있는 워크로드에 매우 중요합니다. 이 문서에 설명된 세 가지 컨테이너 서비스는 모두 가동 중지 시간 배포를 지원하지만 다른 방식으로 지원합니다.

Container Apps AKS Web App for Containers
가동 중지 시간 0개 전략 롤링 업데이트 롤링 업데이트 및 기타 모든 Kubernetes 전략 배포 슬롯

애플리케이션 아키텍처는 가동 중지 시간 배포도 지원해야 합니다. 지침은 Azure Well-Architected Framework를 참조하세요.

리소스 한계

신뢰할 수 있는 공유 환경의 또 다른 중요한 구성 요소는 컨테이너의 리소스 사용량(예: CPU 또는 메모리)을 제어하는 것입니다. 단일 애플리케이션이 모든 리소스를 차지하고 다른 애플리케이션을 잘못된 상태로 만드는 시나리오를 피해야 합니다.

Container Apps AKS Web App for Containers
리소스 제한(CPU 또는 메모리) 앱/컨테이너당 앱/컨테이너당
네임스페이스당		 App Service 계획당
  • Web App for Containers: 단일 App Service 계획에서 여러 애플리케이션(컨테이너)을 호스트할 수 있습니다. 예를 들어 컨테이너에서 여러 웹앱을 실행할 수 있는 CPU 코어 2개와 RAM 4GiB를 사용하여 계획을 할당할 수 있습니다. 그러나 앱 중 하나를 특정 양의 CPU 또는 메모리로 제한할 수는 없습니다. 모두 동일한 App Service 계획 리소스를 놓고 경쟁합니다. 애플리케이션 리소스를 격리하려면 추가 App Service 계획을 만들어야 합니다.
  • Container Apps: 환경에서 애플리케이션당 CPU 및 메모리 제한을 설정할 수 있습니다. 그러나 CPU와 메모리의 허용된 조합 집합으로 제한됩니다. 예를 들어 하나의 vCPU와 1GiB의 메모리를 구성할 수는 없지만 하나의 vCPU와 2GiB의 메모리를 구성할 수 있습니다. Container Apps 환경은 Kubernetes 네임스페이스와 유사합니다.
  • AKS: 노드에 지원할 하드웨어가 있는 한 vCPU와 메모리의 조합을 선택할 수 있습니다. 클러스터를 그런 식으로 분할하려는 경우 네임스페이스 수준에서 리소스를 제한할 수도 있습니다.

안정성을 위한 잘 설계된 프레임워크

이 문서에서는 Azure의 컨테이너 서비스 기능 간의 기본 차이점에 중점을 둡니다. 특정 서비스에 대한 전체 안정성 지침을 검토하려면 다음 문서를 참조하세요.

결론

잘 설계된 솔루션은 성공적인 워크로드를 위한 토대를 마련합니다. 워크로드가 증가하고 팀이 클라우드 여정에서 진행함에 따라 아키텍처를 조정할 수 있지만, 특히 네트워킹과 관련된 일부 결정은 상당한 가동 중지 시간 또는 다시 배포 없이는 되돌리기가 어렵습니다.

일반적으로 Azure 컨테이너 서비스를 비교할 때 테마가 나타납니다. AKS는 가장 기본적인 인프라를 표시하므로 가장 큰 구성 가능성과 확장성을 제공합니다. 운영 오버헤드 및 복잡성의 양은 AKS 워크로드에 매우 가변적입니다. 일부 팀은 Microsoft 관리형 추가 기능 및 확장뿐만 아니라 자동 업그레이드 기능을 사용하여 운영 오버헤드를 크게 줄일 수 있습니다. 다른 고객은 Kubernetes 및 CNCF 에코시스템의 완전한 확장성을 활용하기 위해 클러스터의 모든 권한을 선호할 수 있습니다. 예를 들어 Microsoft는 Flux를 관리형 GitOps 확장으로 제공하지만, 많은 팀에서 ArgoCD를 자체 설정 및 운영하도록 대신 선택합니다.

예를 들어 CNCF 애플리케이션이 필요하지 않거나 작업 환경이 적거나 애플리케이션 기능에 집중하려는 워크로드 팀은 PaaS 제품을 선호할 수 있습니다. 먼저 Container Apps를 고려하는 것이 좋습니다.

컨테이너 앱과 Web App for Containers는 모두 비슷한 수준의 Microsoft 관리 인프라를 제공하는 PaaS 제품이지만 주요 차이점은 Container Apps가 Kubernetes에 더 가깝고 서비스 검색, 이벤트 기반 자동 크기 조정, Dapr 통합 등에 대한 추가 클라우드 네이티브 기능을 제공한다는 점입니다. 그러나 이러한 기능이 필요하지 않고 App Service 네트워킹 및 배포 모델에 익숙한 팀은 Web App for Containers를 선호할 수 있습니다.

일반화를 사용하면 고려할 Azure 컨테이너 서비스 목록의 범위를 좁힐 수 있습니다. 그러나 개별 요구 사항을 자세히 검토하고 서비스별 기능 집합과 일치시켜 선택을 확인해야 합니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

기타 기여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계