Azure App Service는 플랫폼을 호스트하는 강력한 웹 애플리케이션입니다. App Service 인프라를 기반으로 구축된 Azure Functions는 서버리스 및 이벤트 기반 컴퓨팅 워크로드를 쉽게 빌드할 수 있습니다. 두 서비스 모두 다중 테넌트 솔루션에서 자주 사용됩니다.
다중 테넌트를 지원하는 Azure App Service 및 Azure Functions의 기능
Azure App Service 및 Azure Functions에는 다중 테넌트를 지원하는 많은 기능이 포함됩니다.
사용자 지정 도메인 이름
Azure App Service는 와일드카드 DNS 사용과 사용자 고유의 와일드카드 TLS 인증서 추가를 지원합니다. 테넌트별 하위 도메인을 사용하는 경우 와일드카드 DNS 및 TLS 인증서를 사용하면 각 새 테넌트에 대해 수동으로 재구성하지 않고도 솔루션을 많은 수의 테넌트에 쉽게 확장할 수 있습니다.
테넌트별 사용자 지정 도메인 이름을 사용하는 경우 많은 수의 사용자 지정 도메인 이름을 앱에 추가해야 할 수 있습니다. 특히 개별 TLS 인증서가 필요한 경우 많은 사용자 지정 도메인 이름을 관리하는 것은 번거로울 수 있습니다. App Service는 관리형 TLS 인증서를 제공하므로 사용자 지정 도메인으로 작업할 때 필요한 업무를 줄일 수 있습니다. 그러나 단일 앱에 적용할 수 있는 사용자 지정 도메인 수와 같이 고려해야 할 제한이 있습니다.
Azure Front Door와 통합
App Service 및 Azure Functions는 Azure Front Door와 통합되어 솔루션의 인터넷 연결 구성 요소 역할을 합니다. Azure Front Door를 사용하면 WAF(웹 애플리케이션 방화벽) 및 에지 캐싱을 추가하고, 다른 성능을 최적화할 수 있습니다. 변화하는 비즈니스 또는 기술 요구 사항에 따라 트래픽 흐름을 쉽게 재구성하여 트래픽을 다른 백 엔드로 보낼 수 있습니다.
다중 테넌트 앱에서 Azure Front Door를 사용하는 경우 사용자 지정 도메인 이름을 관리하고 TLS 연결을 종료할 수 있습니다. 그러면 App Service 애플리케이션이 단일 호스트 이름으로 구성되고 모든 트래픽 흐름이 해당 애플리케이션으로 향하게 되어 여러 위치에서 사용자 지정 도메인 이름을 관리하지 않아도 됩니다.
위의 예제와 같이 요청의 Host 헤더를 수정하도록 Azure Front Door를 구성할 수 있습니다. 클라이언트에서 보낸 원래 Host 헤더는 X-Forwarded-Host 헤더를 통해 전파되며 사용자의 애플리케이션 코드는 이 헤더를 사용하여 요청을 올바른 테넌트에 매핑할 수 있습니다.
Warning
애플리케이션이 쿠키 또는 리디렉션 응답을 보내는 경우 특별히 주의해야 합니다. 요청의 Host 헤더를 변경하면 이러한 응답이 무효화될 수 있습니다. 자세한 내용은 호스트 이름 유지 모범 사례를 참조하세요.
프라이빗 엔드포인트 또는 App Service 액세스 제한을 사용하여 트래픽이 Front Door를 통해 흘러 앱에 도달하도록 할 수 있습니다.
다중 테넌트 솔루션에서 Azure Front Door를 사용하는 방법에 대한 자세한 내용은 다중 테넌트 솔루션에서 Azure Front Door 사용을 참조 하세요.
인증 및 권한 부여
Azure App Service는 앱을 대신하여 인증 토큰의 유효성을 검사할 수 있습니다. App Service가 요청을 받으면 다음 각 조건이 충족되는지 여부를 확인하는 검사.
- 요청에 토큰이 포함됩니다.
- 토큰이 유효합니다.
- 요청 권한이 부여됩니다.
조건이 충족되지 않으면 App Service에서 요청을 차단하거나 사용자를 ID 공급자로 리디렉션하여 로그인할 수 있습니다.
테넌트가 Microsoft Entra ID를 ID 시스템으로 사용하는 경우 /common 엔드포인트를 사용하여 사용자 토큰의 유효성을 검사하도록 Azure 앱 Service를 구성할 수 있습니다. 이렇게 하면 사용자의 Microsoft Entra 테넌트에 관계없이 해당 토큰의 유효성을 검사하고 수락할 수 있습니다.
소비자 인증을 위해 Azure App Service를 Azure AD B2C와 통합할 수도 있습니다.
추가 정보:
액세스 제한
액세스 제한을 사용하여 앱에 대한 트래픽을 제한할 수 있습니다. 이를 사용하여 앱에 연결할 수 있는 IP 주소 범위 또는 가상 네트워크를 지정할 수 있습니다.
다중 테넌트 솔루션으로 작업하는 경우 액세스 제한 규칙의 최대 수를 알고 있어야 합니다. 예를 들어 모든 테넌트에 대한 액세스 제한 규칙을 만들어야 하는 경우 허용되는 최대 규칙 수를 초과할 수 있습니다. 더 많은 수의 규칙이 필요한 경우 Azure Front Door와 같은 역방향 프록시를 배포하는 것이 좋습니다.
격리 모델
Azure App Service 및 Azure Functions를 사용하는 다중 테넌트 시스템을 사용하는 경우 사용하려는 격리 수준을 결정해야 합니다. 다중 테넌트 솔루션에 대해 고려할 테넌트 모델 및 다중 테넌트 솔루션의 컴퓨팅에 대한 아키텍처 접근 방식에 제공된 참고 자료를 참조하면 시나리오에 가장 적합한 격리 모델을 선택하는 데 도움을 받을 수 있습니다.
Azure App Service 및 Azure Functions로 작업할 때 다음과 같은 주요 개념을 알고 있어야 합니다.
- Azure App Service에서 플랜은 호스팅 인프라를 나타냅니다. 앱은 해당 인프라에서 실행되는 단일 애플리케이션을 나타냅니다. 단일 플랜으로 여러 앱을 배포할 수 있습니다.
- Azure Functions에서는 호스팅과 애플리케이션도 구분되지만 탄력적 호스팅에 사용할 수 있는 추가 호스팅 옵션이 있으며, 여기서 Azure Functions가 스케일링을 관리합니다. 여기서 설명하는 원칙은 사용하는 호스팅 모델에 관계없이 App Service 및 Azure Functions 모두에 적용되므로 간단히 하기 위해 문서 전체에서 호스팅 인프라를 플랜이라고 하겠습니다.
다음 표에는 Azure App Service 및 Azure Functions에 대한 기본 테넌트 격리 모델 간의 차이점이 요약되어 있습니다.
| 고려 사항 | 공유 앱 | 공유 플랜이 있는 테넌트당 앱 | 테넌트당 플랜 |
|---|---|---|---|
| 구성 격리 | 낮음 | 중간. 앱 수준 설정은 테넌트 전용이며 계획 수준 설정은 공유됩니다. | 높음. 각 테넌트는 자체 구성을 가질 수 있습니다. |
| 성능 격리 | 낮음 | 낮음-중간. 잠재적으로 노이지 네이버 문제가 발생할 수 있습니다. | 높음 |
| 배포 복잡성 | 낮음 | 중간 | 높음 |
| 운영 복잡성 | 낮음 | 높음 | 높음 |
| 리소스 비용 | 낮음 | 애플리케이션에 따라 낮음-높음 | 높음 |
| 예제 시나리오 | 공유 애플리케이션 계층이 있는 대규모 다중 테넌트 솔루션 | 테넌시를 인식하지 못하는 애플리케이션을 Azure로 마이그레이션하면서 비용 효율성을 높입니다. | 단일 테넌트 애플리케이션 계층 |
공유 앱
단일 계획에 공유 애플리케이션을 배포하고 모든 테넌트에서 공유 애플리케이션을 사용할 수 있습니다.
이는 가장 비용 효율적인 옵션인 경우가 많으며, 관리할 리소스가 적기 때문에 운영 오버헤드가 가장 적게 필요합니다. 로드나 수요에 따라 전체 플랜을 스케일링할 수 있으며, 플랜을 공유하는 모든 테넌트는 증가된 용량의 이점을 누릴 수 있습니다.
단일 앱에 추가할 수 있는 최대 사용자 지정 도메인 수 및 프로비전할 수 있는 플랜의 최대 인스턴스 수와 같은 App Service 할당량 및 제한을 아는 것이 중요합니다.
이 모델을 사용할 수 있으려면 애플리케이션 코드가 다중 테넌트 지원을 인식해야 합니다.
공유 플랜이 있는 테넌트당 앱
여러 테넌트 간에 플랜을 공유하지만 각 테넌트에 대해 별도의 앱을 배포하도록 선택할 수도 있습니다. 이렇게 하면 각 테넌트 간에 논리적 격리가 제공되며, 이 방법은 다음과 같은 이점이 있습니다.
- 비용 효율성: 호스팅 인프라를 공유하면 일반적으로 테넌트당 전체 비용을 줄일 수 있습니다.
- 구성 분리: 각 테넌트의 앱에 고유한 도메인 이름, TLS 인증서, 액세스 제한 및 토큰 권한 부여 정책이 적용될 수 있습니다.
- 업그레이드 분리: 각 테넌트의 애플리케이션 이진 파일을 동일한 플랜의 다른 앱과 독립적으로 업그레이드할 수 있습니다.
그러나 플랜의 컴퓨팅 리소스가 공유되므로 앱에 노이지 네이버 문제가 발생할 수 있습니다. 또한 단일 플랜에 배포할 수 있는 앱 수에 제한이 있습니다.
참고
서로 다른 테넌트에 배포 슬롯을 사용해서는 안 됩니다. 슬롯은 리소스 격리를 제공하지 않습니다. 슬롯은 파란색-녹색 배포 및 카나리아 출시 전략과 같이 짧은 시간 동안 여러 버전의 앱을 실행해야 하는 배포 시나리오를 위해 설계되었습니다.
테넌트당 플랜
테넌트에 대해 전용 플랜을 배포하는 가장 강력한 격리 수준입니다. 이 전용 플랜을 사용하면 테넌트가 해당 플랜에 할당된 모든 서버 리소스를 완전히 사용할 수 있습니다.
이 방법을 사용하면 솔루션을 스케일링하여 각 테넌트에 대한 성능 격리를 제공하고 노이지 네이버 문제를 방지할 수 있습니다. 그러나 리소스가 여러 테넌트와 공유되지 않기 때문에 비용이 더 높습니다. 또한 단일 Azure 리소스 그룹에 배포할 수 있는 최대 플랜 수를 고려해야 합니다.
호스트 API
Azure App Service 및 Azure Functions 모두에서 API를 호스트할 수 있습니다. 플랫폼 선택은 필요한 특정 기능 집합 및 스케일링 옵션에 따라 달라집니다.
API를 호스트하는 데 어떤 플랫폼을 사용하든지 API 애플리케이션 앞에 Azure API Management를 사용하는 것이 좋습니다. API Management는 다음을 포함하여 다중 테넌트 솔루션에 유용할 수 있는 많은 기능을 제공합니다.
- 모든 인증에 대한 중앙 집중식 지점. 여기에는 토큰 클레임 또는 기타 요청 메타데이터에서 테넌트 식별자를 확인하는 것이 포함될 수 있습니다.
- 요청의 테넌트 식별자를 기반으로 할 수 있는 다른 API 백 엔드로 요청을 라우팅. 이는 여러 배포 스탬프를 자체 독립 API 애플리케이션을 사용하여 호스트할 때 유용할 수 있지만 모든 요청에 대해 단일 API URL이 있어야 합니다.
네트워킹 및 다중 테넌트 지원
IP 주소
많은 다중 테넌트 애플리케이션이 데이터 전송을 위해 테넌트의 온-프레미스 네트워크에 연결해야 합니다.
알려진 고정 IP 주소 또는 알려진 고정 IP 주소 집합에서 아웃바운드 트래픽을 보내야 하는 경우 NAT 게이트웨이를 사용하는 것이 좋습니다. 다중 테넌트 솔루션에서 NAT 게이트웨이를 사용하는 방법에 대한 자세한 내용은 다중 테넌트에 대한 Azure NAT Gateway 고려 사항을 참조 하세요. App Service는 NAT 게이트웨이와 통합하는 방법에 대한 참고 자료를 제공합니다.
고정 아웃바운드 IP 주소가 필요하지 않지만 그 대신 애플리케이션이 아웃바운드 트래픽에 사용하는 IP 주소를 가끔 확인해야 하는 경우 App Service 배포의 현재 IP 주소를 쿼리할 수 있습니다.
할당량
App Service 자체가 다중 테넌트 서비스이므로 공유 리소스를 사용하는 방법을 주의해야 합니다. 네트워킹은 SNAT(Source Network Address Translation) 및 TCP 포트 제한을 포함하여 애플리케이션이 인바운드 및 아웃바운드 네트워크 연결을 사용하는 방법에 영향을 주는 제한이 있기 때문에 특히 주의해야 하는 영역입니다.
애플리케이션이 많은 수의 데이터베이스 또는 외부 서비스에 연결하는 경우 앱이 SNAT 포트 고갈의 위험에 처할 수 있습니다. 일반적으로 SNAT 포트 고갈은 코드가 TCP 연결을 올바르게 재사용하지 않음을 나타내며, 다중 테넌트 솔루션에서도 연결을 재사용하는 권장 사례를 따라야 합니다.
그러나 일부 다중 테넌트 솔루션에서 고유 IP 주소에 대한 아웃바운드 연결 개수 때문에 좋은 코딩 방법을 따르는 경우에도 SNAT 포트가 고갈될 수 있습니다. 이러한 시나리오에서는 다음 옵션 중 하나를 고려합니다.
- NAT 게이트웨이를 배포하여 애플리케이션에서 사용할 수 있는 SNAT 포트 수를 늘입니다. 다중 테넌트 솔루션에서 NAT 게이트웨이를 사용하는 방법에 대한 자세한 내용은 다중 테넌트에 대한 Azure NAT Gateway 고려 사항을 참조 하세요.
- Azure 서비스에 연결할 때 서비스 엔드포인트를 사용하여 부하 분산 장치 제한을 무시합니다.
이렇게 제어한 상황에서도 테넌트 수가 많아서 제한에 접근할 수 있으므로 추가 App Service 요금제 또는 배포 스탬프로 스케일링할 계획을 세워야 합니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- John Downs | 수석 고객 엔지니어, FastTrack for Azure
기타 기여자:
- Thiago Almeida | 수석 프로그램 관리자, Azure Functions
- Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.
다음 단계
다중 테넌트 솔루션의 설계자 및 개발자를 위한 리소스를 검토합니다.