Hochskalierbare GraphQL-Lösung bereitstellen
Diese Referenzarchitektur demonstriert, wie Sie eine GraphQL-basierte Lösung bereitstellen können, die leicht skaliert werden kann, um Workload-Anforderungen zu erfüllen.
GraphQL, eine Open Source-Datenabfrage- und -manipulationssprache für APIs und eine Laufzeit zur Erfüllung von Abfragen mit vorhandenen Daten, ist eine ideale Komponente für solche Implementierungen wie mobile Anwendungen, die explizit erforderliche Attribute definieren. Er stellt APIs bereit, bei denen ein Client Daten über verwandte Entitäten hinweg anfordern möchte, um den Anforderungs- und Antwortablauf zu optimieren, z.B. den mobilen Netzwerkverkehr für mobile Anwendungen zu minimieren. GraphQL bietet auch ein effektives Mittel, um API-Consumer davon zu überzeugen, wie Backend-Lösungen implementiert werden können, indem ein einzelnes Schema bereitgestellt wird, das viele verschiedene Backend-Services abdecken kann.
Architektur
Diese Architektur definiert verschiedene Routen für statischen und dynamischen API-Inhalt. Diese Lösung erleichtert die Optimierung des Zugriffs auf den statischen Inhalt, indem Sie Caching-Optionen auf mehreren Ebenen konfigurieren, einschließlich Content Delivery Network (CDN) am Load Balancer und im Backend-Service, der den Inhalt lädt und bedient.
Backend-Services werden in dieser Architektur mit Microservices implementiert. Diese Services könnten auch eine CMS-Lösung wie Oracle Content and Experience über Open-Source-CMS-Optionen bereitstellen. Da der Inhalt statisch ist, sind die Sicherheitsrisiken erheblich geringer.
API-Inhalt wird über ein API-Gateway weitergeleitet, damit die API-Anforderungen validiert und gesteuert werden können (z.B. Ratenbegrenzung). Der Traffic wird dann an den Load Balancer der Oracle Kubernetes-Engine gesendet, den Ingress-Punkt im Cluster, der ihn an einen GraphQL-Server weiterleitet. Wenn Microservices verwendet werden, um den statischen Inhalt zu bedienen, werden die Services, die GraphQL unterstützen, und der statische Inhalt in separaten Namespaces gespeichert, um die Isolation und Kontrolle zu verbessern.
Diese Implementierung nimmt den Open-Source-Server Apollo GraphQL an, um die Aufrufe zu empfangen und die Arbeit zu zerlegen, um Microservices zu trennen, auf denen die Resolver- und Mutatorlogik gehostet wird. Sie können die Implementierung effizienter skalieren, indem Sie die verschiedenen Subdomains innerhalb des Datenmodells mit separaten Services implementieren. Daher ist es einfacher, die Lösung mit einem speicherresidenten Caching abzustimmen.
Das folgende Diagramm veranschaulicht diese Referenzarchitektur.
Beschreibung der Abbildung Deploy-hs-graphql.png
Der Code und die Dokumentation zur Implementierung der Architektur, einschließlich Beispielservices, finden Sie im relevanten GitHub-Repository (siehe das Thema "Bereitstellen" unten). Die API-Route verwendet für jede Subdomain einen Apollo GraphQL-Server und Python-Services. Weitere Informationen finden Sie in der GitHub-Dokumentation.
- Mandant
Ein Mandant deckt alle verwendeten Regionen ab. Für eine maximale Performance und Resilienz möchten Sie das Deployment in mehreren verschiedenen Regionen auf der ganzen Welt replizieren und das öffentliche DNS-Routing kombinieren, damit Clients in die nächste Region wechseln, um Latenz zu minimieren. Daher müssen Backend-Daten zwischen Regionen repliziert werden.
- Region
Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der ein oder mehrere Data Center enthält, die als Availability-Domains bezeichnet werden. Regionen sind nicht von anderen Regionen abhängig, und große Distanzen können sie trennen (über Länder oder sogar Kontinente).
- Compartment
Compartments sind regionsübergreifende logische Partitionen in einem Oracle Cloud Infrastructure-Mandanten. Mit Compartments können Sie Ihre Ressourcen in Oracle Cloud organisieren, den Zugriff auf die Ressourcen kontrollieren und Nutzungs-Quotas festlegen. Um den Zugriff auf die Ressourcen in einem bestimmten Compartment zu kontrollieren, definieren Sie Policys, mit denen angegeben wird, wer auf die Ressourcen zugreifen kann und welche Aktionen sie ausführen können. Compartment-Kontrollen für diese Architektur können hinzugefügt werden, um die öffentliche Zugriffsebene und das Backend zu trennen, um das Risiko zu minimieren, dass versehentlich direkte Pfade zur Sicherheitsschicht erstellt werden.
- Availability-Domains
Availability-Domains sind eigenständige, unabhängige Data Center innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was Fehlertoleranz bietet. Availability-Domains haben keine gemeinsamen Infrastrukturen wie Stromversorgung, Kühlung oder das interne Availability-Domainnetzwerk. Daher ist es unwahrscheinlich, dass ein Fehler in einer Availability-Domain die anderen Availability-Domains in der Region beeinflusst. In dieser Referenzarchitektur werden Kubernetes-Worker-Knoten über Faultdomains und Availability-Domains verteilt, um die maximale Resilienz sicherzustellen.
- Faultdomains
Eine Faultdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain umfasst drei Faultdomains mit unabhängiger Stromversorgung und Hardware. Wenn Sie Ressourcen über mehrere Faultdomains verteilen, können Ihre Anwendungen Fehler, Systemwartung und Stromausfälle innerhalb einer Faultdomain tolerieren.
- Virtuelles Cloud-Netzwerk (VCN) und Subnetze
Ein VCN ist ein anpassbares, Softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten können. Wie bei traditionellen Data Center-Netzwerken haben VCNs die vollständige Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain skalieren lassen. Jedes Subnetz besteht aus einem nachfolgenden Adressbereich, der sich nicht mit den anderen Subnetzen im VCN überschneidet. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.
- Load Balancer
Der Oracle Cloud Infrastructure Load Balancing-Service ermöglicht automatisierte Datenverkehrsverteilung von einem einzelnen Einstiegspunkt zu mehreren Servern im Backend. In dieser Referenzarchitektur enthält der Load Balancer Routing-Policys, die Traffic zum API-Gateway für dynamische Daten und den statischen Inhalt (z.B. Bilder, Webseiten usw.) trennen. Dadurch können die Web Application Acceleration-(WAA-)Funktionen des Load Balancers genutzt werden.
- Sicherheitsliste
Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Traffictyp angeben, die in das Subnetz ein- und ausgehen dürfen.
- NAT-Gateway
Das NAT-Gateway ermöglicht privaten Ressourcen in einem VCN den Zugriff auf Hosts im Internet, ohne diese Ressourcen für eingehende Internetverbindungen freizugeben.
- Servicegateway
Das Servicegateway ermöglicht den Zugriff von einem VCN auf andere Services, wie Oracle Cloud Infrastructure Object Storage. Der Traffic vom VCN zum Oracle-Service durchläuft die Oracle-Netzwerk-Fabric und nie das Internet.
- Cloud Guard
Mit Oracle Cloud Guard können Sie die Sicherheit Ihrer Ressourcen in Oracle Cloud Infrastructure überwachen und verwalten. Cloud Guard verwendet Detektorrezepte, die Sie definieren können, um Ihre Ressourcen auf Sicherheitsschwächen zu untersuchen und Operatoren und Benutzer auf riskante Aktivitäten zu überwachen. Wenn falsche oder unsichere Aktivitäten erkannt werden, empfiehlt Cloud Guard Korrekturmaßnahmen und hilft Ihnen, diese Aktionen basierend auf den verfügbaren Responder-Rezepten auszuführen.
- Sicherheitszone
Sicherheitszonen stellen die Best Practices der Oracle-Sicherheit von Anfang an sicher, indem Policys wie das Verschlüsseln von Daten und das Verhindern des öffentlichen Zugriffs auf Netzwerke für ein gesamtes Compartment durchgesetzt werden. Eine Sicherheitszone ist mit einem Compartment mit demselben Namen verknüpft und enthält Sicherheitszonen-Policys oder ein "Rezept", das für das Compartment und die zugehörigen Sub-Compartments gilt. Sie können ein Standard Compartment zu einem Sicherheitszonen-Compartment hinzufügen oder verschieben.
- Autonomous Database
Autonome Oracle Cloud Infrastructure-Datenbanken sind vollständig verwaltete, vorkonfigurierte Datenbankumgebungen, die Sie für Transaktionsverarbeitung und Data Warehousing-Workloads verwenden können. Sie müssen keine Hardware konfigurieren oder verwalten und keine Software installieren. Oracle Cloud Infrastructure verarbeitet das Erstellen der Datenbank sowie das Backup, Patching, Upgrade und Tuning der Datenbank.
- Container Engine for Kubernetes
Oracle Cloud Infrastructure Container Engine for Kubernetes ist ein vollständig verwalteten, skalierbaren und hochverfügbaren Service, mit dem Sie Ihre Containeranwendungen in der Cloud bereitstellen können. Sie geben die Compute-Ressourcen an, die Ihre Anwendungen benötigen, und Container Engine for Kubernetes stellt sie in einem vorhandenen Mandanten auf Oracle Cloud Infrastructure bereit. Container Engine for Kubernetes automatisiert mit Kubernetes das Deployment, die Skalierung und die Verwaltung containerisierter Anwendungen über Hostcluster hinweg. Dem Kubernetes-Cluster werden Knoten verschiedenen Vault-Zonen und Verfügbarkeitszonen zugewiesen, um die Resilienz und Verfügbarkeit zu maximieren. Das Kubernetes-Cluster verfügt idealerweise über Istio oder eine andere Service-Mesh-Funktion zum Verwalten und Überwachen der Microservices. Der GraphQL-Service ist in seinem eigenen Pod vorhanden. Die verschiedenen Resolver und Mutatoren werden als eigene Microservices im Kubernetes-Cluster bereitgestellt.
- Registrierung
Oracle Cloud Infrastructure Registry ist eine von Oracle verwaltete Registry, mit der Sie Ihren Workflow von der Entwicklung bis zur Produktion vereinfachen können. Die Registry erleichtert das Speichern, Freigeben und Verwalten von Entwicklungsartefakten wie Docker-Images. Die hoch verfügbare und skalierbare Architektur von Oracle Cloud Infrastructure stellt sicher, dass Sie Ihre Anwendungen zuverlässig bereitstellen und verwalten können.
Empfehlungen
- VCN
Wenn Sie ein VCN erstellen, bestimmen Sie die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen, die Sie an Subnetze im VCN anhängen möchten. Verwenden Sie CIDR-Blöcke, die sich im privaten Standardadressbereich befinden.
Wählen Sie CIDR-Blöcke aus, die sich nicht mit einem anderen Netzwerk (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider) überschneiden, für das Sie private Verbindungen einrichten möchten.
Nachdem Sie ein VCN erstellt haben, können Sie die zugehörigen CIDR-Blöcke ändern, hinzufügen und entfernen.
Berücksichtigen Sie bei der Entwicklung der Subnetze Ihren Trafficfluss und Ihre Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Tier oder Rolle an dasselbe Subnetz an, das als Sicherheitsgrenze dienen kann.
- Sicherheit
Mit Oracle Cloud Guard können Sie die Sicherheit Ihrer Ressourcen in Oracle Cloud Infrastructure proaktiv überwachen und verwalten. Cloud Guard verwendet Detektorrezepte, die Sie definieren können, um Ihre Ressourcen auf Sicherheitsschwächen zu untersuchen und Operatoren und Benutzer auf riskante Aktivitäten zu überwachen. Wenn falsche oder unsichere Aktivitäten erkannt werden, empfiehlt Cloud Guard Korrekturmaßnahmen und hilft Ihnen, diese Aktionen basierend auf den verfügbaren Responder-Rezepten auszuführen. Für Ressourcen, die maximale Sicherheit erfordern, empfiehlt Oracle, Sicherheitszonen zu verwenden. Eine Sicherheitszone ist ein Compartment, das mit einem von Oracle definierten Rezept der Sicherheits-Policys verknüpft ist, die auf Best Practices basieren. Beispiel: Die Ressourcen in einer Sicherheitszone dürfen nicht über das öffentliche Internet zugänglich sein und müssen mit vom Kunden verwalteten Schlüsseln verschlüsselt werden. Wenn Sie Ressourcen in einer Sicherheitszone erstellen und aktualisieren, validiert Oracle Cloud Infrastructure die Vorgänge anhand der Policys im Rezept der Sicherheitszone und lehnt Vorgänge ab, die eine der Policys verletzen.
- Cloud Guard
Klonen und passen Sie die von Oracle bereitgestellten Standardrezepte an, um benutzerdefinierte Detektor- und Responder-Rezepte zu erstellen. Mit diesen Rezepten können Sie angeben, welche Art von Sicherheitsverletzungen eine Warnung generieren und welche Aktionen für sie ausgeführt werden dürfen. Beispiel: Sie möchten Object Storage-Buckets ermitteln, deren Sichtbarkeit auf "Öffentlich" gesetzt ist. Wenden Sie Cloud Guard auf Mandantenebene an, um den weitesten Geltungsbereich abzudecken und den administrativen Aufwand bei der Verwaltung mehrerer Konfigurationen zu reduzieren. Sie können auch das Feature "Verwaltete Liste" verwenden, um bestimmte Konfigurationen auf Detektoren anzuwenden.
- Netzwerksicherheitsgruppen (NSGs)
Mit NSGs können Sie ein Set von Ingress- und Egress-Regeln definieren, die für bestimmte VNICs gelten. Es wird empfohlen, keine Sicherheitslisten sondern NSGs zu verwenden, da NSGs die Subnetzarchitektur des VCN von den Sicherheitsanforderungen Ihrer Anwendung trennen können.
Mit NSGs können Sie ein Set von Ingress- und Egress-Regeln definieren, die für bestimmte VNICs gelten. Es wird empfohlen, keine Sicherheitslisten sondern NSGs zu verwenden, da NSGs die Subnetzarchitektur des VCN von den Sicherheitsanforderungen Ihrer Anwendung trennen können.
- Load-Balancer- Bandbreite
Beim Erstellen des Load Balancers können Sie entweder eine vordefinierte Ausprägungen mit fester Bandbreite auswählen oder eine benutzerdefinierte (flexible) Ausprägungen angeben, bei der Sie einen Bandbreitenbereich festlegen und der Service die Bandbreite basierend auf Trafficmustern automatisch skalieren lässt. Bei beiden Lösungen können Sie die Ausprägungen nach dem Erstellen des Load Balancers jederzeit ändern.
- API Gateway
Mit dem API-Gateway können Sie eine erste Ebene von Screening und Nutzungskontrollen bereitstellen, wie z.B.:
- Serviceauthentifizierung und -autorisierung
- Servicekontrollen wie Ratenbegrenzung
- Erfassung von Analysen zur Servicenutzung
Hinweise
Beachten Sie beim Deployment dieser Referenzarchitektur die folgenden Punkte.
- Performance
Mit dieser Architektur können Sie die Performance sowohl vertikal als auch horizontal ausbauen. Selbst bei den optimiertesten Microservices gibt es Verzögerungen beim Aufbringen neuer Knoten. Dies muss also bei der manuellen oder dynamischen Skalierung zugelassen werden. Dies gilt insbesondere für die Persistenzschicht einer beliebigen Lösung.
- Sicherheit
Sie müssen die Sicherheit auf Anwendungsebene im API-Gateway adressieren. Sie können die feingranulierte GraphQL-spezifische Sicherheit (z.B. Zugriff auf Attributebene) jedoch mit GraphQL-Anweisungen wie
@authbeheben. - Verfügbarkeit
- Kubernetes
Faultdomains bieten Resilienz innerhalb einer Availability-Domain. Sie können Kubernetes-Worker-Knoten für das Deployment in verschiedenen Verfügbarkeitszonen konfigurieren.
- API-Gateway, Load Balancer usw.
Für verwaltete Services wie das API-Gateway wird die Verfügbarkeit in einer Region verarbeitet. Sie können Load Balancer konfigurieren, um die Koordination zwischen Verfügbarkeitszonen sicherzustellen.
- Kubernetes
- Kostenfaktor
Je mehr Verfügbarkeit und Resilienz erforderlich sind, desto höher sind die Betriebskosten. Der Grund dafür ist, dass das erforderliche Volumen redundanter Compute-Ressourcen wächst. Überlegen Sie, welche Implementierung von GraphQL Sie verwenden und welche Lizenzierungs-Constraints bestehen und ob die Implementierung vom Provider unterstützt wird.