다음을 통해 공유

다중 테넌트 솔루션의 컴퓨팅에 대한 아키텍처 접근 방식

  • 아티클

대부분의 클라우드 기반 솔루션은 웹 및 애플리케이션 계층, 일괄 처리 프로세서, 예약된 작업, GPU 및 HPC(고성능 컴퓨팅)와 같은 특수 리소스와 같은 일종의 컴퓨팅 리소스로 구성됩니다. 다중 테넌트 솔루션은 인프라에 대한 테넌트의 밀도가 높을수록 운영 비용 및 관리가 감소하기 때문에 공유 컴퓨팅 리소스의 이점을 활용하는 경우가 많습니다. 격리 요구 사항 및 공유 인프라의 의미를 고려해야 합니다.

이 문서에서는 다중 테넌트 컴퓨팅 계층을 계획할 때 솔루션 설계자가 고려해야 하는 고려 사항 및 요구 사항에 대한 지침을 제공합니다. 여기에는 컴퓨팅 서비스에 다중 테넌티를 적용하기 위한 몇 가지 일반적인 패턴과 피해야 할 몇 가지 안티패턴이 포함됩니다.

주요 고려 사항 및 요구 사항

다중 테넌트 및 선택한 격리 모델은 컴퓨팅 리소스의 크기 조정, 성능, 상태 관리 및 보안에 영향을 줍니다. 이 섹션에서는 다중 테넌트 컴퓨팅 솔루션을 계획할 때 내려야 하는 몇 가지 주요 결정을 검토합니다.

저울

시스템은 변화하는 수요에 따라 적절하게 수행해야 합니다. 테넌트 수와 트래픽 양이 증가함에 따라 리소스의 용량을 늘리고, 증가하는 테넌트 수를 유지하고, 허용 가능한 성능 속도를 유지해야 할 수 있습니다. 마찬가지로 활성 사용자 수 또는 트래픽 양이 감소하면 컴퓨팅 용량을 자동으로 줄여 비용을 절감해야 하지만 사용자에게 미치는 영향을 최소화하면서 용량을 줄여야 합니다.

각 테넌트에 대한 전용 리소스를 배포하는 경우 각 테넌트의 리소스를 독립적으로 확장할 수 있는 유연성이 있습니다. 컴퓨팅 리소스가 여러 테넌트 간에 공유되는 솔루션에서 해당 리소스의 크기를 조정하면 모든 테넌트가 새 규모를 사용할 수 있습니다. 그러나 규모가 전체 부하를 처리하기에 충분하지 않을 때 모두가 어려움을 겪을 것입니다. 자세한 내용은 시끄러운 이웃 문제를 참조하세요.

클라우드 솔루션을 빌드할 때 가로 또는 세로크기를 조정할지 선택할 수 있습니다. 테넌트가 늘어나는 다중 테넌트 솔루션에서 수평적으로 크기를 조정하면 일반적으로 유연성이 향상되고 전체적인 확장성이 향상됩니다.

성능 문제는 종종 애플리케이션이 로드될 때까지 검색되지 않은 상태로 유지됩니다. azure Load Testing같은 완전 관리형 서비스를 사용하여 애플리케이션이 스트레스 상태에서 어떻게 동작하는지 알아볼 수 있습니다.

트리거 크기 조정

크기를 조정하는 데 어떤 방법을 사용하든 일반적으로 구성 요소의 크기를 조정하는 트리거를 계획해야 합니다. 공유 구성 요소가 있는 경우, 리소스를 사용하는 각 테넌트의 워크로드 패턴을 고려하여 프로비전된 용량이 총 필요 용량을 충족할 수 있도록 하고, 테넌트들이 노이즈 네이버 문제를겪을 가능성을 최소화합니다. 테넌트 수를 고려하여 크기 조정 용량을 계획할 수도 있습니다. 예를 들어 100개의 테넌트에 서비스를 제공하는 데 사용하는 리소스를 측정한 다음 더 많은 테넌트에 온보딩할 때 추가 100개 테넌트에 대해 리소스를 두 배로 확장하도록 계획할 수 있습니다.

상태

컴퓨팅 리소스는 무상태수 있거나 상태 저장수 있습니다. 무상태 구성 요소는 요청 간에 데이터를 유지하지 않습니다. 확장성 관점에서 무상태 구성 요소는 새 작업자, 인스턴스 또는 노드를 빠르게 추가할 수 있기 때문에 확장하기가 쉬운 경우가 많습니다. 이들은 즉시 요청을 처리하기 시작할 수 있습니다. 아키텍처에서 허용하는 경우 한 테넌트에 할당된 인스턴스를 용도를 변경하고 다른 테넌트에 할당할 수도 있습니다.

상태 저장 리소스는 유지 관리하는 상태 유형에 따라 추가로 세분화할 수 있습니다. 영구 상태 영구적으로 저장해야 하는 데이터입니다. 클라우드 솔루션에서는 컴퓨팅 계층에 영구 상태를 저장하지 않아야 합니다. 대신 데이터베이스 또는 스토리지 계정과 같은 스토리지 서비스를 사용합니다. 일시적 상태 일시적으로 저장되는 데이터이며 읽기 전용 메모리 내 캐시와 로컬 디스크의 임시 파일 스토리지가 포함됩니다.

일시적 상태는 백 엔드 스토리지 서비스에 대한 요청 수를 줄여 애플리케이션 계층의 성능을 향상시키는 데 유용한 경우가 많습니다. 예를 들어 메모리 내 캐시를 사용하는 경우 데이터베이스에 연결하지 않고 다른 요청을 처리할 때 최근에 수행한 집중적인 쿼리를 수행하지 않고 읽기 요청을 처리할 수 있습니다.

대기 시간에 민감한 애플리케이션에서는 캐시 하이드레이션 비용이 상당할 수 있습니다. 다중 테넌트 솔루션은 각 테넌트에 다른 데이터를 캐시해야 하는 경우 이 문제를 악화시킬 수 있습니다. 이 문제를 완화하기 위해 일부 솔루션은 세션 선호도 사용하여 특정 사용자 또는 테넌트에 대한 모든 요청이 동일한 컴퓨팅 작업자 노드에서 처리되도록 합니다. 세션 선호도는 애플리케이션 계층에서 캐시를 효과적으로 사용하는 기능을 향상시킬 수 있지만, 작업자 간에 트래픽 부하의 크기를 조정하고 균형을 맞추기가 더 어려워집니다. 이러한 절충안은 신중하게 고려해야 합니다. 많은 애플리케이션의 경우 세션 선호도가 필요하지 않습니다.

Azure Cache for Redis와 같은 외부 캐시에 데이터를 저장할 수도 있습니다. 외부 캐시는 대기 시간이 짧은 데이터 검색에 최적화된 반면, 상태를 컴퓨팅 리소스에서 격리된 상태로 유지하므로 별도로 크기를 조정하고 관리할 수 있습니다. 많은 솔루션에서 외부 캐시를 사용하면 컴퓨팅 계층을 무상태로 유지하면서 애플리케이션 성능을 향상시킬 수 있습니다.

중요하다

메모리 내 캐시 또는 상태를 유지하는 다른 구성 요소를 사용할 때마다 테넌트 간에 데이터가 누출되는 것을 방지합니다. 예를 들어 모든 캐시 키에 테넌트 식별자를 앞에 추가하여 각 테넌트에 대해 데이터가 구분되도록 하는 것이 좋습니다.

격리

다중 테넌트 컴퓨팅 계층을 디자인할 때 모든 테넌트에서 사용할 공유 컴퓨팅 리소스배포, 각 테넌트에 전용 컴퓨팅 리소스 또는 이러한 극단적인사이에 있는 항목을 등 테넌트 간의 격리 수준에 대해 고려해야 할 많은 옵션이 있는 경우가 많습니다. 각 옵션에는 타협점이 있습니다. 솔루션에 가장 적합한 옵션을 결정하는 데 도움이 되도록 격리 요구 사항을 고려하세요.

테넌트 논리적 격리와 각 테넌트에 적용되는 관리 책임 또는 정책을 분리하는 방법에 관심이 있을 수 있습니다. 또는 테넌트의 워크로드에 맞게 특정 가상 머신 SKU를 배포하는 등 특정 테넌트에 대해 고유한 리소스 구성을 배포해야 할 수 있습니다.

어떤 격리 모델을 선택하든 구성 요소를 사용할 수 없거나 오작동하는 경우에도 테넌트 데이터가 적절하게 격리된 상태로 유지되는지 확인합니다. 정기적인 자동화된 테스트 프로세스의 일부로 Azure Chaos Studio 사용하여 실제 중단을 시뮬레이션하는 오류를 의도적으로 도입하고 솔루션이 테넌트 간에 데이터를 누출하지 않고 압력을 받고도 제대로 작동하는지 확인하는 것이 좋습니다.

고려해야 할 접근 방식 및 패턴

자동 스케일링

Azure 컴퓨팅 서비스는 워크로드 크기를 조정하는 다양한 기능을 제공합니다. 많은 컴퓨팅 서비스는 자동 크기 조정지원하므로 크기를 조정해야 하는 시기와 최소 및 최대 크기 조정 수준을 고려해야 합니다. 크기 조정에 사용할 수 있는 특정 옵션은 사용하는 컴퓨팅 서비스에 따라 달라집니다. 다음 예제 서비스를 참조하세요.

  • azure App Service: 요구 사항에 따라 인프라를 확장하는 자동 크기 조정 규칙을 지정합니다.
  • Azure Functions: 함수가 수행하는 작업에 따라 자동으로 크기 조정되는 이벤트 기반 모델을 포함하여 여러 크기 옵션중에서 선택합니다.
  • Azure Container Apps: 이벤트 기반 자동 크기 조정 사용하여 수행되는 작업 및 현재 부하에 따라 애플리케이션 크기를 조정합니다.
  • AKS(Azure Kubernetes Service): 애플리케이션의 요구를 따라가려면 워크로드실행하는 노드 수를 조정해야 할 수 있습니다. 또한 AKS 클러스터에서 애플리케이션 워크로드의 크기를 빠르게 조정하려면가상 노드를 사용할 수 있습니다.
  • 가상 머신: 가상 머신 확장 집합은 애플리케이션을 실행하는 VM 인스턴스 수를 자동으로 늘리거나 줄일 수 있습니다.

배포 스탬프 패턴

배포 스탬프 패턴 다중 테넌트 솔루션을 지원하는 방법에 대한 자세한 내용은 개요참조하세요.

컴퓨팅 리소스 통합 패턴

컴퓨팅 리소스 통합 패턴 기본 컴퓨팅 리소스를 공유하여 인프라를 컴퓨팅하는 테넌트 밀도를 높일 수 있습니다. 컴퓨팅 리소스를 공유하면 해당 리소스의 직접 비용을 줄일 수 있는 경우가 많습니다. 또한 관리할 구성 요소가 적기 때문에 관리 비용이 낮은 경우가 많습니다.

그러나 컴퓨트 리소스 통합은 노이즈 네이버(이웃) 문제가능성을 증가시킵니다. 모든 테넌트의 워크로드는 사용 가능한 컴퓨팅 용량의 불균형한 양을 소비할 수 있습니다. 솔루션의 크기를 적절하게 조정하고 할당량 및 API 제한과 같은 컨트롤을 적용하여 용량의 공평한 점유율 이상을 소비하는 테넌트를 방지하여 이러한 위험을 완화할 수 있습니다.

이 패턴은 사용하는 컴퓨팅 서비스에 따라 다양한 방식으로 수행됩니다. 다음 예제 서비스를 참조하세요.

  • Azure App Service 및 Azure Functions 계획 : 호스팅 서버 인프라를 나타내는 공유 App Service 계획을 배포합니다.
  • Azure Container Apps: 공유 환경배포하기.
  • AKS(Azure Kubernetes Service): 다중 테넌트 인식 애플리케이션을 사용하여 공유 Pod를 배포합니다.
  • 가상 머신: 사용할 모든 테넌트에 대해 단일 가상 머신 집합을 배포합니다.

테넌트당 전용 컴퓨팅 리소스

모든 테넌트에 대한 전용 컴퓨팅 리소스를 배포할 수도 있습니다. 전용 리소스를 통해 모든 테넌트의 컴퓨팅 리소스를 다른 테넌트와 격리시켜, 소란스러운 이웃 문제위험을 완화합니다. 또한 요구 사항에 따라 각 테넌트의 리소스에 대해 고유한 구성을 배포할 수 있습니다. 그러나 전용 리소스는 일반적으로 리소스에 대한 테넌트 밀도가 낮기 때문에 비용이 더 많이 듭니다.

사용하는 Azure 컴퓨팅 서비스에 따라 다음과 같이 다른 전용 리소스를 배포해야 합니다.

  • azure App Service 및 Azure Functions: 각 테넌트에 대해 별도의 App Service 계획을 배포합니다.
  • azure Container Apps: 각 테넌트에 대해 별도의 환경을 배포합니다.
  • AKS(Azure Kubernetes Service): 각 테넌트에 대한 전용 클러스터를 배포합니다.
  • 가상 머신: 각 테넌트에 전용 가상 머신을 배포합니다.

반 격리된 컴퓨팅 리소스

반 격리된 접근 방식을 사용하려면 격리된 구성에서 솔루션의 측면을 배포하고 다른 구성 요소를 공유해야 합니다.

App Service 및 Azure Functions를 사용하는 경우 각 테넌트에 대해 고유한 애플리케이션을 배포할 수 있으며 공유 App Service 계획에서 애플리케이션을 호스트할 수 있습니다. App Service 계획은 청구 단위를 나타내므로 이 방법을 사용하면 컴퓨팅 계층의 비용이 줄어듭니다. 또한 각 애플리케이션에 고유한 구성 및 정책을 적용할 수 있습니다. 그러나 이 방법은 노이즈 네이버 문제문제를 초래할 수 있습니다.

Azure Container Apps를 사용하면 공유 환경에 여러 애플리케이션을 배포한 다음 Dapr 및 기타 도구를 사용하여 각 애플리케이션을 개별적으로 구성할 수 있습니다.

AKS(Azure Kubernetes Service) 및 Kubernetes는 다음과 같은 다양한 다중 테넌트 옵션을 제공합니다.

  • 공유 클러스터 및 노드 풀에 배포되는 테넌트별 리소스의 논리적 격리를 위한 테넌트별 네임스페이스입니다.
  • 공유 클러스터의 테넌트별 노드 또는 노드 풀.
  • 동일한 노드 풀을 사용할 수 있는 테넌트별 Pod입니다.

AKS를 사용하면 Pod 수준 거버넌스를 적용하여 노이즈 네이버 문제완화할 수 있습니다. 자세한 내용은 애플리케이션 개발자가 AKS(Azure Kubernetes Service)리소스를 관리하는 모범 사례를 참조하세요.

Kubernetes 클러스터의 공유 구성 요소와 이러한 구성 요소가 다중 테넌트의 영향을 받는 방법도 알고 있어야 합니다. 예를 들어 Kubernetes API 서버는 전체 클러스터에서 사용되는 공유 서비스입니다. 테넌트의 애플리케이션 워크로드를 격리하기 위해 테넌트별 노드 풀을 제공하는 경우에도 API 서버는 테넌트 전체의 많은 요청에서 경합이 발생할 수 있습니다.

방지할 안티패턴

시끄러운 이웃 역패턴

테넌트 간에 공유되는 구성 요소를 배포할 때마다 노이즈 네이버 문제 잠재적인 위험이 있습니다. 다른 테넌트의 활동에 의해 영향을 받는 테넌트의 컴퓨팅 워크로드 위험을 완화하기 위해 리소스 거버넌스 및 모니터링을 포함해야 합니다.

테넌트 간 데이터 유출

컴퓨팅 계층은 제대로 처리되지 않은 경우 테넌트 간 데이터 누수의 영향을 받을 수 있습니다. Microsoft는 플랫폼 계층에서 보호를 제공하기 때문에 일반적으로 Azure에서 다중 테넌트 서비스를 사용할 때 고려해야 할 사항이 아닙니다. 그러나 자체 다중 테넌트 애플리케이션을 개발할 때 공유 리소스(예: 로컬 디스크 캐시, RAM 및 외부 캐시)에 다른 테넌트가 실수로 보거나 수정할 수 있는 데이터가 포함될 수 있는지 여부를 고려합니다.

과부하된 프론트엔드 안티패턴

사용 중인 프런트 엔드 안티패턴방지하려면 프런트 엔드 계층이 아키텍처의 다른 구성 요소 또는 계층에서 처리할 수 있는 많은 작업을 수행하지 않도록 합니다. 이 안티패턴은 다중 테넌트 솔루션에 대한 공유 프런트 엔드를 만들 때 특히 중요합니다. 바쁜 프런트 엔드는 모든 테넌트에 대한 환경을 저하하기 때문입니다.

대신 큐 또는 기타 메시징 서비스를 사용하여 비동기 처리를 사용하는 것이 좋습니다. 또한 이 방법을 사용하면 요구 사항에 따라 서로 다른 테넌트에 대한 서비스 품질(QoS) 제어를 적용할 수 있습니다. 예를 들어 모든 테넌트는 공통 프런트 엔드 계층을 공유할 수 있지만 더 높은 서비스 수준 비용을 지불할 있는 테넌트는 큐 메시지에서 작업을 처리하기 위해 더 높은 전용 리소스 집합을 가질 수 있습니다.

비탄력적 또는 불충분한 크기 조정

다중 테넌트 솔루션은 종종 버스트형 스케일링 패턴의 영향을 받습니다. 공유 구성 요소는 버스트의 범위가 더 높고 고유한 사용 패턴을 가진 테넌트가 더 많을 때 영향이 더 커지므로 이 문제에 특히 취약합니다.

클라우드의 탄력성과 규모를 잘 활용해야 합니다. 가로 또는 세로 크기 조정사용하고 자동 크기 조정을 사용하여 부하 급증을 자동으로 처리해야 하는지 여부를 고려합니다. 솔루션을 테스트하여 다양한 부하 수준에서 동작하는 방식을 이해합니다. 프로덕션에 예상되는 부하 볼륨과 예상된 증가를 포함해야 합니다. azure Load Testing같은 완전 관리형 서비스를 사용하여 애플리케이션이 스트레스 상태에서 어떻게 동작하는지 알아볼 수 있습니다.

캐싱 안티패턴 없음

캐싱 방지 방지 애플리케이션 계층이 요청 간에 다시 사용할 수 있는 정보를 반복적으로 요청하거나 다시 계산하기 때문에 솔루션 성능이 저하되는 경우입니다. 테넌트 간 또는 단일 테넌트 내의 사용자 간에 공유할 수 있는 데이터가 있는 경우 백 엔드/데이터베이스 계층의 부하를 줄이기 위해 캐싱할 가치가 있습니다.

불필요한 상태 유지

No Caching 안티패턴의 결과는 컴퓨팅 계층에 불필요한 상태를 저장하지 않는 것입니다. 상태를 유지 관리하는 위치 및 이유에 대해 명시적이어야 합니다. 상태 저장 프런트 엔드나 애플리케이션 계층은 확장성을 감소시킬 수 있습니다. 상태 저장 컴퓨팅 계층에는 일반적으로 세션 선호도가 필요하므로 작업자 또는 노드 간에 트래픽 부하를 효과적으로 분산하는 기능을 줄일 수 있습니다.

컴퓨팅 계층에서 유지 관리하는 각 상태의 장단점과 테넌트의 워크로드 패턴이 변경됨에 따라 크기를 조정하거나 확장하는 기능에 영향을 주는지 여부를 고려합니다. Azure Cache for Redis와 같은 외부 캐시에 상태를 저장할 수도 있습니다.

참여자

이 문서는 Microsoft에서 유지 관리합니다. 그것은 원래 다음 기여자에 의해 작성되었습니다.

주요 작성자:

  • Dixit Arora | 선임 고객 엔지니어, Azure용 FastTrack
  • John Downs | 주요 소프트웨어 엔지니어

기타 기여자:

다음 단계

컴퓨팅 서비스에 대한 서비스별 지침을 검토합니다.