Google Cloud デプロイ アーキタイプ ガイドのこのセクションでは、可用性、停止に対する堅牢性、費用、運用の複雑さの観点から、デプロイ アーキタイプを比較します。
次の表は、基本的なデプロイ アーキタイプ（ゾーン、リージョン、マルチリージョン、グローバル）の比較分析をまとめたものです。ハイブリッド トポロジとマルチクラウド トポロジでは、トポロジの Google Cloud 部分に使用されるデプロイ アーキタイプが、可用性、停止に対する堅牢性、費用、運用の複雑さに影響します。
| 設計上の考慮事項 | ゾーン | リージョン | マルチリージョン | グローバル |
|---|---|---|---|---|
| インフラストラクチャの可用性 | 99.9%（スリーナイン） | 99.99%（フォーナイン） | 99.999%（ファイブナイン） | 99.999%（ファイブナイン） |
| ゾーンの停止に対するインフラストラクチャの堅牢性 | RTO（時間数または日数） | レプリケーションが同期的であれば RTO はほぼゼロになる | レプリケーションが同期的であれば RTO はほぼゼロになる | レプリケーションが同期的であれば RTO はほぼゼロになる |
| リージョンの停止に対するインフラストラクチャの堅牢性 | RTO（時間数または日数） | RTO（時間数または日数） | レプリケーションが同期的であれば RTO はほぼゼロになる | レプリケーションが同期的であれば RTO はほぼゼロになる |
| Google Cloud リソースの費用 | 低 | 中 | 高 | 中 |
| 運用の複雑さ | 他のデプロイ アーキタイプよりもシンプルである | ゾーンよりも複雑である | リージョンよりも複雑である | マルチリージョンよりもシンプルになる可能性がある |
以降のセクションでは、上の表にまとめた比較分析について説明します。
インフラストラクチャの可用性
以降のセクションでは、各デプロイ アーキタイプにおけるインフラストラクチャの可用性の違いについて説明します。
ゾーン、リージョン、マルチリージョン、グローバル デプロイ アーキタイプ
Google Cloud インフラストラクチャは、ワークロードに対して、ゾーン デプロイ アーキタイプを使用する場合は 99.9%、リージョン デプロイの場合は 99.99%、マルチリージョン デプロイとグローバル デプロイの場合は 99.999% の目標可用性をサポートするように構築されています。これらの可用性の数値は、プラットフォーム レベルのインフラストラクチャの目標です。
Google Cloud にデプロイされたアプリケーションで想定される可用性は、デプロイのアーキタイプに加えて、次の要因によって異なります。
- アプリケーションの設計
- アプリケーション スタック内の相互依存する階層の数
- 使用する Google Cloud サービスの稼働時間に関するサービスレベル契約（SLA）
- 冗長リソースの量
- リソースのロケーション スコープ
詳細については、Google Cloud における信頼性の構成要素をご覧ください。
ハイブリッド デプロイ アーキタイプとマルチクラウド デプロイ アーキタイプ
ハイブリッド トポロジやマルチクラウド トポロジの場合、全体的な可用性は各環境のインフラストラクチャと環境間の相互依存性によって異なります。
- Google Cloud のコンポーネントと Google Cloud 外のコンポーネントの間に重要な相互依存関係が存在する場合、全体的な可用性はすべての環境で可用性が最も低いコンポーネントの可用性よりも低くなります。
- アプリケーションの各コンポーネントが Google Cloud とオンプレミスや他のクラウド プラットフォームの間で重複してデプロイされると、冗長性によって高可用性が確保されます。
ゾーンとリージョンの停止に対するインフラストラクチャの堅牢性
次のセクションでは、Google Cloud のゾーンとリージョンが停止しても、ワークロードのサポートを継続できるインフラストラクチャの能力という観点で、デプロイ アーキタイプの違いについて説明します。
ゾーン デプロイ アーキタイプ
基本的なシングルゾーン デプロイ アーキタイプを使用するアーキテクチャは、ゾーンの停止に対して堅牢ではありません。目標復旧時点（RPO）と目標復旧時間（RTO）に基づいて、ゾーンの停止からの復旧を計画する必要があります。たとえば、別の（フェイルオーバー）ゾーンでインフラストラクチャのパッシブ レプリカまたはスケールダウン レプリカを維持できます。プライマリ ゾーンでサービスが停止した場合は、フェイルオーバー ゾーンのデータベースをプライマリ データベースに昇格させて、フェイルオーバー ゾーンのフロントエンドにトラフィックを送信するようにロードバランサを更新できます。
リージョン デプロイ アーキタイプ
リージョン デプロイ アーキタイプを使用するアーキテクチャは、ゾーンの停止に対して堅牢です。1 つのゾーンで障害が発生しても、他のゾーンのインフラストラクチャに影響する可能性はほとんどありません。データが同期的にレプリケーションされる場合、RTO はほぼゼロになります。ただし、停止が Google Cloud リージョン全体に影響する場合は、アプリケーションが使用できなくなります。アプリケーションの RPO と RTO に沿って停止からの復旧を計画します。たとえば、リージョンの停止時には、インフラストラクチャのパッシブ レプリカを別のリージョンにプロビジョニングしてレプリカを有効にできます。
マルチリージョン デプロイ アーキタイプとグローバル デプロイ アーキタイプ
マルチリージョン デプロイ アーキタイプまたはグローバル デプロイ アーキタイプを使用するアーキテクチャは、ゾーンとリージョンの停止に対して堅牢です。データが同期的にレプリケーションされる場合、RTO はほぼゼロになります。アプリケーションがグローバルに分散されたロケーションを意識しないスタックとして実行されるアーキテクチャは、リージョンの停止に対して最高レベルの堅牢性を実現します。
ハイブリッド デプロイ アーキタイプとマルチクラウド デプロイ アーキタイプ
ハイブリッド アーキテクチャとマルチクラウド アーキテクチャの堅牢性は、各環境（Google Cloud、オンプレミス、その他のクラウド プラットフォーム）の堅牢性と環境間の相互依存性によって異なります。
たとえば、アプリケーションのすべてのコンポーネントが Google Cloud と別の環境（オンプレミスまたは別のクラウド プラットフォーム）の両方で重複して実行されている場合、そのアプリケーションはどのような Google Cloud のサービス停止に対しても堅牢です。Google Cloud のコンポーネントと、オンプレミスや他のクラウド プラットフォームにデプロイされているコンポーネントの間に重要な相互依存性がある場合、Google Cloud の停止に対する堅牢性は、アーキテクチャの Google Cloud の部分で使用するデプロイ アーキタイプの堅牢性に依存します。
Google Cloud リソースの費用
アプリケーションに必要な Google Cloud リソースの費用は、使用する Google Cloud サービス、プロビジョニングするリソースの数、リソースを保持または使用する期間、選択したデプロイ アーキタイプによって異なります。デプロイ アーキタイプに基づいてアーキテクチャの Google Cloud リソースの費用を見積もるには、Google Cloud 料金計算ツールを使用します。
次のセクションでは、さまざまなデプロイ アーキタイプでの Google Cloud リソースの費用の違いについて説明します。
ゾーンと対比したリージョンとマルチリージョンのデプロイ アーキタイプ
ゾーン デプロイ アーキタイプを使用するアーキテクチャと比較すると、マルチリージョン デプロイ アーキタイプを使用するアーキテクチャでは、冗長ストレージの追加費用が発生する可能性があります。また、リージョンの境界を通過するネットワーク トラフィックには、クロスリージョンのデータ転送の費用も考慮する必要があります。
グローバル デプロイ アーキタイプ
このアーキタイプを使用すると、グローバル ロードバランサをはじめとする高可用性のグローバル リソースを使用できます。クラウド リソースを設定して運用する費用は、リージョン リソースの複数のインスタンスをプロビジョニングして構成するマルチリージョン デプロイよりも少なくなる可能性があります。ただし、グローバル リソースには、より高額な費用がかかる場合があります。たとえば、グローバル ロードバランサにはプレミアム ティア ネットワーキングが必要ですが、リージョン ロードバランサにはスタンダード ティアを選択できます。
ハイブリッド デプロイ アーキタイプとマルチクラウド デプロイ アーキタイプ
ハイブリッド デプロイ アーキテクチャやマルチクラウド デプロイ アーキテクチャでは、プロビジョニングするリソースの費用とともに追加の費用を考慮する必要があります。たとえば、ハイブリッド ネットワーキングやクロスクラウド ネットワーキングなどの費用と、複数の環境にわたってリソースのモニタリングと管理を行う費用について考慮します。
すべてのデプロイ アーキタイプに関する考慮事項
クラウド ワークロードを実行する費用を評価する場合、プロビジョニングする Google Cloud リソースの費用とともに追加の費用を考慮する必要があります。たとえば、クラウドのデプロイを設計、構築、維持するための人件費とオーバーヘッド費用を考慮します。
デプロイ アーキタイプ間で Google Cloud リソースの費用を比較する場合は、アプリケーションで実行される作業単位あたりの費用も考慮します。アプリケーションが処理するユーザー数やリクエストの処理件数など、アプリケーションのビジネス推進要因を反映した作業単位を特定します。
Google Cloud リソースの使用率を慎重に管理し、Google 推奨のベスト プラクティスを採用することで、クラウドのデプロイの費用を最適化できます。詳細については、Google Cloud アーキテクチャ フレームワーク: 費用の最適化をご覧ください。
運用の複雑さ
次のセクションでは、デプロイ アーキタイプにおける運用の複雑さの違いについて説明します。これは、運用する必要があるインフラストラクチャ リソース、機能、アプリケーション スタックの数によって異なります。
ゾーンと対比したリージョンとマルチリージョンのデプロイ アーキタイプ
ゾーン デプロイ アーキタイプに基づくアーキテクチャは、他のデプロイ アーキテクチャと比較して設定と運用が容易です。複数のゾーンやリージョンで重複してアプリケーションを実行する場合は、次の理由により、運用上の作業が増えます。
- 複数のロケーションにあるアプリケーション スタックのステータスは、スタックレベルとアプリケーションの各コンポーネントの両方でモニタリングする必要があります。
- コンポーネントがどのロケーションでも使用不能になった場合、処理中のリクエストを適切に処理する必要があります。
- アプリケーションの変更は慎重にロールアウトする必要があります。
- データベースはすべてのロケーションにわたって同期する必要があります。
グローバル デプロイ アーキタイプ
グローバル デプロイ アーキタイプを使用すると、グローバル ロードバランサやグローバル データベースといった高可用性グローバル リソースを使用できます。クラウド リソースを設定して運用する労力は、リージョン リソースの複数のインスタンスを管理する必要があるマルチリージョン デプロイよりも少なくなる可能性があります。ただし、グローバル リソースの変更の管理は慎重に行う必要があります。
グローバル デプロイ アーキタイプを使用するアーキテクチャを運用する労力は、ロケーションを意識しない分散スタックをデプロイするか、リージョンに分離された複数のスタックをデプロイするかによっても異なります。
- ロケーションを意識しない分散アプリケーションは、より柔軟に拡張、スケーリングできます。たとえば、特定のコンポーネントで特定のロケーションにのみエンドユーザーの重要なレイテンシ要件がある場合、こうしたコンポーネントを必要なロケーションにデプロイし、残りのスタックを他のロケーションで運用できます。
- リージョンに分離された複数のスタックとしてデプロイされたアプリケーションの場合、次の理由により、運用とメンテナンスに多くの労力が必要になります。
- 複数のロケーションにあるアプリケーション スタックのステータスは、スタックレベルと各コンポーネントの両方でモニタリングする必要があります。
- コンポーネントがどのロケーションでも使用不能になった場合、処理中のリクエストを適切に処理する必要があります。
- アプリケーションの変更は慎重にロールアウトする必要があります。
- データベースはすべてのロケーションにわたって同期する必要があります。
ハイブリッド デプロイ アーキタイプとマルチクラウド デプロイ アーキタイプ
ハイブリッド トポロジやマルチクラウド トポロジでは、Google Cloud のみを使用するアーキテクチャよりも設定と運用により多くの労力が必要となります。
- リソースは、オンプレミス トポロジと Google Cloud トポロジの間で一貫した方法で管理する必要があります。コンテナ化されたハイブリッド アプリケーションを管理するには、GKE Enterprise のようなソリューションを使用できます。これは、複数のロケーションで Kubernetes クラスタのプロビジョニング、更新、最適化を行う統合クラウド運用モデルです。
- 複数のプラットフォーム間でリソースを効率的にプロビジョニングして管理する方法が必要です。Terraform などのツールを使用すると、プロビジョニングの労力を軽減できます。
- セキュリティの機能やツールは、クラウド プラットフォーム間で標準的なものではありません。セキュリティ管理者は、使用するすべてのクラウド プラットフォームを横断して分散しているリソースのセキュリティを管理するためのスキルと専門知識を獲得する必要があります。