다중 테넌트 솔루션에서 Container Apps를 사용하기 위한 고려 사항
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을 기본적으로 지원합니다. Container Apps에서 Dapr 구성 요소는 환경 수준 리소스입니다. 여러 테넌트 간에 단일 환경을 공유하는 경우 격리를 보장하고 데이터 유출 위험을 방지하기 위해 Dapr 구성 요소의 범위를 올바른 테넌트별 컨테이너 앱으로 적절하게 지정해야 합니다.
참고
수정 버전을 사용하여 다른 테넌트용 앱의 다른 버전을 만들지 마세요. 수정 버전은 리소스 격리를 제공하지 않습니다. 파란색/녹색 배포 및 A/B 테스트와 같이 업데이트 롤아웃 프로세스의 일부로 여러 버전의 앱을 실행해야 하는 배포 시나리오를 위해 설계되었습니다.
테넌트당 하나의 환경
각 테넌트마다 하나의 Container Apps 환경을 배포하는 것이 좋습니다. Container Apps 환경은 컨테이너 앱 그룹 주위의 격리 경계입니다. 환경은 데이터 평면에서 컴퓨팅 및 네트워크 격리를 제공합니다. 각 환경은 환경 내의 모든 앱에서 공유하는 자체 가상 네트워크에 배포됩니다. 각 환경에는 자체 Dapr 및 모니터링 구성이 있습니다.
이 방법은 각 테넌트의 데이터와 트래픽이 특정 환경으로 격리되기 때문에 가장 강력한 수준의 데이터 및 성능 격리를 제공합니다. 또한 이 모델을 사용하는 경우 애플리케이션은 다중 테넌트 인식이 필요하지 않습니다. 이 방법을 사용하면 환경 내의 컨테이너 앱에 리소스를 할당하는 방법을 보다 세밀하게 제어할 수 있습니다. 테넌트의 요구 사항에 따라 할당을 결정할 수 있습니다. 예를 들어 일부 테넌트는 다른 테넌트보다 더 많은 CPU 및 메모리 리소스가 필요할 수 있으므로 테넌트별 환경이 제공하는 격리를 활용하면서 이러한 테넌트의 애플리케이션에 더 많은 리소스를 제공할 수 있습니다.
그러나 영역당 구독 내에서 배포할 수 있는 환경 수에 대한 한도는 낮습니다. 경우에 따라 Azure 지원 티켓을 만들어 이러한 할당량을 늘릴 수 있습니다.
이 격리 모델을 구현하기 전에 테넌트 수의 예상 증가를 알고 있어야 합니다. 이 방법은 배포 및 관리해야 하는 추가 리소스로 인해 더 높은 총 소유 비용과 높은 수준의 배포 및 운영 복잡성이 발생하는 경우가 많다는 점에 유의하세요.
다중 테넌시를 지원하는 Container Apps 기능
사용자 지정 도메인 이름
Container Apps는 와일드카드 DNS 사용과 사용자 고유의 와일드카드 TLS 인증서 추가를 지원합니다. 테넌트별 하위 도메인을 사용하는 경우 와일드카드 DNS 및 TLS 인증서를 사용하면 각 새 테넌트에 대해 수동으로 재구성하지 않고도 솔루션을 많은 수의 테넌트에 쉽게 확장할 수 있습니다.
Container Apps에서는 환경 수준에서 인증서를 관리합니다. 또한 컨테이너 앱에 대해수신을 사용하도록 설정해야 컨테이너 앱에 사용자 지정 도메인을 바인딩할 수 있습니다.
인증 및 권한 부여 요청
Container Apps는 앱을 대신하여 인증 토큰의 유효성을 검사할 수 있습니다. 요청에 토큰이 포함되어 있지 않거나, 토큰이 유효하지 않거나, 요청이 승인되지 않은 경우 사용자가 로그인할 수 있도록 Container Apps를 구성하여 요청을 차단하거나 ID 공급자로 리디렉션할 수 있습니다.
테넌트가 Microsoft Entra ID를 ID 공급자로 사용하는 경우 /common 엔드포인트를 사용하여 사용자 토큰의 유효성을 검사하도록 Container Apps를 구성할 수 있습니다. 이렇게 하면 사용자의 Microsoft Entra 테넌트에 관계없이 해당 토큰의 유효성을 검사하고 수락할 수 있습니다.
파트너 ID 공급자를 통해 사용자 인증을 위해 Container Apps를 Azure Active Directory B2C와 통합할 수도 있습니다.
이러한 응용 프로그램은 Azure AD Graph API를 사용할 수 있습니다. 자세한 내용은 다음 리소스를 참조하세요.
참고 항목
Container Apps의 인증 및 권한 부여 기능은 Azure App Service의 해당 기능과 비슷합니다. 하지만 약간의 차이점이 있습니다. 자세한 내용은 기본 제공 인증 사용에 대한 고려 사항을 참조하세요.
관리 ID
Microsoft Entra ID의 관리 ID를 사용하여 컨테이너 앱이 Microsoft Entra ID로 인증된 다른 리소스에 액세스할 수 있도록 할 수 있습니다. 관리 ID를 사용하는 경우 컨테이너 앱은 서비스 간 통신을 위한 자격 증명을 관리할 필요가 없습니다. 역할 기반 액세스 제어를 위해 컨테이너 앱의 ID에 특정 권한을 부여할 수 있습니다.
관리 ID를 사용하는 경우 선택한 격리 모델을 염두에 두어야 합니다. 예를 들어 모든 테넌트 간에 컨테이너 앱을 공유하고 테넌트별 데이터베이스를 배포한다고 가정해 보겠습니다. 한 테넌트의 애플리케이션이 다른 테넌트의 데이터베이스에 액세스할 수 없도록 해야 합니다.
자세한 내용은 Azure Container Apps의 관리 ID를 참조하세요.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
주요 작성자:
- Daniel Larsen | 수석 고객 엔지니어, FastTrack for Azure
- Will Velida | 고객 엔지니어 2, FastTrack for Azure
기타 기여자:
- John Downs | 주요 소프트웨어 엔지니어
- Chad Kittel | 주 소프트웨어 엔지니어, Microsoft
- Xuhong Liu | 선임 서비스 엔지니어, FastTrack for Azure
- Aarthi Murugan | 선임 프로그램 관리자, CS 기술 전략 앱 혁신
- Kendall Roden | 선임 프로그램 관리자, Azure Container Apps
- Paolo Salvatori | 수석 고객 엔지니어, FastTrack for Azure
- Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.