Udostępnij przez

Korzystanie z usługi Azure API Management w rozwiązaniu wielodostępnym

Usługa Azure API Management to kompleksowa brama interfejsu API i zwrotny serwer proxy dla interfejsów API. Udostępnia wiele funkcji, które są przydatne w przypadku aplikacji skoncentrowanych na interfejsie API, w tym buforowania, pozorowania odpowiedzi i portalu dla deweloperów. Ten artykuł zawiera podsumowanie niektórych kluczowych funkcji usługi API Management, które są przydatne w przypadku rozwiązań wielodostępnych.

Uwaga

Ten artykuł koncentruje się na tym, jak można używać usługi API Management, gdy masz własne aplikacje wielodostępne hostujące interfejsy API do użytku wewnętrznego lub zewnętrznego.

Inną formą wielodostępności jest udostępnianie bramy zarządzania API jako usługi dla innych zespołów. Na przykład organizacja może mieć udostępnione wystąpienie usługi API Management, które może być wdrażane i używane przez wiele zespołów aplikacji. W tym artykule nie omówiono tej formy wielodostępności. Rozważ użycie obszarów roboczych, które pomagają udostępniać wystąpienie usługi API Management w wielu zespołach z różnymi poziomami dostępu.

Modele izolacji

Usługa API Management jest zazwyczaj wdrażana jako wspólny komponent z pojedynczym wystąpieniem, które obsługuje żądania wielu dzierżawców. Jednak w oparciu o Twój model najmu istnieje wiele sposobów wdrażania zarządzania API. W tym artykule założono, że rozwiązanie jest wdrażane przy użyciu znaczników wdrażania.

Zazwyczaj sposób, w jaki usługa API Management jest używana, pozostaje spójna w różnych modelach izolacji. Ta sekcja koncentruje się na różnicach między modelami izolacji w zakresie kosztów i złożoności oraz na sposobie, w jaki każde podejście kieruje żądania do aplikacji API zaplecza.

Kwestie wymagające rozważenia Współdzielone wystąpienie z jedno-tenantowym zapleczem Współdzielone wystąpienie z współdzielonym wielodostępnym zapleczem Instancja dla każdego najemcy
Liczba obsługiwanych najemców Dużo Prawie nieograniczony Jeden na każde wystąpienie
Koszt Niższy Niższy Wyższa
Złożoność wdrożenia Niski. Pojedyncze wystąpienie do zarządzania dla każdej sygnatury. Niski. Pojedyncze wystąpienie do zarządzania dla każdej sygnatury. Wysoki. Zarządzanie wieloma wystąpieniami.
Złożoność konfiguracji routingu Wyższa Niższy Niższy
Podatność na problemy z hałaśliwym sąsiadem Tak Tak Nie.
Izolacja sieci na poziomie dzierżawy Nie. Nie. Tak
Przykładowy scenariusz Spersonalizowane nazwy domen dla każdego najemcy Rozwiązanie wielodostępne na dużą skalę z współdzieloną warstwą aplikacji Znaczniki wdrożenia dedykowane dla lokatora

Modele izolacji dzielonego wystąpienia

Zwykle udostępnia się instancję usługi API Management między wieloma dzierżawami, co pomaga zmniejszyć koszty oraz złożoność wdrażania i zarządzania. Szczegółowe informacje na temat sposobu udostępniania wystąpienia usługi API Management zależą od sposobu przypisywania najemców do zaplecza API.

Aplikacja zaplecza jedno użytkownikowa

Jeśli wdrażasz odrębne aplikacje zaplecza dla każdego dzierżawcy, możesz wdrożyć jedno wystąpienie usługi API Management i kierować ruch do właściwego zaplecza dla każdego zapytania. Takie podejście wymaga skonfigurowania zarządzania API przy użyciu nazw hostów zaplecza dla każdej dzierżawy lub znalezienia innego sposobu mapowania przychodzącego żądania na zaplecze właściwej dzierżawy.

Ponieważ wymaga to dodatkowego odpytania, takie podejście może się nie skalować do dużej liczby najemców, którzy współużytkują pojedyncze wystąpienie usługi API Management. Podczas sprawdzania zaplecza dzierżawy może również wystąpić pewne obciążenie związane z wydajnością. Jednak rozmiar tego obciążenia związanego z wydajnością zależy od sposobu projektowania tego wyszukiwania.

Udostępniona wielodostępna aplikacja zaplecza

W scenariuszach, w których dzierżawcy mają wspólną aplikację zaplecza, proces routingu usługi API Management jest uproszczony, ponieważ można kierować wszystkie żądania do jednego zaplecza. Jeśli używasz domen wieloznacznych lub domen wystawionych przez dostawcę, możesz osiągnąć niemal niezwiązaną skalę przy użyciu tego podejścia. Ponadto, ponieważ żądania nie muszą być mapowane na zaplecze techniczne najemcy, dostosowane decyzje o trasowaniu nie wpływają na wydajność.

Instancja dla każdego najemcy

W niektórych scenariuszach można wdrożyć wystąpienie usługi API Management dla każdej dzierżawy. Zalecamy takie podejście tylko wtedy, gdy masz kilka dzierżaw lub jeśli masz ścisłe wymagania dotyczące zgodności, które ograniczają udostępnianie dowolnej infrastruktury między dzierżawami. Na przykład, jeśli wdrożysz dedykowaną sieć wirtualną dla każdej dzierżawy, prawdopodobnie musisz również wdrożyć dedykowane wystąpienie usługi zarządzania API dla każdej dzierżawy.

Napiwek

Jeśli jedynym powodem wdrażania wielu wystąpień jest obsługa użytkowników w różnych regionach geograficznych, warto rozważyć, czy funkcja wdrażania wieloregionalnego w usłudze API Management spełnia Twoje wymagania.

Podczas wdrażania usługi API Management należy wziąć pod uwagę limity usług, w tym wszelkie ograniczenia, które mogą dotyczyć liczby wdrożonych instancji w subskrypcji lub regionie na platformie Azure.

Instancje jednodzierżawcze zwykle mają minimalną konfigurację routingu, ponieważ można kierować wszystkie żądania do jednego serwera. Ten scenariusz nie wymaga niestandardowych decyzji dotyczących routingu, więc nie ma dodatkowego wpływu na wydajność. Jednak zazwyczaj wiąże się to z wyższym kosztem zasobów niż w przypadku wdrożenia wystąpienia udostępnionego. Jeśli musisz wdrożyć instancje jednokrotnego wynajmu, rozważ, czy bramy samodzielnie hostowane umożliwiają ponowne użycie zasobów obliczeniowych specyficznych dla dzierżawy, które już wdrożyłeś.

Funkcje usługi API Management, które obsługują wielodostępność

API Management używa zasad, aby umożliwić elastyczność. Możesz dostosować sposób weryfikowania, kierowania i przetwarzania żądań podczas korzystania z zasad. Podczas projektowania wielodostępnego rozwiązania za pomocą usługi API Management można użyć zasad w celu zaimplementowania wielu jego możliwości.

Identyfikowanie najemców w żądaniach przychodzących

Zastanów się, jak można zidentyfikować odpowiedniego najemcę w każdym przychodzącym żądaniu. W rozwiązaniu wielodostępnym ważne jest, aby jasno wiedzieć, kto wysyła każde żądanie, aby zwracać dane dla tego konkretnego najemcy i nikt inny.

Usługa API Management udostępnia subskrypcje, których można użyć do uwierzytelniania żądań. Te subskrypcje używają unikatowego klucza subskrypcji, który pomaga zidentyfikować subskrybenta, który wysyła żądanie. Jeśli zdecydujesz się używać subskrypcji, rozważ sposób mapowania subskrypcji usługi API Management na własną dzierżawę lub identyfikatory klientów. Subskrypcje są ściśle zintegrowane z portalem deweloperów. W przypadku większości rozwiązań dobrą praktyką jest użycie subskrypcji do identyfikowania dzierżawców.

Alternatywnie można zidentyfikować najemcę przy użyciu innych metod. Poniższe przykładowe podejścia są uruchamiane w ramach zdefiniowanych zasad niestandardowych:

  • Użyj niestandardowego składnika adresu URL, takiego jak poddomena, ścieżka lub ciąg zapytania. Na przykład w adresie URL https://api.contoso.com/tenant1/productsmożesz wyodrębnić pierwszą część ścieżki tenant1i traktować ją jako identyfikator dzierżawy. Podobnie, biorąc pod uwagę przychodzący adres URL https://tenant1.contoso.com/products, możesz wyodrębnić poddomenę , tenant1. Aby użyć tego podejścia, rozważ przeanalizowanie ścieżki lub ciągu zapytania z Context.Request.Url właściwości.

  • Użyj nagłówka żądania. Na przykład aplikacje klienckie mogą dodawać niestandardowy TenantID nagłówek do żądań. Aby użyć tego podejścia, rozważ przeczytanie z kolekcji Context.Request.Headers .

  • Wyodrębnianie oświadczeń z tokenu internetowego JSON (JWT). Możesz na przykład mieć oświadczenie niestandardowe tenantId w zestawie JWT, które ma problem z dostawcą tożsamości. Aby użyć tej metody, użyj zasad validate-jwt i ustaw output-token-variable-name właściwość , aby definicja zasad mogła odczytywać wartości z tokenu.

  • Dynamiczne wyszukiwanie identyfikatorów najemców. Podczas przetwarzania żądania można komunikować się z zewnętrzną bazą danych lub usługą. Korzystając z tego podejścia, można utworzyć niestandardową logikę mapowania dzierżawy, aby zamapować identyfikator dzierżawy logicznej na określony adres URL lub uzyskać więcej informacji o dzierżawie. Aby zastosować to podejście, użyj zasad wysyłania żądań .

    Takie podejście może zwiększyć opóźnienie żądań. Aby wyeliminować ten efekt, warto użyć buforowania w celu zmniejszenia liczby wywołań do zewnętrznego interfejsu API. Aby zaimplementować podejście buforowania, można użyć zasad cache-store-value i cache-lookup-value . Pamiętaj, aby unieważnić pamięć podręczną przy użyciu każdej dodanej, usuniętej lub przeniesionej dzierżawy, która ma wpływ na wyszukiwanie zaplecza.

Nazwane wartości

Usługa API Management obsługuje nazwane wartości, które są niestandardowymi ustawieniami konfiguracji, których można używać w ramach zasad. Możesz na przykład użyć nazwanej wartości do przechowywania adresu URL zaplecza dzierżawy, a następnie ponownie użyć tej samej wartości w kilku miejscach w zasadach. Jeśli musisz zaktualizować adres URL, możesz zaktualizować go w jednym miejscu.

Ostrzeżenie

W rozwiązaniu wielodostępnym należy zachować ostrożność podczas nadawania nazw wartościom. Jeśli ustawienia różnią się między tenantami, pamiętaj, aby uwzględnić identyfikator tenant w nazwie. Na przykład można użyć wzorca, takiego jak tenantId-key:value po potwierdzeniu, że tenantId jest odpowiednie dla żądania.

Włącz identyfikator, aby zmniejszyć ryzyko przypadkowego odwołania się do albo manipulowania wartością innego najemcy podczas przetwarzania żądania dla tego najemcy.

Uwierzytelnianie żądań przychodzących

Żądania interfejsu API wysyłane do bramy usługi API Management zwykle wymagają uwierzytelnienia. Usługa API Management udostępnia kilka metod uwierzytelniania żądań przychodzących do bramy, w tym OAuth 2.0 i certyfikaty klienta. Należy wziąć pod uwagę typy poświadczeń, które należy obsługiwać i gdzie powinny być weryfikowane. Rozważ na przykład, czy walidacja powinna nastąpić w usłudze API Management, w aplikacjach zaplecza, czy w obu miejscach.

Aby uzyskać więcej informacji, zobacz Uwierzytelnianie i autoryzacja do interfejsów API w usłudze API Management.

Uwaga

Jeśli używasz klucza subskrypcji lub klucza interfejsu API, dobrym rozwiązaniem jest również użycie innej metody uwierzytelniania.

Sam klucz subskrypcji nie jest silną formą uwierzytelniania. Jednak jest to przydatne w przypadku innych scenariuszy, takich jak śledzenie użycia interfejsu API poszczególnych dzierżawców.

Kierowanie do zapleczy specyficznych dla dzierżawy

W przypadku używania usługi API Management jako składnika udostępnionego może być konieczne kierowanie przychodzących żądań interfejsu API do różnych backendów specyficznych dla najemców. Te zaplecza mogą znajdować się w różnych sygnaturach wdrożenia lub mogą być różne aplikacje w ramach pojedynczej sygnatury. Aby dostosować routing w definicji polisy, użyj zasady set-backend-service. Należy określić nowy podstawowy adres URL, do którego ma zostać przekierowane żądanie.

Buforowanie odpowiedzi lub innych danych

Usługa API Management ma zaawansowaną funkcję pamięci podręcznej, której można użyć do buforowania całych odpowiedzi HTTP lub innych danych. Możesz na przykład użyć pamięci podręcznej dla mapowań najemców, jeśli stosujesz logikę niestandardową lub jeśli wyszukujesz mapowanie z usługi zewnętrznej.

Użyj zasad cache-store-value i cache-lookup-value, aby zaimplementować podejście do buforowania.

Ostrzeżenie

W rozwiązaniu wielodostępnym należy zachować ostrożność podczas ustawiania kluczy pamięci podręcznej. Jeśli buforowane dane mogą się różnić w zależności od dzierżawy, upewnij się, że uwzględniono identyfikator dzierżawy w kluczu pamięci podręcznej.

Włącz identyfikator, aby zmniejszyć ryzyko przypadkowego odwołania się do albo manipulowania wartością innego najemcy podczas przetwarzania żądania dla tego najemcy.

Interfejsy API modelu dużego języka

Użyj funkcji bramy sztucznej inteligencji w usłudze API Management, gdy interfejsy API nazywają duże modele językowe. Te funkcje ułatwiają kontrolowanie kosztów, wydajności i izolacji w rozwiązaniach wielodostępnych.

Buforowanie semantyczne

Jeśli interfejsy API znajdują się przed modelami usługi Azure OpenAI, rozważ użycie buforowania semantycznego w usłudze API Management, aby zmniejszyć koszty i opóźnienia dla powtarzających się lub niemal zduplikowanych monitów.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

Pamięć podręczną należy podzielić na dzierżawę przy użyciu vary-by elementu , aby monity i odpowiedzi były odizolowane od dzierżawy, dla której są przeznaczone. Umieść zasady w przetwarzaniu lookup przychodzącym i zasady w przetwarzaniu store wychodzącym.

W poniższym przykładzie pokazano, jak wpisy semantycznej pamięci podręcznej są partycjonowane według identyfikatora subskrypcji lub klucza:

<!-- inbound -->
<azure-openai-semantic-cache-lookup
   score-threshold="0.05"
   embeddings-backend-id="embeddings-backend"
   embeddings-backend-auth="system-assigned">
   <vary-by>@(context.Subscription.Id)</vary-by>
   <!-- or: <vary-by>@(context.Subscription.Key)</vary-by> -->
</azure-openai-semantic-cache-lookup>

<!-- outbound -->
<azure-openai-semantic-cache-store duration="60" />

Poniższy przykład partycjonuje semantyczną pamięć podręczną według oświadczenia lub nagłówka dzierżawy:

<!-- inbound; requires validate-jwt if using a claim -->
<azure-openai-semantic-cache-lookup
   score-threshold="0.05"
   embeddings-backend-id="embeddings-backend"
   embeddings-backend-auth="system-assigned">
   <vary-by>@(context.Principal?.Claims.GetValueOrDefault("tenantId", ""))</vary-by>
   <!-- Alternative using a custom header: -->
   <!-- <vary-by>@(context.Request.Headers.GetValueOrDefault("TenantID", ""))</vary-by> -->
</azure-openai-semantic-cache-lookup>

<!-- outbound -->
<azure-openai-semantic-cache-store duration="60" />

Limity oparte na tokenach dla dużych modeli językowych

Użyj limitów opartych na tokenach w bramie sztucznej inteligencji, aby ograniczyć użycie dla każdej dzierżawy, nie tylko dla poszczególnych żądań. W przypadku korzystania z zapleczy usługi Azure OpenAI użyj zasad azure-openai-token-limit. W przypadku zapleczy zgodnych z interfejsem OpenAI lub interfejsu API wnioskowania modelu AI platformy Azure użyj zasad llm-token-limit. Aby uzyskać więcej informacji, zobacz Zasady limitu tokenów.

Wybierz klucz unikatowy dla dzierżawy, taki jak identyfikator subskrypcji lub oświadczenie tokenu identyfikatora dzierżawy, aby upewnić się, że limity skutecznie izoluje każdą dzierżawę. Użycie tokenu jest śledzone niezależnie w każdej bramie, regionie lub obszarze roboczym, a liczniki nie są agregowane w całym wystąpieniu.

Poniższy przykład ogranicza każdą dzierżawę do 60 000 tokenów na minutę według subskrypcji:

<azure-openai-token-limit
   counter-key="@(context.Subscription.Id)"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

W poniższym przykładzie limity są ograniczane przez oświadczenie lub nagłówek dzierżawy:

<!-- Using a tenant claim; requires validate-jwt earlier in the pipeline -->
<azure-openai-token-limit
   counter-key="@(context.Principal?.Claims.GetValueOrDefault(&quot;tenantId&quot;, &quot;&quot;))"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

<!-- Or using a custom header populated by your edge/CDN/gateway -->
<azure-openai-token-limit
   counter-key="@(context.Request.Headers.GetValueOrDefault(&quot;TenantID&quot;, &quot;&quot;))"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

Uwaga

Sprawdź, czy oświadczenie lub nagłówek jest obecny i niepusty przed zastosowaniem limitów, aby uniknąć przypadkowego zwijania wielu dzierżaw w ramach pojedynczego licznika.

Niestandardowe domeny

Użyj zarządzania interfejsem API, aby skonfigurować własne niestandardowe domeny dla bramy API i portalu deweloperów. W niektórych warstwach można skonfigurować domeny wieloznaczne lub wiele w pełni kwalifikowanych nazw domen (FQDN).

Możesz również używać usługi API Management razem z usługą, taką jak Azure Front Door. W tej konfiguracji usługa Azure Front Door często obsługuje domeny niestandardowe i certyfikaty TLS (Transport Layer Security) i komunikuje się z usługą API Management przy użyciu jednej nazwy domeny. Jeśli oryginalny adres URL od klienta zawiera informacje o dzierżawie, które musisz wysłać do instancji API Management w celu późniejszego przetworzenia, rozważ użycie X-Forwarded-Host nagłówka żądania lub użyj reguł usługi Azure Front Door, aby przekazać informacje jako nagłówek HTTP.

Limity szybkości

Często stosuje się limity przydziału lub limity czasowe w rozwiązaniu wielodostępnym. Limity szybkości mogą pomóc w ograniczeniu problemu hałaśliwego sąsiada. Możesz również użyć limitów przepustowości, aby wymusić jakość usługi i rozróżnić różne poziomy cenowe.

Użyj usługi API Management, aby wymusić limity częstotliwości specyficzne dla dzierżawy. Jeśli używasz subskrypcji specyficznych dla dzierżawy, rozważ użycie polityki ograniczeń w celu wymuszenia limitu dla każdej subskrypcji. Alternatywnie rozważ użycie zasad limitu przydziału według klucza , aby wymusić przydziały przy użyciu dowolnego innego klucza limitu szybkości, takiego jak identyfikator dzierżawy uzyskany z adresu URL żądania lub JWT.

Aby uzyskać więcej informacji, zobacz Limity oparte na tokenach dla dużych modeli językowych.

Ważne

Zakres licznika różni się od topologii zasad i wdrożenia:

  • Zasady rate-limit i rate-limit-by-key zachowują oddzielne liczniki dla każdej repliki bramy. W przypadku wdrożeń bramy wieloregionowej lub obszaru roboczego każda brama regionalna lub brama obszaru roboczego wymusza własny licznik.

  • Zasady azure-openai-token-limit i llm-token-limit śledzą również tokeny dla każdej bramy, regionu lub obszaru roboczego i nie są agregowane w całym wystąpieniu usługi.

  • Zasady quota i quota-by-key są globalne na poziomie usługi i mają zastosowanie w różnych regionach dla określonego wystąpienia.

Jeśli potrzebujesz globalnie spójnej przepustowości dla dzierżawy, preferuj limity przydziału, wymuszaj limity na nadrzędnej krawędzi, która widzi cały ruch lub kieruje dzierżawę do jednej bramy lub regionu.

Monetyzacja

Dokumentacja usługi API Management zawiera obszerne wskazówki dotyczące zarabiania na interfejsach API, w tym przykładowej implementacji. Metody zarabiania łączą wiele funkcji usługi API Management, dzięki czemu deweloperzy mogą publikować interfejs API, zarządzać subskrypcjami i pobierać opłaty na podstawie różnych modeli użycia.

Zarządzanie pojemnością

Wystąpienie usługi API Management obsługuje określoną ilość pojemności, która reprezentuje zasoby dostępne do przetwarzania żądań. Jeśli używasz złożonych zasad lub wdrażasz więcej interfejsów API w wystąpieniu, zużywasz więcej zasobów. Można zarządzać pojemnością instancji na kilka sposobów, na przykład kupując więcej jednostek. Możesz również dynamicznie skalować pojemność wystąpienia.

Niektóre wystąpienia wielodostępne mogą zużywać więcej pojemności niż wystąpienia z jedną dzierżawą, na przykład jeśli używasz wielu zasad do routingu żądań do różnych zapleczy dzierżawy. Rozważ dokładne planowanie pojemności i zaplanuj skalowanie pojemności wystąpienia, jeśli widzisz wzrost użycia. Należy również przetestować wydajność rozwiązania, aby zrozumieć potrzeby dotyczące zasobów z wyprzedzeniem.

Aby uzyskać więcej informacji na temat skalowania usługi API Management, zobacz Uaktualnianie i skalowanie wystąpienia usługi API Management.

Wdrożenia w wielu regionach

Usługa API Management obsługuje wieloregionalne wdrożenia, co oznacza, że można rozmieścić jeden logiczny zasób usługi API Management w wielu regionach platformy Azure bez potrzeby replikacji jego konfiguracji na oddzielne zasoby. Ta funkcja jest szczególnie przydatna w przypadku globalnego dystrybuowania lub replikowania rozwiązania. Możesz skutecznie wdrożyć flotę wystąpień usługi API Management w wielu regionach, co umożliwia przetwarzanie żądań o małych opóźnieniach i zarządzanie nimi jako pojedyncze wystąpienie logiczne.

Ważne

Wdrożenie wieloregionowe jest obsługiwane tylko w warstwie Premium (wersja klasyczna). Nie jest ona dostępna w warstwach Consumption, Developer, Basic, Standard, Basic, Basic v2, Standard v2 lub Premium v2 (wersja zapoznawcza). Jeśli korzystasz z warstw w wersji 2 i musisz wdrożyć je w wielu regionach, użyj oddzielnego wystąpienia dla każdego regionu i użyj routingu zewnętrznego (takiego jak usługa Azure Front Door) lub rozważ własne bramy.

Jeśli jednak potrzebujesz w pełni izolowanych wystąpień usługi API Management, możesz również wdrożyć niezależne zasoby usługi API Management w różnych regionach. Takie podejście oddziela płaszczyznę zarządzania dla każdego wystąpienia usługi API Management.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy

  • John Downs | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure
  • Daniel Scott-Raynsford | Starszy architekt rozwiązań partnerskich, rozwiązania partnerskie dla przedsiębiorstw

Inny współautor:

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

  • Last updated on