Režimy připojení k sadě SQL SDK služby Azure Cosmos DB

  • Článek

PLATÍ PRO: NoSQL

Způsob, jakým se klient připojuje ke službě Azure Cosmos DB, má důležité vlivy na výkon, zejména pro pozorovanou latenci na straně klienta. Azure Cosmos DB nabízí jednoduchý a otevřený programovací model RESTful přes HTTPS označovaný jako režim brány. Kromě toho nabízí efektivní protokol TCP, který je ve svém komunikačním modelu také RESTful a používá protokol TLS pro počáteční ověřování a šifrování provozu, označovaný jako přímý režim.

Dostupné režimy připojení

Mezi dva dostupné režimy připojení patří:

  • Režim brány

    Režim brány se podporuje na všech platformách sady SDK. Pokud vaše aplikace běží v podnikové síti s přísnými omezeními brány firewall, je nejlepší volbou režim brány, protože používá standardní port HTTPS a jeden koncový bod DNS. Kompromisem výkonu je ale to, že režim brány zahrnuje další segment směrování sítě při každém čtení dat ze služby Azure Cosmos DB nebo jejich zápisu do služby Azure Cosmos DB. Režim připojení brány doporučujeme také při spouštění aplikací v prostředích s omezeným počtem připojení soketů.

    Pokud používáte sadu SDK v Azure Functions, zejména v plánu Consumption, mějte na paměti aktuální omezení připojení.

  • Přímý režim

    Přímý režim podporuje připojení přes protokol TCP, používá protokol TLS pro počáteční ověřování a šifrování provozu a nabízí lepší výkon, protože existuje méně segmentů směrování sítě. Aplikace se připojí přímo k back-endovým replikám. Přímý režim se v současné době podporuje jenom na platformách .NET a Java SDK.

Režimy připojení ke službě Azure Cosmos DB

Tyto režimy připojení v podstatě podmiňovaly trasu, kterou požadavky roviny dat – čtení a zápisy dokumentů – přebírají z vašeho klientského počítače do oddílů v back-endu služby Azure Cosmos DB. Upřednostňovanou možností pro dosažení nejlepšího výkonu je přímý režim – umožňuje klientovi otevírat připojení TCP přímo do oddílů v back-endu služby Azure Cosmos DB a odesílat požadavky přímobez zprostředkování. Naproti tomu v režimu brány se požadavky provedené vaším klientem směrují na takzvaný server brány ve front-endu služby Azure Cosmos DB, který následně rozdmýchá vaše požadavky na příslušné oddíly v back-endu služby Azure Cosmos DB.

Rozsahy portů služby

Pokud používáte přímý režim, musíte zajistit, aby klient měl přístup k portům v rozsahu od 10000 do 20000, protože Azure Cosmos DB používá dynamické porty TCP. To je navíc k portům brány. Při použití přímého režimu na privátních koncových bodech může Azure Cosmos DB používat celou řadu portů TCP – od 0 do 65535. Pokud tyto porty nejsou ve vašem klientovi otevřené a pokusíte se použít protokol TCP, může se zobrazit chyba 503 Service Unavailable (Nedostupná služba).

Následující tabulka obsahuje souhrn režimů připojení dostupných pro různá rozhraní API a porty služby používané pro jednotlivá rozhraní API:

Režim připojení Podporovaný protokol Podporované sady SDK Port rozhraní API nebo služby
brána HTTPS Všechny sady SDK SQL (443), MongoDB (10255), Table (443), Cassandra (10350), Graph (443)
Direct TCP (šifrované přes TLS) .NET SDK Java SDK Při použití veřejných koncových bodů nebo koncových bodů služby: porty v rozsahu od 10000 do 20000
Při použití privátních koncových bodů: porty v rozsahu od 0 do 65535

Architektura připojení v přímém režimu

Jak je podrobně popsáno v úvodu, klienti s přímým režimem se budou přímo připojovat k back-endovým uzlům prostřednictvím protokolu TCP. Každý back-endový uzel představuje repliku v sadě replik patřící do fyzického oddílu.

Směrování

Když sada SDK služby Azure Cosmos DB v přímém režimu provádí operaci, musí vyřešit, ke které back-endové replice se má připojit. Prvním krokem je znalost fyzického oddílu, do kterého má operace přejít, a za tímto účelem sada SDK získá informace o kontejneru, které obsahují definici klíče oddílu , z uzlu brány. Potřebuje také informace o směrování, které obsahují adresy TCP replik. Informace o směrování jsou k dispozici také z uzlů brány a oba jsou považovány za metadata řídicí roviny. Jakmile sada SDK získá informace o směrování, může pokračovat v otevírání připojení TCP k replikám, které patří do cílového fyzického oddílu, a provádět operace.

Každá sada replik obsahuje jednu primární repliku a tři sekundární repliky. Operace zápisu jsou vždy směrovány na uzly primární repliky, zatímco operace čtení je možné obsluhovat z primárních nebo sekundárních uzlů.

Diagram znázorňující, jak služba S D Ks v přímém režimu načítá informace o kontejneru a směrování z brány před otevřením připojení T C P k back-endovým uzlům

Vzhledem k tomu, že se informace o kontejneru a směrování často nemění, ukládají se místně do mezipaměti v sadách SDK, aby tyto informace mohly využít pro následné operace. Již navázáná připojení TCP se také opakovaně používají napříč operacemi. Pokud není nakonfigurováno jinak prostřednictvím možností sad SDK, připojení se trvale udržují po celou dobu životnosti instance sady SDK.

Stejně jako u jakékoli distribuované architektury můžou počítače, které uchovávají repliky, procházet upgrady nebo údržbou. Služba zajistí, aby sada replik zachovala konzistenci, ale jakýkoli přesun repliky by způsobil změnu stávajících adres TCP. V těchto případech musí sady SDK aktualizovat informace o směrování a znovu se připojit k novým adresm prostřednictvím nových požadavků brány. Tyto události by neměly mít vliv na celkovou smlouvu SLA P99.

Objem připojení

Každý fyzický oddíl má sadu replik po čtyřech replikách, aby byly zajištěny co nejlepší výkon, sady SDK nakonec otevřou připojení ke všem replikám pro úlohy, které kombinují operace zápisu a čtení. Souběžné operace se vyrovnávají zatížení mezi stávajícími připojeními, aby se využila propustnost, která každá replika poskytuje.

Existují dva faktory, které určují počet připojení TCP, která sada SDK otevře:

  • Počet fyzických oddílů

    Ve stabilním stavu bude mít sada SDK jedno připojení na repliku na fyzický oddíl. Tím větší je počet fyzických oddílů v kontejneru, tím větší bude počet otevřených připojení. Vzhledem k tomu, že se operace směrují napříč různými oddíly, navazují se připojení na vyžádání. Průměrný počet připojení by pak byl počet fyzických oddílů krát čtyři.

  • Objem souběžných požadavků

    Každé navázané připojení může sloužit konfigurovatelnému počtu souběžných operací. Pokud objem souběžných operací překročí tuto prahovou hodnotu, budou otevřená nová připojení, která je budou obsluhovat, a je možné, že u fyzického oddílu počet otevřených připojení překročí číslo stabilního stavu. Toto chování se očekává u úloh, které můžou mít špičky v provozním objemu. Pro sadu .NET SDK tuto konfiguraci nastavuje CosmosClientOptions.MaxRequestsPerTcpConnection a pro sadu Java SDK můžete přizpůsobit pomocí DirectConnectionConfig.setMaxRequestsPerConnection.

Ve výchozím nastavení se připojení trvale udržují, aby se prospělo výkonu budoucích operací (otevření připojení má výpočetní režii). V některých situacích můžete chtít ukončit připojení, která se po určitou dobu nepoužívají, protože to může mírně ovlivnit budoucí operace. Pro sadu .NET SDK tuto konfiguraci nastavuje CosmosClientOptions.IdleTcpConnectionTimeout a pro sadu Java SDK můžete přizpůsobit pomocí DirectConnectionConfig.setIdleConnectionTimeout. Nedoporučuje se nastavovat tyto konfigurace na nízké hodnoty, protože to může způsobit časté zavření připojení a ovlivnit celkový výkon.

Podrobnosti implementace specifické pro konkrétní jazyk

Další podrobnosti o implementaci jazyka najdete tady:

Další kroky

Optimalizace výkonu konkrétní platformy SADY SDK: