Azure 컨테이너 서비스 선택

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

개요

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

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

이 가이드는 워크로드의 기술 요구 사항, 크기 및 복잡성에 따라 장차를 평가하는 데 도움이 됩니다. 또한 정보에 입각한 의사 결정을 보장하기 위해 팀의 전문 지식을 고려합니다.

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

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

Azure 컨테이너 서비스의 전체 목록은 Azure의 컨테이너를 참조하세요.

서비스 모델 고려 사항

서비스 모델은 각 Azure 컨테이너 서비스에서 제공하는 유연성과 제어의 양을 이해하는 데 도움이 됩니다. 복잡한 서비스는 더 많은 제어를 제공하는 반면, 더 간단한 서비스는 관리를 더 쉽게 만들지만 사용자 지정을 제한합니다.

IaaS(Infrastructure as a Service) 및 PaaS(Platform as a Service)를 비롯한 서비스 모델 용어 및 개념에 대한 자세한 내용은 클라우드의 공유 책임을 참조하세요.

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

AKS(Azure Kubernetes Service)

AKS는 단순성보다 제어에 더 중점을 둔 IaaS와 PaaS의 조합입니다. 컨테이너 오케스트레이션을 위한 표준 시스템인 Kubernetes를 사용합니다. AKS는 기본 핵심 인프라의 관리를 간소화합니다. 그러나 이 VM(가상 머신) 기반 플랫폼은 애플리케이션에 노출되며 보안 및 비즈니스 연속성을 보장하기 위해 패치와 같은 적절한 가드레일 및 프로세스가 필요합니다. 컴퓨팅 인프라는 Azure 부하 분산 장치, 컨테이너 레지스트리 또는 애플리케이션 게이트웨이와 같이 구독에서 직접 호스트되는 추가 Azure 리소스에서 지원됩니다.

AKS는 컨테이너 오케스트레이션을 사용자 지정하고 Cloud Native Computing Foundation에서 보조 애플리케이션을 배포할 수 있는 Kubernetes API 서버에 대한 액세스를 제공합니다. 결과적으로 Kubernetes에 새로운 워크로드 팀은 상당한 학습 부담에 직면해 있습니다. 컨테이너화된 솔루션에 익숙하지 않은 경우 이 학습 곡선을 고려해야 합니다. 다음 PaaS 솔루션은 진입 장벽을 낮춥니다. 요구 사항에 따라 Kubernetes로 전환할 수 있습니다.

AKS 자동화

AKS 자동 을 사용하면 복잡한 클러스터 관리 작업을 자동화하여 Kubernetes를 더 쉽게 채택할 수 있습니다. 이 자동화를 통해 고급 Kubernetes 전문 지식의 필요성이 줄어듭니다. Kubernetes의 유연성과 확장성을 유지하면서 보다 간소화된 PaaS와 같은 환경을 제공합니다. Azure는 클러스터 설정, 노드 프로비저닝, 크기 조정, 보안 패치를 관리하고 기본적으로 모범 사례 구성을 적용합니다. 이 자동화는 운영 작업을 줄이지만 사용 가능한 토폴로지 옵션을 제한합니다.

컨테이너 앱

Container Apps는 기본 인프라를 직접 관리하지 않고도 앱을 실행하고 확장할 수 있도록 하는 Kubernetes 위에 있는 추상화 계층입니다. Container Apps는 서버리스 및 전용 컴퓨팅 옵션을 모두 제공합니다. 이러한 옵션을 사용하면 애플리케이션에서 사용할 수 있는 컴퓨팅 리소스의 유형과 양을 완전히 제어할 수 있습니다. Container Apps는 컨테이너 오케스트레이션 API를 추상화하면서 계층 7 수신, 트래픽 분할, A/B 테스트 및 애플리케이션 수명 주기 관리와 같은 주요 기능에 대한 기본 제공 액세스를 제공합니다.

컨테이너용 웹 애플리케이션

Web App for Containers는 Container Apps에 비해 제어보다 단순성을 우선시하는 PaaS 제품입니다. 크기 조정, 애플리케이션 수명 주기 관리, 트래픽 분할, 네트워크 통합 및 관찰 가능성을 계속 지원하면서 컨테이너 오케스트레이션을 추상화합니다.

호스팅 모델 고려 사항

AKS 클러스터와 같은 Azure 리소스를 사용하여 여러 워크로드를 호스트할 수 있습니다. 이 방법을 사용하면 작업을 간소화하여 전체 비용을 줄일 수 있습니다. 이 옵션을 선택하는 경우 다음 기능을 고려합니다.

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

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

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

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

• Web App for Containers은 App Service의 기능입니다. App Service는 애플리케이션을 App Service 계획이라는 논리적 컴퓨팅 경계로 그룹화합니다. 애플리케이션 수준에서 역할 기반 액세스 제어의 범위를 지정할 수 있으므로 단일 계획에서 여러 워크로드를 호스트할 수 있습니다. 그러나 시끄러운 인접 문제를 방지하기 위해 각 계획에 대해 단일 워크로드를 호스트하는 것이 가장 좋습니다. 단일 App Service 계획의 모든 앱은 동일한 할당된 컴퓨팅, 메모리 및 스토리지를 공유합니다.

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

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

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

제어와 사용 편의성 간의 균형

AKS는 가장 구성성을 제공하지만, 이러한 구성을 위해서는 다른 서비스에 비해 더 많은 운영 노력이 필요합니다. 컨테이너 앱과 Web App for Containers는 모두 비슷한 수준의 Microsoft 관리 기능이 있는 PaaS 서비스입니다. Web App for Containers는 인터페이스에 익숙한 기존 App Service 고객인 대상 그룹을 제공하기 위한 단순성을 중시합니다.

모범 사례

더 간단한 서비스를 제공하는 서비스는 일반적으로 인프라 관리 대신 기능 개발에 집중하는 고객에게 적합합니다. 더 많은 제어를 제공하는 서비스는 일반적으로 구성이 필요하고 자체 인프라를 관리하기 위한 기술, 리소스 및 비즈니스 정당성이 있는 고객에게 적합합니다.

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

워크로드 팀은 특정 서비스 모델을 선호할 수 있지만 해당 모델은 조직의 전반적인 요구 사항을 충족하지 못할 수 있습니다. 예를 들어 개발자는 운영 작업을 덜 원할 수 있지만 보안 팀은 규정 준수에 필요한 오버헤드를 고려할 수 있습니다. 팀은 올바른 절충안을 찾기 위해 협력해야 합니다.

공유 고려 사항은 다양한 요소를 다룹니다. 워크로드 유형에 따라 고려 사항의 하위 집합만 적용할 수 있습니다. 조직 내의 역할은 관련 고려 사항에도 영향을 줍니다.

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

위의 고려 사항을 검토한 후에도 일반적인 완벽한 적합을 찾지 못할 수 있습니다.

절충 평가

클라우드 컴퓨팅은 복잡합니다. 여기에는 여러 팀의 협업이 포함되며 사람, 예산 및 시간의 제약 조건을 고려해야 합니다. 이러한 요인으로 인해 클라우드 서비스 선택이 어렵고 절충이 가득합니다.

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

위의 공유 고려 사항은 가장 일반적인 요구 사항을 다루지만 포괄적이지는 않습니다. 결정을 내리기 전에 선호하는 서비스의 기능 집합에 대해 모든 요구 사항을 평가해야 합니다.

결론

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

많은 워크로드 팀은 PaaS 또는 IaaS를 선호하는지 여부에 따라 Azure 컨테이너 서비스를 선택합니다. 다른 팀은 서비스별 기능이 워크로드 또는 조직의 요구 사항을 해결하는 방법을 결정하기 위해 추가로 조사해야 합니다.

이 가이드를 사용하여 옵션을 신중하게 평가하고 되돌리기 어려운 결정을 내리지 않도록 합니다. 그러나 개발자가 서비스를 시도하고 이론 대신 실습 경험을 기반으로 평가하기 전까지는 최종 결정이 내려지지 않습니다.

참여자

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

주요 작성자:

• 안드레 듀스 | 선임 고객 엔지니어
• 마르코스 마르티네스 | 선임 서비스 엔지니어
• Julie Ng | 선임 엔지니어

기타 기여자:

• 마틴 조셰프스키 | 선임 고객 엔지니어
• Don High | 수석 고객 엔지니어
• Nelly Kiboi | 서비스 엔지니어
• 쉬홍 리우 | 선임 서비스 엔지니어
• 파이살 무스타파 | 선임 고객 엔지니어
• 월터 마이어스 | 수석 고객 엔지니어링 관리자
• 소날리카 로이 | 선임 고객 엔지니어
• 파올로 살바토리 | 수석 고객 엔지니어
• 빅터 산타나 | 수석 고객 엔지니어
• Carlos Mestre del Pino | 클라우드 솔루션 설계자

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

관련 리소스

• 공유 아키텍처 고려 사항