Víceklientská architektura a Azure Queue Storage

Azure Queue Storage ukládá zprávy pro asynchronní zpracování. Tento článek popisuje strategie dělení, modely izolace a funkce Queue Storage pro víceklientská řešení. Obsahuje pokyny, které vám pomůžou distribuovat zatížení zpráv, izolovat zprávy tenantů a spravovat přístup, šifrování a využití.

Strategie particionování

Queue Storage nezpřístupňuje klíč oddílu ani dílčí frontu v rámci fronty. Fronta je nejmenší mez, kterou můžete použít k distribuci zatížení zprávami, a účet úložiště je další mez. Sdílená fronta neposkytuje propustnost nebo izolaci výkonu specifickou pro tenanta.

Pro zprávy o velikosti 1 KiB má jedna fronta cílovou propustnost až 2 000 zpráv za sekundu a účet úložiště má maximální rychlost požadavků 20 000 zpráv za sekundu. Velikost zprávy a vzory přístupu ovlivňují propustnost, jaké vaše úloha dosahuje. Zprávy fronty můžou být až 64 KiB. U větších zpráv nebo pokročilých funkcí zprostředkovatele zvažte použití Azure Service Bus.

Pokud vaše zátěž může překročit cíl pro každou frontu, distribuujte zprávy napříč několika frontami. V závislosti na směrování a provozních požadavcích můžete rozdělit fronty podle tenantu, skupiny tenantů nebo úrovně služby, funkční úlohy, deployment stampu nebo oblasti. Tenant s vysokým objemem provozu, který sdílí frontu s jinými tenanty, může spotřebovávat nepřiměřený podíl propustnosti fronty a způsobit omezování pro ostatní tenanty.

Více front ve stejném účtu úložiště stále sdílí kapacitu účtu a konfiguraci na úrovni účtu. Pokud souhrnné zatížení může překročit limit účtu úložiště nebo pokud tenant potřebuje nezávislou konfiguraci škálování nebo oblasti, distribuujte fronty mezi více účtů úložiště. Sledujte omezování propustnosti, používejte opakování s exponenciálně rostoucí prodlevou a otestujte svou úlohu s využitím zdokumentovaných cílů škálovatelnosti služby Queue Storage. Možnosti přístupu k tenantovi a izolace dat najdete v tématu Modely izolace.

Modely izolace

Jakmile určíte, jak distribuovat zatížení zpráv, určete úroveň izolace tenanta, která se má použít. Queue Storage podporuje sdílené fronty, fronty pro každého tenanta a účty úložiště pro každého tenanta. Následující tabulka shrnuje rozdíly mezi hlavními modely izolace tenantů pro Queue Storage.

Consideration Sdílené fronty Fronty pro každého tenanta Účty úložiště pro každého tenanta
Izolace dat Nízké. Aplikace vynucuje izolaci. Nízký-střední High
Výkonová izolace Low Nízké. Většina kvót a omezení platí pro celý účet úložiště. High
Složitost nasazení Low Středně High
Provozní složitost Low Středně High
Ukázkový scénář Velké víceklientové řešení má sdílenou aplikační vrstvu. Vydávají se adresy URL sdíleného přístupového podpisu (SAS) s rozsahem tenanta. Každý tenant má vlastní značku nasazení.

Note

Při výběru modelu izolace zvažte kvóty a omezení. Mezi tyto limity patří limity služby Azure, cíle škálovatelnosti služby Queue Storage a cíle škálovatelnosti pro poskytovatele prostředků úložiště.

Sdílené fronty

Pokud sdílíte frontu, všichni tenanti sdílejí cíl propustnosti. Vytížený tenant může způsobit omezování pro ostatní tenanty. Strategie distribuce zatížení zpráv naleznete v tématu Strategie dělení oddílů.

Fronty neposkytují dělení na oddíly ani podfronty, takže se můžou smíchat všechna data tenantů. Vaše aplikace musí identifikovat tenanta pro každou zprávu a během zpracování vynutit izolaci. Neudělujte klientům přímý přístup ke sdílené frontě, pokud nesmí mít přístup ke zprávám jiných tenantů.

Fronty pro každého tenanta

Jednotlivé fronty můžete vytvořit pro každého tenanta v rámci jednoho účtu úložiště. Počet front, které můžete vytvořit v rámci účtu úložiště, není nijak omezený.

Fronty zpráv pro každého tenanta poskytují hranici směrování a řízení přístupu, ale neposkytují izolaci výkonu. Všechny fronty v účtu sdílejí kapacitu a výkonnostní cíle účtu úložiště.

V tomto scénáři můžete ke správě přístupu pro data jednotlivých tenantů použít řízení přístupu ke službě Queue Storage, včetně SAS.

Když dynamicky vytváříte fronty pro každého tenanta, zvažte, jak vaše aplikační vrstva spotřebovává zprávy z fronty každého tenanta. V případě pokročilých scénářů zvažte použití Azure Service Bus, které podporuje funkce, jako jsou relace, automatické přeposílání zpráv a témata a předplatná.

Účty úložiště pro každého tenanta

Nejsilnější úroveň izolace používá pro každého tenanta vyhrazený účet úložiště. Tento model zajišťuje úplnou izolaci klíčů účtu úložiště, které můžete nezávisle obměňovat. Umožňuje také škálovat řešení nad rámec limitů a kvót pro každý účet úložiště. Zvažte tento model pro tenanty, kteří mají trvale vysoké objemy zpráv nebo vyžadují nezávislé regionální konfigurace nebo výkonnostní cíle. Musíte ale také zvážit maximální počet účtů úložiště povolených v rámci jednoho předplatného Azure.

Funkce Queue Storage, které podporují multitenanci

Následující funkce Queue Storage vám můžou pomoct implementovat a provozovat zvolený model izolace.

Sdílené přístupové podpisy

Pokud používáte Službu Queue Storage z klientské aplikace, zvažte, jestli se mají žádosti směrovat prostřednictvím aplikační vrstvy, nebo umožnit klientům připojit se přímo k frontě. Přímý klientský přístup může snížit zatížení back-endových aplikací a počet síťových skoků.

Podpis sdíleného přístupu (SAS) umožňuje poskytnout klientským aplikacím omezený přístup k frontě. Můžete omezit operace, které může klient provádět, a časové období, kdy je povolený přístup. Můžete například vydat SAS, který tenantovi umožní přidávat zprávy do vlastní fronty, aniž by mu bylo povoleno číst nebo odstraňovat zprávy.

Pomocí vzoru Valet Key můžete vydávat stanovené a omezené tokeny SAS z vaší aplikační vrstvy. Ověřte klienta pomocí ověřovacího systému vaší aplikace, určete frontu tenanta, ke které má přístup, a vydejte token pouze pro požadované operace.

Uložené zásady přístupu umožňují definovat jednu zásadu, která se má použít při vydávání více tokenů služby SAS. Uložené zásady přístupu se nevztahují na tokeny SAS delegování uživatele nebo tokeny SAS účtu.

Delegování uživatele SAS

SAS služby nebo SAS účtu je podepsán jedním z klíčů vašeho účtu úložiště. SAS delegování uživatele je místo toho zabezpečeno pomocí přihlašovacích údajů Microsoft Entra. Vaše aplikační vrstva požádá o klíč delegování uživatele pomocí vlastní spravované identity a pak pro každého tenanta podepíše tokeny s omezeným rozsahem a časovým omezením. Klíče účtu nedistribuujete ani neukládáte. Microsoft doporučuje používat SAS delegování uživatele místo SAS klíče účtu, pokud to váš návrh podporuje.

Používejte krátké životnosti tokenů a naplánujte, jak zneplatnit token nebo odebrat přístup v případě ohrožení tokenu. Pokud chcete korelovat protokoly aplikace s protokoly Queue Storage, nastavte ID požadavku klienta (x-ms-client-request-id) na požadavky úložiště a protokolujte ho společně s ID tenanta.

Řízení přístupu na základě identit

Queue Storage poskytuje řízení přístupu na základě identit prostřednictvím Microsoft Entra ID. Používejte spravované identity a řízení přístupu na základě role v Azure k autorizaci aplikace pro přístup k frontám bez ukládání klíčů účtu. Omezte přístup ke frontě každého tenanta v případech, kdy tenant vyžaduje přímý přístup. Autorizace na úrovni fronty neizoluje zprávy jednotlivých tenantů ve sdílené frontě.

Encryption

Queue Storage ve výchozím nastavení šifruje neaktivní uložená data pomocí klíčů spravovaných společností Microsoft. Pokud chcete použít klíče spravované zákazníkem, nakonfigurujte účet úložiště tak, aby při vytváření účtu používal šifrovací klíč s rozsahem účtu pro fronty. Po vytvoření účtu nemůžete změnit tento rozsah šifrovacího klíče.

Pokud tenanti vyžadují samostatné klíče spravované zákazníkem, použijte samostatné účty úložiště. Rozsahy šifrování Blob Storage a klíče poskytované zákazníkem u jednotlivých požadavků se nevztahují na Queue Storage. Naplánujte obměnu klíčů a zneplatnění spolu s životním cyklem klienta.

Monitoring

Ve víceklientských řešeních zvažte, jestli potřebujete měřit spotřebu pro každého tenanta. Definujte konkrétní metriky, které se mají sledovat, například počet zpráv nebo operací pro každého tenanta. Přidělení nákladů můžete také použít ke sledování nákladů na využití jednotlivých tenantů a povolení zpětného účtování napříč několika předplatnými.

Queue Storage poskytuje integrované možnosti monitorování. Když tenanti sdílejí frontu, zahrňte do telemetrie vaší aplikace identifikátory tenanta, abyste mohli přiřadit zpracování zpráv a využití správnému tenantovi.

Monitorujte frekvence požadavků a odpovědi HTTP 500 a 503 a detekujte fronty nebo účty, které se blíží limitům škálovatelnosti. Korelujte tuto telemetrii s identifikátory tenanta, abyste mohli identifikovat tenanty, jejichž využití ovlivňuje sdílenou kapacitu.

Můžete shromažďovat protokoly požadavků a pak je agregovat a analyzovat společně s telemetrií vaší aplikace. V řešeních, která vytvářejí velké objemy požadavků, zvažte, jestli výhoda zdůvodňuje náklady na zachytávání a zpracování těchto záznamů.

Contributors

Společnost Microsoft udržuje tento článek. Tento článek napsali následující přispěvatelé.

Hlavní autor:

  • John Downs | Hlavní softwarový inženýr, vzory a postupy Azure

Další přispěvatelé:

Pokud chcete zobrazit nepublikované profily LinkedIn, přihlaste se k LinkedIn.

  • Poslední aktualizace v