Azure Queue Storage 비동기 처리를 위해 메시지를 저장합니다. 이 문서에서는 다중 테넌트 솔루션에 대한 분할 전략, 격리 모델 및 Queue Storage 기능에 대해 설명합니다. 메시지 로드를 분산하고, 테넌트의 메시지를 격리하고, 액세스, 암호화 및 사용을 관리하는 데 도움이 되는 지침을 제공합니다.
분할 전략
Queue Storage는 큐 내에서 파티션 키 또는 하위 큐를 노출하지 않습니다. 큐는 메시지 부하를 분산하는 데 사용할 수 있는 가장 작은 경계이며 스토리지 계정은 다음 경계입니다. 공유 큐는 테넌트별 처리량 또는 성능 격리를 제공하지 않습니다.
1KiB인 메시지의 경우 단일 큐의 대상 처리량은 초당 최대 2,000개의 메시지이며 스토리지 계정은 초당 최대 요청 속도 20,000개의 메시지를 가집니다. 메시지 크기 및 액세스 패턴은 워크로드가 달성하는 처리량에 영향을 줍니다. 큐 메시지는 최대 64KiB일 수 있습니다. 더 큰 메시지 또는 고급 브로커 기능의 경우 Azure Service Bus 사용하는 것이 좋습니다.
워크로드가 큐별 목표치를 초과할 수 있는 경우 여러 큐에 메시지를 분산합니다. 라우팅 및 운영 요구 사항에 따라 테넌트, 테넌트 그룹 또는 서비스 계층, 기능 워크로드, 배포 스탬프 또는 지역별로 큐를 분할할 수 있습니다. 다른 테넌트와 큐를 공유하는 대용량 테넌트는 큐 처리량의 불균형적으로 큰 부분을 차지하고 다른 테넌트에 스로틀링을 유발할 수 있습니다.
동일한 스토리지 계정의 여러 큐는 여전히 계정의 용량 및 계정 수준 구성을 공유합니다. 집계 워크로드가 스토리지 계정 한도를 초과할 수 있거나 테넌트에 독립적인 규모 또는 지역 구성이 필요한 경우 여러 스토리지 계정에 큐를 분산합니다. 스로틀링을 모니터링하고, 지수 백오프 재시도를 사용하고, 문서화된 Queue Storage 확장성 한도에 대해 워크로드를 테스트합니다. 테넌트 액세스 및 데이터 격리 옵션은 격리 모델을 참조하세요.
격리 모델
메시지 부하를 분산하는 방법을 확인한 후 적용할 테넌트 격리 수준을 결정합니다. Queue Storage는 공유 큐, 각 테넌트에 대한 큐 및 각 테넌트에 대한 스토리지 계정을 지원합니다. 다음 표에서는 Queue Storage에 대한 기본 테넌시 격리 모델 간의 차이점을 요약합니다.
| Consideration | 공유 큐 | 각 테넌트를 위한 대기열 | 각 테넌트에 대한 스토리지 계정 |
|---|---|---|---|
| 데이터 격리 | 낮다. 애플리케이션은 격리를 적용합니다. | 낮음-중간 | High |
| 성능 격리 | Low | 낮다. 대부분의 할당량 및 제한은 전체 스토리지 계정에 적용됩니다. | High |
| 배포 복잡성 | Low | Medium | High |
| 운영 복잡성 | Low | Medium | High |
| 예제 시나리오 | 대규모 다중 테넌트 솔루션에는 공유 애플리케이션 계층이 있습니다. | 테넌트 범위 SAS(공유 액세스 서명) URL이 발급됩니다. | 각 테넌트에는 자체 배포 스탬프가 있습니다. |
Note
격리 모델을 선택할 때 할당량 및 제한을 고려합니다. 이러한 제한에는 Azure 서비스 제한, Queue Storage 확장성 목표 및 Storage 리소스 공급자의 확장성 목표가 포함됩니다.
공유 큐
큐를 공유하는 경우 모든 테넌트는 처리량 대상을 공유합니다. 과부하 상태의 테넌트는 다른 테넌트에 스로틀링을 일으킬 수 있습니다. 메시지 부하를 분산하기 위한 전략은 분할 전략을 참조하세요.
큐는 분할이나 하위 큐를 제공하지 않기 때문에 모든 사용자의 데이터가 뒤섞일 수 있습니다. 애플리케이션은 각 메시지에 대한 테넌트 식별 및 처리 중 격리를 적용해야 합니다. 다른 테넌트의 메시지에 액세스하지 않아야 하는 경우 테넌트에 공유 큐에 대한 직접 액세스 권한을 부여하지 마세요.
각 테넌트를 위한 대기열
단일 스토리지 계정 내에서 각 테넌트에 대한 개별 큐를 만들 수 있습니다. 스토리지 계정 내에서 만들 수 있는 큐 수에는 제한이 없습니다.
각 테넌트에 대한 큐는 라우팅 및 액세스 제어 경계를 제공하지만 성능 격리를 제공하지는 않습니다. 계정의 모든 큐는 스토리지 계정의 용량 및 성능 목표를 공유합니다.
이 시나리오에서는 SAS를 포함한 Queue Storage 액세스 제어를 사용하여 각 테넌트의 데이터에 대한 액세스를 관리할 수 있습니다.
각 테넌트에 대한 큐를 동적으로 만들 때 애플리케이션 계층이 각 테넌트의 큐에서 메시지를 사용하는 방법을 고려합니다. 고급 시나리오의 경우 Azure Service Bus 사용을 고려하세요. 이 서비스는 세션, 메시지 자동 전달, 토픽 및 구독과 같은 기능을 지원합니다.
각 테넌트에 대한 스토리지 계정
가장 강력한 격리 수준은 각 테넌트에 대해 전용 스토리지 계정을 사용합니다. 이 모델은 독립적으로 교체할 수 있는 스토리지 계정 키의 전체 격리를 보장합니다. 또한 각 스토리지 계정에 대한 제한 및 할당량을 초과하여 솔루션을 확장할 수 있습니다. 메시지 볼륨이 높거나 독립적인 지역 구성 또는 성능 목표가 필요한 테넌트에 대해 이 모델을 고려합니다. 그러나 단일 Azure 구독 내에서 허용되는 최대 스토리지 계정 수도 고려해야 합니다.
다중 테넌시를 지원하는 Queue Storage의 기능
다음 Queue Storage 기능은 선택한 격리 모델을 구현하고 운영하는 데 도움이 될 수 있습니다.
공유 액세스 서명
클라이언트 애플리케이션에서 Queue Storage를 사용하는 경우 애플리케이션 계층을 통해 요청을 라우팅할지 아니면 클라이언트가 큐에 직접 연결할 수 있는지를 고려합니다. 직접 클라이언트 액세스는 사용자의 백엔드 애플리케이션의 부하와 네트워크 홉 수를 줄일 수 있습니다.
SAS(공유 액세스 서명)를 사용하면 클라이언트 애플리케이션에 큐에 대한 제한된 액세스 권한을 제공할 수 있습니다. 클라이언트가 수행할 수 있는 작업과 액세스가 허용되는 기간을 제한할 수 있습니다. 예를 들어 테넌트가 메시지를 읽거나 삭제할 수 없게 하면서 자체 큐에 메시지를 추가할 수 있는 SAS를 발급할 수 있습니다.
발레 키 패턴을 사용하여 애플리케이션 계층에서 제한되고 범위가 지정된 SAS 토큰을 발급합니다. 애플리케이션의 인증 시스템을 사용하여 클라이언트를 인증하고, 액세스할 수 있는 테넌트의 큐를 결정하고, 필요한 작업에 대해서만 토큰을 발급합니다.
저장된 액세스 정책을 사용하면 여러 서비스 SAS 토큰을 발급할 때 사용할 단일 정책을 정의할 수 있습니다. 저장된 액세스 정책은 사용자 위임 SAS 토큰 또는 계정 SAS 토큰에는 적용되지 않습니다.
사용자 위임 SAS
서비스 SAS 또는 계정 SAS는 스토리지 계정 키 중 하나로 서명됩니다. 사용자 위임 SAS는 대신 Microsoft Entra 자격 증명으로 보호됩니다. 애플리케이션 계층은 자체 관리 ID를 사용하여 사용자 위임 키를 요청한 다음, 각 테넌트에 대해 범위가 지정되고 시간 제한이 있는 토큰을 생성합니다. 계정 키를 배포하거나 저장하지 않습니다. Microsoft는 설계에서 이를 지원하는 경우 계정 키 SAS 대신 사용자 위임 SAS를 사용하는 것이 좋습니다.
짧은 토큰 수명을 사용하고 토큰이 침해된 경우 액세스를 취소하는 방법을 계획합니다. 애플리케이션 로그를 Queue Storage 로그와 상호 연결하려면 스토리지 요청에 클라이언트 요청 ID(x-ms-client-request-id)를 설정하고 테넌트 ID와 함께 기록합니다.
ID 기반 액세스 제어
Queue Storage는 Microsoft Entra ID 통해 ID 기반 액세스 제어를 제공합니다. 관리형 ID 및 Azure 역할 기반 액세스 제어를 사용하여 계정 키를 저장하지 않고 애플리케이션이 큐에 액세스할 수 있도록 권한을 부여합니다. 테넌트에 직접 액세스가 필요한 경우 각 테넌트의 큐에 대한 액세스 범위를 지정합니다. 큐 수준 권한 부여는 공유 큐 내에서 개별 테넌트의 메시지를 격리하지 않습니다.
Encryption
Queue Storage는 기본적으로 Microsoft 관리형 키를 사용하여 저장 데이터를 암호화합니다. 고객 관리형 키를 사용하려면 계정을 만들 때 큐에 계정 범위 암호화 키를 사용하도록 스토리지 계정을 구성하세요. 계정을 만든 후에는 이 암호화 키 범위를 변경할 수 없습니다.
테넌트에 별도의 고객 관리형 키가 필요한 경우 별도의 스토리지 계정을 사용합니다. 개별 요청에 대한 Blob Storage 암호화 범위 및 고객이 제공한 키는 Queue Storage에 적용되지 않습니다. 테넌트 수명 주기와 함께 키 회전 및 해지를 계획합니다.
Monitoring
다중 테넌트 솔루션에서 각 테넌트의 소비량을 측정해야 하는지 여부를 고려합니다. 각 테넌트에 대한 메시지 또는 작업 수와 같이 추적할 특정 메트릭을 정의합니다. 비용 할당을 사용하여 각 테넌트의 사용 비용을 추적하고 여러 구독에서 차지백을 사용하도록 설정할 수도 있습니다.
Queue Storage는 기본 제공 모니터링 기능을 제공합니다. 테넌트가 큐를 공유하는 경우 메시지 처리 및 사용량을 올바른 테넌트에 귀속할 수 있도록 애플리케이션 원격 분석에 테넌트 식별자를 포함합니다.
요청 속도 및 HTTP 500 및 503 응답을 모니터링하여 확장성 목표에 접근하는 큐 또는 계정을 감지합니다. 공유 용량에 영향을 미치는 사용량의 테넌트를 식별할 수 있도록 이 원격 분석을 테넌트 식별자와 연결합니다.
요청 로그를 수집한 다음 애플리케이션 원격 분석과 함께 집계 및 분석할 수 있습니다. 대량의 요청을 만드는 솔루션에서는 이 이점이 해당 로그를 캡처하고 처리하는 비용을 정당화하는지 여부를 고려합니다.
Contributors
Microsoft는 이 문서를 유지 관리합니다. 이 문서를 작성한 기여자는 다음과 같습니다.
대표 저자:
- John Downs | 주요 소프트웨어 엔지니어, Azure 패턴 및 사례
기타 기여자:
- 크리스티안 구어 폴만 박사 | 수석 고객 엔지니어, Azure용 FastTrack
- 패트릭 혼 | 선임 고객 엔지니어링 관리자, Azure용 FastTrack
- 벤 험머스톤 | 수석 고객 엔지니어, Azure용 FastTrack
- 빅 페르다나 | 클라우드 솔루션 설계자, Azure ISV
- 다니엘 스콧-레인스포드 | 파트너 솔루션 설계자, 데이터 및 AI
- Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure
LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.