スケーラブルなGraphQLソリューションのデプロイ
このリファレンス・アーキテクチャでは、ワークロードの要求を満たすために簡単にスケーリングできるGraphQLベースのソリューションをデプロイする方法を示します。
GraphQLは、API用のオープンソースのデータ問合せおよび操作言語であり、既存のデータを使用して問合せを実行するためのランタイムであり、必要な属性を明示的に定義するモバイル・アプリケーションなどの実装に最適なコンポーネントです。モバイル・アプリケーションのモバイル・ネットワーク・トラフィックを最小限に抑えるなど、関連するエンティティ間でデータをリクエストしてリクエストおよびレスポンス・フローを最適化するAPIを提供します。GraphQLは、様々なバックエンド・サービスをカバーする1つのスキーマを提供することで、バックエンド・ソリューションを実装する方法をAPIコンシューマから抽象化する効果的な手段も提供します。
アーキテクチャ
このアーキテクチャは、静的および動的APIコンテンツの様々なルートを定義します。この方法では、コンテンツ配信ネットワーク(CDN)を使用したり、ロード・バランサでコンテンツをロードして処理するバックエンド・サービス内で、複数のレイヤーにキャッシュ・オプションを構成することで、静的コンテンツへのアクセスを簡単に最適化できます。
バックエンド・サービスは、このアーキテクチャでマイクロサービスとともに実装されます。これらのサービスは、オープン・ソースのCMSオプションを介して、Oracle Content and ExperienceなどのCMSソリューションをデプロイすることもできます。コンテンツが静的であるため、セキュリティ・リスクはかなり低くなります。
APIコンテンツはAPIゲートウェイを介してルーティングされるため、APIリクエストを検証および管理できます(レート制限など)。トラフィックは、Oracle Kubernetes Engineロード・バランサ(クラスタへのイングレスのポイント)に送信され、GraphQLサーバーに転送されます。理想的には、マイクロサービスが静的コンテンツを提供するために使用される場合、GraphQLおよび静的コンテンツをサポートするサービスは、分離および制御を強化するために個別のネームスペースに保持されます。
この実装では、オープンソースのApollo GraphQLサーバーを採用して呼出しを受け取り、リゾルバおよびミューテータ・ロジックをホストするマイクロサービスを分離するために作業を分解します。個別のサービスを使用してデータ・モデル内に異なるサブドメインを実装することで、実装をより効率的にスケーリングできます。したがって、任意のインメモリー・キャッシングでソリューションをチューニングする方が簡単です。
次の図は、このリファレンス・アーキテクチャを示しています。
サービス例を含むアーキテクチャを実装するためのコードおよびドキュメントは、関連するGitHubリポジトリにあります(下のデプロイのトピックを参照)。APIルートは、各サブドメインにApollo GraphQLサーバーおよびPythonサービスを使用します。詳細は、提供されているGitHubドキュメントに含まれています。
- テナント
テナンシは、使用されているすべてのリージョンを対象とします。パフォーマンスと回復力を最大限に高めるために、世界中の複数の異なるリージョンでデプロイメントをレプリケートし、パブリックDNSルーティングを組み合せて、クライアントが最寄りのリージョンに移動してレイテンシを最小限に抑えます。これには、バックエンド・データをリージョン間でレプリケートする必要があります。
- リージョン
Oracle Cloud Infrastructureリージョンは、可用性ドメインと呼ばれる1つ以上のデータ・センターが含まれる、ローカライズされた地理的な領域です。リージョンは他のリージョンから独立しており、巨大な距離は(国全体または大陸にわたって)分離できます。
- コンパートメント
コンパートメントは、Oracle Cloud Infrastructureテナンシ内のリージョン間論理パーティションです。コンパートメントを使用して、Oracle Cloudでリソースを編成し、リソースへのアクセスを制御して、使用割当てを設定します。特定のコンパートメント内のリソースへのアクセスを制御するには、誰がリソースにアクセスできるか、どのアクションを実行できるかを指定するポリシーを定義します。このアーキテクチャのコンパートメント・コントロールを追加して、パブリック・アクセス・レイヤーとバックエンドを分離することで、セキュリティ・レイヤーへのダイレクト・パスを誤って作成するリスクを最小限に抑えることができます。
- 可用性ドメイン
可用性ドメインは、リージョン内の独立したスタンドアロン・データ・センターです。各アベイラビリティ・ドメインの物理リソースは、フォルト・トレランスを提供する他のアベイラビリティ・ドメインのリソースから分離されます。アベイラビリティ・ドメインは、電力や冷却装置などのインフラや、内部の可用性ドメイン・ネットワークを共有しません。そのため、1つの可用性ドメインでの障害が、リージョン内の他の可用性ドメインに影響しない可能性があります。このリファレンス・アーキテクチャでは、最大耐障害性を確保するために、Kubernetesワーカー・ノードがフォルト・ドメインと可用性ドメインの両方に分散されます。
- フォルト・ドメイン
フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。各アベイラビリティ・ドメインに3つのフォルト・ドメインがあり、電源とハードウェアが独立しています。複数のフォルト・ドメインにリソースを分散すると、アプリケーションは、フォルト・ドメイン内の物理サーバーの障害、システム・メンテナンスおよび電源障害を許容できます。
- 仮想クラウド・ネットワーク(VCN)とサブネット
VCNは、Oracle Cloud Infrastructureリージョンで設定する、カスタマイズ可能なソフトウェア定義のネットワークです。従来のデータ・センター・ネットワークと同様に、CNはネットワーク環境を完全に制御できます。VCNには、VCNの作成後に変更できる複数の重複しないCIDRブロックを含めることができます。VCNをサブネットにセグメント化して、そのスコープをリージョンまたは可用性ドメインに指定できます。各サブネットは、VCN内の他のサブネットと重複しない連続した範囲のアドレスで構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックにもプライベートにもできます。
- ロード・バランサ
Oracle Cloud Infrastructure Load Balancingサービスは、1つのエントリ・ポイントからバックエンド内の複数のサーバーへの自動トラフィック分散を提供します。このリファレンス・アーキテクチャでは、ロード・バランサには、動的データおよび静的コンテンツ(イメージ、Webページなど)のためにAPIゲートウェイに送信されるトラフィックを分離するルーティング・ポリシーが含まれます。これにより、Load BalancerのWebアプリケーション・アクセラレーション(WAA)機能を利用できます。
- セキュリティ・リスト
サブネットごとに、サブネットの内外で許可する必要があるトラフィックのソース、宛先およびタイプを指定するセキュリティ・ルールを作成できます。
- NATゲートウェイ
NATゲートウェイを使用すると、VCN内のプライベート・リソースは、着信インターネット接続にそれらのリソースを公開せずに、インターネット上のホストにアクセスできます。
- サービス・ゲートウェイ
サービス・ゲートウェイは、VCNからOracle Cloud Infrastructure Object Storageなどの他のサービスへのアクセスを提供します。The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.
- クラウド・ガード
Oracle Cloud Guardを使用して、Oracle Cloud Infrastructureのリソースのセキュリティを監視および保守できます。Cloud Guardでは、セキュリティの弱点についてリソースを調べたり、リスクのあるアクティビティについてオペレータとユーザーをモニターするために定義できるディテクタ・レシピを使用します。構成の誤りや安全でないアクティビティが検出された場合、クラウド・ガードは、定義できるレスポンダ・レシピに基づいて、修正アクションを推奨し、それらのアクションの実行を支援します。
- セキュリティ・ゾーン
セキュリティ・ゾーンは、データの暗号化やコンパートメント全体のネットワークへのパブリック・アクセスの防止などのポリシーを適用することで、Oracleのセキュリティのベスト・プラクティスを最初から確保します。セキュリティ・ゾーンは、同じ名前のコンパートメントに関連付けられ、コンパートメントとそのサブコンパートメントに適用されるセキュリティ・ゾーン・ポリシーまたはレシピが含まれます。セキュリティ・ゾーン・コンパートメントに標準コンパートメントを追加または移動することはできません。
- 自律型データベース
Oracle Cloud Infrastructureの自律型データベースは、トランザクション処理およびデータ・ウェアハウス・ワークロードに使用できる、完全に管理された事前構成済のデータベース環境です。ハードウェアの構成や管理、ソフトウェアのインストールを行う必要はありません。Oracle Cloud Infrastructureでは、データベースの作成や、データベースのバックアップ、パッチ適用、アップグレードおよびチューニングが処理されます。
- Container Engine for Kubernetes
Oracle Cloud Infrastructure Container Engine for Kubernetesは、完全に管理されたスケーラブルで可用性の高いサービスで、コンテナ化アプリケーションをクラウドにデプロイする際に使用できます。ユーザーは、アプリケーションが必要とするコンピュート・リソースを指定し、Container Engine for KubernetesがそれらをOracle Cloud Infrastructureの既存のテナンシにプロビジョニングします。Container Engine for Kubernetesは、Kubernetesを使用して、ホストのクラスタ間でコンテナ化されたアプリケーションのデプロイメント、スケーリングおよび管理を自動化します。Kubernetesクラスタでは、自己回復性と可用性を最大限に高めるために、異なるボールト・ゾーンおよび可用性ゾーンにノードが割り当てられます。Kubernetesクラスタは、マイクロサービスを管理および監視するIstioまたは別のサービス・メッシュ機能を使用することが理想的です。GraphQLサービスは独自のポッドに存在し、様々なリゾルバおよびミュータータが独自のマイクロサービスとしてKubernetesクラスタにデプロイされます。
- レジストリ
Oracle Cloud Infrastructure Registryは、開発から本番ワークフローを簡略化できる、Oracle管理のレジストリです。レジストリを使用すると、Dockerイメージなどの開発アーティファクトを簡単に格納、共有および管理できます。Oracle Cloud Infrastructureの高可用性とスケーラブルなアーキテクチャにより、アプリケーションを高い信頼性でデプロイし管理できます。
推奨事項
- VCN
VCNを作成する際、VCNのサブネットにアタッチする予定のリソース数に基づいて、必要なCIDRブロックの数および各ブロックのサイズを決定します。標準のプライベートIPアドレス領域内にあるCIDRブロックを使用します。
プライベート接続を設定する他のネットワーク(Oracle Cloud Infrastructure、オンプレミス・データ・センターまたは別のクラウド・プロバイダ)と重複しないCIDRブロックを選択します。
VCNを作成した後、そのCIDRブロックを変更、追加および削除できます。
サブネットを設計する際は、トラフィック・フローおよびセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを、セキュリティ境界として機能する同じサブネットにアタッチします。
- セキュリティ
Oracle Cloud Guardを使用して、Oracle Cloud Infrastructure内のリソースのセキュリティをプロアクティブに監視および保守します。Cloud Guardでは、セキュリティの弱点についてリソースを調べたり、リスクのあるアクティビティについてオペレータとユーザーをモニターするために定義できるディテクタ・レシピを使用します。構成の誤りや安全でないアクティビティが検出された場合、クラウド・ガードは、定義できるレスポンダ・レシピに基づいて、修正アクションを推奨し、それらのアクションの実行を支援します。最大限のセキュリティを必要とするリソースの場合、Oracleではセキュリティーゾーンを使用することをお勧めします。セキュリティ・ゾーンは、ベスト・プラクティスに基づくセキュリティ・ポリシーのOracle定義レシピに関連付けられたコンパートメントです。たとえば、セキュリティ・ゾーン内のリソースは、パブリック・インターネットからアクセスできず、顧客管理キーを使用して暗号化する必要があります。セキュリティ・ゾーンでリソースを作成および更新すると、Oracle Cloud Infrastructureはセキュリティ・ゾーン・レシピのポリシーに対して操作を検証し、いずれかのポリシーに違反する操作を拒否します。
- クラウド・ガード
Oracleが提供するデフォルトのレシピをクローニングおよびカスタマイズして、カスタム・ディテクタおよびレスポンダ・レシピを作成します。これらのレシピでは、警告を生成するセキュリティ違反のタイプと、それに対して実行できるアクションを指定できます。たとえば、可視性がpublicに設定されているオブジェクト・ストレージ・バケットを検出できます。クラウド・ガードをテナンシ・レベルで適用して、広範な範囲に対応し、複数の構成を維持する管理上の負担を軽減します。管理対象リスト機能を使用して、特定の構成をディテクタに適用することもできます。
- ネットワーク・セキュリティ・グループ(NSG)
NSGを使用して、特定のVNICに適用されるイングレスおよびエグレス・ルールのセットを定義できます。NSGではVCNのサブネット・アーキテクチャをアプリケーションのセキュリティ要件から分離できるため、セキュリティ・リストではなくNSGを使用することをお薦めします。
NSGを使用して、特定のVNICに適用されるイングレスおよびエグレス・ルールのセットを定義できます。NSGではVCNのサブネット・アーキテクチャをアプリケーションのセキュリティ要件から分離できるため、セキュリティ・リストではなくNSGを使用することをお薦めします。
- ロード・バランサの帯域幅
ロード・バランサの作成時に、固定帯域幅を提供する事前定義済のシェイプを選択するか、帯域幅範囲を設定してトラフィック・パターンに基づいて帯域幅を自動的にスケーリングするカスタム(フレキシブル)シェイプを指定できます。どちらの方法でも、ロード・バランサの作成後にいつでもシェイプを変更できます。
- APIゲートウェイ
APIゲートウェイを使用して、スクリーニングの初期レベルおよび次のような使用状況コントロールを提供できます。
- サービス認証と認可
- レート制限などのサービス制御
- サービス利用分析の取得
注意事項
この参照アーキテクチャをデプロイするときは、次の点を考慮してください。
- パフォーマンス
このアーキテクチャは、垂直方向と水平方向の両方のパフォーマンスのための容量を構築する手段を提供します。最適化されたマイクロサービスであっても、新しいノードを起動する遅延時間があるため、手動で、または動的にスケーリングを処理するときに許可する必要があります。これは、ソリューションの永続性レイヤーに特に当てはまります。
- セキュリティ
APIゲートウェイでアプリケーション・レベルのセキュリティに対処する必要があります。ただし、
@authなどのGraphQLディレクティブを使用して、GraphQL固有のファイングレイン・セキュリティ(属性レベルのアクセスなど)に対処できます。 - 可用性
- Kubernetes
フォルト・ドメインは、可用性ドメイン内の回復性を提供します。異なる可用性ゾーン間でデプロイするようにKubernetesワーカー・ノードを構成できます。
- APIゲートウェイ、ロード・バランサなど
APIゲートウェイなどの管理対象サービスの可用性は、リージョン内で処理されます。ロード・バランサを構成して、可用性ゾーン間の調整を保証できます。
- Kubernetes
- コスト
必要な可用性と回復力が大きいほど、運用コストが高くなります。これは、必要な冗長コンピュート・リソースの量が増えるためです。使用するGraphQLの実装と、どのようなライセンス制約が課せられるか、および実装がプロバイダによってサポートされるかどうかを検討します。