Azure Container Apps를 사용하여 서버리스 플랫폼에서 마이크로 서비스 및 컨테이너화된 애플리케이션을 실행할 수 있습니다. 이 문서에서는 다중 테넌트 솔루션에 유용한 Container Apps의 몇 가지 기능을 설명합니다. 또한 계획 단계에서 도움이 될 수 있는 리소스를 제공합니다.
격리 모델
Container Apps를 사용하는 다중 테넌트 시스템에서 작업하는 경우 필요한 격리 수준을 결정해야 합니다. Container Apps는 다양한 다중 테넌트 모델을 지원합니다.
공유 환경을 사용하여 신뢰할 수 있는 다중 테넌트 구현할 수 있습니다. 예를 들어 이 모델은 테넌트가 모두 조직 내에서 온 경우에 적합할 수 있습니다.
별도의 환경을 각 테넌트에 배포하여 적대적 다중 테넌시를 구현할 수 있습니다. 예를 들어 이 모델은 테넌트가 실행하는 코드를 신뢰하지 않는 경우에 적합할 수 있습니다.
다음 표에서는 Container Apps에 대한 기본 테넌시 격리 모델 간의 차이점을 요약합니다. 모델은 이 문서의 뒷부분에 설명되어 있습니다.
| 고려 사항 | 각 테넌트에 대한 하나의 환경 | 테넌트별 컨테이너 앱 | 공유 컨테이너 앱 |
|---|---|---|---|
| 데이터 격리 | 높음 | 낮음 | 낮음 |
| 성능 격리 | 높음 | 중간, 네트워크 격리 없음 | 낮음 |
| 배포 복잡성 | 중간 | 낮음에서 중간 | 낮음 |
| 운영 복잡성 | 중간 | 낮음 | 낮음 |
| 리소스 비용 | 높음 | 낮음 | 낮음 |
| 예제 시나리오 | 보안 및 규정 준수를 위해 격리된 환경에서 적대적인 다중 테넌트 워크로드를 실행합니다. | 신뢰할 수 있는 다중 테넌트 애플리케이션에 대한 비용, 네트워킹 리소스 및 작업을 최적화합니다. | 비즈니스 논리 수준에서 다중 테넌트 솔루션을 구현합니다. |
공유 컨테이너 앱
모든 테넌트에서 사용하는 단일 Container Apps 환경에서 공유 컨테이너 앱을 배포하는 것이 좋습니다.
이 방법은 일반적으로 비용 효율적이며 관리할 리소스가 적기 때문에 운영 오버헤드가 가장 적습니다.
그러나 이 격리 모델을 사용하려면 애플리케이션 코드가 다중 테넌트 인식이어야 합니다. 이 격리 모델은 네트워크, 컴퓨팅, 모니터링 또는 데이터 수준에서 격리를 보장하지 않습니다. 애플리케이션 코드는 테넌트 격리를 처리해야 합니다. 이 모델은 실행 중인 코드를 신뢰하지 않는 적대적인 다중 테넌트 워크로드에 적합하지 않습니다.
이 모델은 잠재적으로 시끄러운 인접 문제가 발생할 수 있습니다. 즉, 한 테넌트의 워크로드가 다른 테넌트의 워크로드 성능에 영향을 줄 수 있습니다. 이러한 문제를 완화하기 위해 전용 처리량을 제공해야 하는 경우 공유 컨테이너 앱 모델이 적합하지 않을 수 있습니다.
메모
배포 스탬프 패턴은 테넌트가 서로 다른 가격 책정 모델에 있을 때 유용합니다. 예를 들어 테넌트는 가격 책정 계층에 따라 공유 또는 전용 Container Apps 환경에 할당될 수 있습니다. 이 배포 전략을 사용하면 각 지역에 대한 단일 구독에 대한 Container Apps 제한을 초과하고 테넌트 수가 증가함에 따라 선형적으로 확장할 수 있습니다.
테넌트별 컨테이너 앱
고려할 수 있는 또 다른 방법은 공유 환경 내에서 테넌트별 컨테이너 앱을 배포하여 테넌트를 격리하는 것입니다.
이 격리 모델은 다음과 같은 몇 가지 이점을 제공하면서 테넌트 간의 논리적 분리를 보장합니다.
비용 효율성: Container Apps 환경, 가상 네트워크 및 Log Analytics 작업 영역과 같은 기타 연결된 리소스를 공유하면 일반적으로 각 테넌트에 대한 전반적인 비용 및 관리 복잡성을 줄일 수 있습니다.
업그레이드 및 배포 분리: 각 테넌트의 애플리케이션 이진 파일은 동일한 환경에 있는 다른 컨테이너 앱의 이진 파일과 독립적으로 배포 및 업그레이드할 수 있습니다. 이 방법은 서로 다른 시간에 다른 테넌트 코드를 특정 버전으로 업그레이드해야 하는 경우에 유용할 수 있습니다.
리소스 격리: 환경 내의 각 컨테이너 앱에는 자체 CPU 및 메모리 리소스가 할당됩니다. 특정 테넌트에 더 많은 리소스가 필요한 경우 해당 테넌트의 특정 컨테이너 앱에 더 많은 CPU 및 메모리를 할당할 수 있습니다. 컨테이너 앱에서 총 CPU 및 메모리 할당에는
제한이 있다는 점을 염두에 두세요.
그러나 이 방법은 테넌트 간에 하드웨어 또는 네트워크 격리를 제공하지 않습니다. 단일 환경의 모든 컨테이너 앱은 동일한 가상 네트워크를 공유합니다. 앱에 배포된 워크로드가 공유 리소스를 오용하지 않는다는 것을 신뢰할 수 있어야 합니다.
Container Apps는 Dapr에 대한 기본 지원을 제공하며, Dapr은 모듈식 디자인을 통해 구성 요소기능을 제공합니다. Container Apps에서 Dapr 구성 요소는 환경 수준 리소스입니다. 여러 테넌트 간에 단일 환경을 공유하는 경우 격리를 보장하고 데이터 누출을 방지하기 위해 Dapr 구성 요소의 범위를 올바른 테넌트별 컨테이너 앱으로 적절하게 지정해야 합니다.
메모
수정 사용하여 다른 테넌트에 대해 다른 버전의 앱을 만들지 마세요. 수정 버전은 리소스 격리를 제공하지 않습니다. 업데이트 출시 중에 여러 버전의 앱을 실행해야 하는 배포 시나리오를 위해 설계되었습니다. 이 방법은 청록색 배포 및 A/B 테스트와 같은 전략을 포함합니다.
각 테넌트에 대한 하나의 환경
각 테넌트에 대해 하나의 Container Apps 환경을 배포하는 것이 좋습니다. Container Apps 환경은 컨테이너 앱 그룹을 위한 격리 경계입니다. 환경은 데이터 평면에서 컴퓨팅 및 네트워크 격리를 제공합니다. 각 환경은 자체 가상 네트워크에 배포됩니다. 환경 내의 모든 앱은 이 가상 네트워크를 공유합니다. 각 환경에는 자체 Dapr 및 모니터링 구성이 있습니다.
이 방법은 각 테넌트의 데이터와 트래픽이 특정 환경으로 격리되기 때문에 가장 강력한 수준의 데이터 및 성능 격리를 제공합니다. 이 모델은 애플리케이션을 다중 테넌트 인식할 필요가 없습니다. 이 방법을 사용하면 환경 내의 컨테이너 앱에 리소스를 할당하는 방법을 보다 세부적으로 제어할 수 있습니다. 테넌트의 요구 사항에 따라 할당을 결정할 수 있습니다. 예를 들어 일부 테넌트에는 다른 테넌트보다 더 많은 CPU 및 메모리 리소스가 필요할 수 있습니다. 테넌트별 환경에서 제공하는 격리를 활용하면서 이러한 테넌트의 애플리케이션에 더 많은 리소스를 제공할 수 있습니다.
그러나 각 지역에 대한 구독 내에서 배포할 수 있는 환경 수에 대한 제한은 낮습니다. 일부 시나리오에서는 Azure 지원 티켓을 만들어 이러한 할당량을 늘릴 수 있습니다.
이 격리 모델을 구현하기 전에 테넌트 수가 예상되는 증가를 알고 있는지 확인합니다. 이 방법은 배포 및 관리해야 하는 추가 리소스로 인해 TCO(총 소유 비용)가 더 높고 배포 및 운영 복잡성이 더 높은 경우가 많습니다.
다중 테넌시를 지원하는 Container Apps 기능
다음 Container Apps 기능은 다중 테넌트 기능을 지원합니다.
사용자 지정 도메인 이름
Container Apps를 사용하면 DNS(와일드카드 도메인 이름 시스템)를 사용하고 고유한 TLS(와일드카드 전송 계층 보안) 인증서를 추가할 수 있습니다. 테넌트별 하위 도메인을 사용하는 경우 와일드카드 DNS 및 TLS 인증서를 사용하면 각 새 테넌트를 수동으로 다시 구성할 필요 없이 솔루션을 많은 수의 테넌트에 쉽게 확장할 수 있습니다.
Container Apps에서는 환경 수준에서 인증서를 관리합니다. 인그레스도 컨테이너 앱에 대해 활성화해야 사용자 지정 도메인을 바인딩할 수 있습니다.
인증 및 권한 부여 요청
Container Apps는앱 대신
테넌트가 Microsoft Entra ID를 ID 공급자로 사용하는 경우, Container Apps를 구성하여 /common 엔드포인트을 사용해 사용자 토큰의 유효성을 검사할 수 있습니다. 이 방법을 사용하면 사용자의 Microsoft Entra 테넌트에 관계없이 사용자의 토큰의 유효성을 검사하고 수락할 수 있습니다.
파트너 ID 공급자를 통해 사용자 인증을 위해 Container Apps를 Microsoft Entra 외부 ID와 통합할 수도 있습니다.
자세한 내용은 다음 리소스를 참조하세요.
메모
Container Apps의 인증 및 권한 부여 기능은 Azure App Service의 기능과 유사합니다. 그러나 몇 가지 차이점이 있습니다. 자세한 내용은 기본 제공 인증사용하기 위한
관리형 IDentities
Microsoft Entra ID의 관리 ID를 사용하여 컨테이너 앱이 Microsoft Entra ID가 인증하는 다른 리소스에 액세스할 수 있도록 할 수 있습니다. 관리 ID를 사용하는 경우 컨테이너 앱은 서비스 간 통신을 위한 자격 증명을 관리할 필요가 없습니다. Azure RBAC(Azure 역할 기반 액세스 제어)에 대한 컨테이너 앱의 ID에 특정 권한을 부여할 수 있습니다.
관리 ID를 사용하는 경우 선택한 격리 모델을 염두에 두어야 합니다. 예를 들어 모든 테넌트 간에 컨테이너 앱을 공유하고 테넌트별 데이터베이스를 배포한다고 가정합니다. 한 테넌트의 애플리케이션이 다른 테넌트의 데이터베이스에 액세스할 수 없도록 해야 합니다.
자세한 내용은 Container Apps의 관리 ID를 참조하세요.
전용 컴퓨팅의 워크로드 프로필
Container Apps는 테넌트에 대한 전용 리소스를 예약할 수 있는 전용 계획을 제공합니다. 이 계획은 여러 컨테이너 앱에서 공유할 수 있는 테넌트에서 사용할 수 있는 리소스를 제한하는 데 유용합니다. 또한 더 높은 메모리 대 CPU 비율 또는 GPU 가용성과 같은 특정 테넌트 요구 사항을 충족하는 데 도움이 됩니다.
자세한 내용은 Container Apps의 워크로드 프로필을 참조하세요.
규칙 기반 라우팅
규칙 기반 라우팅을 사용하면 인바운드 트래픽을 특정 컨테이너 앱 또는 컨테이너 앱 수정 버전으로 보낼 수 있습니다. HTTP 요청 경로에 따라 요청을 라우팅할 수 있으며 URL에서 경로를 다시 작성할 수 있습니다. 이 기능은 요청의 경로를 사용하는 테넌트별 컨테이너 앱 또는 수정 버전에 요청을 매핑 해야 하는 다중 테넌트 시스템에 유용합니다. 이 기능은 일반적으로 테넌트별 컨테이너 앱 격리 모델에서 사용됩니다.
자세한 내용은 Container Apps에서 규칙 기반 라우팅 사용을 참조하세요.
참여자
Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.
주요 작성자:
- 다니엘 라슨 | 수석 고객 엔지니어, Azure용 FastTrack
- Will Velida | 고객 엔지니어 2, Azure용 FastTrack
기타 기여자:
- John Downs | 주요 소프트웨어 엔지니어, Azure 패턴 및 사례
- 채드 키텔 | 주요 소프트웨어 엔지니어, Azure 패턴 및 사례
- 쉬홍 리우 | 선임 서비스 엔지니어, Azure용 FastTrack
- Aarthi Murugan | 선임 프로그램 관리자, CS 기술 전략 및 애플리케이션 혁신
- 켄달 로덴 | 선임 프로그램 관리자, Container Apps
- 파올로 살바토리 | 수석 고객 엔지니어, Azure용 FastTrack
- 다니엘 스콧-레인스포드 | 파트너 솔루션 설계자, 데이터 및 AI
- 아르센 블라디미르스키 | 수석 고객 엔지니어, Azure용 FastTrack
LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.
다음 단계
관련 리소스
- 다중 테넌트 솔루션 설계자 및 개발자를 위한
리소스 - Azure에서 멀티 테넌트 솔루션을 설계하기
- Azure 다중 테넌트 솔루션을 설계하고 빌드하기 위한
검사 목록