다중 테넌트 솔루션의 메시징을 위한 아키텍처 접근 방식
비동기 메시지 및 이벤트 기반 통신은 여러 내부 및 외부 서비스로 구성된 분산 애플리케이션을 빌드할 때 중요한 자산입니다. 다중 테넌트 솔루션을 설계할 때, 예비 분석을 수행하여 다른 테넌트와 관련된 메시지를 공유하거나 분할하는 방법을 정의하는 것이 중요합니다.
동일한 메시지 시스템 또는 이벤트 스트리밍 서비스를 공유하면 운영 비용과 관리 복잡성을 크게 줄일 수 있습니다. 그러나 각 테넌트에 전용 메시징 시스템을 사용하면 더 나은 데이터 격리를 제공하고, 데이터 유출 위험을 줄이고, 노이시 네이버 문제를 제거하고, Azure 비용을 테넌트에 쉽게 다시 청구할 수 있습니다.
이 문서에서는 메시지와 이벤트의 차이를 알 수 있으며, 솔루션 설계자가 다중 테넌트 솔루션에서 메시지 또는 이벤트 인프라에 사용할 방법을 결정할 때 따를 수 있는 지침을 찾을 수 있습니다.
메시지, 데이터 포인트 및 불연속 이벤트
모든 메시지 시스템의 기능, 전송 프로토콜 및 사용 시나리오는 비슷합니다. 예를 들어 대부분의 최신 메시지 시스템은 휘발성 또는 영구 큐, AMQP 및 HTTPS 전송 프로토콜, 최소 1회 전송 등을 사용하는 비동기 통신을 지원합니다. 그러나 게시된 정보의 종류와 클라이언트 애플리케이션에서 데이터를 사용하고 처리하는 방법을 자세히 살펴보면 다양한 종류의 메시지와 이벤트를 구분할 수 있습니다. 이벤트를 전송하는 서비스와 메시지를 전송하는 서비스 간에는 중요한 차이점이 있습니다. 자세한 내용은 다음 자료를 참조하세요.
- 세 가지 Azure 메시징 서비스인 Event Grid, Event Hubs 및 Service Bus 중에서 선택합니다.
- 이벤트, 데이터 요소 및 메시지 - 데이터에 적합한 Azure 메시지 서비스 선택
이벤트
이벤트는 조건 또는 상태 변경에 대한 간단한 알림입니다. 이벤트는 불연속 단위 또는 시리즈의 일부일 수 있습니다. 이벤트는 일반적으로 알리는 용도 이외의 목적으로는 게시자의 의도를 전달하지 않는 메시지입니다. 이벤트는 팩트를 캡처하여 다른 서비스 또는 구성 요소에 전달합니다. 이벤트 소비자는 게시자를 즐겁게 하지만 게시자가 갖고 있는 특정 기대치를 충족하지 이벤트를 처리할 수 있습니다. 이벤트를 다음과 같은 두 가지 주요 범주로 분류할 수 있습니다.
- 불연속 이벤트는 게시 애플리케이션이 수행한 특정 작업에 대한 정보를 보유합니다. 비동기 이벤트 기반 통신을 사용하는 경우 애플리케이션은 도메인 내에서 무언가가 발생할 때 알림 이벤트를 게시합니다. 하나 이상의 소비 애플리케이션은 제품 카탈로그 애플리케이션의 가격 변경과 같은 이러한 상태 변경을 알고 있어야 합니다. 소비자는 이벤트를 구독하여 비동기적으로 이벤트를 수신합니다. 특정 이벤트가 발생하면 소비 애플리케이션이 자체 도메인 엔터티를 업데이트할 수 있으며, 이로 인해 더 많은 통합 이벤트가 게시될 수 있습니다.
- 시리즈 이벤트는 분석용 디바이스의 온도 판독값 또는 클릭 분석 솔루션의 사용자 작업과 같은 정보 데이터 요소를 지속적인 연속 스트림의 요소로 전달합니다. 이벤트 스트림은 필드 디바이스에서 보고하는 온도 또는 습도와 같은 특정 컨텍스트와 관련이 있습니다. 동일한 컨텍스트와 관련된 모든 이벤트에는 엄격한 임시 순서가 있으며, 이러한 순서는 이벤트 스트림 처리 엔진을 사용하여 이벤트를 처리할 때 중요합니다. 데이터 요소를 전달하는 이벤트 스트림을 분석하려면 원하는 기간에 걸쳐 있는 버퍼에 이러한 이벤트를 누적해야 합니다. 또는 거의 실시간 솔루션 또는 기계 학습 알고리즘을 사용하여 선택한 수의 항목에 포함한 다음, 이러한 이벤트를 처리할 수 있습니다. 일련의 이벤트를 분석하면 임계값을 초과하는 기간 동안 측정된 값의 평균과 같은 신호를 생성할 수 있습니다. 그런 다음, 이러한 신호를 실행 가능한 개별 이벤트로 발생시킬 수 있습니다.
불연속 이벤트는 상태 변경을 보고하며 실행이 가능합니다. 이벤트 페이로드는 발생한 상황에 대한 정보를 갖고 있지만, 일반적으로 이벤트를 트리거한 온전한 데이터를 갖고 있지는 않습니다. 예를 들어 이벤트는 보고 애플리케이션이 스토리지 계정에 새 파일을 만들었다는 것을 소비자에게 알립니다. 이벤트 페이로드에 파일에 대한 일반 정보가 포함될 수는 있지만 파일 자체를 포함하지는 않습니다. 불연속 이벤트는 크기를 조정해야 하는 서버리스 솔루션에 이상적입니다.
시리즈 이벤트는 조건을 보고하며 분석이 가능합니다. 불연속 이벤트는 시간 순서가 지정되며 상호 연관됩니다. 일부 컨텍스트에서는 소비자가 전체 이벤트 시퀀스를 수신하여 어떤 일이 있었는지 분석하고 필요한 조치를 취해야 합니다.
메시지
메시지는 다른 곳에 사용하거나 저장하기 위해 서비스에서 생성한 원시 데이터입니다. 메시지는 수신 서비스가 워크플로 또는 처리 체인에서 단계를 실행하는 데 필요한 정보를 전달하는 경우가 많습니다. 이러한 통신의 예는 명령 패턴입니다. 또한 게시자는 메시지 수신자가 일련의 작업을 실행한 후 비동기 메시지를 통해 처리 결과를 다시 보고할 것으로 기대합니다. 메시지 게시자와 메시지 수신자 간의 계약이 있습니다. 예를 들어 게시자는 원시 데이터가 포함된 메시지를 보냅니다. 그리고 소비자가 이 데이터로 파일을 만들고 작업이 완료되면 응답 메시지를 다시 자신에게 보낼 것으로 기대합니다. 다른 상황에서 발신자 프로세스는 다른 서비스에 특정 작업을 수행하도록 요청하는 비동기 단방향 메시지를 보낼 수 있지만, 승인 또는 응답 메시지를 다시 받을 것으로 기대하지는 않습니다.
이러한 종류의 계약 메시지 처리는 이러한 알림을 처리하는 방법에 대한 구체적인 기대 없이 불연속 이벤트를 소비자 에이전트의 대상 그룹에 게시하는 게시자와는 매우 다릅니다.
예제 시나리오
다음은 메시지, 데이터 요소 및 불연속 이벤트에 대한 다중 테넌트 예제 시나리오 목록입니다.
- 불연속 이벤트:
- 음악 공유 플랫폼은 특정 테넌트의 특정 사용자가 특정 음악 트랙을 들었다는 사실을 추적합니다.
- 온라인 스토어 웹 애플리케이션에서 카탈로그 애플리케이션은 게시자-구독자 패턴을 사용하는 이벤트를 다른 애플리케이션에 보내 품목 가격이 변경되었음을 알립니다.
- 제조 회사는 장비 유지 관리, 시스템 상태 및 계약 업데이트에 대한 실시간 정보를 고객과 타사에 푸시합니다.
- 데이터 포인트:
- 건물 제어 시스템은 여러 고객에게 속한 센서에서 온도 또는 습도 판독값과 같은 원격 분석 이벤트를 수신합니다.
- 이벤트 기반 모니터링 시스템은 웹 서버와 같은 여러 서비스에서 거의 실시간으로 진단 로그를 수신하고 처리합니다.
- 웹 페이지의 클라이언트 쪽 스크립트는 사용자 작업을 수집하여 클릭 분석 솔루션으로 보냅니다.
- 메시지:
- B2B 금융 애플리케이션은 테넌트의 뱅킹 레코드 처리를 시작하는 메시지를 받습니다.
- 장기 실행 워크플로는 다음 단계의 실행을 트리거하는 메시지를 받습니다.
- 온라인 스토어 애플리케이션의 장바구니 애플리케이션은 비동기 영구 메시지를 사용하여 주문 애플리케이션에 CreateOrder 명령을 보냅니다.
주요 고려 사항 및 요구 사항
솔루션에 대해 선택하는 배포 및 테넌트 모델은 보안, 성능, 데이터 격리, 관리 및 테넌트에 리소스 비용을 교차 청구하는 기능에 깊은 영향을 줍니다. 이 분석에는 메시지 및 이벤트 인프라에 대해 선택하는 모델이 포함됩니다. 이 섹션에서는 다중 테넌트 솔루션에서 메시지 시스템을 계획할 때 내려야 하는 중요한 의사 결정을 검토합니다.
확장
메시지 또는 이벤트 인프라를 계획할 때 테넌트 수, 메시지 흐름 및 이벤트 스트림의 복잡성, 메시지 볼륨, 예상 트래픽 프로필 및 격리 수준에 따라 결정을 내려야 합니다.
첫 번째 단계는 보통 또는 최대 트래픽에서 예상되는 메시지 볼륨을 적절하게 처리하는 데 필요한 처리량의 관점에서 철저한 용량 계획을 수립하고 메시지 시스템에 필요한 최대 용량을 설정하는 것입니다.
Azure Service Bus 프리미엄 계층과 같은 일부 서비스 제품은 각 고객 워크로드가 격리된 상태로 실행되도록 CPU 및 메모리 수준에서 리소스 격리를 제공합니다. 이 리소스 컨테이너를 메시징 단위라고 합니다. 각 프리미엄 네임스페이스에는 하나 이상의 메시징 단위가 할당됩니다. Service Bus 프리미엄 네임스페이스마다 1, 2, 4, 8 또는 16 메시징 단위를 구입할 수 있습니다. 단일 워크로드 또는 엔터티가 여러 메시징 단위에 걸쳐 있을 수 있으며 메시징 단위를 필요한 대로 변경할 수 있습니다. 그 결과로 Service Bus 기반 솔루션에 대해 예측 가능하고 반복 가능한 성능이 구현됩니다. 자세한 내용은 Service Bus 프리미엄 및 표준 메시지 계층을 참조하세요. 마찬가지로 Azure Event Hubs 가격 책정 계층을 통해 인바운드 및 아웃바운드 이벤트의 예상 볼륨에 따라 네임스페이스의 크기를 조정할 수 있습니다. 예를 들어 프리미엄 서비스의 요금은 기본 인프라에서 격리된 리소스(CPU, 메모리 및 스토리지)의 공유에 해당하는 PU(처리 단위)를 기준으로 청구됩니다. PU당 유효한 수집 및 스트림 처리량은 다음과 같은 요인에 따라 달라집니다.
- 생산자와 소비자의 수
- 페이로드 크기
- 파티션 수
- 송신 요청 속도
- Event Hubs 캡처, 스키마 레지스트리 및 기타 고급 기능 사용
자세한 내용은 Event Hubs 프리미엄 개요를 참조하세요.
솔루션이 처리하는 테넌트가 너무 많아서 테넌트마다 별도의 메시지 시스템을 채택하기로 결정하는 경우 각 인프라의 배포, 모니터링, 경고 및 크기 조정을 서로 별도로 자동화하는 일관적인 전략이 있어야 합니다.
예를 들어 Terraform, Bicep 또는 ARM(Azure Resource Manager) JSON 템플릿 같은 IaC(Infrastructure as code) 도구와 Azure DevOps 또는 GitHub Actions 같은 DevOps 시스템을 사용하여 프로비저닝 프로세스 중에 특정 테넌트에 대한 메시지 시스템을 배포할 수 있습니다. 자세한 내용은 다중 테넌트 솔루션의 배포 및 구성을 위한 아키텍처 접근 방식을 참조하세요.
메시지 시스템의 크기는 최대 처리량(단위 시간당 메시지 수)으로 조정할 수 있습니다. 시스템이 동적 자동 크기 조정을 지원하는 경우 예상되는 서비스 수준 계약을 충족하기 위해 트래픽 조건 및 메트릭에 따라 용량이 자동으로 증가하거나 감소할 수 있습니다.
성능 예측 가능성 및 안정성
제한된 수의 테넌트에 대한 메시지 시스템을 설계하고 빌드할 때, 단일 메시지 시스템을 사용하는 것이 처리량 측면에서 기능 요구 사항을 충족하는 훌륭한 솔루션이 될 수 있으며 총 소유 비용을 줄일 수 있습니다. 다중 테넌트 애플리케이션은 큐 및 토픽과 같은 동일한 메시지 엔터티를 여러 고객 간에 공유할 수 있습니다. 또는 테넌트 격리를 향상하기 위해 각 테넌트에 전용 구성 요소 세트를 사용할 수도 있습니다. 반면 여러 테넌트 간에 동일한 메시지 인프라를 공유하면 전체 솔루션이 노이즈 네이버 문제에 노출될 수 있습니다. 한 테넌트의 활동이 성능 및 작동성 측면에서 다른 테넌트에 해를 끼칠 수 있습니다.
이 경우 피크 타임에 예상되는 트래픽 부하를 감당할 수 있도록 메시지 시스템의 크기를 적절하게 조정해야 합니다. 자동 크기 조정을 지원하는 것이 가장 좋습니다. 트래픽이 증가할 때 메시지 시스템을 동적으로 스케일 아웃하고 트래픽이 감소할 때 스케일 인해야 합니다. 테넌트마다 전용 메시지 시스템을 사용하면 노이지 네이버 위험을 완화할 수 있지만, 많은 수의 메시지 시스템을 관리하려면 솔루션의 복잡성이 증가할 수 있습니다.
다중 테넌트 애플리케이션은 결국 내부 비동기 통신을 구현하기 위해 핵심 서비스가 단일 공유 메시지 시스템에서 동일한 큐 및 토픽 세트를 사용하는 하이브리드 접근 방식을 채택할 수 있습니다. 반면 다른 서비스는 노이지 네이버 문제를 완화하고 데이터 격리를 보장하기 위해 각 테넌트에 전용 메시지 엔터티 그룹 또는 전용 메시지 시스템을 채택할 수 있습니다.
가상 머신에 메시지 시스템을 배포할 때, 네트워크 대기 시간을 줄일 수 있도록 이러한 가상 머신을 컴퓨팅 리소스와 함께 배치해야 합니다. 메시지 인프라가 CPU, 메모리 및 네트워크 대역폭과 같은 시스템 리소스를 두고 다른 시스템과 경쟁하지 않도록 이러한 가상 머신을 다른 서비스 또는 애플리케이션과 공유하면 안 됩니다. 또한 가상 머신을 여러 가용성 영역에 분산하여 메시지 시스템을 비롯한 중요 비즈니스용 워크로드의 지역 내 복원력과 안정성을 높일 수 있습니다. 가상 머신에 RabbitMQ 또는 Apache ActiveMQ와 같은 메시지 시스템을 호스트하기로 결정했다고 가정하겠습니다. 이 경우 가상 머신 확장 집합에 배포하고 CPU 또는 메모리와 같은 메트릭을 기반으로 자동 크기 조정을 구성하는 것이 좋습니다. 이렇게 하면 메시지 시스템을 호스트하는 에이전트 노드 수가 트래픽 조건에 따라 적절하게 스케일 아웃 및 스케일 인됩니다. 자세한 내용은 Azure 가상 머신 확장 집합을 사용한 자동 크기 조정 개요를 참조하세요.
마찬가지로 Kubernetes 클러스터에서 메시지 시스템을 호스트할 때에는 노이지 네이버 문제를 방지하기 위해 노드 선택기 및 taint를 사용하여 다른 워크로드와 공유되지 않는 전용 노드 풀에서 해당 Pod의 실행을 예약하는 것이 좋습니다. 영역 중복 AKS 클러스터에 메시지 시스템을 배포할 때에는 Pod 토폴로지 분산 제약 조건을 사용하여 지역, 가용성 영역 및 노드와 같은 장애 도메인의 AKS 클러스터에 Pod가 분산되는 방식을 제어합니다. AKS에 타사 메시지 시스템을 호스트할 때에는 Kubernetes 자동 크기 조정을 사용하여 트래픽이 증가할 때 작업자 노드 수를 동적으로 스케일 아웃합니다. 수평형 Pod 자동 크기 조정기 및 AKS 클러스터 자동 크기 조정기를 사용하면 노드 및 Pod 볼륨이 실시간으로 동적으로 조정되어 트래픽 조건과 일치하게 되고 용량 문제로 인한 가동 중지 시간을 방지할 수 있습니다. 자세한 내용은 AKS(Azure Kubernetes Service)에 대한 애플리케이션 요구 사항을 충족하도록 클러스터 자동 확장을 참조하세요. 특정 큐의 길이에 따라 RabbitMQ 또는 Apache ActiveMQ와 같은 Kubernetes 호스팅 메시지 시스템의 Pod 수를 스케일 아웃하려는 경우 KEDA(Kubernetes 이벤트 기반 자동 크기 조정)를 사용하는 것이 좋습니다. KEDA를 사용하면 처리해야 하는 이벤트 수에 따라 Kubernetes에서 컨테이너의 크기 조정을 구동할 수 있습니다. 예를 들어 KEDA를 사용하여 Azure Service Bus 큐, RabbitMQ 큐 또는 ActiveMQ 큐의 길이에 따라 애플리케이션을 스케일링할 수 있습니다. KEDA에 대한 자세한 내용은 Kubernetes 이벤트 기반 자동 크기 조정을 참조하세요.
격리
다중 테넌트 솔루션의 메시지 시스템을 디자인할 때에는 테넌트의 성능, 개인 정보 보호 및 감사 요구 사항에 따라 애플리케이션 유형별로 다른 종류의 격리가 필요하다는 점을 고려해야 합니다.
- 여러 테넌트가 동일한 메시지 시스템에서 큐, 토픽 및 구독과 같은 동일한 메시지 엔터티를 공유할 수 있습니다. 예를 들어 다중 테넌트 애플리케이션은 단일 Azure Service Bus 큐에서 여러 테넌트에 대한 데이터를 전달하는 메시지를 받을 수 있습니다. 이 솔루션은 성능 및 확장성 문제로 이어질 수 있습니다. 일부 테넌트에서 다른 테넌트보다 많은 양의 주문을 생성하는 경우 메시지 백로그가 발생할 수 있습니다. 노이지 네이버 문제라고도 하는 이 문제는 대기 시간 측면에서 일부 테넌트의 서비스 수준 계약을 저하시킬 수 있습니다. 소비자 애플리케이션이 큐에서 메시지를 한 번에 하나씩 엄격한 시간순으로 읽고 처리하는 경우와 메시지를 처리하는 데 필요한 시간이 페이로드의 항목 수에 따라 달라지는 경우에는 문제가 더 분명합니다. 여러 테넌트에서 하나 이상의 큐 리소스를 공유하는 경우 메시지 인프라와 처리 시스템은 스케일링 및 처리량 요구 사항 기반의 예상 트래픽을 수용할 수 있어야 합니다. 이 아키텍처 접근 방식은 다중 테넌트 솔루션이 모든 테넌트에 대한 메시지를 수신, 처리 및 전송할 수 있도록 단일 작업자 프로세스 풀을 채택하는 시나리오에 적합합니다.
- 여러 테넌트가 동일한 메시지 시스템을 공유하지만 다른 토픽 또는 큐 리소스를 사용합니다. 이 접근 방식은 시스템 관리자가 더 많은 수의 큐 리소스를 프로비저닝, 모니터링 및 유지 관리해야 하므로 비용, 운영 복잡성 및 민첩성을 희생하는 대가로 보다 나은 격리와 데이터 보호를 제공합니다. 이 솔루션은 테넌트가 다른 테넌트에 영향을 미칠 수 있는 병목 상태를 만들지 못하도록 차단하므로 성능 및 서비스 수준 계약의 측면에서 모든 테넌트에 일관적이고 예측 가능한 환경을 보장합니다.
- 각 테넌트에 별도의 전용 메시지 시스템을 사용합니다. 예를 들어 다중 테넌트 솔루션은 각 테넌트에 별도의 Azure Service Bus 네임스페이스를 사용할 수 있습니다. 이 솔루션은 복잡성과 운영 비용이 증가하는 대신 최고 수준의 격리를 제공합니다. 이 접근 방식은 일관적인 성능을 보장하며 테넌트 요구 사항에 따라 메시지 시스템을 미세 조정할 수 있습니다. 새 테넌트가 온보딩되면 완전한 전용 메시지 시스템뿐 아니라 프로비저닝 애플리케이션도 새로 만든 네임스페이스에 액세스할 수 있는 적절한 RBAC 권한이 있는 별도의 관리 ID 또는 서비스 주체를 만들어야 할 수도 있습니다. 예를 들어 Kubernetes 클러스터를 동일한 SaaS 애플리케이션의 여러 인스턴스(테넌트마다 하나씩, 각 인스턴스는 별도의 네임스페이스에서 실행됨)가 공유하는 경우 각 애플리케이션 인스턴스는 서로 다른 서비스 주체 또는 관리 ID를 사용하여 전용 메시지 시스템에 액세스할 수 있습니다. 이러한 맥락에서 메시지 시스템은 Azure Service Bus 네임스페이스와 같은 완전 관리형 PaaS 서비스 또는 RabbitMQ와 같은 Kubernetes 호스팅 메시지 시스템일 수 있습니다. 시스템에서 테넌트를 삭제할 경우 애플리케이션에서 메시지 시스템과 이전에 테넌트에 대해 만들어진 전용 리소스를 제거해야 합니다. 이 접근 방식의 주요 단점은 특히 시간이 지나면서 테넌트 수가 증가하면 운영 복잡성이 증가하고 민첩성이 감소한다는 것입니다.
다음과 같은 추가 고려 사항 및 관찰 결과를 검토하세요.
- 테넌트가 자체 키를 사용하여 메시지를 암호화 및 암호 해독해야 하는 경우 다중 테넌트 솔루션은 각 테넌트에 별도의 Azure Service Bus 프리미엄 네임스페이스를 채택하는 옵션을 제공해야 합니다. 자세한 내용은 Azure Service Bus 미사용 데이터를 암호화하기 위해 고객 관리형 키 구성을 참조하세요.
- 테넌트에 높은 수준의 복원력과 비즈니스 연속성이 필요한 경우 다중 테넌트 솔루션은 지역 재해 복구 및 가용성 영역을 사용하도록 설정된 Service Bus 프리미엄 네임스페이스를 프로비저닝하는 기능을 제공해야 합니다. 자세한 내용은 Azure Service Bus 지역 재해 복구를 참조하세요.
- 각 테넌트에 별도의 큐 리소스 또는 전용 메시지 시스템을 사용하는 경우 각 테넌트에 별도의 작업자 프로세스 풀을 채택하여 데이터 격리 수준을 높이고 여러 메시지 엔터티를 처리하는 복잡성을 줄이는 것이 합리적입니다. 처리 시스템의 각 인스턴스는 전용 메시지 시스템에 액세스하기 위해 연결 문자열, 서비스 주체 또는 관리 ID와 같은 여러 자격 증명을 채택할 수 있습니다. 이 접근 방식은 보다 나은 보안 수준과 테넌트 간 격리를 제공하지만, ID 관리의 복잡성이 증가합니다.
마찬가지로 이벤트 기반 애플리케이션은 다음과 같은 여러 수준의 격리를 제공할 수 있습니다.
- 이벤트 기반 애플리케이션은 단일 공유 Azure Event Hubs 인스턴스를 통해 여러 테넌트에서 이벤트를 수신합니다. 이 솔루션은 새 테넌트 온보딩 시 전용 이벤트 수집 리소스를 만들 필요가 없으므로 높은 수준의 민첩성을 제공하지만, 데이터 구조가 같은 여러 테넌트의 메시지와 섞이므로 낮은 데이터 보호 수준을 제공합니다.
- 보안 및 데이터 보호를 위해 이벤트가 다른 테넌트의 이벤트와 섞이면 안 되는 경우 테넌트는 전용 이벤트 허브 또는 Kafka 토픽을 선택하여 노이지 네이버 문제를 방지하고 데이터 격리 요구 사항을 충족할 수 있습니다.
- 테넌트에 높은 수준의 복원력과 비즈니스 연속성이 필요한 경우 다중 테넌트는 지역 재해 복구 및 가용성 영역을 사용하도록 설정된 Event Hubs 프리미엄 네임스페이스를 프로비저닝하는 기능을 제공해야 합니다. 자세한 내용은 Azure Event Hubs - 지리적 재해 복구를 참조하세요.
- 규정 준수 및 의무 이행을 위해 Azure Storage 계정에 이벤트를 보관해야 하는 고객을 위해 Event Hubs 캡처를 사용하도록 설정된 전용 Event Hubs를 만들어야 합니다. 자세한 내용은 Azure Blob Storage 또는 Azure Data Lake Storage에서 Azure Event Hubs를 통해 이벤트 캡처를 참조하세요.
- 단일 다중 테넌트 애플리케이션은 Azure Event Grid를 사용하여 여러 내부 및 외부 시스템에 알림을 보낼 수 있습니다. 이 경우 소비자 애플리케이션마다 별도의 Event Grid 구독을 만들어야 합니다. 애플리케이션이 여러 Event Grid 인스턴스를 사용하여 여러 외부 조직에 알림을 보내는 경우 애플리케이션이 각 테넌트에 대한 토픽과 같은 수천 개의 토픽에 이벤트를 게시할 수 있는 이벤트 도메인을 사용하는 것이 좋습니다. 자세한 내용은 Event Grid 토픽을 관리하는 이벤트 도메인 이해를 참조하세요.
구현의 복잡성
다중 테넌트 솔루션을 설계할 때는 시간이 지나면서 복잡성이 증가하지 않도록 솔루션의 일부 또는 전체를 재설계해야 하는 시점이 오기 전까지 시스템이 중장기적으로 어떻게 발전할지 고려해야 합니다. 이 재설계는 점점 많아지는 테넌트에 대처하는 데 도움이 됩니다. 메시지 시스템을 설계할 때는 향후 몇 년 동안 메시지 볼륨 및 테넌트의 예상 성장 속도를 고려한 다음, 예상 트래픽을 감당하고 프로비저닝, 모니터링 및 유지 관리와 같은 작업의 복잡성을 줄일 수 있도록 스케일 아웃 가능한 시스템을 만들어야 합니다.
솔루션은 수동 작업 없이 테넌트 애플리케이션이 프로비저닝되거나 프로비전 해제될 때마다 필요한 메시지 엔터티를 자동으로 만들거나 삭제해야 합니다.
다중 테넌트 데이터 솔루션의 관심사는 지원하는 사용자 지정 수준입니다. 단일 테넌트 또는 다중 테넌트 애플리케이션이 배포될 때마다 초기 매개 변수 세트를 기반으로 하는 애플리케이션 프로비저닝 시스템(예: DevOps 시스템)에서 사용자 지정을 자동으로 구성하고 적용해야 합니다.
관리 및 운영의 복잡성
메시지 및 이벤트 인프라를 운영, 모니터링 및 유지 관리하는 방법과 다중 테넌트 접근 방식이 운영 및 프로세스에 미치는 영향을 처음부터 계획합니다. 예를 들어 다음과 같은 가능성을 생각해 보세요.
- 애플리케이션에서 사용하는 메시지 시스템을 각 테넌트에 하나씩 전용 가상 머신 세트에 호스트할 수 있습니다. 이 경우 이러한 시스템을 어떻게 배포, 업그레이드, 모니터링 및 스케일 아웃해야 할까요?
- 마찬가지로 공유 Kubernetes 클러스터에 메시지 시스템을 컨테이너화하고 호스트하는 경우 개별 메시지 시스템을 어떻게 배포, 업그레이드, 모니터링 및 확장하도록 계획을 세워야 할까요?
- 메시지 시스템을 여러 테넌트에서 공유한다고 가정하겠습니다. 솔루션이 어떤 방식으로 테넌트별 사용 현황 메트릭을 수집 및 보고하거나 각 테넌트가 보내거나 받을 수 있는 메시지 수를 제한할 수 있을까요?
- 메시징 시스템이 Azure Service Bus와 같은 PaaS 서비스를 활용하는 경우 다음 질문을 해야 합니다.
- 테넌트에서 요청하는 기능 및 격리 수준(공유 또는 전용)에 따라 각 테넌트의 가격 책정 계층을 사용자 지정하려면 어떻게 해야 할까요?
- 테넌트별 관리 ID 및 Azure 역할 할당을 만들어 테넌트가 액세스할 수 있는 큐, 토픽 및 구독과 같은 메시지 엔터티에만 적절한 권한을 할당하려면 어떻게 해야 할까요? 자세한 내용은 Microsoft Entra ID를 사용하여 관리 ID 인증을 참조 하여 Azure Service Bus 리소스에 액세스합니다.
- 테넌트가 다른 유형의 메시지 서비스, 다른 배포 또는 다른 지역으로 이동해야 하는 경우 테넌트를 어떻게 마이그레이션하나요?
비용
일반적으로 배포 인프라의 테넌트 밀도가 높을수록 해당 인프라를 프로비저닝하는 비용이 적게 듭니다. 그러나 공유 인프라는 노이지 네이버 문제와 같은 문제가 발생할 가능성이 높아지므로 장단점이 신중하게 고려해야 합니다.
고려해야 할 접근 방식 및 패턴
Azure 아키텍처 센터의 여러 클라우드 디자인 패턴을 다중 테넌트 메시지 시스템에 적용할 수 있습니다. 하나 이상의 패턴을 일관적으로 따르도록 선택할 수도 있고, 요구 사항에 따라 패턴을 적절히 조합하는 방법을 생각해 볼 수도 있습니다. 예를 들어 대부분의 테넌트에 다중 테넌트 Service Bus 네임스페이스를 사용할 수 있지만, 격리 및 성능 측면에서 더 많은 비용을 지불하거나 요구 사항이 더 까다로운 테넌트에 전용 단일 테넌트 Service Bus 네임스페이스를 배포할 수도 있습니다. 마찬가지로 스탬프 내에서 다중 테넌트 Service Bus 네임스페이스 또는 전용 네임스페이스를 사용하는 경우에도 배포 스탬프를 사용하여 스케일링하는 것이 좋을 때가 자주 있습니다.
배포 스탬프 패턴
배포 스탬프 패턴 및 다중 테넌시에 대한 자세한 내용은 다중 테넌시에 대한 아키텍처 접근 방식의 배포 스탬프 패턴 섹션을 참조하세요. 테넌트 모델에 대한 자세한 내용은 다중 테넌트 솔루션에 대해 고려해야 하는 테넌트 모델을 참조하세요.
공유 메시지 시스템
Azure Service Bus 같은 공유 메시지 시스템을 배포하고 모든 테넌트에서 공유할 수 있습니다.
이 방법은 인프라의 테넌트 밀도가 가장 높으므로 총 소유 비용이 절감됩니다. 또한 관리하고 보호해야 하는 메시지 시스템 또는 리소스가 하나뿐이므로 관리 오버헤드가 감소합니다.
그러나 여러 테넌트 간에 리소스 또는 전체 인프라를 공유하는 경우에는 다음 주의 사항을 고려해야 합니다.
- 항상 해당 리소스의 제약 조건, 크기 조정 기능, 할당량 및 제한을 고려합니다. 예를 들어 더 많은 테넌트를 지원하기 위해 아키텍처가 확장될 때 Azure 구독의 최대 Service Bus 네임스페이스 수, 단일 네임스페이스의 최대 Event Hubs 수 또는 최대 처리량 제한이 결국 까다로운 방해 요소가 될 수 있습니다. 단일 Azure 구독당 네임스페이스 수 또는 단일 네임스페이스당 큐 수의 측면에서 달성해야 하는 최대 규모를 신중하게 고려해야 합니다. 그런 다음, 이 패턴을 선택하기 전에 현재와 미래의 추정치를 원하는 메시지 시스템의 기존 할당량 및 제한과 비교합니다.
- 위의 섹션에서 설명한 것처럼, 여러 테넌트 간에 리소스를 공유하는 경우, 특히 일부 테넌트가 유난히 많이 사용되거나 다른 테넌트보다 높은 트래픽을 생성하는 경우에는 노이지 네이버 문제가 요인이 될 수 있습니다. 이 경우 제한 패턴 또는 속도 제한 패턴을 적용하여 이러한 효과를 완화하는 것이 좋습니다. 예를 들어 단일 테넌트가 단위 시간 동안 보내거나 받을 수 있는 최대 메시지 수를 제한할 수 있습니다.
- 단일 테넌트에 대한 활동을 모니터링하고 리소스 소비량을 측정하기가 어려울 수 있습니다. Azure Service Bus 같은 일부 서비스는 메시지 작업에 대한 요금이 청구됩니다. 따라서 여러 테넌트 간에 네임스페이스를 공유하는 경우 애플리케이션은 각 테넌트 대신 수행된 메시지 작업의 수와 각 테넌트에 청구되는 차지백 비용을 추적할 수 있어야 합니다. 다른 서비스는 동일한 수준의 세부 정보를 제공하지 않습니다.
테넌트의 보안, 지역 내 복원력, 재해 복구 또는 위치에 대한 요구 사항이 서로 다를 수 있습니다. 이러한 요구 사항이 메시지 시스템 구성과 일치하지 않는 경우 단일 리소스만으로는 요구 사항을 수용하지 못할 수 있습니다.
분할 패턴
분할 패턴은 큐 및 토픽과 같은 테넌트의 메시지 엔터티를 하나 이상 포함하고 있는 분할된 데이터베이스라고 부르는 여러 메시지 시스템을 배포하는 것입니다. 배포 스탬프와 달리, 분할된 데이터베이스는 전체 인프라가 중복된다는 뜻이 아닙니다. 솔루션에서 다른 인프라를 복제하거나 분할하지 않고도 메시지 시스템을 분할할 수 있습니다.
안정성, SKU 및 위치의 측면에서 모든 메시지 시스템 또는 분할된 데이터베이스의 특성이 서로 다를 수 있습니다. 예를 들어 성능, 안정성, 데이터 보호 또는 비즈니스 연속성의 측면에서 해당 위치 또는 요구 사항에 따라 다양한 특성을 가진 여러 메시지 시스템에 테넌트를 분할할 수 있습니다.
분할 패턴을 사용하는 경우 특정 테넌트를 큐가 포함된 메시지 시스템에 매핑하려면 분할 전략을 사용해야 합니다. 조회 전략은 맵을 사용하여 테넌트 이름 또는 ID에 따라 대상 메시지 시스템을 개별화합니다. 여러 테넌트가 같은 분할된 데이터베이스를 공유할 수는 있지만, 단일 테넌트에서 사용하는 메시지 엔터티를 여러 분할된 데이터베이스에 분배할 수는 없습니다. 테넌트의 이름을 대상 메시지 시스템의 이름 또는 참조에 매핑하는 단일 사전을 사용하여 맵을 구현할 수 있습니다. 맵은 다중 테넌트 애플리케이션의 모든 인스턴스가 액세스할 수 있는 분산 캐시, 또는 관계형 데이터베이스의 테이블이나 스토리지 계정의 테이블과 같은 영구 저장소에 저장할 수 있습니다.
분할 패턴은 매우 많은 수의 테넌트로 스케일링할 수 있습니다. 또한 워크로드에 따라 분할된 데이터베이스의 테넌트 고밀도를 달성할 수 있으므로 비용이 매력적일 수 있습니다. 분할 패턴을 사용하여 Azure 구독 및 서비스 할당량, 제한 및 제약 조건을 해결할 수도 있습니다.
각 테넌트에 대한 전용 메시지 시스템이 있는 다중 테넌트 앱
또 다른 일반적인 방법은 각 테넌트에 대한 전용 메시지 시스템이 있는 단일 다중 테넌트 애플리케이션을 배포하는 것입니다. 이 테넌트 모델에는 컴퓨팅 리소스와 같은 공유 구성 요소가 있는 반면, 다른 서비스는 단일 테넌트 전용 배포 방법을 사용하여 프로비저닝되고 관리됩니다. 예를 들어 다음 그림과 같이 단일 애플리케이션 계층을 빌드한 다음, 각 테넌트에 대한 개별 메시지 시스템을 배포할 수 있습니다.
시스템의 부하 대부분이 각 테넌트에 대해 별도로 배포할 수 있는 특정 구성 요소 때문이라는 것이 확인되면 수평 분할 배포를 통해 노이지 네이버 문제를 완화할 수 있습니다. 예를 들어 단일 인스턴스로는 여러 테넌트에서 생성되는 트래픽을 감당할 수 없어서 각 테넌트에 별도의 메시지 또는 이벤트 스트리밍 시스템을 사용해야 할 수도 있습니다. 각 테넌트에 전용 메시지 시스템을 사용하면 단일 테넌트가 대량의 메시지 또는 이벤트를 발생시킬 때 공유 구성 요소에는 영향을 주지만 다른 테넌트의 메시지 시스템에는 영향을 주지 않을 수 있습니다.
각 테넌트에 전용 리소스를 프로비저닝하기 때문에 이 방법의 비용은 공유 호스팅 모델보다 높을 수 있습니다. 반면 이 테넌트 모델을 채택하면 전용 시스템의 리소스 비용을, 리소스를 사용하는 고유 테넌트에 더 쉽게 차지백할 수 있습니다. 이 방법을 사용하면 컴퓨팅 리소스와 같은 다른 서비스의 고밀도를 달성할 수 있으며, 이러한 구성 요소의 비용을 줄일 수 있습니다.
수평 분할 배포를 사용하면 다중 테넌트 애플리케이션의 서비스, 특히 단일 테넌트에서 사용하는 서비스를 배포하고 관리하도록 자동화된 프로세스를 채택해야 합니다.
지오드 패턴
지오드 패턴은 백 엔드 서비스 컬렉션을 지리적 노드 세트에 배포하는 것입니다. 각 백엔드 서비스는 임의의 지역의 임의의 클라이언트에 대한 모든 요청을 처리할 수 있습니다. 이 패턴을 사용하면 요청 처리를 전 세계에 분산하여 대기 시간을 개선하고 가용성을 높이는 활성-활성 스타일로 요청을 처리할 수 있습니다.
Azure Service Bus 및 Azure Event Hubs는 최상의 지역 내 복원력을 제공하기 위해 기본 및 보조 재해 복구 네임스페이스와 별도의 지역 및 가용성 영역에서 메타데이터 재해 복구를 지원합니다. 또한 Azure Service Bus 및 Azure Event Hubs는 결국 서로 다른 지역에 배치되는 여러 네임스페이스에서 사용할 수 있도록 동일한 논리 토픽, 큐 또는 이벤트 허브를 적극적으로 복제하는 페더레이션 패턴 세트를 구현합니다. 자세한 내용은 다음 자료를 참조하세요.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- Paolo Salvatori | 수석 고객 엔지니어, FastTrack for Azure
기타 기여자:
- John Downs | 소프트웨어 수석 엔지니어
- Clemens Vasters | 수석 설계자, Messaging Services and Standards
- Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure
다음 단계
메시지 디자인 패턴에 대한 자세한 내용은 다음 리소스를 참조하세요.