대부분의 클라우드 기반 솔루션은 컴퓨팅 리소스로 구성됩니다. 이러한 리소스에는 웹 및 애플리케이션 계층, 일괄 처리 프로세서, 예약된 작업 또는 GPU 및 고성능 컴퓨팅과 같은 특수 리소스가 포함될 수 있습니다. 다중 테넌트 솔루션은 공유 컴퓨팅 리소스의 이점을 활용하는 경우가 많습니다. 각 인프라에 대한 테넌트의 밀도가 높을수록 운영 비용이 절감되고 관리가 간소화되기 때문입니다. 격리 요구 사항 및 공유 인프라의 의미를 고려해야 합니다.
이 문서에서는 솔루션 설계자가 다중 테넌트 컴퓨팅 계층을 계획할 때 고려해야 할 중요한 고려 사항 및 요구 사항에 대한 지침을 제공합니다. 이 지침에는 다중 테넌티를 컴퓨팅 서비스에 적용하는 일반적인 패턴과 방지할 수 있는 안티패턴이 포함되어 있습니다.
주요 고려 사항 및 요구 사항
다중 테넌트 및 선택한 격리 모델 모두 컴퓨팅 리소스의 크기 조정, 성능, 상태 관리 및 보안에 영향을 줍니다. 다음 섹션에서는 다중 테넌트 컴퓨팅 솔루션을 계획할 때 수행해야 하는 주요 결정을 검토합니다.
저울
시스템은 수요가 변경됨에 따라 적절하게 수행해야 합니다. 테넌트 수와 트래픽이 증가함에 따라 증가하는 수요에 맞게 리소스를 확장하고 허용 가능한 성능을 유지해야 할 수 있습니다. 마찬가지로 활성 사용자 수 또는 트래픽 양이 감소하면 컴퓨팅 용량을 자동으로 줄여 비용을 절감해야 합니다. 그러나 용량을 조정할 때 사용자의 중단을 최소화해야 합니다.
각 테넌트에 대한 전용 리소스를 배포하는 경우 각 테넌트의 리소스를 독립적으로 확장할 수 있는 유연성이 있습니다. 컴퓨팅 리소스가 여러 테넌트 간에 공유되는 솔루션에서 이러한 리소스의 크기를 조정하면 모든 테넌트가 증가된 용량을 활용할 수 있습니다. 그러나 규모가 부족하여 전체 부하를 처리할 수 없는 경우 모든 테넌트가 어려움을 겪습니다. 자세한 내용은 소란스러운 이웃 안티패턴을 참조하세요.
클라우드 솔루션을 빌드할 때 가로 또는 세로
성능 문제는 종종 애플리케이션이 로드될 때까지 검색되지 않은 상태로 유지됩니다. Azure Load Testing과 같은 완전 관리형 서비스를 사용하여 애플리케이션이 스트레스에서 작동하는 방식을 알아볼 수 있습니다.
트리거 크기 조정
크기를 조정하는 데 사용하는 방법에 관계없이 일반적으로 구성 요소의 크기를 조정하는 트리거를 계획해야 합니다. 공유 구성 요소가 있는 경우 각 테넌트의 워크로드 패턴을 고려하여 프로비전된 용량이 필요한 총 수요를 충족하는지 확인합니다. 이 방법은 리소스 경합을 방지하고 테넌트에서 시끄러운 인접 문제가 발생할 가능성을 줄이는 데 도움이 됩니다. 테넌트 수를 고려하여 크기 조정 용량을 계획할 수도 있습니다. 예를 들어 100개의 테넌트에 서비스를 제공하는 데 사용하는 리소스를 측정한 다음, 더 많은 테넌트에 온보딩할 때 100개의 추가 테넌트에 대해 리소스가 두 배로 늘어날 수 있도록 크기를 조정할 수 있습니다.
주
컴퓨팅 리소스는 무상태
상태 저장 리소스는 유지 관리하는 상태 유형에 따라 추가로 세분화할 수 있습니다. 영구 상태는 영구적으로 저장해야 하는 데이터입니다. 클라우드 솔루션에서는 컴퓨팅 계층에 영구 상태를 저장하지 않습니다. 대신 데이터베이스 또는 스토리지 계정과 같은 스토리지 서비스를 사용합니다. 일시적 상태는 일시적으로 저장된 데이터입니다. 여기에는 읽기 전용 메모리 내 캐시 및 로컬 디스크의 임시 파일 스토리지가 포함됩니다.
일시적 상태는 백 엔드 스토리지 서비스에 대한 요청 수를 줄여 애플리케이션 계층의 성능을 향상시키는 데 유용한 경우가 많습니다. 예를 들어 메모리 내 캐시를 사용하는 경우 데이터베이스에 연결하지 않고 최근에 다른 요청을 처리할 때 수행한 집중적인 쿼리를 수행하지 않고 읽기 요청을 처리할 수 있습니다.
대기 시간에 민감한 애플리케이션에서는 캐시 하이드레이션 비용이 상당할 수 있습니다. 다중 테넌트 솔루션은 각 테넌트에 다른 데이터를 캐시해야 하는 경우 이 문제를 악화시킬 수 있습니다. 이 문제를 완화하기 위해 일부 솔루션은 세션 선호도를 적용합니다. 이 방법을 사용하면 동일한 컴퓨팅 작업자 노드가 특정 사용자 또는 테넌트에 대한 모든 요청을 처리합니다. 세션 선호도는 애플리케이션 계층이 캐시를 효과적으로 사용하는 기능을 향상시킬 수 있습니다. 그러나 세션 선호도는 작업자 간의 크기 조정 및 트래픽 부하 분산을 복잡하게 만듭니다. 이 절심을 신중하게 고려하십시오. 많은 애플리케이션의 경우 세션 선호도가 필요하지 않습니다.
Azure Managed Redis와 같은 외부 캐시에 데이터를 저장할 수도 있습니다. 외부 캐시는 대기 시간이 짧은 데이터 검색에 최적화된 반면, 컴퓨팅 리소스에서 상태를 격리하여 별도로 크기를 조정하고 관리할 수 있습니다. 많은 솔루션에서 외부 캐시를 사용하면 컴퓨팅 계층을 무상태로 유지하면서 애플리케이션 성능을 향상시킬 수 있습니다.
중요하다
메모리 내 캐시 또는 상태를 유지하는 다른 구성 요소를 사용하는 경우 테넌트 간에 데이터가 누출되는 것을 방지합니다. 예를 들어 모든 캐시 키에 테넌트 식별자를 앞에 추가하여 각 테넌트에 대해 데이터가 구분되도록 하는 것이 좋습니다.
격리
다중 테넌트 컴퓨팅 계층을 디자인할 때 테넌트 격리에 대한 몇 가지 옵션이 있습니다. 모든 테넌트에 대한 공유 컴퓨팅 리소스 , 개별 테넌트에 대한 전용 컴퓨팅 리소스 또는 이러한 극단 사이에 속하는 반 격리된 접근 방식을 배포할 수 있습니다. 각 옵션에는 절충점이 있습니다. 솔루션에 가장 적합한 옵션을 결정하는 데 도움이 되도록 격리 요구 사항을 고려하세요.
테넌트 논리적 격리 및 각 테넌트에 적용되는 관리 책임 또는 정책을 분리하는 방법에 관심이 있을 수 있습니다. 또는 테넌트의 워크로드에 맞게 특정 VM(가상 머신) SKU를 배포하는 등 특정 테넌트에 대한 고유한 리소스 구성을 배포해야 할 수도 있습니다.
선택한 격리 모델에 따라 구성 요소 오류 또는 중단이 발생하더라도 테넌트 데이터가 제대로 격리되어 있는지 확인합니다. 일반적인 자동화된 테스트 프로세스에서 Azure Chaos Studio 를 사용하여 실제 중단을 시뮬레이션하는 오류를 도입하는 것이 좋습니다. 이 테스트는 솔루션이 적절한 테넌트 격리를 유지하고 압력을 받고 계속 작동하는지 확인하는 데 도움이 됩니다.
고려해야 할 접근 방식 및 패턴
자동 스케일링
Azure 컴퓨팅 서비스는 워크로드 크기를 조정하는 다양한 기능을 제공합니다. 많은 컴퓨팅 서비스는 자동 크기 조정을 지원하므로 크기를 조정할 시기를 결정하고 최소 및 최대 크기 조정 수준을 설정해야 합니다. 특정 크기 조정 옵션은 사용하는 컴퓨팅 서비스에 따라 달라집니다. 다음 예제 서비스 또는 구성 요소를 참조하세요.
Azure App Service:요구 사항에 따라 인프라 크기를 조정하는 자동 크기 조정 규칙을 지정합니다.
Azure Functions: 함수가 수행하는 작업에 따라 자동으로 크기 조정되는 이벤트 기반 크기 조정 모델을 포함하여 여러 배율 옵션 중에서 선택합니다.
Azure Container Apps:이벤트 기반 자동 크기 조정을 사용하여 수행되는 작업 및 현재 부하에 따라 애플리케이션 크기를 조정합니다.
AKS(Azure Kubernetes Service): 애플리케이션의 요구를 따라가려면 워크로드를 실행하는 노드 수를 조정해야 할 수 있습니다. AKS 클러스터에서 애플리케이션 워크로드의 크기를 빠르게 조정하려면 가상 노드를 사용할 수 있습니다.
VM: 가상 머신 확장 집합은 애플리케이션 을 실행하는 VM 인스턴스 수를 자동으로 늘리거나 줄일 수 있습니다 .
배포 스탬프 패턴
배포 스탬프 패턴을 사용하여 다중 테넌트 솔루션을 지원하는 방법에 대한 자세한 내용은 다중 테넌트 솔루션에 대한 아키텍처 접근 방식을 참조하세요.
컴퓨팅 리소스 통합 패턴
컴퓨팅 리소스 통합 패턴을 사용하면 기본 컴퓨팅 리소스를 공유하여 테넌트 밀도를 높여 인프라를 컴퓨팅할 수 있습니다. 컴퓨팅 리소스를 공유하면 해당 리소스의 직접 비용을 줄일 수 있습니다. 또한 관리할 구성 요소가 적기 때문에 관리 비용이 낮은 경우가 많습니다.
그러나 컴퓨팅 리소스 통합은 시끄러운 인접 문제의 가능성을 높입니다. 모든 테넌트의 워크로드는 사용 가능한 컴퓨팅 용량의 불균형한 양을 소비할 수 있습니다. 솔루션의 크기를 적절하게 조정하고 할당량 및 API 제한과 같은 컨트롤을 적용하여 용량의 공평한 점유율 이상을 소비하는 테넌트를 방지하여 이러한 위험을 완화할 수 있습니다.
이 패턴은 사용하는 컴퓨팅 서비스에 따라 다른 방식으로 수행됩니다. 다음 예제 서비스 또는 구성 요소를 참조하세요.
App Service 및 Azure Functions: 호스팅 서버 인프라를 나타내는 공유 App Service 계획을 배포합니다.
Container Apps:공유 환경을 배포합니다.
AKS: 다중 테넌트 인식 애플리케이션을 사용하여 공유 Pod를 배포합니다.
VM: 사용할 모든 테넌트에 대해 단일 VM 집합을 배포합니다.
각 테넌트에 대한 전용 컴퓨팅 리소스
각 테넌트에 대한 전용 컴퓨팅 리소스를 배포할 수도 있습니다. 전용 리소스는 각 테넌트에 대한 컴퓨팅 리소스가 다른 테넌트로부터 격리되도록 하여 시끄러운 인접 문제의 위험을 완화합니다. 또한 요구 사항에 따라 각 테넌트의 리소스에 대해 고유한 구성을 배포할 수 있습니다. 그러나 전용 리소스는 일반적으로 리소스에 대한 테넌트 밀도가 낮기 때문에 더 높은 비용이 발생합니다.
사용하는 Azure 컴퓨팅 서비스에 따라 다른 전용 리소스를 배포해야 할 수 있습니다.
App Service 및 Azure Functions: 각 테넌트에 대해 별도의 App Service 계획을 배포합니다.
Container Apps: 각 테넌트에 대해 별도의 환경을 배포합니다.
AKS: 각 테넌트에 대한 전용 클러스터를 배포합니다.
VM: 각 테넌트에 대한 전용 VM을 배포합니다.
단일 고객에 대해 전체 물리적 서버를 예약하는 Azure 전용 호스트에서 테넌트 VM을 실행하여 물리적 호스트 수준 격리를 제공할 수도 있습니다. 그러나 이 방법은 일반적으로 공유 호스트를 사용하는 것보다 비용이 더 많이 듭니다.
반 격리된 컴퓨팅 리소스
반 격리 접근 방식을 사용하려면 다른 구성 요소를 공유하는 동안 격리된 구성에서 솔루션의 측면을 배포해야 합니다.
App Service 및 Azure Functions를 사용하는 경우 각 테넌트에 대해 고유한 애플리케이션을 배포하고 공유 App Service 계획에서 애플리케이션을 호스트할 수 있습니다. 컴퓨팅 계층의 비용을 줄이는 이유는 App Service 계획이 청구 단위로 사용되기 때문입니다. 또한 각 애플리케이션에 고유한 구성 및 정책을 적용할 수 있습니다. 그러나 이 방법은 시끄러운 이웃 문제의 위험을 초래합니다.
Container Apps를 사용하여 공유 환경에 여러 애플리케이션을 배포한 다음 Dapr 및 기타 도구를 사용하여 각 애플리케이션을 개별적으로 구성할 수 있습니다.
AKS 및 Kubernetes는 다중 테넌트용으로 다양한 옵션을 제공합니다.
공유 클러스터 및 노드 풀에 배포되는 테넌트별 리소스의 논리적 격리를 제공할 수 있는 테넌트별 네임스페이스
공유 클러스터의 테넌트별 노드 또는 노드 풀
노드 풀을 공유할 수 있는 테넌트 전용 Pod
AKS를 사용하여 Pod 수준 거버넌스를 적용하여 시끄러운 인접 문제를 완화할 수도 있습니다. 자세한 내용은 애플리케이션 개발자가 AKS에서 리소스를 관리하는 모범 사례를 참조하세요.
또한 Kubernetes 클러스터의 공유 구성 요소와 다중 테넌트에서 이러한 구성 요소에 미치는 영향을 알고 있어야 합니다. 예를 들어 Kubernetes API 서버는 전체 클러스터에서 사용되는 공유 서비스입니다. 테넌트의 애플리케이션 워크로드를 격리하기 위해 테넌트별 노드 풀을 제공하는 경우에도 API 서버는 테넌트 전체의 많은 요청에서 경합이 발생할 수 있습니다.
방지할 안티패턴
다음 안티패턴을 피하십시오.
시끄러운 이웃 역패턴
테넌트가 공유하는 구성 요소를 배포할 때 시끄러운 인접 문제는 잠재적인 위험입니다. 테넌트의 컴퓨팅 워크로드에 영향을 주는 다른 테넌트 활동의 위험을 완화하기 위해 리소스 거버넌스 및 모니터링을 포함해야 합니다.
테넌트 간 데이터 유출
컴퓨팅 계층이 제대로 처리되지 않으면 테넌트 간 데이터 유출의 영향을 받을 수 있습니다. Microsoft는 플랫폼 계층에서 보호를 제공하기 때문에 Azure에서 다중 테넌트 서비스를 사용할 때 이 위험은 일반적으로 고려해야 할 사항이 아닙니다. 그러나 자체 다중 테넌트 애플리케이션을 개발할 때 로컬 디스크 캐시, RAM 및 외부 캐시와 같은 공유 리소스에 다른 테넌트가 실수로 보거나 수정할 수 있는 데이터가 포함될 수 있는지 여부를 고려합니다.
과부하된 프론트엔드 안티패턴
바쁜 프런트 엔드 안티패턴을 방지하려면, 아키텍처의 다른 구성 요소 또는 계층이 처리할 수 있는 대부분의 작업을 프런트 엔드 계층에서 담당하지 않도록 하십시오. 다중 테넌트 솔루션에 대한 공유 프런트 엔드를 만들 때 이 안티패턴은 특히 중요한데, 프런트 엔드가 혼잡하면 모든 테넌트의 사용 경험이 저하되기 때문입니다.
대신 큐 또는 다른 메시징 서비스를 사용하여 비동기 처리를 사용하는 것이 좋습니다. 또한 이 방법을 사용하면 요구 사항에 따라 다양한 테넌트에 QOS(서비스 품질) 컨트롤을 적용할 수 있습니다. 예를 들어 모든 테넌트는 공통 프런트 엔드 계층을 공유할 수 있지만, 더 높은 서비스 수준에 대한 비용을 지불하는 테넌트는 큐 메시지에서 작업을 처리하기 위해 더 높은 전용 리소스 집합을 가질 수 있습니다.
비탄력적 또는 불충분한 크기 조정
다중 테넌트 솔루션은 종종 버스트형 스케일링 패턴의 영향을 받습니다. 공유 구성 요소는 버스트의 범위가 더 높고 고유한 사용 패턴이 있는 테넌트가 더 많을 때 효과가 더 커지므로 이 문제에 특히 취약합니다.
클라우드의 탄력성과 규모를 활용해야 합니다. 가로 또는 세로 크기 조정
캐싱 안티패턴 없음
No Caching Antipattern은 애플리케이션 계층이 요청 간에 다시 사용할 수 있는 정보를 반복적으로 요청하거나 다시 계산하기 때문에 솔루션의 성능이 저하되는 경우입니다. 테넌트 간 또는 단일 테넌트 내의 사용자 간에 공유할 수 있는 데이터가 있는 경우 백 엔드 또는 데이터베이스 계층의 부하를 줄이기 위해 캐싱할 가치가 있습니다.
불필요한 상태 유지
No Caching antipattern의 의미는 컴퓨팅 계층에 불필요한 상태를 저장하지 않아야 한다는 것입니다. 상태를 유지 관리하는 위치 및 이유에 대해 명시적이어야 합니다. 상태 저장 프런트 엔드나 애플리케이션 계층은 확장성을 감소시킬 수 있습니다. 상태 저장 컴퓨팅 계층에는 일반적으로 세션 선호도가 필요하므로 작업자 또는 노드 간에 트래픽 부하를 효과적으로 분산하는 기능을 줄일 수 있습니다.
컴퓨팅 계층에서 유지 관리하는 각 상태의 장단점과 테넌트의 워크로드 패턴이 변경됨에 따라 크기를 조정하거나 확장하는 기능에 영향을 주는지 여부를 고려합니다. Azure Managed Redis와 같은 외부 캐시에 상태를 저장할 수도 있습니다.
참여자
Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.
주요 작성자:
- Dixit Arora | 선임 고객 엔지니어, Azure용 FastTrack
- John Downs | 주요 소프트웨어 엔지니어, Azure 패턴 및 사례
기타 기여자:
- 아르센 블라디미르스키 | 수석 고객 엔지니어, Azure용 FastTrack
LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.
관련 리소스
컴퓨팅 서비스에 대한 서비스별 지침을 검토합니다.