Freigeben über

Bewährte Methoden für die Architektur für die Azure-API-Verwaltung

Azure API Management ist eine Verwaltungsplattform und ein Gateway für APIs in allen Umgebungen, einschließlich Hybrid und Multicloud. Als Plattform-as-a-Service-Lösung (PaaS) unterstützt API-Verwaltung den API-Lebenszyklus Ihrer Workload.

In diesem Artikel wird davon ausgegangen, dass Sie als Architekt die Entscheidungsstruktur der Integrationsdienste überprüft und api Management als Integrationsdienst für Ihre Workload ausgewählt haben. Die Anleitung in diesem Artikel enthält Architekturempfehlungen, die den Grundsätzen der Well-Architected Rahmenpfeilerzugeordnet sind.

Technologieumfang

Diese Überprüfung konzentriert sich auf die in Beziehung stehenden Entscheidungen für die folgende Azure-Ressource:

  • Azure-API-Verwaltung

Der Umfang dieses Leitfadens ist der API-Management-Dienst, insbesondere die Gateway-Komponente (Datenebene), die API-Anforderungen von Clientanwendungen zu Back-End-APIs leitet, die auf verschiedenen Plattformen oder in standortübergreifenden Umgebungen gehostet werden. Die Architektur der Workload sollte die API-Verwaltungssteuerungsebene und zugehörige Komponenten wie Clientanwendungen, die auf das Gateway zugreifen, und die Back-End-APIs berücksichtigen, die Routinganforderungen verarbeiten. Außerdem werden unterstützende Azure-Dienste integriert, einschließlich Netzwerk, Überwachung, Identitätsverwaltung und anderen Funktionen.

In diesem Handbuch wird das Azure API Center nicht behandelt. Es befasst sich nur mit Themen auf API-Ebene, die sich auf API-Verwaltung beziehen, anstatt eine gut durchdachte Perspektive auf API-Entwurfsaspekte bereitzustellen.

Note

Nicht alle Empfehlungen gelten für alle Dienstebenen der API-Verwaltung. Viele Empfehlungen in diesem Leitfaden konzentrieren sich auf die Stufen Standard v2, classic Premium und Premium v2 der API-Verwaltung, die die empfohlenen Produktionsstufen für die meisten Unternehmensworkloads sind.

Reliability

Der Zweck der Säule für Zuverlässigkeit besteht darin, eine kontinuierliche Funktionalität bereitzustellen, indem genügend Resilienz geschaffen und die Fähigkeit zur schnellen Wiederherstellung von Fehlerngewährleistet wird.

Entwurfsprinzipien für Zuverlässigkeit bieten eine allgemeine Designstrategie, die für einzelne Komponenten, Systemflüsse und das gesamte System angewendet wird.

Checkliste für die Arbeitsauslastungsgestaltung

Starten Sie Ihre Designstrategie basierend auf der Designüberprüfung-Checkliste für Zuverlässigkeit. Bestimmen Sie ihre Relevanz für Ihre Geschäftlichen Anforderungen, und berücksichtigen Sie dabei die Ebenen und Features der API-Verwaltung und deren Abhängigkeiten. Erweitern Sie die Strategie, um bei Bedarf weitere Ansätze einzuschließen.

  • Bewerten von Gatewayfunktionen für Zuverlässigkeit und Redundanz: Ermitteln Sie die API-Verwaltungsebene und -features , die erforderlich sind, um die Zuverlässigkeitsanforderungen der Workload für jede Umgebung zu erfüllen.

    Bewerten Sie die Gateway-Redundanzfunktionen, einschließlich Verfügbarkeitszonen, mehrfachen Gatewayeinheiten, mehreren Regionen und Arbeitsbereichen. Alle diese Features werden in der Premium-Stufe unterstützt. Die Premium v2-Stufe unterstützt derzeit alle diese Features mit Ausnahme mehrerer Regionen. Die Entwicklerebene, die keine Vereinbarung zum Servicelevel (Service Level Agreement, SLA) enthält, eignet sich nicht für Produktionsworkloads. Berücksichtigen Sie die Kompromisse bei der Einführung von Features wie externem Zwischenspeichern, die potenzielle Fehlerpunkte und Leistungsengpässe darstellen können.

  • Überprüfen der Observability-Funktionen: Berücksichtigen Sie die Observability-Funktionen des Diensts, einschließlich Azure Monitor-Protokolle und -Metriken, Application Insights, integrierte Analysen und integrierte Diagnosen. Verwenden Sie diese Funktionen, um die Zuverlässigkeitssignale Ihrer Workload zu überwachen.

    Erwägen Sie beispielsweise die Verwendung von Azure Monitor-Warnungen , um Sie über potenzielle Probleme mit dem API-Verwaltungsgateway oder deren Abhängigkeiten zu informieren.

  • Überprüfen Sie Skalierungsstrategien: Definieren Sie Kriterien zum Skalieren des Gateways, indem Sie Einheiten hinzufügen, um die Dienstzulässigkeit aufrechtzuerhalten. Überlegen Sie, ob unter Berücksichtigung von Anforderungen, Ausnahmen oder beidem skaliert werden soll. Bewerten Sie die Auswirkungen der Skalierung der Gatewaykomponente auf andere Komponenten der Workload. Die Auswirkung auf den Netzwerkadressraum und die Skalierungsfunktionen des Back-Ends beispielsweise.

  • Isolieren kritischer Workloads: Ermitteln Sie, ob die Computeisolation erforderlich ist, um Arbeitsauslastungsanforderungen wie Datenhoheit oder Leistungsoptimierung in Ihren APIs zu erfüllen. Verwenden Sie dedizierte Gateways für kritische APIs und freigegebene Gateways für weniger kritische APIs.

    Wählen Sie einen Isolationsansatz aus, wie die Verwendung eines dedizierten Arbeitsbereich-Gateways oder einer separaten API-Verwaltungsinstanz. Halten Sie die Umgebungen für mehrere Instanzen im Rahmen Ihrer sicheren Bereitstellungspraktiken synchronisiert.

  • SLO-Ausrichtung (Service Level Objective): Berücksichtigen Sie den SLA-Bereich des Gateways, wenn Sie die SLOs Ihrer Workload festlegen. Der Dienst stellt eine eigene SLA bereit, aber Sie müssen auch die erwartete Zuverlässigkeit anderer Workloadkomponenten berücksichtigen, z. B. die API-Back-Ends.

  • Behandeln von Back-End-Fehlern: Planen Sie sowohl erwartete als auch unerwartete Back-End-Fehler. Testen Sie Clienterfahrungen in diesen Szenarien. Bewerten Sie Gatewayrichtlinien , um die Resilienz zu verbessern und die Clienterfahrung zu verbessern. Konzentrieren Sie sich auf Kontingente, Ratenbegrenzungen, Wiederholungsrichtlinien, Schaltkreisschutz für das Back-End, Lastverteilung und Ausnahmebehandlung, wie in Ihren API-Spezifikationen dokumentiert.

  • Definieren von Teststrategien: Verwenden Sie eine Testlösung wie Azure Load Testing aus Ihrem Netzwerk, um die tatsächlichen Produktionsworkloads widerzuspiegeln. Verlassen Sie sich nicht auf den veröffentlichten Durchsatz oder andere Schätzungen, die möglicherweise nicht für Ihre Workload gelten.

  • Planen der Notfallwiederherstellung (DR): Überprüfen Sie optionen zum Sichern und Wiederherstellen der Gatewayinfrastruktur und APIs. Integrierte Sicherungs- und Wiederherstellungsfunktionen können in einigen Szenarien hilfreich sein. Kundenverwaltete Optionen wie APIOps-Tools und Lösungen für Infrastruktur als Code (IaC) können jedoch auch berücksichtigt werden. Entwickeln Sie Strategien zum Verwalten anderer Systemdaten, einschließlich Benutzerabonnements.

Konfigurationsempfehlungen

Diese Zuverlässigkeitsempfehlungen gelten entweder für den Dienst selbst oder für den Datenverkehr, der über APIs und deren Richtlinien fließt. Die Designatoren (Dienst) oder (API) geben an, ob eine Empfehlung auf den Dienst oder die APIs abzielt.

Recommendation Benefit
(Dienst) Aktivieren Sie Zonenredundanz (verfügbar in den Premium- und Premium v2-Stufen) und stellen Sie mindestens zwei Einheiten bereit.

Unter normalen Betriebsbedingungen sind alle Skalierungseinheiten in allen konfigurierten Zonen aktiv und dienen dem Gatewaydatenverkehr.

Planen Sie in jedem aktiven Szenario, die Skalierung in den verbleibenden aktiven Zonen zu unterstützen, um Datenverkehr zu behandeln, der ursprünglich in der fehlerhaften Zone verarbeitet wurde.		 Resilienz wird während eines Ausfalls eines Rechenzentrums innerhalb einer Region sichergestellt. Während eines vollständigen Ausfalls eines Rechenzentrums fließt der API-Verkehr weiterhin durch die verbleibenden Einheiten, die in anderen Zonen bereitgestellt werden.
(Dienst) Aktivieren Sie das automatische Skalieren basierend auf den Anforderungen des Datenverkehrs.

In Multiregion-Bereitstellungen verfügen sekundäre Regionen nicht über automatische Skalierungs- oder Skalierungsfunktionen. Sie müssen eine benutzerdefinierte Funktion oder Logik-App implementieren, die als Reaktion auf Azure Monitor-Metrikwarnungen aktiviert wird, um Einheitenanpassungen basierend auf Bedarf zu verwalten.		 Ausreichende Ressourcen werden garantiert, um die Nachfrage von API-Clients zu erfüllen, wodurch Fehler aufgrund unzureichender Kapazität verhindert werden.
(Dienst) Verwenden Sie eine Multiregion-Topologie , um Resilienz gegen einen vollständigen regionalen Fehler zu unterstützen.

Bei diesem Ansatz müssen Sie sich mit anderen Komponenten in Ihrer Workload abstimmen und deren geplante Failovermerkmale verstehen. Planen Sie in jedem aktiven Szenario die Unterstützung der Skalierung in verbleibenden aktiven Regionen, um Datenverkehr zu verarbeiten, den die jetzt inaktive Region ursprünglich verarbeitet hat.

Stellen Sie sicher, dass Ihre multiregionale Topologie alle Complianceanforderungen für Daten bei der Übertragung oder Daten im Cache-Aufenthalt erfüllt.		 Robuste Resilienz wird während eines vollständigen regionalen Ausfalls gewährleistet, wodurch unterbrechungsfreier API-Verkehr durch Einheiten in anderen Regionen sichergestellt wird.
(Dienst) Isolieren Sie nicht verwandte APIs mit Arbeitsbereichen oder zusätzlichen API-Verwaltungsinstanzen. Die Auswirkungen von Fehlern, die durch Fehlkonfiguration oder Ausfälle verursacht werden, werden minimiert, indem APIs in verschiedenen Computeinstanzen getrennt werden.
(API) Testen Sie Richtlinienausdrücke und -logik gründlich und koppeln Sie sie mit widerstandsfähigen Fehlerbehandlungstechniken in API-Verwaltungsrichtlinien. Die Clienterfahrung wird verbessert, indem neue Fehlerquellen am Gateway verhindert und eine ordnungsgemäße oder sichere vorübergehende Fehlerbehandlung bereitgestellt wird.
(Dienst und API) Sammeln Sie Zuverlässigkeitsmetriken.

Typische API-Zuverlässigkeitsmetriken umfassen:

- Quotenbeschränkungen und Verstöße gegen Quoten.
– Fehlerrate basierend auf HTTP-Statuscodes.
- Anforderungsratenabweichungen von der Basislinie.
– Integritätsprüfungen, einschließlich Abhängigkeitsintegrität.		 Abweichungen von erwartetem Verhalten und vergangenen Basiswerten werden identifiziert. Diese Daten können verwendet werden, um Stammursachen wie geändertes Benutzerverhalten, Störungen aus Routinevorgängen, unerwartete Auswirkungen von neuen Features oder ungeplante Fehler in der Workload nachzuverfolgen.
(Dienst und API) Verwenden Sie integrierte Sicherungs- und Wiederherstellungsfunktionen , die im Rahmen Ihres DR-Playbooks in die API-Verwaltung integriert sind. Ergänzen Sie diese Features mit Ihren IaC-Artefakten und APIOps-Prozessen für eine robuste Lösung, die verschiedene Szenarien verarbeiten kann, einschließlich der Wiederherstellungskoordination mit Abhängigkeiten und Back-Ends. Die Geschäftskontinuität wird sichergestellt, indem die Wiederherstellung des API-Gateways und die Wiederherstellung definierter APIs nach einem vollständigen Systemverlust ermöglicht wird.

Security

Der Zweck der Säule „Security“ besteht darin, Vertraulichkeit, Integrität und Verfügbarkeit für die Arbeitsauslastung zu garantieren.

Die Prinzipien des Sicherheitsdesigns stellen eine allgemeine Designstrategie für die Erreichung dieser Ziele bereit, indem Ansätze auf das technische Design der API-Verwaltung angewendet werden.

Note

Die Checkliste und Empfehlungen in diesem Abschnitt konzentrieren sich auf die Sicherung der API-Verwaltungsgatewayressource. Das Sichern der APIs selbst wird nur kurz behandelt. Weitere Informationen finden Sie in Mitigate OWASP API Security Top 10 in der API-Verwaltung.

Checkliste für die Arbeitsauslastungsgestaltung

Starten Sie Ihre Designstrategie basierend auf der -Designüberprüfungsprüfliste für Sicherheit und identifizieren Sie Sicherheitsrisiken und Kontrollen, um die Sicherheitslage zu verbessern.

  • Einrichten einer Sicherheitsbasislinie: Überprüfen Sie die Sicherheitsgrundwerte für die API-Verwaltung , und integrieren Sie entsprechende Maßnahmen in Ihren Basisplan.

  • Schützen sie die Bereitstellungspipeline: Identifizieren Sie die rollenbasierten Zugriffssteuerungsrollen, die zum Verwalten der Dienstplattform, der kontinuierlichen Integration und der kontinuierlichen Bereitstellung (CI/CD)-Pipelines und der einzelnen APIs erforderlich sind. Stellen Sie sicher, dass nur autorisierte Personen Zugriff auf die Verwaltung des Diensts und der zugehörigen APIs haben.

  • Auswerten der Datenempfindlichkeit: Wenn vertrauliche Daten über API-Anforderungen und -Antworten im API-Verwaltungsgateway fließen, stellen Sie ihren Schutz während des gesamten Lebenszyklus sicher. Berücksichtigen Sie unterschiedliche Datenschutzanforderungen in verschiedenen Regionen. Bewerten sie Dienstfeatures wie mehrere Regionen , um bestimmte Daten zu isolieren. Vergewissern Sie sich außerdem, ob Ihre Zwischenspeicherungsstrategie diesen Isolationsanforderungen entspricht.

  • Entwickeln von Segmentierungsstrategien für freigegebene Gateways: Wenn Ihre API-Verwaltungsinstanz APIs für mehrere Workloadteams hostet, verwenden Sie Arbeitsbereiche , um Rollen, Netzwerke und möglicherweise Gateways zu trennen. Mit diesem Ansatz wird sichergestellt, dass jedes Team über geeignete Zugriffe und Kontrolle über die APIs verfügt, die sie verwalten, während der Zugriff auf die APIs anderer Teams eingeschränkt wird.

  • Berücksichtigen Sie Netzwerksteuerelemente: Identifizieren Sie Anforderungen und Optionen zum Isolieren oder Filtern von eingehendem und ausgehenden Gatewaydatenverkehr mithilfe virtueller Netzwerke. Ermitteln Sie, ob der Zugriff auf das Gateway über azure Private Link eingeschränkt werden kann oder ob der öffentliche Zugriff auf das Gateway erforderlich ist. Bewerten Sie, ob die Architektur eine Webanwendungsfirewall enthalten soll, z. B. azure Web Application Firewall in Azure Application Gateway oder Azure Front Door, um die erforderliche Netzwerkisolation zu erreichen und netzwerkdatenverkehr zu filtern.

  • Berücksichtigen Sie Funktionen für DIE API-Authentifizierung und -Autorisierung: Bewerten Sie die Verwendung von Identitätsanbietern wie Microsoft Entra ID, die integrierte Gruppen enthält, oder microsoft Entra External ID , um Gatewayanforderungen zu überprüfen und die OAuth-Autorisierung für Back-End-APIs zu aktivieren.

  • Netzwerkdatenverkehr verschlüsseln: Identifizieren Sie die sichersten TLS-Protokollversionen ( Transport Layer Security) und Verschlüsselungen, die Ihre Workloads unterstützen können. Sie benötigen keine unsicheren TLS-Versionen. Verwenden Sie TLS 1.3, wenn sie von Ihren Clients unterstützt wird.

  • Führen Sie die Bedrohungsmodellierung für die API-Verwaltung durch, und reduzieren Sie deren Oberflächenfläche: Bestimmen Sie, ob bestimmte API-Verwaltungskomponenten wie die direkte Verwaltungs-API oder der öffentliche Zugriff auf das Entwicklerportal deaktiviert, eingeschränkt oder entfernt werden können.

  • Identifizieren Sie Geheimnisse, die Workloads erfordern: Für den Betrieb des Gateways sind möglicherweise Zertifikate, API-Schlüssel oder andere geheime Werte erforderlich. Überprüfen Sie die Anforderungen und Funktionen von Azure Key Vault, um geheime Schlüssel und Zertifikate zu speichern. Oder überprüfen Sie die integrierten API-Verwaltungsfunktionen wie benannte Werte und verwaltete Zertifikate.

Konfigurationsempfehlungen

Diese Sicherheitsempfehlungen können entweder auf den Dienst selbst oder auf den Datenverkehr angewendet werden, der über APIs und deren Richtlinien fließt. Die Designatoren (Dienst) oder (API) geben an, ob eine Empfehlung auf den Dienst oder die APIs abzielt.

Recommendation Benefit
(Dienst) Deaktivieren Sie die veraltete Direct Management-API. Verwenden Sie Azure Resource Manager als Steuerungsebene. Die Fläche des Dienstes wird reduziert, indem ein Steuerebene-Zugangspunkt entfernt wird.
(Dienst) Beschränken Sie die Exposition des Gateways basierend ausschließlich darauf, wo legitime Clients eine Verbindung herstellen.

– Verwenden Sie virtuelle Netzwerk-Injection ohne öffentliche IP-Adresse, wenn alle Clients Datenverkehr über ein virtuelles Netzwerk weiterleiten können. Verwenden Sie eine Netzwerksicherheitsgruppe (Network Security Group, NSG), um den Datenverkehr auf die erwarteten IP-Adressen des Clientursprungs weiter einzuschränken.

– Verwenden Sie die Integration des virtuellen Netzwerks mit Application Gateway oder Azure Front Door, wenn jeglicher Datenverkehr aus dem Internet kommen muss. Konfigurieren Sie die NSG so, dass nur Datenverkehr vom einzigen Eintrittspunkt akzeptiert wird.		 Die Vertraulichkeit des Netzwerkdatenverkehrs wird geschützt, indem die Gefährdung der IP-Quelladressenbereiche eingeschränkt wird, die erwartet werden, dass sie legitime Clients enthalten. Diese Einschränkungen blockieren den Zugriff von Quellen, die keine legitime Clientkommunikation initiieren sollten. Das Einschränken der Exposition gegenüber legitimen Datenverkehrsquellen verbessert die Vertraulichkeit, Integrität und Verfügbarkeit des Diensts.
(Dienst) Deaktivieren Sie das Entwicklerportal , wenn es nicht verwendet wird. Wenn das Portal verwendet wird, deaktivieren Sie die Anmeldeoberfläche, deaktivieren Sie den anonymen Zugriff, und beschränken Sie den Zugriff nur auf vertrauenswürdige Netzwerkspeicherorte. Der Oberflächenbereich des Dienstes und die Chance auf Fehlkonfiguration oder Vernachlässigung werden reduziert.
(Dienst) Legen Sie explizit die schmalsten unterstützten TLS-Versionen, -Protokolle und -Chiffre für Ihre Clients und Ihre Back-Ends fest. Versionen und unterstützte Verschlüsselungen werden nur auf die Optionen reduziert, die Clients und Back-Ends unterstützen. Dieser Ansatz trägt dazu bei, sicherzustellen, dass Verbindungen die bestmöglichen Verbindungen für vertraulichkeitsgerechte Verbindungen priorisieren.
(Dienst) Speichern Sie benutzerdefinierte Zertifikate im Key Vault. Die Zertifikatsverwaltung wird mithilfe von Key Vault bereitgestellt, das regelmäßige Rotation und Prüfung des Zugriffs auf Zertifikate unterstützt.
(Dienst) Back-Ends sollten nur Datenverkehr von den API-Gateways akzeptieren und den gesamten anderen Datenverkehr blockieren. Bösartiger Datenverkehr wird daran gehindert, die Sicherheitsvorkehrungen und andere übergreifende Aufgaben, die dem Gateway übertragen wurden, zu umgehen.
(Dienst) Entwerfen Sie für API-Verwaltungsinstanzen, die APIs für mehrere Teams oder segmentierte Workloads hosten, eine robuste Strategie für die Zugriffssteuerungsisolation. Verwenden Sie Arbeitsbereiche oder implementieren Sie einen strengen APIOps-Prozess , um diese Strategie zu erreichen.

Teams dürfen nur Zugriff auf die APIs haben, die sie besitzen. Sie sollten keinen Zugriff auf andere APIs haben, die möglicherweise in derselben Instanz gehostet werden.		 Die seitliche Bewegung von Angreifern von einem kompromittierten API-Set in andere nicht zusammenhängende APIs wird reduziert.
(API) Speichern Sie geheime Schlüssel im Key Vault, und machen Sie sie über benannte Werte für Richtlinien verfügbar. Verwenden Sie Key Vault nicht, um nicht geheime Informationen zu speichern. Verwenden Sie benannte Werteigenschaften direkt für diese Werte. Geheime Drehung wird durch eine einzige Verwaltungsebene im Key Vault gefördert, ähnlich wie bei der Methode, die für Zertifikate verwendet wird. Dieser Prozess stellt sicher, dass die API-Verwaltung entsprechend aktualisiert wird. Benannte Werte sorgen außerdem für eine konsistente Erfahrung bei der Richtlinienkonfiguration sowohl für geheime Informationen als auch für nicht-geheime Informationen. Der gesamte geheime Zugriff wird auch im Key Vault überwacht, um einen Zugriffsverlauf bereitzustellen. Nur das Speichern geheimer Schlüssel im Key Vault minimiert die Abhängigkeit von Key Vault und wandelt Key Vault nicht in einen Anwendungskonfigurationsdienst um.
(API) Verwenden Sie unterschiedliche vom Benutzer zugewiesene verwaltete Identitäten für unterschiedliche APIs mithilfe der Authentifizierungs-Richtlinie für verwaltete Identitäten . Jede API kann eine eigenständige Identität haben, die durch den geringstmöglichen Berechtigungszugriff für jede API die Segmentierungsziele unterstützt. Es bietet auch eine bessere Auditierbarkeit in den Back-End-Systemen.
(API) Wenn möglich, müssen Clients sich bei OAuth 2.0-Flüssen authentifizieren , anstatt nur vorab gemeinsam genutzte Schlüssel zu verwenden, einschließlich Abonnementschlüssel oder Clientzertifikaten. Die Clientidentifikation für Überwachungszwecke wird verbessert, die Schlüsselrotation wird abgeschafft, und die Last für die Kunden, vertrauliche Informationen zu schützen, wird im Vergleich zur Verwendung von vorab genutzten Schlüsseln reduziert.
(API) Unterdrücken Sie HTTP-Header aus API-Antworten, indem Sie die Set-Header-Richtlinie verwenden, die Implementierungsdetails verfügbar machen kann. Die Kosten für Angreifer werden erhöht, indem Implementierungsinformationen zurückbehalten werden.
(API) Verwenden Sie die API-Ablaufverfolgung nicht in der Produktion. Vertrauliche Daten werden daran gehindert, in Anforderungsablaufverfolgungen verfügbar zu werden.
(API) Verwenden Sie Defender für APIs. API-Sicherheitserkenntnisse, Empfehlungen und Bedrohungserkennung werden bereitgestellt.
(API) Schützen Sie Back-End-Ressourcen, indem Sie wichtige Sicherheitsüberprüfungen in der API-Richtlinie delegieren, z. B. validate-jwt, ip-filter, validate-headers, validate-content. Der Umfang des nichtlegitimate Datenverkehrs, der Back-End-Dienste erreicht, wird durch die Durchführung von Sicherheitsprüfungen am Gateway reduziert. Dieser Offloading-Ansatz trägt zum Schutz der Integrität und Verfügbarkeit dieser Ressourcen bei.
(API) Wenden Sie Methoden für den Sicherheitsentwicklungslebenszyklus (SDL) auf API-Richtlinienänderungen auf die gleiche Weise an, wie Sie vorgeschlagene Änderungen auf Anwendungscode in Ihrer Workload anwenden. Richtlinien werden mit einer hochgradig privilegierten Ansicht des API-Datenverkehrs ausgeführt. Das Umgehen von Back-End-Schutz für Vertraulichkeit, Integrität und Verfügbarkeit durch ein kompromittiertes API-Gateway wird verhindert.
(Dienst und API) Verwenden Sie verwaltete Identitäten für Dienst- und API-Abhängigkeiten. Verbindungen mit Key Vault, Azure Event Hubs und anderen Abhängigkeiten, z. B. Zertifikate und benannte Werte, werden eingerichtet, ohne sich auf vorgegebene Geheimnisse zu verlassen.
(Dienst und API) Stellen Sie nach Möglichkeit eine Verbindung mit Abhängigkeiten wie Key Vault, Event Hubs und Back-Ends über private Netzwerkverbindungen her. Die Vertraulichkeit des Datenverkehrs wird geschützt, indem der Datenverkehr nicht über das private Netzwerk hinaus verfügbar ist.
(Dienst und API) Clientverkehr, der auf Internet-exponierte APIs abzielt, sollte zuerst eine Webanwendungsfirewall durchlaufen, z. B. Webanwendungsfirewall, bevor er das API-Management erreicht. Schützen Sie auch öffentliche Endpunkte mithilfe von Azure DDoS Protection. Der Umfang des nichtlegitimate Datenverkehrs, der das Gateway und die Back-End-Dienste erreicht, wird durch die Durchführung von Sicherheitsprüfungen mit einer Webanwendungsfirewall reduziert. Das Reduzieren dieses Datenverkehrs trägt zum Schutz der Integrität und Verfügbarkeit dieser Ressourcen bei.
(Dienst und API) Bewerten und Aktivieren aller Für Ihre Workload relevanten Azure Policy Regulatory Compliance-Kontrollen. Die API-Verwaltungsinstanz richtet sich an den gewünschten Stand und bleibt ausgerichtet, wenn sich die Workload weiterentwickelt, indem Sicherheitsrichtlinien vorhanden sind.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich darauf, Ausgabenmuster zu erkennen, Investitionen in kritische Bereiche zu priorisieren und andere Bereiche zu optimieren, um das Budget der Organisation einzuhalten und gleichzeitig die Geschäftsanforderungen zu erfüllen.

Die Designprinzipien für die Kostenoptimierung bieten eine allgemeine Entwurfsstrategie, um diese Ziele zu erreichen und bei Bedarf im technischen Design im Zusammenhang mit API Management und seiner Umgebung Kompromisse zu erzielen.

Checkliste für die Arbeitsauslastungsgestaltung

Erstellen Sie Ihre Entwurfsstrategie basierend auf der Checkliste zur Entwurfsüberprüfung in Bezug auf „Kostenoptimierung“ für Investitionen. Feinabstimmen Sie das Design so, dass die Lastverteilung mit dem für die Workload zugewiesenen Budget übereinstimmt. Ihr Design sollte die richtigen Azure-Funktionen verwenden, Investitionen überwachen und Möglichkeiten zur Optimierung im Laufe der Zeit finden.

  • Berücksichtigen Sie das KOSTENmodell für die API-Verwaltung: Verwenden Sie den Azure-Preisrechner mit den Kontovorteilen und Kriterien Ihrer Organisation für SLA und Skalierbarkeit, um genaue Kostenschätzungen für die Verwendung einer API-Verwaltungsdienstebene zu entwickeln. Ermitteln Sie, ob ein Charge-Back-Modell erforderlich ist, und bestimmen Sie, wie sie basierend auf Metriken, Tags und Token berechnet werden soll.

    Das Dienstkostenmodell wird hauptsächlich durch die Dienstebene, die Anzahl der Einheiten und die Anzahl der Gateways beeinflusst. Bewerten Sie die zusätzlichen Kosten, die mit der Wartung einer Reserveeinheit oder der Implementierung einer aktiv-passiven DR-Konfiguration verbunden sind.

    Wenn Sie Arbeitsbereiche implementieren, bewerten Sie die Kosten für die Verwendung von separaten gegenüber gemeinsamen Arbeitsbereichsgateways, um den unterschiedlichen Anforderungen des API-Flusses von verschiedenen API-Teams oder Stakeholdern gerecht zu werden.

  • Skalierungskosten schätzen: Entwickeln Sie Skalierungskriterien, um eine hohe Nutzung der Gatewayressourcen aufrechtzuerhalten. Bewerten Sie die geplanten Kosten in einer Vorproduktionsumgebung, und führen Sie Tests durch, um die Kosten für die Skalierung basierend auf dem erwarteten Workloaddatenverkehr zu modellieren.

    Entwerfen Sie eine Entschärfungsstrategie, um Missbrauch Ihrer Gateways zu verhindern, was zu einer teuren Skalierung über die vorhergesagte Nutzung hinaus führen kann.

  • Bewerten Sie Dienstkonfigurationen und -richtlinien: Fähigkeiten wie Ratebegrenzung und Limitierung der Gleichzeitigkeit können als Kostenoptimierungstechniken zur Verwaltung von Anforderungslasten eingesetzt werden.

  • Optimieren der Logikplatzierung: Bewerten Sie, ob Back-End-Server für die Verarbeitungslogik kostengünstiger sind oder ob das Gateway die Ressourcennutzung verarbeiten soll. Das Gateway ist eine starke Komponente für die Implementierung von querschneidenden Bedenken, kann aber in bestimmten Szenarien übermäßige Funktionen ausführen. Identifizieren Sie ressourcenintensive Anforderungsverarbeitungsaufgaben, die das Gateway ausführt, und bestimmen Sie, ob das Verschieben dieser Logik auf Back-End-Server Kosten reduzieren kann.

Konfigurationsempfehlungen

Diese Empfehlungen zur Kostenoptimierung gelten entweder für den Dienst selbst oder für den Datenverkehr, der über APIs und deren Richtlinien fließt. Die Designatoren (Dienst) oder (API) geben an, ob eine Empfehlung auf den Dienst oder die APIs abzielt.

Recommendation Benefit
(Dienst) Verwenden Sie die am wenigsten kostspielige Stufe , die die Anforderungen Ihrer Workload unterstützt. Wählen Sie z. B. eine Standardstufe anstelle einer Premium-Stufe aus, wenn Ihre Workload nicht von der zusätzlichen Funktionalität profitieren wird, die die Rendite für Investitionen (ROI) rechtfertigt. Der Kauf nicht verwendeter oder nicht genutzter Funktionen wird vermieden.
(Service) Verwenden Sie Nichtproduktionsstufen oder flüchtige Infrastruktur in niedrigeren Umgebungen, z. B. Entwicklungsumgebungen, Machbarkeitsstudien-Deployments und anfängliche Kostenmodellierungsaktivitäten. Die Ressourcenkosten werden für Umgebungen gespart, die nützlich bleiben können, ohne die exakten Konfigurations- oder Verfügbarkeitsanforderungen der Produktion vollständig zu spiegeln.
(Dienst) Abskalieren, wenn die Nachfrage sinkt. Konfigurieren Sie Autoskalenregeln oder andere automatisierte Prozesse, um Einheiten zu reduzieren, wenn die Gatewaykapazität unter definierte Schwellenwerte fällt. Unnötige Kosten werden durch die Anpassung der Kapazität an den Bedarf reduziert.
(Dienst) Berechnen Sie alle Kostenvorteile eines Verbundmodells für die API-Verwaltung, indem Sie Arbeitsbereiche zum Bereitstellen von APIs verwenden und gleichzeitig teamisolieren. Die Bereitstellungs- und Verwaltungsoberfläche wird reduziert. Dieser Ansatz zielt darauf ab, Größenvorteile von Zeit- und Ressourcenkäufen zu erzielen.
(Dienst) Arbeitsbereiche stilllegen, wenn sie nicht mehr verwendet werden. Die Ausgaben für nicht verwendete Ressourcen werden vermieden.
(Dienst) Verwenden Sie den integrierten Cache , wenn die zwischengespeicherten Daten Ihrer Workload in die Einschränkungen des integrierten Caches in Ihrer Ebene passen. Kosten für den Einkauf und die Wartung eines externen Redis-kompatiblen Caches werden vermieden.
(Dienst) Blockieren Sie bösartigen Datenverkehr, bevor sie das Gateway erreicht, indem Sie Netzwerksteuerelemente, DDoS-Schutz und Webanwendungsfirewalls verwenden. Bestimmte Ebenen der API-Verwaltung verursachen Gebühren basierend auf der Anzahl der HTTP-Anforderungsvorgänge, die das Gateway verarbeitet. Daher kann unerwünschter Datenverkehr, wie z. B. botgenerierte Anforderungen, die Kosten erhöhen.

Bewerten Sie die Kosten des Blockierungsmechanismus im Vergleich zu den geschätzten Kosten der HTTP-Vorgangsreduzierung, um zu bewerten, ob dieser Ansatz über einen ROI verfügt.		 Gebühren, die aufgrund übermäßiger böswilliger oder belästigender HTTP-Vorgänge gegen das Gateway entstehen, werden reduziert.
(API) Optimieren Sie die Richtlinienausdrücke, die Verarbeitung und den Code, um eine übermäßige Nutzung von Rechenressourcen wie Prozessor, Netzwerk oder Arbeitsspeicher zu vermeiden. Unnötige Bereitstellung von mehr Einheiten, um Kapazität für nicht optimierte Richtlinienimplementierungen und Code bereitzustellen, wird vermieden.
(API) Bewerten Sie die Kosten der logischen Platzierung zwischen Ihrem Gateway, Ihrem Back-End oder Ihrem öffentlichen Eintrittspunkt, z. B. Azure Front Door. Dieselbe Verarbeitung kann häufig auf jeder dieser Ebenen erfolgen, wobei jede mit eigenen Abwägungen verbunden ist. Einige Ebenen können jedoch kostensparend sein, da nicht genutzte Kapazität auf dieser Ebene verfügbar ist. So kann beispielsweise zwischenspeicherungslogik, die ursprünglich im Back-End implementiert wurde, kosteneffizienter auf Gatewayebene mithilfe des integrierten Caches implementiert werden. Dieser Ansatz reduziert zusätzlichen Netzwerk- und Computeaufwand für Back-End-Dienste. Die Auslastung von Ressourcen mit hohen Kosten wird minimiert, indem Funktionen auf der kostengünstigsten Ebene platziert werden. Dieser Ansatz verschiebt Workloads auf Ebenen, die über freie Kapazität oder kostengünstige Berechnungsoptionen verfügen.

Operative Exzellenz

„Optimaler Betrieb“ konzentriert sich primär auf Verfahren für Entwicklungsmethoden, Einblick und Releaseverwaltung.

Die Designprinzipien der Operational Excellence bieten eine übergeordnete Strategie zur Erreichung dieser Ziele in Bezug auf die betrieblichen Anforderungen der Arbeitslast.

Checkliste für die Arbeitsauslastungsgestaltung

Beginnen Sie mit Ihrer Designstrategie auf der Grundlage der Prüfliste für die Designüberprüfung im Rahmen der Operational Excellence, um Prozesse für Beobachtbarkeit, Tests und Bereitstellung für das API-Management zu definieren.

  • Überprüfen Sie wichtige Kenntnisse und Fähigkeiten, die für den Betrieb des Dienstes erforderlich sind: Zu den Bereichen zählen API-Lebenszyklus, DevOps-Prozesse, Netzwerk- und Konnektivität, Überwachung und Observability sowie Softwareentwicklung. Dieser Ansatz umfasst Richtlinienkonfiguration, Komponententests und die Erstellung von CI/CD-Pipelines.

  • Berücksichtigen Sie die Dokumentationsanforderungen: Verpflichten Sie sich zur Dokumentation von Prozessen für die Konfiguration auf Dienstebene und API-Ebene, Lebenszyklusoperationen sowie die verschiedenen Zugriffsmuster für API-Teams.

  • Bewerten Sie Standardtools zur Unterstützung von Dienstvorgängen. Übernehmen Sie beispielsweise APIOps-Methoden wie GitOps und CI/CD, um APIs zu veröffentlichen und API-Konfigurationen zu verwalten. Verwenden Sie IaC-Tools für Konfigurationsänderungen auf Dienstebene. Entwerfen Sie wiederverwendbare Artefakte, die nahtlos von Entwicklungsumgebungen zu Produktion wechseln können. Erwägen Sie, einen Linter wie Spectral, entweder selbstverwaltet oder integriert in einen Azure-Dienst wie das Azure API Center, in API-Genehmigungspipelines zu integrieren.

  • Bestimmen sie die wichtigsten betriebstechnischen Metriken und Protokolle: Überprüfen Sie die Metriken für die Produktion. Zu diesen Metriken gehören Die Gatewaykapazität, die CPU-Auslastung, die Speicherauslastung und die Anzahl der Anforderungen. Überprüfen Sie Protokolle und Observability-Tools, z. B. Azure Monitor und Application Insights. Bestimmen Sie die Strategien und Tools, die zum effektiven Verwalten großer Mengen von Beobachtungsdaten in Produktionsumgebungen erforderlich sind. Ermitteln Sie Abfragen, die Umsetzbare Einblicke sowohl für den Gatewayoperator als auch für die Projektbeteiligten bereitstellen, die bestimmte gehostete APIs überwachen.

  • Planen Sie regelmäßige Tests von Produktionsworkloads mithilfe von Auslastungstests.

  • Identifizieren Sie operative Aufgaben, die über CI/CD- oder IaC-Prozesse hinausgehen , die Automatisierung erfordern. Planen Sie die Automatisierung in Bereichen wie api Management-Richtlinienquellverwaltung, Azure-Richtlinien und spezifische Entwicklerportalkonfigurationen.

Konfigurationsempfehlungen

Diese Empfehlungen für operative Exzellenz können entweder auf den Dienst selbst oder auf den Datenverkehr angewendet werden, der über APIs und deren Richtlinien fließt. Die Designatoren (Dienst) oder (API) geben an, ob eine Empfehlung auf den Dienst oder die APIs abzielt.

Recommendation Benefit
(Dienst) Konfigurieren Sie Azure Diagnostics-Ressourcenprotokolle für die API-Verwaltung. Plattformgenerierte Protokolle sind verfügbar, um Routinevorgänge, Bedarfsanforderungen oder dringende Szenarien wie Sicherheitsprüfungen abzufragen.
(Dienst) Verwenden Sie Azure Event Grid für die Automatisierung basierend auf sinnvollen Ereignissen, die Ihre API-Verwaltungsinstanz auslöst, z. B. APICreated. Automatisierungs- oder Benachrichtigungsaufgaben können um wichtige Lebenszyklusereignisse herum erstellt werden, die in der API-Verwaltungsinstanz auftreten.
(Dienst) Vermeiden Sie die Verwendung eines selbst gehosteten Gateways , wenn eine von Microsoft gehostete Gatewayeinheit in Ihrem Szenario funktioniert. Automatisierungs- oder Benachrichtigungsaufgaben können um wichtige Lebenszyklusereignisse herum erstellt werden, die in der API-Verwaltungsinstanz auftreten.
(Dienst) Wenden Sie alle integrierten Azure-Richtlinienrichtlinien an, mit denen Sie Ihre Instanz steuern und einschränken können, um sie an Workloadanforderungen anzupassen, einschließlich Sicherheitsanforderungen. Verwenden Sie z. B. Verweigerungsrichtlinien , um zu verhindern, dass APIs über HTTP verfügbar gemacht werden, oder um die Aktivierung der REST-API für die direkte Verwaltung zu verhindern. Verwenden Sie Überwachungsrichtlinien , wenn Verweigerungsrichtlinien nicht verfügbar sind, oder erstellen Sie benutzerdefinierte Verweigerungsrichtlinien, wenn es für Ihre Workload wichtig ist. Ihre API-Verwaltungsinstanz ist mit dem Design abgestimmt und bleibt abgestimmt, während sich die Arbeitslast weiterentwickelt.
(Dienst) Machen Sie sich mit der Diagnose - und Lösungsfunktion im Azure-Portal vertraut.

Verwenden Sie das Blatt "Netzwerkstatus " im Portal, um Probleme mit der Netzwerkkonnektivität zu beheben.		 Standortsicherheitsingenieure können Gatewayleistung, Dienstverfügbarkeit und Netzwerkkonnektivitätsprobleme in allen Umgebungen identifizieren und beheben.
(API) Verwenden Sie Event Hubs , um Protokoll- oder Ereignisdatenströme aus API-Aufrufen zu behandeln, die nahezu Echtzeitreaktionen oder Zeitrahmen-Fenstervorgänge erfordern. Die Verfügbarkeit von Protokolleinträgen in nahezu Echtzeit steht zur Verfügung. Die Protokolldatenaufnahmeverzögerung , die auftritt, wenn die Protokollierung bei Azure Monitor innerhalb von APIs erfolgt, wird vermieden.
(API) Unterstützen Sie die Verwendung der API-Ablaufverfolgung in der Entwicklung, damit Entwickler ihre Richtlinienimplementierung verstehen können. Die Entwicklerproduktivität wird optimiert, indem Sie Einblicke in die Implementierung von Richtlinien innerhalb einer API bieten. Ohne diese Funktion müssen Entwickler Hacks in die Richtlinienimplementierung einführen, um Einblicke zu erhalten.
(API) Definieren Sie Back-Ends immer mithilfe der Backends-Funktion von API Management. Verweisen Sie in der Richtlinie auf diese Back-Ends anhand der ID, indem Sie set-backend-service verwenden. Lastverteilte Backends sollten als Back-End-Pool definiert werden. Back-End-Verbindungsänderungen gelten für alle APIs, die das Back-End verwenden, ohne dass Aktualisierungen an einzelnem Richtliniencode erforderlich sind. Das Risiko von Fehlkonfigurationen oder übersehenen API-Richtlinienänderungen wird reduziert, und Szenarien, in denen mehrere APIs dasselbe Back-End gemeinsam nutzen, sind über diese Ebene der Konfigurationsabstraktion geeignet.
(API) Entwerfen Sie den Versionsverwaltungsansatz Ihrer APIs entsprechend den Versionsverwaltungs- und Revisionsfunktionen der API-Verwaltung. Berücksichtigen Sie diesen Ansatz in Ihren API-Bereitstellungsvorgängen. Eine api-Versionsverwaltungsstrategie, die von der API-Verwaltung unterstützt wird, wird verwendet, um integrierte Funktionen zu nutzen, anstatt benutzerdefinierte Lösungen zu erstellen.
(Dienst und API) Definieren Sie einen konsistenten und nachhaltigen Betrieblichen Prozess zum Hinzufügen, Ändern und Löschen von APIs. Ermitteln Sie, ob diese Oberfläche manuell über das Portal verwaltet oder über einen APIOps-Prozess implementiert werden soll. Verwenden Sie lieber einen IaC-basierten Ansatz anstelle eines portalbasierten Ansatzes.

Die Darstellung des API-Managements in der Ressourcen-Manager-API besteht aus vielen untergeordneten Ressourcen. Daher ist es wichtig, einen mehrstufigen Ansatz zur IaC-basierten Verwaltung dieser Ressourcensammlung anzuwenden.		 API-Spezifikationen und ihre Gatewayimplementierungen werden in die Änderungskontrollesprozesse der Workload integriert. Mit diesem Ansatz wird verhindert, dass Änderungen an Back-End-APIs anders behandelt werden, als sie für API-Clients über das Gateway verfügbar gemacht werden.

Leistungseffizienz

Bei der Leistungseffizienz geht es um Aufrechterhaltung der Benutzererfahrung, auch wenn durch die Verwaltung der Kapazität eine Zunahme der Last erfolgt. Die Strategie umfasst die Skalierung von Ressourcen, das Identifizieren und Optimieren potenzieller Engpässe und die Optimierung der Spitzenleistung.

Die Designprinzipien der Leistungseffizienz bieten eine übergeordnete Entwurfsstrategie zur Erreichung dieser Kapazitätsziele unter Berücksichtigung der erwarteten Nutzung.

Checkliste für die Arbeitsauslastungsgestaltung

Starten Sie Ihre Designstrategie basierend auf der Prüfliste für die Entwurfsüberprüfung für die Leistungseffizienz. Definieren Sie einen Basisplan, der auf Schlüsselleistungsindikatoren für die API-Verwaltung basiert.

  • Definieren von Leistungszielen: Wichtige Metriken zur Bewertung der Leistung des API-Verwaltungsgateways umfassen Kapazitätsmetriken, z. B. CPU- und Speicherauslastungsprozentsätze für Gatewayinfrastruktur, Anforderungsdauer und Anforderungsdurchsatz. Definieren Sie in multiregionsbasierten Bereitstellungen Leistungsziele für jede Region. Der Kunde muss geeignete Skalierungsschwellenwerte basierend auf Datenverkehrsmustern, API-Workloads und Skalierungszeiten definieren.

  • Erfassen von Leistungsdaten: Überprüfen Sie die Funktionen integrierter Analysen, Azure Monitor-Metriken, Azure Monitor-Protokolle, Application Insights und Event Hubs, um die Leistung auf verschiedenen Granularitätsebenen zu sammeln und zu analysieren.

  • Überprüfen Sie, wie Sie Probleme mit der Live-Leistung erkennen: Indikatoren für Live-Leistungsprobleme können die Verfügbarkeit von Azure-Diensten, HTTP-Antwortfehler sowie im Abschnitt Diagnose und Lösung von Problemen im Portal ausgelöste Fehler umfassen. Behandeln von Leistungs- und Verfügbarkeitsproblemen mithilfe von Application Insights, Kusto-Abfragen und Empfehlungen aus der API-Verwaltungsdiagnose im Azure-Portal.

  • Testleistung: Testen Sie die Leistung unter Produktionsbedingungen mithilfe von Auslastungstests.

  • Bewerten Sie angrenzende Dienste, die die Leistung verbessern können: Zwischenspeicherungsrichtlinien oder ein externer Cache können die Leistung bestimmter API-Vorgänge verbessern. Azure Front Door und Application Gateway sind häufige Auswahlmöglichkeiten für tls offloading.

  • Überprüfen Sie die dokumentierten Grenzwerte und Einschränkungen:API-Verwaltung weist Beschränkungen und Einschränkungen auf. Überprüfen Sie die dokumentierten Einschränkungen, und vergleichen Sie sie mit den Anforderungen Ihrer Workload, um festzustellen, ob Sie eine Lösung entwerfen müssen, die diese Einschränkungen vermeidet.

Konfigurationsempfehlungen

Diese Empfehlungen zur Leistungseffizienz können entweder auf den Dienst selbst oder auf den Datenverkehr angewendet werden, der über APIs und deren Richtlinien fließt. Die Designatoren (Dienst) oder (API) geben an, ob eine Empfehlung auf den Dienst oder die APIs abzielt.

Recommendation Benefit
(Dienst) Dynamisch skalieren, um den Bedarf zu erfüllen. Konfigurieren Sie Autoskalenregeln oder andere automatisierte Prozesse, um Gateway-Einheiten an eine Zielauslastung anzupassen. Die Flexibilität wird auf der Grundlage der gleichzeitigen Nutzung erreicht, wodurch die Ressourcenauslastung der aktuell bereitgestellten Einheiten oder die Überlastung der Kapazität verhindert wird.
(API) Minimieren Sie teure Verarbeitungsaufgaben, z. B. das Generieren großer gepufferter Nutzlastgrößen, indem Sie die Validate-Content-Richtlinie für große Anforderungstexte verwenden oder eine hohe Anzahl aktiver WebSockets verwalten. Die Auslastung von Skalierungseinheiten wird reduziert, wodurch sie mehr Anforderungen gleichzeitig verarbeiten können, bevor sie verkleinert werden müssen.
(Dienst und API) Erfassen Sie Leistungsmetriken.

Allgemeine API-Leistungsmetriken umfassen:

– Anforderung der Verarbeitungszeit für das Gateway selbst und für den vollständigen Betrieb.
– Metriken für die Ressourcennutzung der Gatewayeinheit.
- Durchsatzmessungen wie Anforderungen pro Sekunde oder Megabit pro Sekunde.
Cachetrefferquote in Prozent		 Die tatsächliche Leistung wird anhand der Ziele der Arbeitslast gemessen.
(Dienst und API) Definieren Sie einen Sampling-Prozentsatz für Application Insights , der ausreichende Sichtbarkeit bietet, ohne die Leistung zu beeinträchtigen. Der Bedarf an Observability-Daten wird erfüllt, ohne die Gesamtleistung zu beeinträchtigen.
(Dienst und API) Bewerten Sie die Leistungsauswirkungen der Platzierung der Logik zwischen Ihrem Gateway, Ihrem Backend oder Ihrem öffentlichen Einstiegspunkt, wie beispielsweise Azure Front Door. Dieselben Verarbeitungsaufgaben können häufig auf einer dieser Ebenen auftreten, mit Leistungskonflikten und Einschränkungen bei den Optimierungsmöglichkeiten für jeden. Wenn eine Aufgabe, z. B. eine API-Verwaltungs-API-Richtlinie, zu viel Latenz einführt, überlegen Sie, ob diese Aufgabe an einer anderen Stelle optimiert ausgeführt werden kann. Aufgaben, die APIs Latenz hinzufügen, werden auf für die Workloadanforderungen optimierten Rechenprozessen ausgeführt.

Azure-Richtlinien

Azure bietet einen umfassenden Satz integrierter Richtlinien im Zusammenhang mit der API-Verwaltung und deren Abhängigkeiten. Einige der vorstehenden Empfehlungen können über Azure-Richtlinie überwacht werden. Sie können beispielsweise überprüfen, ob:

  • Das Gateway ist für Zonenredundanz konfiguriert.
  • Die richtigen Netzwerksteuerelemente sind für das API-Verwaltungsgateway vorhanden, z. B. die Bereitstellung in einem virtuellen Netzwerk.
  • Die Konfigurationsendpunkte des Dienstes sind nicht öffentlich zugänglich.
  • Die direkte Verwaltungs-REST-API ist deaktiviert.

Überprüfen Sie für eine umfassende Governance die integrierten Azure-Richtliniendefinitionen und andere Richtlinien, die sich auf die Sicherheit des API-Verwaltungsgateways auswirken können.

Azure Advisor-Empfehlungen

Azure Advisor ist ein personalisierter Cloudberater, der Ihnen hilft, bewährte Methoden zur Optimierung Ihrer Azure-Bereitstellungen zu befolgen.

Weitere Informationen finden Sie unter Azure Advisor.

Tradeoffs

Möglicherweise müssen Sie Design-Kompromisse machen, wenn Sie die Ansätze in den Pfeilerlisten verwenden. Hier sind einige Beispiele für Vor- und Nachteile.

Hohe Verfügbarkeit durch Redundanz und Isolation

  • Hochverfügbarkeit. Redundanz wirkt sich auf Kosten aus. Beispielsweise ist die Bereitstellung von mindestens drei Einheiten, um Zonenausfälle zu vermeiden, für Ihre Arbeitsauslastung möglicherweise nicht finanziell machbar. Die Kosten steigen weiter mit einer multiregionsübergreifenden Architektur, die mindestens sechs Einheiten oder drei Einheiten pro Region erfordert. Ein Multiregion-Setup fügt auch Betriebskosten für die Koordination sicherer Bereitstellungen, zuverlässiger Skalierung und Failoverkoordination mit Back-Ends hinzu.

  • Isolation. Das Isolieren von Arbeitslasten über Arbeitsbereiche oder API-Verwaltungsinstanzen hinweg erhöht die Betriebskomplexität, da die Verwaltung eines mehrinstanzenfähigen Systems, das über eine Computeisolation verfügt, umfasst.

Skalieren an Anforderungen

  • Wenn Sie sich automatisch skalieren, um die Nachfrage von gut verhaltenen Kunden zu erfüllen, werden diese Kosten bereits in Ihre Kostenmodelle eingegliedert. Diese Skalierungsfunktion ermöglicht es dem Dienst jedoch auch, den Datenverkehr von Belästigungen und böswilligem Datenverkehr zu verarbeiten.

  • Die Minderung von unerwünschtem Verkehr verursacht Kosten. Das Hinzufügen von Diensten wie einer Webanwendungsfirewall und DDoS-Schutz erhöht die Kosten. Die Skalierung Ihres Diensts zur Verarbeitung von Datenverkehr erhöht die Kosten aufgrund von hinzugefügten Einheiten. Das Festlegen von oberen Skalierungsgrenzwerten kann Ausgaben einschränken, kann aber zu Zuverlässigkeitsproblemen für legitime Benutzer führen, wenn böswilliger oder schädlicher Datenverkehr Ihre API überfordert.

Verbund- und verteilter Ansatz

Eine grundlegende Entscheidung in der API-Verwaltung besteht darin, arbeitsübergreifende Arbeitslasten innerhalb einer einzelnen API-Verwaltungsinstanz zu verlagern oder Workloads in mehreren Instanzen in einer vollständig autonomen Topologie zu isolieren.

API-Verwaltungsarbeitsbereiche ermöglichen einen effizienten Betrieb als mehrinstanzenfähige Colocation-Plattform für mehrere API-Teams. Die gestaffelten Preismodelle sind darauf ausgelegt, die Servicekosten auf alle Mandanten, die die Gateways nutzen, aufzuteilen. Wie jede Colocation-Plattform können Ausfälle oder Fehlkonfigurationen jedoch zu weit verbreiteten Auswirkungen auf nicht verwandte Workloads führen, die dieselbe Infrastruktur nutzen.

Ein vollständig verteiltes Modell, bei dem jedes Workloadteam seine eigenen Instanzen verwaltet, führt duplizierte Kosten und Redundanz in Routinevorgängen ein. Es bietet jedoch eine inhärente Strahlradiusminderung für Zuverlässigkeit, Sicherheit und leistungsbezogene Vorfälle.

Beispielarchitektur

Grundlegende Architektur, die die wichtigsten Empfehlungen veranschaulicht: API-Verwaltungs-Zielzonenarchitektur.

Nächste Schritte

Die API-Verwaltung wird häufig mit den folgenden Diensten kombiniert. Überprüfen Sie ihre Serviceleitfäden oder Produktdokumentationen, wenn Ihre Workload diese Dienste enthält.

Die folgenden Artikel veranschaulichen einige der in diesem Artikel erläuterten Empfehlungen.

  • Last updated on