Azure 컨테이너 서비스 선택

  • 아티클

Azure는 다양한 워크로드, 아키텍처 및 비즈니스 요구 사항을 수용하도록 설계된 다양한 컨테이너 호스팅 서비스를 제공합니다. 이 컨테이너 서비스 선택 가이드는 워크로드 시나리오 및 요구 사항에 가장 적합한 Azure 컨테이너 서비스를 이해하는 데 도움이 될 수 있습니다.

참고 항목

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

이 가이드를 사용하는 방법

이 가이드에는 이 소개 문서와 모든 워크로드 유형에서 공유되는 고려 사항에 대한 또 다른 문서가 포함되어 있습니다.

참고 항목

아직 컨테이너화 에 커밋되지 않은 경우 워크로드를 호스트하는 데 사용할 수 있는 다른 컴퓨팅 옵션에 대한 자세한 내용은 Azure 컴퓨팅 서비스 선택을 참조하세요.

이 소개 문서에서는 이 가이드의 범위에 있는 Azure 컨테이너 서비스와 고객 관리 방식과 Microsoft 관리 방식과 같은 구성 가능성과 의견 있는 솔루션 간의 장단점 측면에서 서비스 모델을 비교하는 방법을 설명합니다. 서비스 모델 기본 설정에 따라 후보 서비스를 식별한 후 다음 단계는 네트워킹, 보안, 작업 및 안정성에 대한 공유 고려 사항에 대한 문서를 검토하여 워크로드 요구 사항에 대한 옵션을 평가하는 것입니다.

이 가이드에서는 워크로드의 기술 요구 사항, 크기 및 복잡성 및 워크로드 팀의 전문 지식을 기반으로 해야 할 수 있는 장단 부분을 고려합니다.

이 가이드의 범위 내 Azure 컨테이너 서비스

이 가이드에서는 Azure에서 현재 제공하는 컨테이너 서비스의 하위 집합에 중점을 둡니다. 이 하위 집합은 웹 애플리케이션 및 API, 네트워킹, 관찰 가능성, 개발자 도구 및 작업에 대한 완성도 높은 기능 집합을 제공합니다. 이러한 컨테이너 서비스는 다음과 같습니다.

Container Apps 로고

Azure Container Apps 는 인프라를 오케스트레이션하지 않고 코드 또는 컨테이너에서 HTTP 및 비 HTTP 앱을 배포하는 데 도움이 되는 완전히 관리되는 Kubernetes 기반 애플리케이션 플랫폼입니다. 자세한 내용은 Azure Container Apps 설명서를 참조하세요.

AKS 로고

AKS(Azure Kubernetes Service) 는 컨테이너화된 애플리케이션을 실행하기 위한 관리되는 Kubernetes 서비스입니다. AKS를 사용하면 가장 광범위한 수준의 구성 가능성을 유지하면서 관리 되는 추가 기능 및 확장을 활용하여 추가 기능을 활용할 수 있습니다. 자세한 내용은 AKS 설명서를 참조 하세요.

App Service 로고

Web App for Containers는 기본 제공 인프라 기본 테넌트, 보안 패치, 크기 조정 및 진단 도구를 사용하여 HTTP 기반 웹앱을 호스팅하기 위한 완전 관리형 서비스인 Azure 앱 Service의 기능입니다. 자세한 내용은 App Service 설명서를 참조하세요.

모든 Azure 컨테이너 서비스의 전체 목록은 컨테이너 서비스 제품 범주 페이지를 참조 하세요.

서비스 모델 고려 사항

서비스 모델은 전체적인 단순성과 사용 편의성을 대가로 Azure 컨테이너 서비스에서 제공하는 유연성 및 제어 수준에 대한 광범위한 인사이트를 제공합니다.

IaaS(Infrastructure as a Service) 및 PaaS(Platform as a Service)를 포함하여 서비스 모델에 대한 용어 및 개념에 대한 일반적인 소개는 클라우드의 공유 책임을 참조하세요.

Azure 컨테이너 솔루션의 서비스 모델 비교

AKS

AKS는 IaaS 및 PaaS의 하이브리드로서 단순성을 제어하는 우선 순위를 지정합니다. AKS는 기본 핵심 인프라의 관리를 간소화하지만 이 VM 기반 플랫폼은 여전히 애플리케이션에 노출되며 보안 및 비즈니스 연속성을 보장하기 위해 패치와 같은 적절한 가드레일 및 프로세스가 필요합니다. 컴퓨팅 인프라는 Azure 부하 분산 장치와 같이 구독에서 직접 호스트되는 추가 Azure 리소스에서 지원됩니다.

AKS는 또한 Kubernetes API 서버에 대한 액세스를 제공하므로 컨테이너 오케스트레이션을 사용자 지정하여 CNCF(Cloud Native Computing Foundation)에서 프로젝트를 배포할 수 있습니다. 따라서 Kubernetes를 새로운 워크로드 팀에 대한 상당한 학습 곡선이 있습니다. 컨테이너화된 솔루션을 접하는 경우 이 학습 곡선이 억제될 수 있습니다. 다음 PaaS 솔루션은 진입 장벽을 낮춥니다. 요구 사항에 따라 이동이 결정되면 Kubernetes로 이동할 수 있습니다.

Azure Container Apps

PaaS 제품인 Container Apps는 간편하게 컨트롤의 균형을 조정합니다. 운영 체제를 기준으로 운영 체제를 패치하거나 애플리케이션을 중심으로 가드레일을 빌드할 필요성을 추상화하는 서버리스 및 전용 컴퓨팅 옵션을 모두 제공합니다. 또한 Container Apps는 컨테이너 오케스트레이션 API를 완전히 추상화하고 팀이 이미 잘 알고 있을 수 있는 Azure API를 통해 주요 기능의 하위 집합을 제공합니다. 또한 계층 7 수신, 트래픽 분할, A/B 테스트 및 애플리케이션 수명 주기 관리는 모두 기본적으로 완전히 사용할 수 있습니다.

Web App for Containers

Web App for Containers는 PaaS 제품이기도 하지만 Container Apps보다 더 단순하고 제어가 적습니다. 컨테이너 오케스트레이션을 추상화하지만 적절한 크기 조정, 애플리케이션 수명 주기 관리, 트래픽 분할, 네트워크 통합 및 관찰 가능성을 제공합니다.

호스팅 모델 고려 사항

AKS 클러스터와 같은 Azure 리소스를 사용하여 여러 워크로드를 호스트할 수 있습니다. 이렇게 하면 작업을 간소화하고 전체 비용을 줄일 수 있습니다. 이 경로를 선택하는 경우 몇 가지 중요한 고려 사항은 다음과 같습니다.

  • AKS 는 일반적으로 여러 워크로드를 호스트하거나 서로 다른 워크로드 구성 요소를 호스트하는 데 사용됩니다. 보안 요구 사항을 충족하기 위해 네임스페이스, 액세스 제어 및 네트워크 컨트롤과 같은 Kubernetes 네이티브 기능을 사용하여 이러한 워크로드 및 구성 요소를 격리할 수 있습니다.

    Kubernetes API에서 제공하는 추가 기능이 필요하고 워크로드 팀이 Kubernetes 클러스터를 운영하기에 충분한 경험이 있는 경우 단일 워크로드 시나리오에서 AKS를 사용할 수도 있습니다. Kubernetes 환경이 적은 팀은 Azure 관리형 추가 기능 및 클러스터 자동 업그레이드와 같은 기능을 활용하여 운영 오버헤드를 줄여 자체 클러스터를 성공적으로 운영할 수 있습니다.

  • 컨테이너 앱 은 공유 보안 경계가 있는 단일 워크로드를 호스트하는 데 사용해야 합니다. Container Apps에는 향상된 보안 경계 역할을 하는 Container Apps 환경이라는 단일 최상위 논리 경계가 있습니다. 추가 세분화된 액세스 제어를 위한 메커니즘은 없습니다. 예를 들어 환경 내 통신은 무제한이며 모든 애플리케이션은 단일 Log Analytics 작업 영역을 공유합니다.

    워크로드에 여러 구성 요소와 여러 보안 경계가 있는 경우 여러 Container Apps 환경을 배포하거나 AKS를 대신 고려합니다.

  • 컨테이너 용 웹앱은 App Service의 기능입니다. App Service는 애플리케이션을 App Service 계획이라는 청구 경계로 그룹화합니다. 애플리케이션 수준에서 RBAC(역할 기반 액세스 제어)의 범위를 지정할 수 있으므로 단일 계획에서 여러 워크로드를 호스트하는 것이 좋습니다. 그러나 노이즈 네이버 문제를 방지하려면 계획당 단일 워크로드를 호스트하는 것이 좋습니다. 단일 App Service 계획의 모든 앱은 동일한 할당된 컴퓨팅, 메모리 및 스토리지를 공유합니다.

    하드웨어 격리를 고려할 때 App Service 계획은 일반적으로 다른 Azure 고객과 공유되는 인프라에서 실행된다는 점에 유의해야 합니다. 전용 VM에 대한 전용 계층 또는 전용 가상 네트워크의 전용 VM에 대한 격리 계층을 선택할 수 있습니다.

일반적으로 모든 Azure 컨테이너 서비스는 여러 구성 요소가 있는 여러 애플리케이션을 호스트할 수 있습니다. 그러나 Container Apps 및 Web App for Containers는 단일 워크로드 구성 요소 또는 단일 팀이 애플리케이션을 소유하고 실행하는 유사한 수명 주기를 공유하는 여러 고도로 관련된 워크로드 구성 요소에 더 적합합니다.

한 호스트에서 서로 다른 잠재적으로 관련이 없는 애플리케이션 구성 요소 또는 워크로드를 호스트해야 하는 경우 AKS를 고려합니다.

제어와 사용 편의성 간의 절충

AKS는 가장 구성성을 제공하지만, 이러한 구성은 다른 서비스에 비해 운영 오버헤드가 증가하는 비용이 발생합니다. Container Apps와 Web App for Containers는 모두 비슷한 수준의 Microsoft 관리 기능을 가진 PaaS 서비스이지만 Web App for Containers는 인터페이스를 잘 알고 있는 기존 Azure PaaS 고객인 대상을 수용하기 위해 단순성을 강조합니다.

주먹구구식 계산

일반적으로 더 단순하게 제공하는 서비스는 기능 개발에 더 집중하고 인프라에 더 적은 것을 선호하는 고객에게 적합한 경향이 있습니다. 더 많은 제어를 제공하는 서비스는 더 많은 구성이 필요하고 자체 인프라를 관리하는 데 필요한 기술, 리소스 및 비즈니스 근거를 가진 고객에게 적합한 경향이 있습니다.

모든 워크로드에서 공유 고려 사항

워크로드 팀은 특정 서비스 모델을 선호할 수 있지만 해당 모델은 조직 전체의 요구 사항을 충족하지 못할 수 있습니다. 예를 들어 개발자는 운영 오버헤드를 덜 선호할 수 있지만 보안 팀은 규정 준수 요구 사항을 충족하는 데 필요한 이러한 유형의 오버헤드를 고려할 수 있습니다. 팀은 적절한 절충을 위해 공동 작업해야 합니다.

공유 고려 사항은 광범위합니다. 워크로드 유형뿐만 아니라 조직 내의 역할에 따라 하위 집합만 사용자와 관련이 있을 수 있습니다.

다음 표에서는 서비스 기능 비교를 포함하여 고려 사항에 대한 개략적인 개요를 제공합니다. 각 범주의 고려 사항을 검토하고 워크로드 요구 사항과 비교합니다.

범주 개요
네트워킹 고려 사항 Azure 컨테이너 서비스의 네트워킹은 단순성 및 구성 가능성에 대한 기본 설정에 따라 달라집니다. AKS는 매우 구성 가능하여 네트워크 흐름을 광범위하게 제어할 수 있지만 더 많은 운영 노력이 필요합니다. Container Apps는 Azure 관리 네트워킹 기능을 제공합니다. App Service에 익숙한 고객에게 맞게 조정된 AKS와 Web App for Containers 간의 중간 지점입니다.

결정적으로 네트워크 디자인 결정은 워크로드를 다시 배포하지 않고 변경해야 하는 어려움 때문에 장기적인 결과를 초래할 수 있습니다. IP 주소 계획, 부하 분산 책임, 서비스 검색 방법 및 프라이빗 네트워킹 기능과 같은 몇 가지 요소는 이러한 서비스 간에 다릅니다. 서비스가 특정 네트워킹 요구 사항을 충족하는 방법을 신중하게 검토해야 합니다.
보안 고려 사항 Container Apps, AKS 및 Web App for Containers는 모두 Azure Key Vault 및 관리 ID와 같은 주요 Azure 보안 제품과 통합됩니다. AKS는 런타임 위협 방지 및 네트워크 정책과 같은 추가 기능을 제공합니다. Container Apps와 같은 PaaS 서비스가 더 적은 보안 기능을 제공하는 것처럼 보일 수 있지만, 이는 기본 인프라 구성 요소 중 더 많은 부분이 Azure에서 관리되고 고객에게 노출되지 않아 위험을 줄이기 때문입니다.
운영 고려 사항 AKS는 가장 많은 사용자 지정을 제공하지만 더 큰 운영 입력이 필요합니다. 반면, Container Apps 및 Web App for Containers와 같은 PaaS 솔루션을 사용하면 Azure에서 OS 업데이트와 같은 작업을 처리할 수 있습니다. 확장성 및 하드웨어 SKU 유연성은 매우 중요합니다. AKS는 유연한 하드웨어 옵션을 제공하는 반면 Container Apps 및 Web App for Containers는 집합 구성을 제공합니다. AKS의 애플리케이션 확장성은 고객의 책임입니다. 컨테이너 앱 및 Web App for Containers는 보다 간소화된 접근 방식을 제공합니다.
안정성 고려 사항 Web App for Containers 및 Container Apps 상태 프로브 구성은 친숙한 Azure Resource Manager API를 사용한다는 점을 감안할 때 AKS보다 더 간소화됩니다. AKS를 사용하려면 Kubernetes API를 사용해야 합니다. 또한 애플리케이션 인스턴스를 올바르게 예약하려면 Kubernetes 노드 풀 확장성 및 가용성을 관리하는 추가적인 책임을 져야 합니다. 이러한 요구 사항으로 인해 AKS에 대한 추가 오버헤드가 발생합니다.

또한 컨테이너 앱용 SLA 및 Web App for Containers는 AKS보다 더 간단하며, 컨트롤 플레인과 노드 풀에는 각각 자체 SLA가 있으며 그에 따라 복합화해야 합니다. 모든 서비스는 이를 제공하는 데이터 센터에서 영역 중복성을 제공합니다.

위의 고려 사항을 검토한 후에도 여전히 완벽한 적합을 찾지 못했을 수 있습니다. 그것은 완벽하게 정상입니다.

절충안 평가

클라우드 서비스를 선택하는 것은 간단한 연습이 아닙니다. 클라우드 컴퓨팅의 복잡성, 많은 팀 간의 공동 작업 및 사람, 예산 및 시간과 관련된 리소스 제약 조건을 감안할 때 모든 솔루션에는 장단분이 있습니다.

지정된 워크로드의 경우 일부 요구 사항이 다른 요구 사항보다 더 중요할 수 있습니다. 예를 들어 애플리케이션 팀은 Container Apps와 같은 PaaS 솔루션을 선호하지만 보안 팀은 Kubernetes 네트워크 정책을 사용하는 AKS 전용 기능인 공동 배치된 워크로드 구성 요소 간에 기본적으로 거부 네트워크 제어가 필요하기 때문에 AKS를 선택할 수 있습니다.

마지막으로, 위의 공유 고려 사항에는 가장 일반적인 요구 사항이 포함되지만 포괄적이지는 않습니다. 결정을 확인하기 전에 기본 서비스의 기능 집합에 대해 모든 요구 사항을 조사하는 것은 워크로드 팀의 책임입니다.

결론

이 가이드에서는 Azure 컨테이너 서비스를 선택할 때 직면하는 가장 일반적인 고려 사항에 대해 설명합니다. 워크로드 팀이 정보에 입각한 의사 결정을 내릴 수 있도록 설계되었습니다. 이 프로세스는 원하는 수준의 제어를 결정하는 클라우드 서비스 모델을 선택하는 것으로 시작합니다. 제어는 단순성을 희생합니다. 즉, 자체 관리형 인프라와 Microsoft에서 관리하는 인프라 간의 적절한 균형을 찾는 프로세스입니다.

많은 워크로드 팀은 기본 서비스 모델인 PaaS와 IaaS를 기반으로 Azure 컨테이너 서비스를 선택할 수 있습니다. 다른 팀은 서비스별 기능이 워크로드 또는 조직의 요구 사항을 해결하는 방법을 결정하기 위해 추가로 조사해야 합니다.

모든 워크로드 팀은 어려운 역방향 결정을 피하기 위해 실사를 통합하는 것 외에도 이 가이드를 사용해야 합니다. 그러나 개발자가 서비스를 시도하고 이론이 아닌 경험을 기반으로 결정할 때까지 결정이 확정되지 않는다는 점에 유의하세요.

참가자

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

주요 작성자:

기타 기여자:

다음 단계

이 문서에서 멘션 서비스에 대한 공유 아키텍처 고려 사항에 대해 자세히 알아봅니다.

공유 아키텍처 고려 사항