여러 내부 및 외부 서비스를 포함하는 분산 애플리케이션에는 비동기 메시징 및 이벤트 기반 통신이 필요합니다. 다중 테넌트 솔루션을 디자인할 때 다른 테넌트에 속하는 메시지를 공유하거나 분할하는 방법을 결정해야 합니다.
모든 테넌트에서 메시징 시스템 또는 이벤트 스트리밍 서비스를 공유하여 운영 비용 및 관리 복잡성을 줄일 수 있습니다. 또는 각 테넌트에 대한 전용 메시징 시스템을 사용하여 더 나은 데이터 격리를 얻고, 데이터 유출 위험을 줄이고, 시끄러운 이웃 문제를 제거하고, Azure 비용을 테넌트에 더 쉽게 다시 청구할 수 있습니다.
이 문서는 솔루션 설계자가 다중 테넌트 솔루션에서 메시징 또는 이벤트 인프라를 사용하는 방법을 결정하는 데 도움이 됩니다.
메시지, 데이터 포인트 및 불연속 이벤트
이벤트를 제공하는 서비스와 메시지를 보내는 시스템의 차이점을 이해해야 합니다. 이벤트는 조건 또는 상태 변경에 대한 간단한 알림입니다. 이벤트는 일반적으로 이미 발생한 항목을 설명합니다. 메시지에는 서비스가 다른 곳에서 사용하거나 저장하기 위해 생성하는 원시 데이터가 포함됩니다. 메시지는 암시적 지침 또는 요청입니다.
다음 표에서는 해당 유형의 엔터티를 사용할 수 있는 주요 메시징 유형 및 다중 테넌트 솔루션 예제를 설명합니다.
| 엔터티 형식 | 목차 | 예시 |
|---|---|---|
| 불연속적 사건 | 게시 애플리케이션이 수행하는 특정 작업에 대한 정보 |
|
| 시리즈 이벤트 | 지속적인 연속 스트림의 정보 데이터 요소 |
|
| 메시지 | 수신 서비스가 워크플로 또는 처리 체인에서 단계를 실행하는 데 필요한 정보 |
|
자세한 내용은 데이터에 적합한 Azure 메시징 서비스 선택을 참조하세요.
Azure는 메시징 요구 사항을 지원할 수 있는 여러 메시징 서비스를 제공합니다. 이러한 서비스에는 Azure Event Hubs, Azure Event Grid 및 Azure Service Bus가 포함됩니다. 자세한 내용은 Azure 메시징 서비스 중에서 선택을 참조하세요.
VM(가상 머신), 컨테이너 또는 AKS(Azure Kubernetes Service)와 같은 서비스에서 사용자 고유의 메시징 서비스를 배포하고 관리할 수도 있습니다. 이 접근 방식을 사용하려면 메시징 인프라를 배포, 관리 및 유지 관리해야 합니다.
주요 고려 사항 및 요구 사항
솔루션에 대해 선택한 배포 및 테넌트 모델은 보안, 성능, 데이터 격리, 관리 및 테넌트에 리소스 비용을 교차 청구하는 기능에 영향을 줍니다. 이 분석을 수행할 때 메시징 및 이벤트 인프라에 대해 선택한 모델도 고려합니다. 다음 섹션에서는 다중 테넌트 솔루션에서 메시징 시스템을 계획할 때 수행해야 하는 주요 결정에 대해 설명합니다.
규모
메시징 또는 이벤트 인프라를 계획할 때 테넌트 수, 메시지 흐름 및 이벤트 스트림의 복잡성, 메시지 볼륨, 예상 트래픽 프로필 및 격리 수준을 고려합니다.
먼저 용량을 계획하고 메시징 시스템의 최대 처리량 용량을 설정합니다. 이 계획을 통해 일반 트래픽 및 최대 트래픽 중에 예상되는 메시지 볼륨을 제대로 처리할 수 있습니다.
솔루션이 여러 테넌트를 처리하고 각 테넌트에 대해 별도의 메시징 시스템을 사용하는 경우 일관된 자동화 전략을 적용합니다. 이 전략은 각 인프라의 배포, 모니터링, 경고 및 크기 조정을 자동화해야 합니다.
예를 들어 Terraform, Bicep 또는 ARM 템플릿(Azure Resource Manager 템플릿)과 같은 IaC(Infrastructure as Code) 도구와 Azure DevOps 또는 GitHub Actions와 같은 DevOps 시스템을 사용하여 프로비저닝 프로세스 중에 테넌트에 대한 메시징 시스템을 배포할 수 있습니다. 자세한 내용은 다중 테넌트 솔루션의 배포 및 구성을 위한 아키텍처 접근 방식을 참조하세요.
메시징 시스템을 시간 단위당 최대 메시지 처리량으로 설계할 수 있습니다. 시스템에서 동적 자동 크기 조정을 지원하는 경우 예상되는 SLA(서비스 수준 계약)를 충족하기 위해 트래픽 조건 및 메트릭에 따라 용량을 자동으로 늘리거나 줄일 수 있습니다.
성능 예측 가능성 및 안정성
일부 테넌트의 경우 단일 메시징 시스템은 기능 처리량 요구 사항을 충족하고 TCO(총 소유 비용)를 줄일 수 있습니다. 다중 테넌트 애플리케이션은 여러 고객 간에 큐 및 토픽과 같은 동일한 메시징 엔터티를 공유할 수 있습니다. 또는 각 테넌트에 대한 전용 구성 요소 집합을 사용하여 테넌트 격리를 늘릴 수 있습니다. 그러나 여러 테넌트에서 공유 메시징 인프라는 전체 솔루션을 시끄러운 이웃 문제에 노출할 수 있습니다. 한 테넌트의 활동은 다른 테넌트의 성능 및 작동성을 방해할 수 있습니다.
이 경우 최대 시간에 예상되는 트래픽 부하를 유지하기 위해 메시징 시스템의 크기를 적절하게 조정해야 합니다. 이상적으로 시스템은 트래픽 증가 시에는 동적으로 확장하고, 트래픽 감소 시에는 축소하는 자동 크기 조정을 지원해야 합니다. 각 테넌트에 대한 전용 메시징 시스템은 시끄러운 인접 위험을 완화할 수도 있지만 많은 메시징 시스템을 관리하면 솔루션 복잡성이 증가합니다.
다중 테넌트 애플리케이션은 하이브리드 접근 방식을 사용할 수 있습니다. 이 방법에서 핵심 서비스는 단일 공유 메시징 시스템에서 동일한 큐 및 토픽 집합을 사용하여 내부 비동기 통신을 구현합니다. 반면, 다른 서비스는 시끄러운 이웃 문제를 완화하고 데이터 격리를 보장하기 위해 각 테넌트에 대한 전용 메시징 엔터티 또는 전용 메시징 시스템을 채택할 수 있습니다.
관리 및 운영 복잡성
처음부터 메시징 및 이벤트 인프라를 운영, 모니터링 및 유지 관리하는 방법과 다중 테넌트 접근 방식이 작업 및 프로세스에 미치는 영향을 계획합니다. 예를 들어 다음 요소를 고려합니다.
여러 테넌트 간에 메시징 시스템을 공유하는 경우 솔루션이 각 테넌트에 대한 사용 메트릭을 수집하고 보고하는 방법 또는 각 테넌트가 보내거나 받을 수 있는 메시지 수를 제한하는 방법을 정의합니다.
테넌트가 다른 유형의 메시징 서비스, 다른 배포 또는 다른 지역으로 이동해야 하는 경우 마이그레이션 방법을 결정합니다.
메시징 시스템에서 PaaS(Platform as a Service) 제품을 사용하는 경우 다음 고려 사항을 고려합니다.
테넌트가 요청하는 기능 및 공유 또는 전용 격리 수준에 따라 각 테넌트에 대한 가격 책정 계층을 사용자 지정합니다.
테넌트별 관리 ID 및 Azure 역할 할당을 만들어 테넌트가 액세스해야 하는 메시징 엔터티에만 적절한 권한을 할당합니다. 예를 들어 Service Bus 리소스에 액세스하려면 Microsoft Entra ID를 사용하여 관리 ID 인증을 참조하세요.
애플리케이션이 전용 VM 또는 컨테이너 집합(각 테넌트에 대해 하나씩)에서 사용하는 메시징 시스템을 호스트하도록 선택하는 경우 이러한 시스템을 배포, 업그레이드, 모니터링 및 스케일 아웃하는 방법을 정의합니다.
비용
일반적으로 배포 인프라의 테넌트 밀도가 높을수록 해당 인프라를 프로비저닝하는 비용이 적게 듭니다. 그러나 공유 인프라는 시끄러운 이웃 문제와 같은 문제의 가능성을 높입니다. 절충안을 신중하게 고려하십시오.
고려해야 할 접근 방식 및 패턴
메시징을 포함하는 다중 테넌트 솔루션을 계획할 때 테넌트 간의 격리 수준을 고려합니다. 다음 고려 사항 및 관찰 사항을 검토합니다.
암호화 키: 테넌트가 메시지를 암호화하고 암호를 해독하기 위해 자체 키가 필요한 경우 메시징 서비스가 키 격리를 지원하는 방법을 확인합니다. 예를 들어 Service Bus를 사용하는 경우 고유한 키가 필요한 각 테넌트에 대해 별도의 Service Bus Premium 네임스페이스를 만들어야 할 수 있습니다. 이렇게 분리하면 CMK(고객 관리형 키)를 사용할 수 있습니다.
비즈니스 연속성: 높은 수준의 복구 가능성 및 비즈니스 연속성이 필요한 테넌트를 식별합니다. 사용 가능한 경우 이러한 테넌트에 대한 영역 중복성, 지역 중복성 및 지역 재해 복구 기능을 고려합니다.
작업자 처리: 각 테넌트에 대해 별도의 큐 리소스 또는 전용 메시징 시스템을 사용하는 경우 각 테넌트에 대해 별도의 작업자 프로세스 풀을 채택할 수 있습니다. 이 방법은 데이터 격리 수준을 높이고 여러 메시징 엔터티를 관리하는 복잡성을 줄입니다.
처리 시스템의 각 인스턴스는 연결 문자열, 서비스 주체 또는 관리 ID와 같은 다양한 자격 증명을 채택하여 전용 메시징 시스템에 액세스할 수 있습니다. 이 방법은 테넌트 간의 보안 및 격리를 개선하지만 ID 관리 복잡성을 증가시킵니다.
공유 메시지 시스템
단일 Service Bus 네임스페이스와 같은 공유 메시징 시스템을 배포하고 모든 테넌트에서 공유할 수 있습니다.
이 방법은 인프라에 대한 테넌트 밀도를 가장 높게 제공하고 전체 TCO를 줄입니다. 단일 메시징 시스템 또는 리소스만 관리하고 보호하면 되므로 관리 오버헤드가 감소하는 경우가 많습니다.
그러나 여러 테넌트에서 리소스 또는 전체 인프라를 공유하는 경우 다음 제한 사항을 고려합니다.
리소스의 제약 조건, 크기 조정 기능, 할당량 및 제한을 고려합니다. 예를 들어 단일 네임스페이스의 최대 Event Hubs 수 또는 최대 처리량 제한은 더 많은 테넌트를 지원하기 위해 아키텍처가 확장될 때 결국 차단기가 될 수 있습니다.
특히 다른 테넌트보다 높은 트래픽을 생성하는 사용량이 많은 테넌트 또는 테넌트가 있는 경우 시끄러운 인접 문제가 여러 테넌트 간에 리소스를 공유할 때 요인이 될 수 있습니다. 이러한 효과를 완화하려면 제한 패턴 또는 속도 제한 패턴을 고려합니다. 예를 들어 단일 테넌트가 일정 기간 내에 보내거나 받을 수 있는 최대 메시지 수를 제한할 수 있습니다.
활동을 모니터링하고 개별 테넌트에 대한 리소스 사용량을 측정하는 데 어려움을 겪을 수 있습니다. Service Bus의 특정 계층과 같은 일부 서비스는 메시징 작업에 대한 요금을 청구합니다. 여러 테넌트 간에 네임스페이스를 공유하는 경우 애플리케이션은 각 테넌트가 생성하는 메시징 작업 수와 관련 차지백 비용을 추적해야 합니다. 다른 서비스는 동일한 수준의 세부 정보를 제공하지 않습니다.
테넌트에는 보안, 지역 내 복원력, 재해 복구 또는 위치에 대한 요구 사항이 다를 수 있습니다. 이러한 요구 사항이 메시징 시스템 구성과 일치하지 않는 경우 단일 리소스로만 수용할 수 없습니다.
샤딩 패턴 사용
샤딩 패턴에는 또한 샤드라고 하는 여러 메시징 시스템을 배포하는 것이 포함됩니다. 각 샤드는 큐 및 토픽과 같은 하나 이상의 테넌트의 메시지 엔티티를 포함합니다. 배포 스탬프와 달리 분할된 데이터베이스는 전체 인프라를 복제한다는 의미는 아닙니다. 솔루션에서 다른 인프라를 복제하거나 분할하지 않고도 메시지 시스템을 분할할 수 있습니다.
안정성, SKU 및 위치의 측면에서 모든 메시지 시스템 또는 분할된 데이터베이스의 특성이 서로 다를 수 있습니다. 예를 들어 성능, 안정성, 데이터 보호 또는 비즈니스 연속성에 대한 위치 또는 요구 사항에 따라 여러 메시징 시스템에 테넌트 분할할 수 있습니다.
분할 패턴을 사용하는 경우 분할 전략을 사용하여 지정된 테넌트를 해당 큐가 포함된 메시징 시스템에 매핑해야 합니다. 조회 전략은 맵을 사용하여 테넌트 이름 또는 ID를 기반으로 대상 메시징 시스템을 식별합니다. 여러 테넌트가 동일한 분할된 데이터베이스를 공유할 수 있지만 단일 테넌트에서 사용하는 메시징 엔터티는 하나의 분할된 데이터베이스 내에 유지됩니다.
각 테넌트 이름을 대상 메시징 시스템의 이름 또는 참조에 연결하는 사전으로 맵을 구현할 수 있습니다. 다중 테넌트 애플리케이션의 모든 인스턴스가 액세스할 수 있는 분산 캐시에 맵을 저장하거나 관계형 데이터베이스 또는 스토리지 계정의 테이블과 같은 영구 저장소에 저장할 수 있습니다.
분할 패턴은 여러 임차인을 지원하도록 확장할 수 있습니다. 워크로드에 따라 분할된 데이터베이스에 대한 테넌트의 밀도가 높아 비용을 줄일 수 있습니다. 분할 패턴을 사용하여 Azure 구독 및 서비스 할당량, 제한 및 제약 조건을 해결할 수도 있습니다.
각 테넌트에 대한 전용 메시징 시스템에서 다중 테넌트 앱 사용
각 테넌트에 전용 메시징 시스템을 사용하는 단일 다중 테넌트 애플리케이션을 배포할 수도 있습니다. 이 테넌트 모델에는 컴퓨팅 리소스와 같은 일부 공유 구성 요소가 포함됩니다. 단일 테넌트 전용 배포 방법을 사용하여 다른 서비스를 프로비전하고 관리합니다. 예를 들어 다음 그림과 같이 단일 애플리케이션 계층을 빌드한 다음 각 테넌트에 대한 개별 메시징 시스템을 배포할 수 있습니다.
특정 구성 요소가 대부분의 시스템 부하를 생성하고 각 테넌트에 대해 이러한 구성 요소를 별도로 배포할 수 있는 경우 수평 분할된 배포를 사용하여 시끄러운 인접 문제를 줄입니다. 예를 들어 단일 인스턴스가 여러 테넌트에서 생성하는 트래픽을 따라갈 수 없는 경우 각 테넌트에 대해 별도의 메시징 또는 이벤트 스트림 시스템을 사용합니다. 각 테넌트에 전용 메시징 시스템을 사용하는 경우 단일 테넌트의 대량 메시지 또는 이벤트는 공유 구성 요소에 영향을 주지만 다른 테넌트의 메시징 시스템에는 영향을 미치지 않을 수 있습니다.
각 테넌트에 대한 전용 리소스를 프로비전하기 때문에 이 방법은 공유 호스팅 모델보다 비용이 많이 드는 경우가 많습니다. 그러나 사용하는 리소스에 대해 각 테넌트에 요금을 청구하는 간단한 방법도 제공합니다. 이 방법을 사용하면 컴퓨팅 리소스와 같은 다른 서비스에 대해 고밀도를 달성하고 이러한 구성 요소의 비용을 줄일 수 있습니다.
수평 분할된 배포를 사용하면 다중 테넌트 애플리케이션의 서비스, 특히 단일 테넌트에서 사용하는 서비스를 배포하고 관리하기 위한 자동화된 프로세스가 필요합니다.
기여자
Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.
주요 저자:
- Paolo Salvatori | 수석 고객 엔지니어, FastTrack for Azure
기타 기여자:
- Daphne Choong | 선임 파트너 솔루션 설계자
- John Downs | 주요 소프트웨어 엔지니어, Azure 패턴 및 사례
- Clemens Vasters | 수석 설계자, Messaging Services and Standards
- Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure
관련 리소스
메시지 디자인 패턴에 대한 자세한 내용은 다음 리소스를 참조하세요.