このドキュメントは、一連の 3 つのドキュメントのうち 2 つ目です。一般的なハイブリッド クラウドとマルチクラウドのアーキテクチャ パターンについて説明します。また、これらのパターンが最も適しているシナリオについても説明します。最後に、このようなアーキテクチャを Google Cloud にデプロイする際に使用できるベスト プラクティスについて説明します。
ハイブリッド クラウドとマルチクラウドのアーキテクチャ パターンのドキュメント セットは、次の部分で構成されています。
- ハイブリッド クラウドとマルチクラウドのアーキテクチャを構築する: Google Cloud でハイブリッド クラウドとマルチクラウドの設定を設計するための戦略の計画について説明します。
- ハイブリッド クラウドとマルチクラウドのアーキテクチャ パターン: ハイブリッド クラウドとマルチクラウド戦略の一部として採用する一般的なアーキテクチャ パターンについて説明します（このドキュメント）。
- ハイブリッド クラウドとマルチクラウドの安全なネットワーキング アーキテクチャ パターン: ネットワーキングの観点から、ハイブリッド クラウドとマルチクラウドのネットワーキング アーキテクチャ パターンについて説明します。
ハイブリッドやマルチクラウドのアーキテクチャを設定するにあたり、要件および制約条件の元となるアプリケーション ワークロードは、企業ごとにそれぞれ異なります。これらの制約と要件を満たすようにアーキテクチャを設計し、調整する必要がありますが、いくつかの一般的なパターンを想定して、基盤となるアーキテクチャを定義できます。
アーキテクチャ パターンは、テクノロジー ソリューション、アプリケーション、またはサービスの複数の機能コンポーネントを構造化して、特定の要件またはユースケースに対応する再利用可能なソリューションを作成する反復可能な方法です。クラウドベースのテクノロジー ソリューションは、多くの場合、複数の個別の分散型クラウド サービスで構成されています。これらのサービスは、必要な機能を提供するために連携して機能します。このコンテキストでは、各サービスはテクノロジー ソリューションの機能コンポーネントとみなされます。同様に、アプリケーションは複数の機能レイヤ、モジュール、サービスで構成でき、それぞれがアプリケーション アーキテクチャの機能コンポーネントを表すことができます。このようなアーキテクチャは、特定のビジネス ユースケースに対応するように標準化でき、基盤となる再利用可能なパターンとして機能します。
アプリケーションまたはソリューションのアーキテクチャ パターンを一般的な内容で定義するには、以下の項目を特定して定義します。
- ソリューションまたはアプリケーションのコンポーネント。
- 各コンポーネントに期待される機能（グラフィカル ユーザー インターフェースを提供するフロントエンド関数や、データアクセスを提供するバックエンド関数など）。
- コンポーネントが相互に、および外部のシステムやユーザーと通信する方法。最新のアプリケーションでは、これらのコンポーネントは明確に定義されたインターフェースまたは API を介して相互作用します。通信モデルには、非同期、同期、リクエスト / レスポンス、キューベースなど、さまざまなものがあります。
ハイブリッド クラウドとマルチクラウドのアーキテクチャ パターンには、次の 2 つの主要なカテゴリがあります。
- 分散型アーキテクチャ パターン: これらのパターンは、ワークロードまたはアプリケーション コンポーネントの分散型デプロイに依存します。つまり、パターンに最適なコンピューティング環境でアプリケーション（または対象アプリケーションの特定のコンポーネント）を実行します。これにより、分散コンピューティング環境と相互接続コンピューティング環境のさまざまなプロパティや特性をパターンに対して活用できます。
- 冗長アーキテクチャ パターン: これらのパターンは、ワークロードの冗長デプロイに基づいています。これらのパターンでは、同じアプリケーションとそのコンポーネントを複数のコンピューティング環境にデプロイします。目標は、アプリケーションのパフォーマンス容量または復元力を高めるか、開発とテストのために既存の環境を複製することです。
選択したアーキテクチャ パターンを実装するときは、適切なデプロイ アーキタイプを使用する必要があります。デプロイ アーキタイプは、ゾーン、リージョン、マルチリージョン、グローバルのいずれかです。この選択は、アプリケーション固有のデプロイ アーキテクチャを構築する基盤となります。各デプロイ アーキタイプは、アプリケーションが動作できる障害発生ドメインの組み合わせを定義します。これらの障害発生ドメインには 1 つ以上の Google Cloud ゾーンまたはリージョンを含めることができます。また、オンプレミス データセンターや他のクラウド プロバイダの障害発生ドメインが含まれるように拡張することもできます。
このシリーズには次のページが含まれます。
冗長アーキテクチャ パターン
作成・変更者
著者: Marwan Al Shawi | パートナー カスタマー エンジニア
その他の寄稿者:
- Saud Albazei | アプリケーション モダナイゼーション担当カスタマー エンジニア
- Anna Berenberg | エンジニアリング フェロー
- Marco Ferrari | クラウド ソリューション アーキテクト
- Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング
- Johannes Passing | クラウド ソリューション アーキテクト
- Mark Schlagenhauf | テクニカル ライター、ネットワーキング
- Daniel Strebel | アプリケーション モダナイゼーション担当 EMEA ソリューション リード
- Ammett Williams | デベロッパー リレーションズ エンジニア
分散型アーキテクチャ パターン
ハイブリッド クラウドまたはマルチクラウド以外のコンピューティング環境からハイブリッド クラウドまたはマルチクラウド アーキテクチャに移行する場合は、まず既存のアプリケーションの制約と、それらの制約がアプリケーションの障害につながる可能性がある方法を検討します。この考慮事項は、アプリケーションまたはアプリケーション コンポーネントが複数の環境に分散して動作する場合に重要になります。制約を考慮したら、制約を回避または克服するための計画を立てます。分散アーキテクチャ内の各コンピューティング環境の独自の機能を考慮してください。
設計上の考慮事項
分散デプロイ パターンには、次の設計上の考慮事項が適用されます。ターゲット ソリューションとビジネス目標に応じて、各考慮事項の優先度と影響は異なります。
レイテンシ
アプリケーション コンポーネント（フロントエンド、バックエンド、マイクロサービス）を異なるコンピューティング環境に分散するアーキテクチャ パターンでは、通信レイテンシが発生する可能性があります。このレイテンシは、ハイブリッド ネットワーク接続（Cloud VPN と Cloud Interconnect）と、オンプレミス サイトとクラウド リージョン間、またはマルチクラウド設定のクラウド リージョン間の地理的な距離の影響を受けます。したがって、アプリケーションのレイテンシ要件とネットワーク遅延に対する感度を評価することが重要です。レイテンシに耐えられるアプリケーションは、ハイブリッド環境またはマルチクラウド環境での最初の分散デプロイに適しています。
一時的な状態と最終的な状態のアーキテクチャ
コスト、スケール、パフォーマンスに関する期待値と潜在的な影響を特定するには、計画段階で必要なアーキテクチャのタイプと想定される期間を分析することが重要です。たとえば、ハイブリッド アーキテクチャまたはマルチクラウド アーキテクチャを長期的または恒久的に使用する場合は、Cloud Interconnect の使用を検討してください。アウトバウンド データ転送の費用を削減し、ハイブリッド接続ネットワークのパフォーマンスを最適化するために、Cloud Interconnect は割引データ転送レートの条件を満たすアウトバウンド データ転送料金を割引します。
信頼性
IT システムを設計する際は、信頼性が重要な考慮事項です。稼働時間の可用性は、システムの信頼性の重要な要素です。Google Cloud では、スイッチオーバー機能を使用して、アプリケーションの冗長コンポーネントを単一リージョン内の複数のゾーンに、または複数のリージョンにデプロイすることで、アプリケーションの復元力を高めることができます。冗長性は、アプリケーションの全体的な可用性を向上させるための重要な要素の 1 つです。ハイブリッド環境とマルチクラウド環境に分散して設定されているアプリケーションでは、一貫したレベルの可用性を維持することが重要です。
オンプレミス環境や他のクラウド環境でシステムの可用性を高めるには、アプリケーションとそのコンポーネントに必要なハードウェアまたはソフトウェアの冗長性（フェイルオーバー メカニズムを含む）を検討してください。理想的には、すべての環境のさまざまなコンポーネントとサポート インフラストラクチャ（ハイブリッド接続の可用性を含む）で、サービスまたはアプリケーションの可用性を検討する必要があります。このコンセプトは、アプリケーションまたはサービスの複合可用性とも呼ばれます。
コンポーネントまたはサービス間の依存関係に基づいて、アプリケーションの複合可用性は、個々のサービスまたはコンポーネントの可用性よりも高くなったり低くなったりする可能性があります。詳細については、複合可用性: クラウド インフラストラクチャの全体的な可用性の計算をご覧ください。
必要なレベルのシステム信頼性を実現するには、明確な信頼性指標を定義し、さまざまな環境で自己修復し、中断に効果的に耐えられるようにアプリケーションを設計します。サービスのカスタマー エクスペリエンスを測定する適切な方法を定義するには、信頼性の目標を定義するをご覧ください。
ハイブリッド クラウドとマルチクラウドの接続性
分散アプリケーション コンポーネント間の通信の要件は、ハイブリッド ネットワーク接続オプションの選択に影響します。各接続オプションには、メリットとデメリットがあります。また、費用、トラフィック量、セキュリティなど、考慮すべき特定の要因もあります。詳細については、接続設計の考慮事項のセクションをご覧ください。
管理機能
一貫性のある統合された管理ツールとモニタリング ツールは、ハイブリッド クラウドとマルチクラウドの設定を成功させるために不可欠です（ワークロードのポータビリティの有無にかかわらず）。短期的には、これらのツールにより開発、テスト、運用の費用が増加する可能性があります。技術的には、使用するクラウド プロバイダが多いほど、環境の管理が複雑になります。ほとんどのパブリック クラウド ベンダーは、機能が異なるだけでなく、クラウド サービスを管理するためのツール、SLA、API も異なります。したがって、選択したアーキテクチャの戦略上のメリットと、短期的な複雑さと長期的なメリットを比較検討してください。
費用
マルチクラウド環境の各クラウド サービス プロバイダには、独自の課金指標とツールがあります。可視性と統合ダッシュボードを向上させるには、マルチクラウドのコスト管理と最適化ツールの使用を検討してください。たとえば、複数のクラウド環境にわたってクラウド ファースト ソリューションを構築する場合、各プロバイダのプロダクト、料金、割引、管理ツールによって、環境間で費用の不整合が生じる可能性があります。
クラウド リソースの費用を明確に定義された単一の方法で計算し、費用の可視性を確保することをおすすめします。費用の最適化には、費用の可視化が不可欠です。たとえば、使用しているクラウド プロバイダの請求データを組み合わせて、Google Cloud の Looker Cloud Cost Management Block を使用すると、マルチクラウドの費用を 1 か所で確認できます。このビューは、複数のクラウドにわたる費用の統合レポートビューを提供できます。詳細については、クラウド料金請求コスト管理を効果的に最適化するための戦略をご覧ください。
また、FinOps の実践を使用して費用を可視化することをおすすめします。強力な FinOps 実践の一環として、中核チームはリソース最適化の意思決定をプロジェクトに関与する他のチームに委任し、個々の責任を促進できます。このモデルでは、中核チームは費用最適化のプロセス、レポート、ツールを標準化する必要があります。費用の最適化のさまざまな側面と考慮すべき推奨事項の詳細については、Google Cloud アーキテクチャ フレームワーク: 費用の最適化をご覧ください。
データの移動
データの移動は、ハイブリッド クラウドとマルチクラウドの戦略とアーキテクチャの計画において重要な考慮事項です（特に分散システムの場合）。企業は、さまざまなビジネス ユースケース、それらを支えるデータ、データの分類方法（規制対象の業界の場合）を特定する必要があります。また、環境間で分散システムのデータ ストレージ、共有、アクセスがアプリケーションのパフォーマンスとデータの整合性にどのように影響するかも考慮する必要があります。これらの要因は、アプリケーションとデータ パイプラインのアーキテクチャに影響する可能性があります。Google Cloud の包括的なデータ移動オプションにより、企業は特定のニーズを満たし、シンプルさ、効率性、パフォーマンスを損なうことなく、ハイブリッド アーキテクチャとマルチクラウド アーキテクチャを採用できます。
セキュリティ
アプリケーションをクラウドに移行する場合は、一貫性、オブザーバビリティ、統合されたセキュリティの可視性など、クラウド ファーストのセキュリティ機能を検討することが重要です。各パブリック クラウド プロバイダには、独自のセキュリティ アプローチ、ベスト プラクティス、機能があります。標準の機能的なセキュリティ アーキテクチャを構築するには、これらの機能を分析して調整することが重要です。強力な IAM 制御、データ暗号化、脆弱性スキャン、業界規制への準拠も、クラウド セキュリティの重要な要素です。
移行戦略を計画する際は、前述の考慮事項を分析することをおすすめします。アプリケーションやトラフィックの量が増加しても、アーキテクチャに複雑さを導入する可能性を最小限に抑えることができます。また、ランディング ゾーンの設計と構築は、ほとんどの場合、クラウド環境にエンタープライズ ワークロードをデプロイするための前提条件です。ランディング ゾーンは、企業が複数の領域にわたってクラウド サービスをより安全にデプロイ、使用、スケーリングするのに役立ちます。ランディング ゾーンには、ID、リソース管理、セキュリティ、ネットワーキングなどのさまざまな要素が含まれています。詳細については、Google Cloud のランディング ゾーンの設計をご覧ください。
このシリーズの次のドキュメントでは、他の分散アーキテクチャ パターンについて説明します。
階層型ハイブリッド パターン
アプリケーションのアーキテクチャ コンポーネントは、フロントエンドまたはバックエンドのいずれかに分類できます。シナリオによっては、これらのコンポーネントをホストして、異なるコンピューティング環境で動作させることができます。階層型ハイブリッド アーキテクチャ パターンの一部として、コンピューティング環境はオンプレミスのプライベート コンピューティング環境と Google Cloud に配置されます。
フロントエンド アプリケーション コンポーネントは、エンドユーザーまたはデバイスに直接公開されます。そのため、フロントエンド アプリケーションでは、パフォーマンスが重視されることが多くなります。新しい機能や改善項目を開発するため、ソフトウェアの更新は頻繁に行われる可能性があります。フロントエンド アプリケーションは通常、データの保存と管理（ビジネス ロジックやユーザー入力処理が含まれる場合もあります）をバックエンド アプリケーションに依存するため、多くの場合にステートレスであるか、管理するデータの量が限られています。
アクセスしやすく使いやすいように、さまざまなフレームワークとテクノロジーを使用してフロントエンド アプリケーションを構築できます。フロントエンド アプリケーションを成功させるための主な要素には、アプリケーションのパフォーマンス、レスポンス速度、ブラウザの互換性などがあります。
バックエンド アプリケーション コンポーネントは通常、データの保存と管理に重点を置いています。一部のアーキテクチャでは、ビジネス ロジックがバックエンド コンポーネントに組み込まれる場合があります。バックエンド アプリケーションの新しいリリースの頻度は、フロントエンド アプリケーションよりも低くなる傾向にあります。バックエンド アプリケーションには、管理すべき次の課題があります。
- 大量のリクエストの処理
- 大量のデータの処理
- データの保護
- すべてのシステム レプリカでの現行データと更新データの維持
3 層アプリケーション アーキテクチャは、さまざまなアプリケーション コンポーネントを含む e コマース ウェブサイトなど、ビジネス ウェブ アプリケーションの構築に最も頻繁に使用される実装の一つです。このアーキテクチャには、次の階層が含まれています。各階層は独立して動作しますが、密接にリンクされており、すべてが連携して機能します。
- ウェブ フロントエンドとプレゼンテーション階層
- アプリケーション階層
- データアクセスまたはバックエンド階層
これらのレイヤをコンテナに配置すると、スケーリング要件などの技術的なニーズが分離され、段階的なアプローチで移行できるようになります。また、環境間で移植可能であり、自動管理を使用でき、Cloud Run や Google Kubernetes Engine（GKE）Enterprise エディションなどのクラウド マネージド プラットフォームでスケーリングできる、プラットフォームに依存しないクラウド サービスにデプロイすることもできます。さらに、Cloud SQL などの Google Cloud マネージド データベースは、データベース レイヤとしてバックエンドを提供する際に活用できます。
階層型ハイブリッド アーキテクチャ パターンでは、既存のフロントエンド アプリケーション コンポーネントをパブリック クラウドにデプロイすることに重点を置いています。このパターンでは、既存のバックエンド アプリケーション コンポーネントをプライベート コンピューティング環境に保持します。アプリケーションの規模と具体的な設計に応じて、フロントエンド アプリケーション コンポーネントをケースバイケースで移行できます。詳細については、Google Cloud への移行をご覧ください。
オンプレミス環境でホストされているバックエンド コンポーネントとフロントエンド コンポーネントを含む既存のアプリケーションがある場合は、現在のアーキテクチャの制限事項を検討してください。たとえば、アプリケーションがスケーリングされ、パフォーマンスと信頼性に対する要件が増加した場合は、アプリケーションの一部をリファクタリングするか、別のより最適なアーキテクチャに移行するべきであるかどうかを最初に評価する必要があります。階層型ハイブリッド アーキテクチャ パターンを使用すると、完全な移行を行う前に、アプリケーションの一部のワークロードとコンポーネントをクラウドに移行できます。また、このような移行に伴う費用、時間、リスクも考慮する必要があります。
次の図は、典型的な階層型ハイブリッド アーキテクチャを示しています。
上の図では、クライアント リクエストは Google Cloud でホストされているアプリケーション フロントエンドに送信されます。次に、アプリケーション フロントエンドは、アプリケーション バックエンドがホストされているオンプレミス環境にデータを返送します（API ゲートウェイを経由することが理想です）。
次の図のアーキテクチャ例に示すように、階層型ハイブリッド アーキテクチャ パターンを使用すると、Google Cloud インフラストラクチャとグローバル サービスを活用できます。アプリケーション フロントエンドには Google Cloud 経由でアクセスできます。また、自動スケーリングを使用して、インフラストラクチャを過剰にプロビジョニングすることなく、スケーリング需要に動的かつ効率的に応答することで、フロントエンドの弾力性を高めることもできます。Google Cloud でスケーラブルなウェブアプリを構築して実行するために使用できるアーキテクチャはいくつかあります。アーキテクチャによって、さまざまな要件に対するメリットとデメリットが異なります。
詳細については、YouTube で Google Cloud でスケーラブルなウェブアプリを実行する 3 つの方法をご覧ください。Google Cloud で e コマース プラットフォームをモダナイズするさまざまな方法について詳しくは、Google Cloud でデジタル コマース プラットフォームを構築する方法をご覧ください。
上の図では、アプリケーション フロントエンドは Google Cloud でホストされています。これにより、グローバルなロード バランシング、自動スケーリング、Google Cloud Armor による DDoS 保護を使用して、マルチリージョンでグローバルに最適化されたユーザー エクスペリエンスを提供できます。
時間の経過とともに、パブリック クラウドにデプロイされるアプリケーションの数が増え、バックエンド アプリケーション コンポーネントのパブリック クラウドへの移行が検討される状態に達する場合があります。大量のトラフィックを処理する必要がある場合は、クラウド マネージド サービスを利用すると、独自のインフラストラクチャを管理する際のエンジニアリング リソースを節約できます。制約や要件でバックエンド アプリケーション コンポーネントをオンプレミスでホストすることが義務付けられている場合を除き、このオプションを検討してください。たとえば、バックエンド データが規制による制限の対象である場合は、データをオンプレミスに保持する必要があると考えられます。ただし、適用可能でありコンプライアンスを遵守している場合は、匿名化の手法などの Sensitive Data Protection の機能を使用して、必要に応じてデータを移動できます。
階層型ハイブリッド アーキテクチャ パターンでは、一部のシナリオで Google Distributed Cloud を使用することもできます。Distributed Cloud を使用すると、Google が提供し Google Cloud データセンターと分離して管理する専用ハードウェアで Google Kubernetes Engine クラスタを実行できます。Distributed Cloud が現在の要件と将来の要件を満たすようにするには、従来のクラウドベースの GKE ゾーンと比較した場合の Distributed Cloud の制限事項を把握してください。
利点
最初にフロントエンド アプリケーションに焦点を当てることには、以下に示すものを含めいくつかのメリットがあります。
- フロントエンド コンポーネントは、バックエンド リソースに依存します。場合によっては、他のフロントエンド コンポーネントに依存することもあります。
- バックエンド コンポーネントはフロントエンド コンポーネントに依存しません。したがって、フロントエンド アプリケーションの分離と移行は、バックエンド アプリケーションの移行ほど複雑ではない傾向があります。
- 一方、フロントエンド アプリケーションは、ステートレスであるか、それ自身はデータを管理しない場合が多いため、バックエンドよりも移行が容易である傾向があります。
- フロントエンド コンポーネントは、ステートレス アーキテクチャを使用するように移行の一環として最適化できます。詳細については、YouTube で ステートフル ウェブアプリを Cloud Run に移植する方法をご覧ください。
既存または新規開発のフロントエンド アプリケーションをパブリック クラウドにデプロイすることには、いくつかのメリットがあります。
- 多くのフロントエンド アプリケーションは頻繁に変更されます。パブリック クラウドでこれらのアプリケーションを実行すると、継続的インテグレーション / 継続的デプロイ（CI / CD）プロセスの設定が簡略化されます。CI / CD を使用すると、効率的かつ自動的にアップデートを送信できます。詳細については、Google Cloud での CI / CD をご覧ください。
- トラフィック負荷が変動するパフォーマンス重視のフロントエンドでは、クラウドベースのデプロイで利用できるロード バランシング、マルチリージョン デプロイ、Cloud CDN キャッシュ、サーバーレス、自動スケーリング機能（理想的にはステートレス アーキテクチャを使用）による大きなメリットが得られます。
GKE などのクラウド管理プラットフォームを使用してコンテナでマイクロサービスを採用すると、マイクロサービスをフロントエンド コンポーネントに拡張するマイクロフロントエンドなどの最新のアーキテクチャを使用できます。
マイクロサービスの拡張は、同じアプリケーションで複数のチームがコラボレーションするフロントエンドに対して一般的に使用されます。このようなチーム構造では、反復的なアプローチと継続的なメンテナンスが必要です。マイクロフロントエンドの使用には次のような利点があります。
- 開発、テスト、デプロイ用の独立したマイクロサービス モジュールにできます。
- 個別の開発チームが適したテクノロジーとコードを選択できる分離を実現します。
- これにより、他のチームが管理している可能性がある他のフロントエンド コンポーネントに影響を与えることなく、開発とデプロイの迅速なサイクルを促進できます。
ユーザー インターフェースや API を実装している、またはモノのインターネット（IoT）データの取り込みを処理している場合でも、フロントエンド アプリケーションでは、Firebase、Pub/Sub、Apigee、Cloud CDN、App Engine、Cloud Run などのクラウド サービスの機能を活用できます。
Cloud マネージド API プロキシは、次の目的に役立ちます。
- アプリ側の API をバックエンド サービス（マイクロサービスなど）から分離します。
- バックエンド コードの変更からアプリを保護します。
- バックエンド フォー フロントエンド（BFF）、マイクロフロントエンドなど、既存の API ドリブンのフロントエンド アーキテクチャをサポートします。
- Apigee で API プロキシを実装して、Google Cloud などの環境で API を公開します。
プライベート コンピューティング環境でフロントエンド アプリケーションを維持しながら、クラウドでバックエンドをデプロイすることによって、階層型ハイブリッド パターンを逆方向に適用することもできます。あまり一般的ではありませんが、このアプローチは、大規模でモノリシックなフロントエンド アプリケーションを扱う場合に適しています。そのような場合は、バックエンド機能の抽出を繰り返しながら、クラウドで新しいバックエンドをデプロイするほうが簡易であることが考えられます。
このシリーズの第 3 部では、このようなアーキテクチャを実現するために考えられるネットワーキング パターンについて説明します。Apigee ハイブリッドは、ハイブリッド デプロイモデルで API プロキシを構築して管理するためのプラットフォームとし活用できます。詳細については、階層型モノリシック アーキテクチャとマイクロサービス アーキテクチャを含む疎結合アーキテクチャをご覧ください。
ベスト プラクティス
階層型ハイブリッド アーキテクチャを計画する際には、このセクションの情報を使用してください。
複雑さを軽減するためのベスト プラクティス
階層型ハイブリッド アーキテクチャ パターンを適用する際は、全体的なデプロイと運用の複雑さを軽減できる次のベスト プラクティスを検討してください。
- 特定されたアプリケーションの通信モデルの評価に基づいて、それらのアプリケーションに最も効率的で効果的な通信ソリューションを選択します。
ユーザーの操作のほとんどが複数のコンピューティング環境をまたがるシステムに関係しているため、システム間の高速かつ低レイテンシの接続が重要になります。可用性とパフォーマンスの要件を満たすには、高可用性、低レイテンシ、適切なスループット レベルを実現するように設計する必要があります。セキュリティの観点から、通信は詳細に制御する必要があります。理想的には、安全な API を使用してアプリケーション コンポーネントを公開する必要があります。詳細については、下り（外向き）ゲート型をご覧ください。
- 環境間の通信レイテンシを最小限に抑えるには、アプリケーション バックエンド コンポーネントがホストされているプライベート コンピューティング環境に地理的に近い Google Cloud リージョンを選択します。詳細については、Compute Engine のリージョン選択に関するベスト プラクティスをご覧ください。
- 異なる環境で動作するシステム間の高い依存性を最小限に抑えます（特に、通信が同期的に処理されている場合）。こうした依存関係は、パフォーマンスの低下、全体的な可用性の低下、アウトバウンド データ転送の追加料金が発生する原因となる可能性があります。
- 階層型ハイブリッド アーキテクチャ パターンでは、Google Cloud からのアウトバウンド トラフィック量よりも、オンプレミス環境から Google Cloud へのインバウンド トラフィック量が多い場合があります。ただし、Google Cloud から送信されるアウトバウンド データ転送の予測量を把握しておく必要があります。アウトバウンド データ転送量が多い状態でこのアーキテクチャを長期的に使用する場合は、Cloud Interconnect の使用を検討してください。Cloud Interconnect を使用すると、接続パフォーマンスを最適化し、特定の条件を満たすトラフィックのアウトバウンド データ転送料金を削減できます。詳しくは、Cloud Interconnect の料金をご覧ください。
- 機密情報を保護するため、転送中のすべての通信を暗号化することをおすすめします。接続レイヤで暗号化が必要な場合は、VPN トンネル、Cloud Interconnect を介した HA VPN、Cloud Interconnect の MACsec を使用できます。
さまざまなバックエンド間でプロトコル、API、認証メカニズムの不整合を解消するには、必要に応じて、統合ファサードとして API ゲートウェイまたはプロキシをデプロイすることをおすすめします。このゲートウェイまたはプロキシは、一元化された制御ポイントとして機能し、次の対策を行います。
- 追加のセキュリティ対策を実装します。
- クライアント アプリやその他のサービスをバックエンド コードの変更から保護します。
- すべてのクロス環境アプリとその分離されたコンポーネント間の通信の監査証跡を容易にします。
- レガシー サービスと最新のサービス間の中間通信レイヤとして機能します。
- Apigee と Apigee ハイブリッドを使用すると、オンプレミス環境、エッジ、他のクラウド、Google Cloud 環境にわたってエンタープライズ クラスのハイブリッド ゲートウェイをホストして管理できます。
ハイブリッド設定の確立を容易にするには、ハイブリッド接続で Cloud Load Balancing を使用します。つまり、クラウドのロード バランシングによるメリットの対象を、オンプレミス コンピューティング環境でホストされているサービスに拡張できます。このアプローチでは、サービスを中断することなく、または中断を最小限に抑えながら、Google Cloud へのワークロードの段階的な移行が可能になり、分散サービスのスムーズな移行が実現します。詳細については、ハイブリッド接続ネットワーク エンドポイント グループの概要をご覧ください。
API ゲートウェイ、またはプロキシとアプリケーション ロードバランサを組み合わせて使用すると、API トラフィックの大規模な管理、保護、分散を行うための、より堅牢なソリューションを実現できます。API ゲートウェイで Cloud Load Balancing を使用すると、次のことができます。
- Apigee と Cloud CDN を使用して高パフォーマンスの API を提供することでレイテンシを短縮し、API をグローバルにホストして、トラフィックのピーク時の可用性を高めます。詳細については、YouTube で Apigee と Cloud CDN を使用した高パフォーマンスの API の提供をご覧ください。
- 高度なトラフィック管理を実装します。
- Google Cloud Armor を DDoS 保護サービスとネットワーク セキュリティ サービスとして使用し、API を保護します。
- 複数のリージョンにあるゲートウェイ間の効率的なロード バランシングを管理します。詳細については、YouTube で Private Service Connect と Apigee による API の保護とマルチリージョン フェイルオーバーの実装をご覧ください。
API 管理とサービス メッシュを使用して、マイクロサービス アーキテクチャでサービスの通信と公開を保護して制御します。
- Cloud Service Mesh を使用すると、分散サービスで構成されたシステムでサービスの品質を維持するサービス間通信が可能になり、サービス間の認証、認可、暗号化を管理できます。
- Apigee などの API 管理プラットフォームを使用して、組織と外部エンティティが API として公開することで、これらのサービスを使用できるようにします。
システムが環境の境界を越えて安全に認証できるように、環境間に共通の ID を確立します。
CI / CD システムと構成管理システムをパブリック クラウドにデプロイします。詳細については、ミラーリングされたネットワーキング アーキテクチャ パターンをご覧ください。
運用効率を高めるために、環境間で一貫したツールと CI / CD パイプラインを使用します。
個別のワークロードとアプリケーション アーキテクチャのベスト プラクティス
- このパターンでは、フロントエンドに重点を置いていますが、バックエンド アプリケーションをモダナイズする必要性にも注意してください。バックエンド アプリケーションの開発ペースがフロントエンド アプリケーションの開発ペースより大幅に遅い場合、その差は複雑さを増加させる要因となる可能性があります。
- API をバックエンド インターフェースとして扱うことで、インテグレーション、フロントエンド開発、サービス インタラクションを効率化し、バックエンド システムの複雑さを隠すことができます。これらの課題に対処するため、Apigee は、ハイブリッド クラウドとマルチクラウドのデプロイに関する API ゲートウェイ / プロキシの開発と管理を容易にします。
- コンテンツ（静的か動的か）、検索エンジン最適化のパフォーマンス、ページ読み込み速度に関する期待値に基づいて、フロントエンド ウェブ アプリケーションのレンダリング アプローチを選択します。
- コンテンツ ドリブン ウェブ アプリケーションのアーキテクチャを選択する場合は、モノリシック、サーバーレス、イベントベース、マイクロサービスのアーキテクチャなどのさまざまなオプションがあります。最適なアーキテクチャを選択するには、現在のアプリケーション要件と将来のアプリケーション要件を踏まえて、これらのオプションを徹底的に評価します。ビジネスと技術の目標に沿ったアーキテクチャの決定を行うには、コンテンツ ドリブンのウェブ アプリケーション バックエンドのさまざまなアーキテクチャの比較とウェブ バックエンドの主な考慮事項をご覧ください。
マイクロサービス アーキテクチャでは、Kubernetes を共通のランタイム レイヤとして使用して、コンテナ化されたアプリケーションを使用できます。階層型ハイブリッド アーキテクチャ パターンでは、次のいずれかのシナリオで実行できます。
両方の環境（Google Cloud 環境とオンプレミス環境）にわたって。
- 環境全体でコンテナと Kubernetes を使用すると、ワークロードをモダナイズしてから Google Cloud に移行するタイミングを柔軟に選択できます。これは、ワークロードが別のワークロードに大きく依存しているために個別に移行できない場合や、ハイブリッド ワークロードのポータビリティを使用して各環境で利用可能な最適なリソースを使用する場合に有効です。いずれの場合も、GKE Enterprise は重要な実現技術になります。詳細については、GKE Enterprise ハイブリッド環境をご覧ください。
移行して最新化したアプリケーション コンポーネントの Google Cloud 環境。
- このアプローチは、コンテナ化のサポートがないレガシー バックエンドがオンプレミスにある場合や、短期間でモダナイズするために大量の時間とリソースを必要とする場合に使用します。
モノリシック アプリをマイクロサービス アーキテクチャに設計してリファクタリングし、ウェブ アプリケーション アーキテクチャをモダナイズする場合について詳しくは、マイクロサービスの概要をご覧ください。
ウェブ アプリケーションのニーズに応じて、データ ストレージ テクノロジーを組み合わせることができます。構造化データに Cloud SQL を使用し、メディア ファイルに Cloud Storage を使用することは、さまざまなデータ ストレージのニーズに対応するための一般的な方法です。ただし、選択はユースケースに大きく依存します。コンテンツ ドリブン アプリケーションのバックエンドと効果的なモダリティのデータ ストレージ オプションの詳細については、コンテンツ ドリブン ウェブアプリのデータ ストレージ オプションをご覧ください。Google Cloud のデータベース オプションについての説明もご覧ください。
分割されたマルチクラウド パターン
パーティション分割されたマルチクラウド アーキテクチャ パターンは、異なるクラウド サービス プロバイダによって運用される複数のパブリック クラウド環境を組み合わたものです。このアーキテクチャでは、このシリーズの最初のパートで説明したマルチクラウドの推進要因と考慮事項を考慮して、最適なコンピューティング環境にアプリケーションを柔軟にデプロイできます。
次の図は、パーティション分割されたマルチクラウド アーキテクチャ パターンを示しています。
このアーキテクチャ パターンは、次の異なる 2 つの方法で構築できます。最初のアプローチは、アプリケーション コンポーネントをさまざまなパブリック クラウド環境にデプロイすることに基づいています。このアプローチは、コンポジット アーキテクチャとも呼ばれ、階層型ハイブリッド アーキテクチャ パターンと同じアプローチです。ただし、パブリック クラウドでオンプレミス環境を使用する代わりに、少なくとも 2 つのクラウド環境を使用します。複合アーキテクチャでは、単一のワークロードまたはアプリケーションが複数のクラウドのコンポーネントを使用します。2 つ目のアプローチでは、異なるパブリック クラウド環境に異なるアプリケーションをデプロイします。次のリストは、2 番目のアプローチにおけるビジネスの推進要因の一部を示したものであり、すべてを網羅したものではありません。
- 2 つの企業間の合併や買収のシナリオで、異なるクラウド環境でホストされているアプリケーションを完全に統合するため。
- 組織内の柔軟性を促進し、多様なクラウドのニーズに対応するため。このアプローチを採用すると、組織部門が特定のニーズと設定に最適なクラウド プロバイダを選択できます。
- マルチリージョンまたはグローバル クラウドのデプロイで運用するため。特定のリージョンまたは国のデータ所在地に関する規制を遵守する必要がある企業は、プライマリ クラウド プロバイダが対象のリージョンにクラウド リージョンを保持していない場合は、ロケーションで利用可能なクラウド プロバイダから選択する必要があります。
パーティション分割されたマルチクラウド アーキテクチャ パターンでは、必要に応じて、あるパブリック クラウド環境から別のパブリック クラウド環境にワークロードをシフトする機能を維持できます。その場合は、ワークロードのポータビリティが重要な要件になります。ワークロードを複数のコンピューティング環境にデプロイしつつ、環境間でワークロードを移動する機能を維持する必要がある場合は、環境間の差異を抽象化する必要があります。GKE Enterprise を使用すると、一貫したガバナンス、運用、セキュリティ ポスチャーでマルチクラウドの複雑さを解決するソリューションを設計して構築できます。詳細については、GKE Multi-Cloud をご覧ください。
前述のように、Google Cloud と別のクラウド プロバイダを組み合わせ、それらのクラウド環境間でワークロードをパーティション分割することに合理的な理由が存在する場合があります。マルチクラウド ソリューションを使用すると、マルチクラウド環境全体で移行、構築、アプリケーションのポータビリティの最適化を柔軟に行うことができます。また、ロックインを最小限に抑え、規制要件を満たすことができます。たとえば、Google Cloud と Oracle Cloud Infrastructure（OCI）を接続して、プライベート Cloud Interconnect を使用し各プラットフォームの機能を活用するマルチクラウド ソリューションを構築することで、OCI で実行されているコンポーネントと Google Cloud で実行されているリソースを組み合わせることができます。詳細については、Google Cloud と Oracle Cloud Infrastructure - マルチクラウドを最大限に活用するをご覧ください。さらに、Cross-Cloud Interconnect を使用すると、Google Cloud と他のサポートされているクラウド サービス プロバイダ間で高帯域幅の専用接続を確立できます。これにより、クラウド間のトラフィック量の増加に対応するマルチクラウド ソリューションを設計して構築できます。
利点
マルチクラウド アーキテクチャを使用すると、推進要因、考慮事項、戦略、アプローチで説明しているようにビジネスと技術の両面でメリットが得られますが、各メリットの実現可能性を詳細に評価することが不可欠です。評価では、直接的または間接的な課題や潜在的な障害、それらを効果的に回避できることについて慎重に検討する必要があります。また、アプリケーションやサービスの長期的な成長により、初期のメリットを上回る複雑さが生じる可能性があることも考慮してください。
パーティション分割されたマルチクラウド アーキテクチャ パターンの主なメリットは次のとおりです。
単一のクラウド プロバイダの確約利用を最小限に抑える必要があるシナリオでは、複数のクラウド プロバイダにアプリケーションを分散できます。その結果、クラウド プロバイダ間でプランを（ある程度）変更できるため、ベンダー ロックインを比較的軽減できます。Open Cloud は、GKE Enterprise などの Google Cloud の機能をさまざまな物理的な場所に提供します。Google Cloud の機能をオンプレミス、複数のパブリック クラウド、エッジに拡張することで、柔軟性とアジリティを実現し、変革を推進します。
規制上の理由から、Google Cloud のクラウド リージョンが存在しない国のユーザーベースとデータの特定のセグメントにサービスを提供できます。
パーティション分割されたマルチクラウド アーキテクチャ パターンによって、プライマリ クラウド プロバイダがクラウド リージョンまたはポイント オブ プレゼンスを保持しないロケーションで、レイテンシを短縮し、ユーザー エクスペリエンスの全体的な品質を改善できます。このパターンは、分散 CDN で Cross-Cloud Interconnect や CDN Interconnect などの大容量で低レイテンシのマルチクラウド接続を使用する場合に特に有効です。
複数のクラウド プロバイダにアプリケーションをデプロイし、他のクラウド プロバイダが提供する最適なサービスの中から選択できるようにします。
パーティシン分割されたマルチクラウド アーキテクチャ パターンは、2 つの企業のアプリケーションとサービスが異なるパブリック クラウド環境でホストされる合併と買収のシナリオを容易にし、加速させることができます。
ベスト プラクティス
- まず、ミッション クリティカルでないワークロードをデプロイします。セカンダリ クラウドでのこの最初のデプロイは、将来のデプロイや移行のパターンとして使用できます。ただし、特定のワークロードを特定のクラウド リージョンに配置することが法律または規制で義務付けられている場合、およびプライマリ クラウド プロバイダが必要な国または地域にリージョンを保持していない場合、このアプローチは適用できない可能性があります。
- 特に通信が同期的に処理されている場合、さまざまなパブリック クラウド環境で動作しているシステム間の依存関係を最小限に抑えます。こうした依存関係は、パフォーマンスの低下、全体的な可用性の低下、アウトバウンド データ転送の追加料金が発生する原因となる可能性があります。
- 環境の違いを抽象化するには、アプリケーションでサポートされており、実行可能な場合は、コンテナと Kubernetes の使用を検討してください。
- CI / CD パイプライン、および、デプロイとモニタリングに使用するツールについては、クラウド環境間で一貫性を保つようにします。
- 使用しているアプリケーションに最も効率的で効果的な通信ソリューションを提供する最適なネットワーク アーキテクチャ パターンを選択します。
- 通信は詳細に制御する必要があります。安全な API を使用して、アプリケーション コンポーネントを公開します。
- 特定のビジネス要件と技術要件に基づいて、メッシュ化されたアーキテクチャ パターンまたはゲート型ネットワーキング パターンのいずれかを使用することを検討してください。
- 可用性とパフォーマンスの期待値を満たすには、エンドツーエンドの高可用性（HA）、低レイテンシ、適切なスループット レベルを実現するように設計します。
機密情報を保護するため、転送中のすべての通信を暗号化することをおすすめします。
- 接続レイヤで暗号化が必要な場合は、選択したハイブリッド接続ソリューションに基づいてさまざまなオプションを使用できます。これらのオプションには、VPN トンネル、Cloud Interconnect を介した HA VPN、Cross-Cloud Interconnect の MACsec などがあります。
マルチクラウドのパーティション分割されたアーキテクチャ パターンの一部として複数の CDN を使用しており、Google Cloud から大量のデータファイルを他の CDN に送信している場合は、Google Cloud とサポートされているプロバイダ間の CDN Interconnect リンクを使用して、このトラフィックと可能な場合はコストを最適化することを検討してください。
システムが環境境界を越えて安全に認証できるように、環境間でID 管理ソリューションを拡張します。
Google Cloud と別のクラウド プラットフォーム間でリクエストを効果的に分散するには、Cloud Load Balancing を使用します。詳細については、オンプレミスの場所または別のクラウドにトラフィックを転送するをご覧ください。
- Google Cloud から他の環境へのアウトバウンド データ転送量が多い場合は、Cross-Cloud Interconnect の使用を検討してください。
さまざまなバックエンド間でプロトコル、API、認証メカニズムの不整合を解消するには、必要に応じて、統合ファサードとして API ゲートウェイまたはプロキシをデプロイすることをおすすめします。このゲートウェイまたはプロキシは、一元化された制御ポイントとして機能し、次の対策を行います。
- 追加のセキュリティ対策を実装します。
- クライアント アプリやその他のサービスをバックエンド コードの変更から保護します。
- すべてのクロス環境アプリとその分離されたコンポーネント間の通信の監査証跡を容易にします。
- レガシー サービスと最新のサービス間の中間通信レイヤとして機能します。
- Apigee と Apigee ハイブリッドを使用すると、オンプレミス環境、エッジ、他のクラウド、Google Cloud 環境にわたってエンタープライズ クラスのハイブリッド ゲートウェイをホストして管理できます。
次のケースの一部では、API ゲートウェイを使用した Cloud Load Balancing によって、複数のリージョン間で API トラフィックを管理、保護、分散するための堅牢で安全なソリューションを実現できます。
- 異なるリージョンでの Apigee API ランタイムに対するマルチリージョン フェイルオーバーのデプロイ。
Cloud CDN によるパフォーマンスの向上。
Google Cloud Armor を介した WAF と DDoS 保護の実施。
可能であれば、クラウド環境全体のロギングとモニタリングに一貫したツールを使用します。オープンソースのモニタリング システムの使用を検討してください。詳細については、ハイブリッド クラウドとマルチクラウドのモニタリングおよびロギング パターンをご覧ください。
単一のアプリケーションのコンポーネントを複数のクラウド環境にデプロイする分散方式でアプリケーション コンポーネントをデプロイする場合は、階層型ハイブリッド アーキテクチャ パターンのベスト プラクティスをご覧ください。
分析のハイブリッド クラウドとマルチクラウドのパターン
このドキュメントでは、分析のハイブリッドとマルチクラウドのパターンの目的が、トランザクション ワークロードと分析ワークロードの分割の活用であることを説明します。
企業向けシステムでは、ほとんどのワークロードが次のカテゴリに分類されます。
- トランザクション ワークロードには、営業、財務処理、エンタープライズ リソース プランニング、通信などのインタラクティブ型アプリケーションが含まれます。
- 分析ワークロードには、意思決定プロセス支援のためのデータの変換、分析、改良、可視化を行うアプリケーションが含まれます。
分析システムは、API のクエリまたはデータベースへのアクセスによってトランザクション システムからデータを取得します。ほとんどの企業では、分析システムとトランザクション システムが分離され、疎結合されてしまう傾向があります。分析のハイブリッドとマルチクラウドのパターンの目的は、2 つの異なるコンピューティング環境でトランザクション ワークロードと分析ワークロードを実行することにより、既存の分割を活用することです。元データは、プライベート コンピューティング環境で実行されるワークロードから最初に抽出され、Google Cloud に読み込まれ分析処理に使用されます。その結果の一部は、トランザクション システムにフィードバックされる可能性があります。
次の図は、考えられるデータ パイプラインを示して、概念的に可能なアーキテクチャを示しています。各パス / 矢印は、利用可能なデータ品質と対象のユースケースに応じて、ETL または ELT ベースで可能なデータ移動と変換パイプライン オプションを表します。
データを Google Cloud に移動して価値を引き出すには、データの取り込み、統合、レプリケーションを包括的に行うデータ移動サービスを使用します。
上の図に示すように、Google Cloud をオンプレミス環境や他のクラウド環境に接続すると、データ ストリーミングやデータベースのバックアップなど、さまざまなデータ分析のユースケースを実現できます。大量のデータ転送を必要とするハイブリッド分析パターンとマルチクラウド分析パターンの基盤となるトランスポートを強化するため、Cloud Interconnect と Cross-Cloud Interconnect は、オンプレミスと他のクラウド プロバイダへの専用接続を提供します。
利点
クラウド内で分析ワークロードを実行することには、いくつかの重要なメリットがあります。
- インバウンド トラフィック（プライベート コンピューティング環境または他のクラウドから Google Cloud へのデータ移動）は追加料金なしで利用できる場合があります。
- 分析ワークロードは、しばしば大量のデータを処理する必要があり、爆発的になる可能性があるため、パブリック クラウド環境でのデプロイに特に適しています。コンピューティング リソースを動的にスケーリングすることにより、大規模なデータセットを迅速に処理し、事前投資を回避でき、コンピューティング機器を過剰にプロビジョニングする必要がなくなります。
- Google Cloud は、最初のデータ取得から、処理、分析、最終的な可視化まで、データのライフサイクル全体を通じてデータを管理する豊富なサービスを提供します。
- Google Cloud のデータ移動サービスは、さまざまな方法でデータをシームレスに移動、統合、変換するための完全なプロダクト スイートを提供します。
- Cloud Storage はデータレイクの構築に適しています。
Google Cloud は、データ プラットフォームをモダナイズして最適化し、データサイロを解消するのに役立ちます。データ レイクハウスを使用すると、さまざまなストレージ形式を標準化できます。また、データが非効率性ではなくビジネスに価値をもたらすようにするために必要な柔軟性、スケーラビリティ、アジリティも提供できます。詳細については、BigLake をご覧ください。
BigQuery Omni は、AWS または Azure のストレージに対してローカルで実行されるコンピューティング能力を提供します。また、Amazon Simple Storage Service（Amazon S3）または Azure Blob Storage に保存されている独自のデータをクエリすることもできます。このマルチクラウド分析機能により、データチームはデータサイロを解消できます。BigQuery の外部に保存されているデータのクエリの詳細については、外部データソースの概要をご覧ください。
ベスト プラクティス
分析のハイブリッド クラウドとマルチクラウドのアーキテクチャ パターンを実装するには、次の一般的なベスト プラクティスを検討してください。
- ハンドオーバー型のネットワーキング パターンを使用して、データの取り込みを有効にします。分析結果をトランザクション システムにフィードバックする必要がある場合は、ハンドオーバー型と下り（外向き）ゲート型のパターンの両方を組み合わせることができます。
- Pub/Sub のキューまたは Cloud Storage のバケットを使用して、プライベート コンピューティング環境で実行しているトランザクション システムから Google Cloud にデータを渡すことができます。これらのキューまたはバケットは、データ処理パイプラインおよびワークロードの送信元として機能します。
- ETL と ELT のデータ パイプラインをデプロイするには、特定のユースケースの要件に応じて Cloud Data Fusion または Dataflow の使用を検討してください。どちらも、データ パイプラインの構築と管理のためのフルマネージドのクラウド ファースト データ処理サービスです。
- 貴重なデータアセットを検出、分類、保護するには、匿名化手法など、Google Cloud Sensitive Data Protection の機能の使用を検討してください。これらの手法では、条件を満たし、コンプライアンスを遵守している場合に、ランダムに生成された鍵または事前定義された鍵を使用して、個人情報（PII）などの機密データをマスキング、暗号化、置換できます。
- 既存の Hadoop または Spark のワークロードがある場合は、ジョブを Dataproc に移行し、既存の HDFS データを Cloud Storage に移行することを検討してください。
プライベート コンピューティング環境から Google Cloud へ最初にデータ転送を実行する場合は、データセットのサイズと使用可能な帯域幅に最も適した転送方法を選択します。詳細については、Google Cloud への移行: 大規模なデータセットの転送をご覧ください。
Google Cloud と他のクラウド間で長期間にわたって大量のトラフィック転送または交換が必要な場合は、Google Cloud と他のクラウド サービス プロバイダ（特定のロケーションで利用可能）の間に高帯域幅の専用接続を確立するために、Google Cloud Cross-Cloud Interconnect の使用を検討する必要があります。
接続レイヤで暗号化が必要な場合は、選択したハイブリッド接続ソリューションに基づいてさまざまなオプションを使用できます。これらのオプションには、VPN トンネル、Cloud Interconnect を介した HA VPN、Cross-Cloud Interconnect の MACsec などがあります。
複数環境間でツールとプロセスの一貫性を保ちます。分析のハイブリッド シナリオにおける前提条件ではありませんが、このプラクティスは運用効率の向上に役立ちます。
エッジ型ハイブリッド パターン
クラウドでワークロードを実行するには、一部のシナリオにおいてクライアントが高速かつ信頼性の高いインターネット接続性を備えている必要があります。今日のネットワークにおいては、この要件がクラウド導入の障害になることはほとんどありません。ただし、次に示すように継続的な接続を利用できないシナリオが考えられます。
- 海洋を航行する船舶、その他の車両においては、断続的な接続のみが利用可能、またはレイテンシの高い衛星リンクを介してのみアクセスが可能な場合があります。
- 工場や発電所がインターネットに接続されている可能性があります。インターネット プロバイダによって保証される可用性では、これらの施設における信頼性の要件を満たすのに不十分な場合があります。
- 小売店やスーパーマーケットでは、接続に間断がある、または使用している接続において、ビジネス クリティカルな取引の処理に必要な信頼性やスループットが実現されない場合もあります。
エッジ型アーキテクチャ パターンでは、時間またはビジネスの面でクリティカルなワークロードをネットワークのエッジでローカル実行し、他の種類のワークロードにクラウドを使用することで、これらの課題に対処しています。エッジ ハイブリッド アーキテクチャでは、インターネット接続は、管理目的やデータの同期化またはアップロード（多くの場合に非同期で）に使用される重要でないコンポーネントであり、緊急時や重要業務のトランザクションには関与しません。
利点
特定のワークロードをエッジで実行し、他のワークロードをクラウドで実行することには、いくつかのメリットがあります。
- インバウンド トラフィック（エッジから Google Cloud へのデータ移動）は追加料金なしで利用できる場合があります。
- 時間やビジネスの面でクリティカルなワークロードをエッジで実行した場合、レイテンシが低下し自足性も向上します。また、インターネットに接続できない場合や一時的に利用できない場合でも、重要なトランザクションをすべて実行できます。同時に、全体のワークロードのかなりの部分をクラウドで実行することは有益です。
- 既存の投資をコンピューティングおよびストレージ機器に再利用できます。
- 時間の経過に伴い、特定のアプリケーションをリワークするか、エッジが所在する場所に信頼性の高いインターネット接続を装備することによって、エッジで実行されるワークロードの割合を徐々に低減し、クラウドに移行できます。
- モノのインターネット（IoT）関連のプロジェクトでは、ローカルでデータ計算を行うことで費用対効果を高めることができます。これにより、企業は一部のサービスをデータソースにより近いエッジでローカルに実行できます。また、企業はデータをクラウドに選択的に送信できるため、IoT ソリューションの容量、データ転送、処理、全体的なコストを削減できます。
- エッジ コンピューティングは、従来のサービスと最新のサービス間の中間通信レイヤとして機能します。たとえば、コンテナ化された API ゲートウェイ（Apigee ハイブリッドなど）を実行しているサービスが該当します。これにより、レガシー アプリケーションとシステムを、IoT ソリューションなどのモダナイズされたサービスと統合できます。
ベスト プラクティス
エッジ型アーキテクチャ パターンを実装するときは、次の推奨事項を考慮してください。
- 通信が単方向である場合は、上り（内向き）ゲート型パターンを使用します。
- 通信が双方向の場合は、下り（外向き）ゲート型と上り（内向き）ゲート型のパターンを検討してください。
- ソリューションが、公共のインターネット経由で Google Cloud に接続する多数のエッジ リモートサイトで構成されている場合は、ソフトウェア定義 WAN（SD-WAN）ソリューションを使用できます。また、Google Cloud パートナーがサポートするサードパーティの SD-WAN ルーターと Network Connectivity Center を組み合わせて使用すると、大規模なセキュア接続のプロビジョニングと管理を簡素化できます。
- エッジで実行されるシステムとクラウド環境で実行されるシステムの間の依存関係を最小限に抑えます。依存関係があると、エッジ型ハイブリッド設定で得られる信頼性とレイテンシに関するメリットが損なわれる可能性があります。
- 複数のエッジのロケーションを効率的に管理して操作するには、クラウドに一元管理プレーンとモニタリング ソリューションを用意する必要があります。
- クラウド環境とエッジ環境間で、CI / CD プロセス、および、デプロイとモニタリング用のツールが一貫していることを確認します。
- 適用可能かつ実現可能な場合は、コンテナと Kubernetes を使用して、さまざまなエッジ ロケーション間、およびエッジ ロケーションとクラウド間の差異を抽象化することを検討してください。Kubernetes は共通のランタイム レイヤを提供するため、コンピューティング環境全体でワークロードを一貫して開発、実行、操作できます。エッジとクラウド間でワークロードを移動することもできます。
- ハイブリッドの設定とオペレーションを簡素化するために、このアーキテクチャに GKE Enterprise を使用できます（環境間でコンテナが使用されている場合）。オンプレミス環境またはエッジ環境で実行されている GKE Enterprise クラスタを Google Cloud に接続するために必要な使用可能な接続オプションを検討します。
- このパターンでは、GKE Enterprise コンポーネントの一部は Google Cloud への接続が一時的に中断されても動作する場合がありますが、通常の動作モードとして Google Cloud から切断された GKE Enterprise を使用しないでください。詳細については、Google Cloud からの一時的な接続解除の影響をご覧ください。
- さまざまなバックエンド サービスとエッジサービス間でプロトコル、API、認証メカニズムの不整合を克服するには、必要に応じて、統合されたファサードとして API ゲートウェイまたはプロキシをデプロイすることをおすすめします。このゲートウェイまたはプロキシは、一元化された制御ポイントとして機能し、次の対策を行います。
- 追加のセキュリティ対策を実装します。
- クライアント アプリやその他のサービスをバックエンド コードの変更から保護します。
- すべてのクロス環境アプリとその分離されたコンポーネント間の通信の監査証跡を容易にします。
- レガシー サービスと最新のサービス間の中間通信レイヤとして機能します。
- Apigee と Apigee ハイブリッドを使用すると、オンプレミス環境、エッジ、他のクラウド、Google Cloud 環境にわたってエンタープライズ クラスのハイブリッド ゲートウェイをホストして管理できます。
- システムが環境の境界を越えて安全に認証できるように、環境間に共通の ID を確立します。
- 環境間で交換されるデータは機密情報であるため、VPN トンネル、TLS、またはその両方を使用して、すべての通信が暗号化されるようにしてください。
環境ハイブリッド パターン
環境ハイブリッド アーキテクチャ パターンでは、ワークロードの本番環境を既存のデータセンターに保持します。その後、開発環境やテスト環境などの環境にパブリック クラウドを使用します。このパターンは、複数のコンピューティング環境にわたる同じアプリケーションの冗長デプロイに依存します。デプロイの目的は、容量、アジリティ、復元力を高めることです。
移行するワークロードを評価するにあたり、特定のアプリケーションをパブリック クラウドで実行することが問題につながるケースに直面することがあります。
- 法令または規制上の制約により、特定の国にデータを保管する必要が生じる場合があります。
- サードパーティ製品のライセンス条項により、クラウド環境で特定のソフトウェアを操作できない場合
- ローカルでのみ使用可能なハードウェア デバイスへのアクセスがアプリケーションで必要になる場合
このような場合は、本番環境だけでなく、開発、テスト、ステージング システムなど、アプリケーションのライフサイクルに関わるすべての環境を考慮する必要があります。これらの制限は、多くの場合、本番環境とそのデータに適用されます。実際のデータを使用しない他の環境には適用されない場合があります。組織のコンプライアンス部門または同等のチームに確認してください。
次の図は、典型的な環境ハイブリッド アーキテクチャ パターンを示しています。
本番環境のシステムとは異なる環境で開発 / テストシステムを実行することは危険であり、既存のベスト プラクティスや環境間の相違を最小限に抑える試みに反するとも考えられます。このような懸念は裏付けのあるものですが、開発プロセスとテストプロセスのステージを区別すれば問題になりません。
開発、テスト、デプロイの各プロセスはアプリケーションごとに異なりますが、通常は次のようなステージごとのバリエーションがあります。
- 開発: リリース候補を作成する。
- 機能テストまたはユーザー受け入れテスト: リリース候補が機能要件を満たしていることを確認する。
- パフォーマンスと信頼性のテスト: リリース候補が非機能要件を満たしていることを確認します。負荷テストとも呼ばれます。
- ステージングまたはデプロイテスト: デプロイ手順が動作していることを確認する。
- 本番環境: 新しいアプリまたは更新されたアプリをリリースします。
単一の環境でこれらの複数のステージを実行するのは実用的ではないため、通常は各ステージにつき 1 つ以上の専用環境が必要となります。
テスト環境の主な目的は、機能テストを実行することです。ステージング環境の主な目的は、アプリケーションのデプロイ手順が意図したとおりに機能するかどうかをテストすることです。リリースがステージング環境に到達するまでに、機能テストが完了している必要があります。ステージングは、本番環境デプロイにソフトウェアをデプロイする前の最後のステップです。
テスト結果が意味を持ち、本番環境にもあてはまることを確実にするには、アプリケーションのライフサイクル全体で使用する一連の環境が、可能な限り、次のルールを満たしている必要があります。
- すべての環境が機能的に同等であること。つまり、オペレーティング システムとライブラリのアーキテクチャ、API、バージョンが同等で、システムが環境全体で同じように動作する必要があります。この同等性により、アプリケーションがある環境では動作するが別の環境では機能しないまたは欠陥が再現できないといった状況が回避されます。
- パフォーマンスと信頼性のテスト、ステージング、本番環境に使用される環境が非機能的に同等であること。つまり、それらのパフォーマンス、スケール、構成、およびそれらが操作され、維持される方法は、同じであるか、違いがあったとしてもわずかなものである必要があります。そうしないと、パフォーマンス テストとステージング テストが無意味になります。
一般に、開発と機能テストに使用される環境がその他の環境と非機能的に異なっても構いません。
次の図に示すように、テスト環境と開発環境は Google Cloud 上に構築されています。Cloud SQL などのマネージド データベースは、Google Cloud での開発とテストのオプションとして使用できます。開発とテストでは、オンプレミス環境と同じデータベース エンジンとバージョン、機能的に同等のバージョン、またはテスト ステージ後に本番環境にロールアウトされる新しいバージョンを使用できます。ただし、2 つの環境の基盤となるインフラストラクチャは同じではないため、パフォーマンス ロードテストに対するこのアプローチは有効ではありません。
次のシナリオは、環境ハイブリッド パターンに適しています。
- 適用可能で実現可能な場合は、共通ランタイム レイヤとして Kubernetes に依存することで、すべての環境で同等の機能を実現します。このアプローチを実現するための重要な技術として、Google Kubernetes Engine（GKE）Enterprise エディションを使用できます。
- ワークロードの移植性を確保し、コンピューティング環境間の違いを抽象化します。ゼロトラスト サービス メッシュを使用すると、さまざまな環境間で必要な通信分離を制御して維持できます。
- パブリック クラウドで開発および機能テスト環境を実行します。これらの環境は機能的には他の環境と同等ですが、パフォーマンスなどの非機能面では異なる場合があります。このコンセプトは上の図に示されています。
- プライベート コンピューティング環境における本番環境、ステージング、パフォーマンス（負荷テスト）、信頼性テストのための環境を稼働させ、機能的および非機能的な同等性を確保します。
設計上の考慮事項
- ビジネスニーズ: アプリケーションのデプロイ戦略とリリース戦略にはそれぞれ長所と短所があります。選択したアプローチが特定の要件に合っていることを確認するには、ビジネスニーズと制約を徹底的に評価したうえで選択してください。
- 環境の違い: このパターンでは、このクラウド環境を使用する主な目的は開発とテストです。最終的な状態は、テスト済みのアプリケーションを限定公開のオンプレミス環境（本番環境）でホストすることです。クラウド環境では想定どおりに機能し、本番環境（オンプレミス）では機能しない可能性のある機能を開発してテストしないようにするには、技術チームが両方の環境のアーキテクチャと機能を理解している必要があります。これには、他のアプリケーションやハードウェア インフラストラクチャ（トラフィック検査を実行するセキュリティ システムなど）に対する依存関係が含まれます。
- ガバナンス: クラウドで開発できる内容とテストに使用できるデータを制御するには、承認とガバナンスのプロセスを使用します。このプロセスは、オンプレミス本番環境に存在しないクラウド機能を開発環境とテスト環境で使用しないようにするのにも役立ちます。
- 成功基準: 組織のソフトウェアの品質保証基準に沿って、明確で事前定義された測定可能なテスト成功基準が必要です。これらの標準は、開発してテストするすべてのアプリケーションに適用します。
- 冗長性: 開発環境とテスト環境では、本番環境ほど信頼性が要求されない場合がありますが、冗長な機能とさまざまな障害シナリオをテストする機能は必要です。障害シナリオの要件によっては、開発環境とテスト環境の一部として冗長性を設計する必要があります。
利点
パブリック クラウドでの開発と機能テストのワークロードの実行には、いくつかのメリットがあります。
- 必要に応じて環境を自動的に開始または停止できます。たとえば、commit リクエストまたは pull リクエストごとに環境全体をプロビジョニングし、テストを実行できるようにする一方で、必要がなくなったら環境を無効にできます。このアプローチには次のような利点もあります。
- 非アクティブ時に仮想マシン（VM）インスタンスを停止するか、オンデマンドでのみ環境をプロビジョニングすることにより費用を削減できます。
- プルリクエストごとにエフェメラル環境を開始すると、開発とテストを高速化できます。また、メンテナンス オーバーヘッドが削減され、ビルド環境の不整合が軽減されます。
- パブリック クラウドでこれらの環境を実行することで、クラウドや関連ツールに精通し、他のワークロードの移行に役立てることができます。このアプローチは、コンテナと Kubernetes を使用してワークロードのポータビリティを検討する場合に特に役立ちます。たとえば、環境間で GKE Enterprise を使用する場合などです。
ベスト プラクティス
環境ハイブリッド アーキテクチャ パターンを正常に実装するには、次の推奨事項を検討してください。
- 最適なネットワークとセキュリティの設計など、アプリケーション通信の要件を定義します。次に、ミラーリングされたネットワーク パターンを使用して、異なる環境のシステム間の直接通信を防ぐようにネットワーク アーキテクチャを設計します。環境間で通信が必要な場合は、制御された方法で行う必要があります。
選択するアプリケーションのデプロイとテストの戦略は、ビジネス目標と要件に合わせて調整する必要があります。これには、ダウンタイムなしで変更をロールアウトしたり、幅広いリリースの前に特定の環境やユーザー グループに機能を段階的に実装したりすることが含まれます。
ワークロードを移植可能にし、環境間の差を抽象化するために、Kubernetes でコンテナを使用できます。詳細については、GKE Enterprise ハイブリッド環境のリファレンス アーキテクチャをご覧ください。
ワークロードのデプロイ、構成、運用のために、コンピューティング環境全体で機能する共通のツールチェーンを確立します。Kubernetes を使用すると、この一貫性が得られます。
CI/CD パイプラインがコンピューティング環境全体で一貫しており、同一のバイナリ、パッケージ、またはコンテナのセットがこれらの環境全体にデプロイされていることを確認します。
Kubernetes を使用する場合は、Tekton などの CI システムを使用して、クラスタにデプロイして各環境で動作するデプロイ パイプラインを実装します。詳細については、Google Cloud の DevOps ソリューションをご覧ください。
安全で信頼性の高いアプリケーションを継続的にリリースするには、DevOps プロセス（DevSecOps）の不可欠な部分としてセキュリティを組み込みます。詳細については、Dev(Sec)Ops ツールキットを使用して、インターネット接続アプリケーションを 1 時間以内に配信して保護するをご覧ください。
Google Cloud と既存のクラウド環境でのロギングとモニタリングには、同じツールを使用します。オープンソースのモニタリング システムの使用を検討してください。詳細については、ハイブリッド クラウドとマルチクラウドのモニタリングおよびロギング パターンをご覧ください。
テスト環境と本番環境のワークロードを異なるチームが管理する場合は、別々のツールを使用することもできます。ただし、同じツールを異なるビュー権限で使用すると、トレーニングの労力と複雑さを軽減できます。
機能テスト用のデータベース、ストレージ、メッセージング サービスを選択する場合は、Google Cloud で同等のマネージド サービスが提供されるプロダクトを使用してください。マネージド サービスを使用することにより、開発環境とテスト環境を管理する作業を軽減できます。
機密情報を保護するため、転送中のすべての通信を暗号化することをおすすめします。接続レイヤで暗号化が必要な場合は、選択したハイブリッド接続ソリューションに基づいてさまざまなオプションを使用できます。これらのオプションには、VPN トンネル、Cloud Interconnect を介した HA VPN、Cloud Interconnect の MACsec などがあります。
次の表は、どの Google Cloud プロダクトが一般的な OSS 製品と互換性があるかを示しています。
| OSS 製品 | Google Cloud プロダクトとの互換性 |
|---|---|
| Apache HBase | Bigtable |
| Apache Beam | Dataflow |
| CDAP | Cloud Data Fusion |
| Apache Hadoop | Dataproc |
| MySQL、PostgreSQL | Cloud SQL |
| Redis クラスタ、Redis、Memcached | Memorystore |
| ネットワーク ファイル システム（NFS） | Filestore |
| JMS、Kafka | Pub/Sub |
| Kubernetes | GKE Enterprise |
ハイブリッド クラウドとマルチクラウドのビジネス継続性のパターン
ミッション クリティカルなシステムのビジネスの継続性を検討する主な目的は、組織が障害発生時と障害発生後に復元力を確保し、ビジネス オペレーションを継続できるようにすることです。複数の地理的リージョンにわたってシステムとデータを複製し、単一障害点を回避することで、自然災害によるローカル インフラストラクチャへのリスクを最小限に抑えることができます。その他の障害シナリオとしては、深刻なシステム障害、サイバーセキュリティ攻撃、システム構成エラーなどがあります。
障害に耐えられるようにシステムを最適化することは、効果的な事業継続を確立するために不可欠です。システムの信頼性は、パフォーマンス、復元力、稼働時間の可用性、セキュリティ、ユーザー エクスペリエンスなど、さまざまな要因によって影響を受けます。Google Cloud で信頼性の高いサービスを設計して運用する方法の詳細については、Google Cloud アーキテクチャ フレームワークの信頼性の柱と Google Cloud における信頼性の構成要素をご覧ください。
このアーキテクチャ パターンは、複数のコンピューティング環境にわたるアプリケーションの冗長デプロイに依存します。このパターンでは、同じアプリケーションを複数のコンピューティング環境にデプロイし、信頼性を高めることを目指します。ビジネスの継続性とは、中断イベントの発生後も事前に定義された許容レベルで主要なビジネス機能やサービスを継続する組織の能力と定義できます。
障害復旧（DR）はビジネスの継続性のサブセットであると見なされ、重要なビジネス機能をサポートする IT システムが、中断後できるだけ早く運用されるようにすることに焦点を当てます。一般的に、DR 戦略と計画は、より広範なビジネス継続性戦略の形成に役立ちます。技術的な観点から、障害復旧戦略の作成を開始するときに、ビジネス インパクト分析で、2 つの主要な指標である目標復旧時点（RPO）と目標復旧時間（RTO）を定義する必要があります。Google Cloud を使用して障害復旧に対処する方法については、障害復旧計画ガイドをご覧ください。
RPO と RTO の目標値が小さいほど、中断から復旧する時間が短くなり、データ損失が最小限に抑えられます。ただし、冗長システムを構築する必要があるため、コストが高くなります。準リアルタイムのデータ複製を実行でき、障害イベント後に同じ規模で動作する冗長システムは、複雑さ、管理オーバーヘッド、コストの増加につながります。
DR 戦略または DR パターンを選択する決定は、ビジネス インパクト分析に基づいて行う必要があります。たとえば、金融サービス組織では、数分間のダウンタイムでも、経済的損失は DR システムの実装コストをはるかに上回る可能性があります。一方、他の業界の企業では、ビジネスに大きな影響を与えることなく、数時間のダウンタイムを許容できる場合があります。
ミッション クリティカルなシステムをオンプレミスのデータセンターで実行する場合、DR の 1 つのアプローチとして、別のリージョンにある第 2 のデータセンターにスタンバイ システムを確保する方法があります。しかし、より費用対効果の高い方法は、フェイルオーバーのためにパブリック クラウドベースのコンピューティング環境を使用することです。このアプローチは、ビジネス継続性ハイブリッド パターンの主な要因です。クラウドは、DR インフラストラクチャの一部を、使用していないときにオフにできるため、コストの観点で特に魅力的です。低コストの DR ソリューションを実現するために、クラウド ソリューションでは RPO と RTO の値が増加する可能性を許容できます。
上の図は、オンプレミス環境へのフェイルオーバーまたは障害復旧環境としてのクラウドの使用を示しています。
一般的ではなく、必要になることがまれなバリエーションとしては、ビジネス継続性マルチクラウド パターンがあります。このパターンでは、本番環境で 1 つのクラウド プロバイダを使用し、DR 環境で別のクラウド プロバイダを使用します。ワークロードのコピーを複数のクラウド プロバイダにデプロイすることで、マルチリージョン デプロイで提供される以上の可用性を実現できる場合があります。
複数のクラウドにまたがる DR と、異なるリージョンで 1 つのクラウド プロバイダを使用する場合の DR を評価するには、次のようないくつかの考慮事項を徹底的に分析する必要があります。
- 管理性
- セキュリティ
- 全体的な実現可能性
- 費用
- 複数のクラウド プロバイダからのアウトバウンドのデータ転送料金は、クラウド間の継続的な通信によって高額になる可能性があります。
- データベースを複製するときに、大量のトラフィックが発生する可能性があります。
- TCO とクラウド間ネットワーク インフラストラクチャの管理コスト。
規制要件を満たすためにデータが国内に保存される必要がある場合は、国内に DR として 2 つ目のクラウド プロバイダを使用する方法もあります。2 つ目のクラウド プロバイダを使用する場合、オンプレミス環境を使用してハイブリッド構成を構築するオプションがないことが前提となります。クラウド ソリューションの再設計を回避するには、2 つ目のクラウド プロバイダが、リージョン内で必要なすべての機能とサービスを提供することが理想的です。
設計上の考慮事項
- DR の期待値: ビジネスが達成したい目標を RPO と RTO に設定し、DR アーキテクチャと構築計画の指針とします。
- ソリューション アーキテクチャ: このパターンでは、DR の期待値を満たすために、オンプレミス環境の既存の機能を複製する必要があります。したがって、クラウド環境で同じ（またはより最適化された）機能とパフォーマンスを提供するために、アプリケーションの再ホスティング、リファクタリング、または再設計の実現可能性を評価する必要があります。
- 設計と構築: ランディング ゾーンの構築は、ほとんどの場合、クラウド環境にエンタープライズ ワークロードをデプロイするための前提条件です。詳細については、Google Cloud のランディング ゾーンの設計をご覧ください。
DR の呼び出し: DR の設計とプロセスでは、次の質問を検討することが重要です。
- 何によって DR シナリオがトリガーされますか？たとえば、プライマリ サイトの特定の機能またはシステムの障害によって DR がトリガーされる場合があります。
- DR 環境へのフェイルオーバーはどのように呼び出されますか？手動の承認プロセスですか、それとも RTO の目標を達成するように自動化できますか。
- 期待される RTO に合わせてフェイルオーバーを呼び出すように、システム障害検出メカニズムと通知メカニズムをどのように設計すればよいですか？
- 障害が検出された後、トラフィックは DR 環境にどのようにして再ルーティングされますか？
テストを通じて、これらの質問に対する回答を検証します。
テスト: DR へのフェイルオーバーを徹底的にテストして評価します。RPO と RTO の要件を満たしていることを確認します。これにより、必要なときに自信を持って DR を呼び出すことができます。プロセスや技術ソリューションに新しい変更や更新を加えるたびに、テストを再度実施します。
チームのスキル: 環境がサードパーティによって管理されている場合を除き、1 つ以上の技術チームが、クラウド環境で本番環境ワークロードを構築、運用、トラブルシューティングするためのスキルと専門知識を備えている必要があります。
利点
Google Cloud をビジネス継続性のために使用することには、多くの利点があります。
- Google Cloud には世界中に多数のリージョンがあり、同じ大陸内の別のサイトにデータをバックアップまたは複製できます。別の大陸のサイトにデータをバックアップまたは複製することもできます。
- Google Cloud では、Cloud Storage のデュアルリージョンまたはマルチリージョン バケットにデータを保存できます。データは、少なくとも 2 つの地理的に分離されたリージョンに冗長的に保存されます。デュアルリージョン バケットとマルチリージョン バケットに保存されたデータは、デフォルトのレプリケーションを使用して複数の地理的リージョンに複製されます。
- デュアルリージョン バケットは、ビジネスの継続性と DR 計画をサポートする地理的な冗長性を提供します。また、RPO を短縮して高速に複製するために、デュアルリージョンに保存されているオブジェクトは、必要に応じてリージョン間でターボ レプリケーションを使用できます。
- 同様に、マルチリージョン レプリケーションでは、マルチリージョンの地理的境界内にデータを保存することで、複数のリージョンにわたって冗長性を確保します。
- 次のオプションのうち 1 つ以上を提供して、DR を構築するための資本支出と運用支出を削減します。
- 停止した VM インスタンスは、ストレージの費用しか発生せず、実行中の VM インスタンスよりも大幅に低価格になります。つまり、コールド スタンバイ システムの保守の費用を最小限に抑えることができます。
- Google Cloud の従量課金モデルでは、実際に使用したストレージとコンピューティング容量に対してのみ料金が発生します。
- 自動スケーリングなどの弾力性の機能により、DR 環境を必要に応じて自動的にスケールアップまたはスケールダウンできます。
たとえば、次の図は、Compute Engine、Cloud SQL、Cloud Load Balancing を使用した Google Cloud 上の復元コンポーネントを使用する、オンプレミス環境（本番環境）で実行されているアプリケーションを示しています。このシナリオでは、VM ベースのデータベースまたは Google Cloud マネージド データベース（Cloud SQL など）を使用してデータベースを事前プロビジョニングし、継続的なデータ レプリケーションによる高速な復元を実現します。作成済みのスナップショットから Compute Engine VM を起動すると、通常のオペレーション時のコストを削減できます。この設定では、障害イベントが発生した後、DNS が Cloud Load Balancing の外部 IP アドレスを参照する必要があります。
アプリケーションをクラウドで動作させるには、ウェブ VM とアプリケーション VM をプロビジョニングする必要があります。目標とする RTO レベルと会社のポリシーに応じて、DR の呼び出し、クラウドへのワークロードのプロビジョニング、トラフィックの再ルーティングを行うプロセス全体を手動または自動で完了できます。
インフラストラクチャのプロビジョニングを高速化および自動化するには、インフラストラクチャをコードとして管理することを検討してください。継続的インテグレーション サービスである Cloud Build を使用して、Terraform マニフェストを環境に自動的に適用できます。詳細については、Terraform、Cloud Build、GitOps を使用してインフラストラクチャをコードとして管理するをご覧ください。
ベスト プラクティス
ビジネス継続性パターンを使用している場合は、次のベスト プラクティスを検討してください。
- フェイルオーバー手順と復旧手順とともにインフラストラクチャについて文書化した障害復旧計画を作成します。
- ビジネス インパクト分析と、特定された必要な RPO と RTO の目標に基づいて、次のアクションを検討してください。
- データのバックアップのみを行う場合は、ハンドオーバー パターンの使用を検討してください。それ以外の場合、メッシュ パターンは、既存の環境のネットワーク アーキテクチャを複製するのに適した方法です。
- 異なる環境で動作するシステム間の依存関係を最小限に抑えます（特に、通信が同期的に処理されている場合）。こうした依存関係は、パフォーマンスや全体的な可用性の低下の原因となります。
スプリット ブレインの問題を回避します。環境間で双方向にデータを複製すると、スプリット ブレインが発生する可能性があります。スプリット ブレインの問題は、データを双方向に複製する 2 つの環境が互いの通信を失う場合に発生します。この分割により、両方の環境のシステムが、他方の環境が利用できず自身がデータへの排他的アクセス権を持っていると判断する可能性があります。これにより、競合するデータ変更が発生する可能性があります。スプリット ブレインの問題を回避する一般的な方法は 2 つあります。
- 3 つ目のコンピューティング環境を使用する。この環境では、システムはデータを変更する前にクォーラムをチェックできます。
接続が復元された後、競合するデータ変更を調整できます。
SQL データベースでは、クライアントが新しいプライマリ インスタンスの使用を開始する前に、元のプライマリ インスタンスにアクセスできないようにすることで、スプリット ブレインの問題を回避できます。詳細については、Cloud SQL データベースの障害復旧をご覧ください。
CI / CD システムとアーティファクトのリポジトリが単一障害点にならないようにします。1 つの環境が利用できない場合でも、新しいリリースをデプロイしたり、構成の変更を適用したりできる必要があります。
スタンバイ システムを使用する場合は、すべてのワークロードの移植可能性を確保します。すべてのワークロードは、環境間でシステムの一貫性が維持されるように、移植可能（アプリケーションでサポートされており、実行可能）である必要があります。このアプローチは、コンテナと Kubernetes を検討することで実現できます。Google Kubernetes Engine（GKE）Enterprise エディションを使用すると、ビルドと運用を簡素化できます。
スタンバイ システムのデプロイを CI / CD パイプラインに統合します。この統合により、環境全体でアプリケーションのバージョンと構成の一貫性が確保されます。
DNS の変更が迅速に伝達されるように、DNS を適度に短い有効期間値で構成します。これにより、災害が発生したときにユーザーをスタンバイ システムに再ルーティングできます。
アーキテクチャとソリューションの動作に沿った DNS ポリシーとルーティング ポリシーを選択します。また、複数のリージョン ロードバランサと DNS ルーティング ポリシーを組み合わせて、ハイブリッド設定など、さまざまなユースケースに対応するグローバル ロード バランシング アーキテクチャを作成することもできます。
複数の DNS プロバイダを使用します。複数の DNS プロバイダを使用すると、次のことが可能になります。
- アプリケーションとサービスの可用性と復元力を向上させる。
マルチプロバイダの DNS 構成を使用すると、オンプレミス環境とクラウド環境の間で依存関係があるハイブリッド アプリケーションのデプロイや移行を簡素化できます。
Google Cloud には、複数の DNS プロバイダを使用する環境の設定と運用に役立つ、octoDNS に基づくオープンソース ソリューションが用意されています。詳細については、Cloud DNS を使用したマルチプロバイダのパブリック DNS をご覧ください。
スタンバイ システムを使用する場合は、ロードバランサを使用して自動フェイルオーバーを作成します。ロードバランサのハードウェアに障害が発生する可能性があるので注意してください。
ハードウェア ロードバランサではなく Cloud Load Balancing を使用すると、このアーキテクチャ パターンの使用時に発生する一部のシナリオに対応できます。内部クライアント リクエストまたは外部クライアント リクエストは、重み付けに基づくトラフィック分割などのさまざまな指標に基づいて、プライマリ環境または DR 環境にリダイレクトできます。詳細については、グローバル外部アプリケーション ロードバランサのトラフィック管理の概要をご覧ください。
Google Cloud から他の環境へのアウトバウンド データ転送量が多い場合は、Cloud Interconnect または Cross-Cloud Interconnect の使用を検討してください。Cloud Interconnect を使用すると、接続パフォーマンスを最適化し、特定の条件を満たすトラフィックのアウトバウンド データ転送料金を削減できます。詳しくは、Cloud Interconnect の料金をご覧ください。
Google Cloud Marketplace 上の希望するパートナー ソリューションを使用して、データのバックアップ、レプリケーション、RPO と RTO の目標などの要件を満たすその他のタスクを容易にすることを検討してください。
DR 呼び出しシナリオをテストして評価し、目標 RTO 値と比較してどのくらいすばやく障害イベントからアプリケーションを復旧できるかを把握します。
転送中の通信を暗号化します。機密情報を保護するため、転送中のすべての通信を暗号化することをおすすめします。接続レイヤで暗号化が必要な場合は、選択したハイブリッド接続ソリューションに基づいてさまざまなオプションを使用できます。これらのオプションには、VPN トンネル、Cloud Interconnect を介した HA VPN、Cloud Interconnect の MACsec などがあります。
クラウド バースト機能のパターン
インターネット アプリケーションでは、使用状況が極端に変動する可能性があります。ほとんどの企業向けアプリケーションでは、このような問題に直面することはありませんが、多くの企業がバッチジョブや CI / CD ジョブなど、バーストの原因となるさまざまなワークロードに対処する必要があります。
このアーキテクチャ パターンは、複数のコンピューティング環境にわたるアプリケーションの冗長デプロイに依存します。目標は、容量または復元力の増加、またはその両方です。
データセンター ベースのコンピューティング環境では、リソースを多めにプロビジョニングすることによって、バーストの原因となるワークロードに対応できますが、この方法は費用効率が優れない場合があります。バッチジョブについては、実行時間を引き延ばすことで使用率を最適化できますが、ジョブを遅延させるため時間が重視される場合には実用的でありません。
クラウド バースト パターンとは、プライベート コンピューティング環境をベースラインのワークロードに使用することにより、追加の容量が必要なときに一時的なバーストをクラウドに担わせることです。
上の図では、オンプレミスのプライベート環境でデータ容量が上限に達した場合は、必要に応じて Google Cloud 環境から追加の容量を取得できます。
このパターンの主な推進要因は、コストの削減と、スケール要件の変更に対応するために必要な時間と労力を削減できることです。このアプローチでは、追加の負荷を処理するときに使用されたリソースに対してのみ料金が発生します。つまり、インフラストラクチャを過剰にプロビジョニングする必要はありません。代わりに、オンデマンドのクラウド リソースを活用して、需要と事前定義された指標に合わせてスケーリングできます。その結果、需要がピーク時のサービスの中断を回避できます。
クラウド バースト シナリオに考えられる重要な要件は、ワークロードのポータビリティです。ワークロードを複数の環境にデプロイできるようにするには、環境間の違いを抽象化する必要があります。たとえば、Kubernetes を使用すると、異なるインフラストラクチャを使用するさまざまな環境でワークロード レベルの整合性を実現できます。詳細については、GKE Enterprise ハイブリッド環境のリファレンス アーキテクチャをご覧ください。
設計上の考慮事項
クラウド バースト パターンは、インタラクティブ型、バッチ型両方のワークロードに適用可能です。ただし、インタラクティブ型のワークロードを処理する場合は、環境間でリクエストを分散する方法を決定する必要があります。
受信したユーザー リクエストを既存のデータセンターで走行するロードバランサに転送し、ロードバランサでローカルおよびクラウドのリソース全体に分散させることができます。
このアプローチでは、クラウドに割り当てられているリソースのトラッキングも行うために、既存のデータセンターで稼働しているロードバランサまたは別のシステムが必要です。ロードバランサまたは別のシステムは、リソースの自動アップ スケーリングまたはダウン スケーリングも開始する必要があります。このアプローチを使用すると、アクティビティの低い時間帯にはすべてのクラウド リソースを廃止できます。一方、リソースを追跡するためのメカニズムを実装すると、ロードバランサ ソリューションのキャパシティを超え全体的な複雑さが増大する可能性があります。
リソースを追跡するためのメカニズムを実装する代わりに、ハイブリッド接続のネットワーク エンドポイント グループ（NEG）バックエンドを使用して Cloud Load Balancing を使用できます。このロードバランサを使用すると、内部クライアント リクエストまたは外部クライアント リクエストを、オンプレミスと Google Cloud の両方に配置され、重みベースのトラフィック分割などのさまざまな指標に基づくバックエンドに転送できます。また、Google Cloud のワークロードのロード バランシング処理能力に基づいてバックエンドをスケーリングすることもできます。詳細については、グローバル外部アプリケーション ロードバランサのトラフィック管理の概要をご覧ください。
この方法には、Google Cloud Armor の DDoS 対策機能、WAF、Cloud CDN を使用したクラウドエッジでのコンテンツ キャッシュなど、その他にもいくつかの利点があります。ただし、追加のトラフィックを処理するには、ハイブリッド ネットワーク接続のサイズを調整する必要があります。
ワークロードのポータビリティで説明したように、ワークロードの整合性を実現するために、アプリケーションをほとんど変更せずに別の環境に移植できますが、アプリケーションが両方の環境で同じパフォーマンスを示すとは限りません。通常は基盤となるコンピューティング、インフラストラクチャのセキュリティ機能、またはネットワーキング インフラストラクチャの相違と、依存関係のあるサービスとの近接性によって、パフォーマンスが異なります。テストを行うことで、より正確な可視化が可能になり、パフォーマンスの予測を把握できます。
クラウド インフラストラクチャ サービスを使用して、ポータビリティのないアプリケーションをホストする環境を構築できます。需要のピーク時にトラフィックがリダイレクトされたときにクライアント リクエストを処理するには、次のアプローチを使用します。
- 一貫したツールを使用して、これらの 2 つの環境をモニタリングおよび管理します。
- ワークロードのバージョニングが一貫していることと、データソースが最新であることを確認します。
- 需要が増加し、クラウド ワークロードがアプリケーションのクライアント リクエストを受け入れることが予想される場合は、クラウド環境をプロビジョニングしてトラフィックを再ルーティングする自動化を追加することが必要になる可能性があります。
需要の少ない時間帯にすべての Google Cloud リソースをシャットダウンする場合、トラフィック ロード バランシングに主に DNS ルーティング ポリシーを使用することは、必ずしも最適とは限りません。これは主に次の理由によるものです。
- リソースを初期化してユーザーに提供できるようになるまでに時間を要する場合があります。
- DNS の更新は、インターネットを介して徐々に伝播する傾向があります。
結果として次のようになります。
- リクエストを処理するためのリソースがない時間帯であっても、ユーザーが Cloud 環境にルーティングされる可能性があります。
- DNS の更新がインターネットに伝播する間、ユーザーはオンプレミス環境にルーティングされ続けることがあります。
Cloud DNS では、ソリューションのアーキテクチャと動作（位置情報 DNS ルーティング ポリシーなど）に適した DNS ポリシーとルーティング ポリシーを選択できます。Cloud DNS は、内部パススルー ネットワーク ロードバランサと内部アプリケーション ロードバランサのヘルスチェックもサポートしています。その場合は、このパターンに基づく全体的なハイブリッド DNS 設定に組み込むことができます。
一部のシナリオでは、内部アプリケーション ロードバランサやクロスリージョン内部アプリケーション ロードバランサを使用する場合など、Cloud DNS を使用して Google Cloud でヘルスチェックによりクライアント リクエストを分散できます。このシナリオでは、Cloud DNS は内部アプリケーション ロードバランサの全体的な状態をチェックし、内部アプリケーション ロードバランサ自体がバックエンド インスタンスの状態を確認します。詳細については、DNS ルーティング ポリシーとヘルスチェックを管理するをご覧ください。
Cloud DNS スプリット ホライズンを使用することもできます。Cloud DNS スプリット ホライズンは、同じドメイン名の DNS クエリ発信元の特定のロケーションまたはネットワークに DNS レスポンスまたはレコードを設定するためのアプローチです。このアプローチは、アプリケーションがプライベートとパブリック両方のエクスペリエンスを提供するように設計されており、それぞれに独自の機能がある場合の要件に対応するために一般的に使用されます。このアプローチは、環境間でトラフィック負荷を分散する際にも有効です。
これらの検討事項を考慮すると、クラウド バースト機能は一般的に、インタラクティブ型のワークロードよりもバッチ型のワークロードに適しています。
利点
クラウド バースト アーキテクチャ パターンの主なメリットは次のとおりです。
- クラウド バースト機能は、データセンターやプライベート コンピューティング環境にある既存の資産の再利用を可能にします。この再利用は、永続的に行うことができます。または、既存の機器の交換期限が到来するまでの間行い、到来した時点で、クラウドの完全移行を検討することもできます。
- ピーク時の需要を満たすために過剰な容量を維持する必要がなくなり、限定公開のコンピューティング環境の使用率と費用効率を高めることができます。
- クラウド バースト機能により、コンピューティング リソースを過剰にプロビジョニングすることなく、バッチジョブを適切なタイミングで実行できます。
ベスト プラクティス
クラウド バースト機能を実装する際は、以下のベスト プラクティスを検討してください。
- クラウドで実行されるワークロードがオンプレミス環境で実行されるワークロードと同じ方法でリソースにアクセスできるようにするには、最小権限のセキュリティ アクセス原則でメッシュ型パターンを使用します。ワークロードの設計で認められている場合は、クラウドからオンプレミス コンピューティング環境へのアクセスのみを許可し、その逆の接続は許可しないようにできます。
- 環境間の通信のレイテンシを最小限に抑えるには、対象となるプライベート コンピューティング環境に地理的に近い Google Cloud のリージョンを選択します。詳細については、Compute Engine のリージョン選択に関するベスト プラクティスをご覧ください。
- バッチ型のワークロードにのみクラウド バースト機能を使用する場合は、すべての Google Cloud リソースを限定非公開にして、セキュリティ攻撃の対象領域を低減します。Google Cloud 外部ロード バランシングを使用してワークロードへのエントリ ポイントを提供している場合でも、インターネットからこれらのリソースに直接アクセスできないようにします。
アーキテクチャ パターンとターゲット ソリューションの動作に合った DNS ポリシーとルーティング ポリシーを選択します。
- このパターンでは、DNS ポリシーの設計を恒久的に適用できます。また、需要のピーク時に別の環境を使用しており追加の容量が必要な場合にも適用できます。
- 位置情報 DNS ルーティング ポリシーを使用して、リージョン ロードバランサのグローバル DNS エンドポイントを設定できます。この方法には、Google Cloud リージョンが存在するオンプレミス デプロイメントとともに Google Cloud を使用するハイブリッド アプリケーションなど、位置情報 DNS ルーティング ポリシーのユースケースが多数あります。
同じ DNS クエリに異なるレコードを提供する必要がある場合は、スプリット ホライズン DNS を使用できます（内部クライアントと外部クライアントからのクエリなど）。
詳細については、ハイブリッド DNS のリファレンス アーキテクチャをご覧ください。
DNS の変更が迅速に伝達されるように、DNS を適度に短い有効期間値で構成します。これにより、クラウド環境を使用しており追加の容量が必要な場合にユーザーをスタンバイ システムに再ルーティングできます。
緊急性がなく、ローカルにデータを保存しないジョブの場合は、通常の VM インスタンスよりも大幅に費用が抑えられる Spot VM インスタンスの使用を検討してください。ただし、前提条件として VM ジョブがプリエンプトされた場合、システムは自動的にジョブを再開できる必要があります。
必要に応じて、コンテナを使用してワークロードのポータビリティを実現します。また、GKE Enterprise は、この設計を実現するための重要な技術です。詳細については、GKE Enterprise ハイブリッド環境のリファレンス アーキテクチャをご覧ください。
Google Cloud から別のコンピューティング環境に送信されたトラフィックをモニタリングします。このトラフィックは、アウトバウンド データ転送料金の対象となります。
アウトバウンド データ転送量が多い状態でこのアーキテクチャを長期的に使用する場合は、Cloud Interconnect の使用を検討してください。Cloud Interconnect を使用すると、接続パフォーマンスを最適化し、特定の条件を満たすトラフィックのアウトバウンド データ転送料金を削減できます。詳しくは、Cloud Interconnect の料金をご覧ください。
Cloud Load Balancing を使用する場合は、必要に応じてアプリケーション容量の最適化機能を使用する必要があります。これにより、グローバルに分散されたアプリケーションで発生する可能性のある容量の問題の一部に対処できます。
システムが環境境界を越えて安全に認証できるように、環境間に共通の ID を確立して、システムを使用するユーザーを認証します。
機密情報を保護するため、転送中のすべての通信を暗号化することを強くおすすめします。接続レイヤで暗号化が必要な場合は、選択したハイブリッド接続ソリューションに基づいてさまざまなオプションを使用できます。これらのオプションには、VPN トンネル、Cloud Interconnect を介した HA VPN、Cloud Interconnect の MACsec などがあります。
ハイブリッド クラウドとマルチクラウドのアーキテクチャ パターン: 次のステップ
- ハイブリッド クラウドとマルチクラウドのアーキテクチャを利用する方法と、適切なワークロードを選択する方法を学習します。
- 選択したハイブリッド クラウドとマルチクラウドのアーキテクチャ パターンに適したネットワーキング アーキテクチャ パターンの詳細を確認します。
- クラウド アプリケーションのデプロイ アーキタイプの詳細について確認します。
- GKE を使用したマイクロサービス ベースの e コマース ウェブ アプリケーションや、サーバーレス API ベースの動的ウェブ アプリケーションなど、さまざまなアーキテクチャを使用して e コマース ウェブ アプリケーションを設計してデプロイする方法について詳しく学びます。