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

  • 아티클

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

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

주요 고려 사항 및 요구 사항

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

확장

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

각 테넌트에 전용 리소스를 배포하는 경우 각 테넌트의 리소스를 유연하게 독립적으로 확장할 수 있습니다. 컴퓨팅 리소스가 여러 테넌트 간에 공유되는 솔루션에서 해당 리소스의 크기를 조정하면 해당 모든 테넌트에서 새 규모를 사용할 수 있습니다. 그러나 규모가 부족하여 전체 부하를 처리할 수 없는 경우에도 문제가 발생합니다. 자세한 내용은 노이지 네이버(Noisy Neighbor) 문제를 참조하세요.

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

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

크기 조정 트리거

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

시스템 상태

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

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

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

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

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

중요

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

격리

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

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

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

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

자동 크기 조정

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

배포 스탬프 패턴

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

Compute 리소스 통합 패턴

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

그러나 컴퓨팅 리소스 통합은 노이지 네이버 문제 발생 가능성을 높입니다. 모든 테넌트의 워크로드에서 사용 가능한 컴퓨팅 용량을 불균형하게 소비할 수 있습니다. 솔루션 크기를 적절하게 조정하고 할당량 및 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 서버에서 테넌트 전반의 많은 요청으로부터 경합이 발생할 수 있습니다.

피해야 할 안티패턴

노이지 네이버 안티패턴

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

테넌트 간 데이터 유출

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

붐비는 프런트 엔드 안태패턴

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

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

비탄력적이거나 부족한 크기 조정

다중 테넌트 솔루션에 버스티 확장 패턴이 적용되는 경우가 많습니다. 공유 구성 요소는 버스트 범위가 더 높고 고유한 사용 패턴을 가진 테넌트가 더 많을 때 영향력이 커지므로 이 문제에 특히 취약합니다.

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

캐싱 없음 안티패턴

캐싱 없음 안티패턴은 애플리케이션 계층이 요청 간에 다시 사용할 수 있는 정보를 반복적으로 요청하거나 다시 계산함으로 인해 솔루션 성능이 저하되는 경우입니다. 테넌트 간에 또는 단일 테넌트 내 사용자 간에 공유할 수 있는 데이터가 있으면 백 엔드/데이터베이스 계층의 부하가 줄어들도록 캐싱하는 것이 좋습니다.

불필요한 상태 저장

캐싱 없음 안티패턴에 대한 필연적인 결과는 컴퓨팅 계층에 불필요한 상태를 저장하지 않아야 한다는 점입니다. 상태를 유지하는 위치와 이유를 명시적으로 지정합니다. 상태 저장 프런트 엔드나 애플리케이션 계층에서 크기 조정 기능을 줄일 수 있습니다. 일반적으로 상태 저장 컴퓨팅 계층에는 세션 선호도도 필요하므로 작업자나 노드 간에 트래픽 부하를 효과적으로 분산하는 기능을 줄일 수 있습니다.

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

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

  • Dixit Arora | 수석 고객 엔지니어, FastTrack for Azure
  • John Downs | FastTrack for Azure 수석 고객 엔지니어

기타 기여자:

다음 단계

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