このドキュメントでは、Google Distributed Cloud（GDC）エアギャップ ユニバースの複数のゾーンに高可用性（HA）ワークロードを設計してデプロイするための技術的なガイダンスとベスト プラクティスについて説明します。このガイドでは、ダウンタイムを最小限に抑え、ビジネスの継続性を確保するための主要なアーキテクチャ パターン、サービス構成、運用上の考慮事項について説明します。
このドキュメントの戦略は、次の技術専門家を対象としています。
復元力のあるインフラストラクチャとアプリケーション アーキテクチャを設計するクラウド アーキテクト。
HA ワークロードのデプロイ戦略、自動化、モニタリング、インシデント対応を実装する DevOps エンジニアとサイト信頼性エンジニア。
HA パターンと統合されたフォールト トレラントなアプリケーションを構築するアプリケーション デベロッパー。
詳細については、 GDC エアギャップ ドキュメントの対象読者をご覧ください。
高可用性の重要性
最新の分散システムでは、高可用性を計画することが重要です。 ダウンタイムは、ビジネスの中断、収益の損失、ユーザー エクスペリエンスの低下につながる可能性があります。
GDC を使用してプライベート データセンターで実行されるワークロードの場合、可用性は多くの場合、コア オペレーションの成功に直接関係します。特に、レイテンシの影響を受けやすいアプリケーションやミッション クリティカルなアプリケーションでは、その傾向が顕著です。復元力と信頼性の高いサービスを構築するには、最初から HA を考慮した設計が不可欠です。
GDC は、複数の切断されたデータセンター（ゾーン）を使用して、エアギャップ環境内でハイパースケール機能を提供します。 マルチゾーン アプリの HA は、ロード バランシングや非同期ストレージなどのマルチゾーン サービスに依存します。HA に使用する重要なサービスの詳細については、このドキュメントのスケーラビリティとロード バランシングと非同期ストレージを使用したゾーン間の HA アプリのデプロイをご覧ください。
ハイパースケール機能をローカルで提供
GDC は、 Google Cloud インフラストラクチャとサービスを エッジとデータセンターに拡張します。GDC はフルマネージドのハードウェアとソフトウェアのソリューションを提供し、GDC クラスタやその他のGoogle Cloud サービスで Google Kubernetes Engine（GKE）を実行して、データの生成と使用の場所に近い場所で実行できます。
このドキュメントでは、マルチゾーン トポロジで構成された GDC ユニバースについて説明します。この構成では、単一の ユニバース が同じロケーション内の複数の物理的に分離された ゾーン で構成されます。
これらのゾーンは、独立した電源、冷却、ネットワーキングを備えており、局所的な物理インフラストラクチャの障害から保護します。ゾーン間の低レイテンシ、高帯域幅のネットワーク接続により、データ レプリケーションと迅速なフェイルオーバーが可能になり、高可用性アプリケーションを構築するための基盤が形成されます。
スケーラビリティとロード バランシング
基本的なコンポーネントの冗長性に加えて、トラフィックを効果的に管理し、シームレスなスケーリングを有効にすることは、特に負荷条件が変化する場合に高可用性を維持するために不可欠です。GDC には、ロード バランシングと高度なトラフィック管理のためのメカニズムがいくつか用意されています。
南北トラフィック用の外部ロードバランサ
GKE on GDC クラスタの外部のユーザーまたはシステム（南北トラフィック）にアプリケーションを公開するには、GDC のマネージド外部ロード バランシング機能を使用します。外部ロードバランサ（ELB）サービスはこれらの機能を提供し、Kubernetes とシームレスに統合されます。
HA とスケーラビリティを提供する ELB サービスの主な特徴は次のとおりです。
マネージド サービス: GDC 固有のサービスとして実行され、 エアギャップ 環境での高可用性と復元力を実現するように設計されています。
外部アクセス: GDC マネージド プールから安定した外部 IP アドレスをプロビジョニングし、外部クライアントの一貫したエントリ ポイントを提供します。
ロードバランサと Kubernetes の統合: 特定の内部アノテーションなしで
Serviceのtype: LoadBalancerの Kubernetes を作成すると、ロードバランサが自動的にプロビジョニングされて 構成されます。ゾーン認識: GDC ユニバース内の使用可能なすべてのゾーンで実行されている正常なアプリケーション Pod に、受信トラフィックを分散します。ELB は、Pod の readiness プローブに依存してバックエンドの健全性を判断します。
スケーラビリティ: アプリケーションがノードとゾーンに水平スケーリングされるときに、外部トラフィックの分散を処理します。
外部トラフィックの上り（内向き）中継で HA を実現し、クライアント リクエストが障害が発生したゾーンまたはインスタンスから自動的に転送されるようにするには、外部ロードバランサを使用することをおすすめします。
詳細については、 外部ロードバランサを構成するをご覧ください。
東西トラフィック用の内部ロードバランサ
同じ GKE on GDC クラスタ内で実行されているサービス間の通信（東西トラフィック）の場合、GDC は内部ロードバランサ（ILB）を提供します。ILB は、内部サービスを分離し、高可用性とスケーラビリティを備えた内部通信パスを提供するために不可欠です。
HA とスケーラビリティを提供する ILB サービスの主な特徴は次のとおりです。
内部アクセス: クラスタノードやその他の内部サービスなど、GDC ネットワーク内からのみアクセスできる安定した内部 IP アドレスをプロビジョニングします。
ロードバランサと Kubernetes の統合: 内部にする必要があることを示す特定のアノテーションを使用して、
type: LoadBalancerの KubernetesServiceを作成することで、ロード バランシングをプロビジョニングします。例:networking.gke.io/load-balancer-type: "Internal"。ゾーン認識: 使用可能なすべてのゾーンにある、readiness プローブで 識別された正常なバックエンド Pod にトラフィックを分散します。この分散により、1 つのゾーンで問題が発生した場合に内部通信の障害を防ぐことができます。
サービス ディスカバリと分離: 安定した内部 IP アドレス と kube-dns および CoreDNS の統合による DNS 名を提供します。サービスは相互に検出して通信できるため、クライアントが個々の Pod IP アドレスを把握する必要がなくなります。
スケーラビリティ: 使用可能なすべての正常なレプリカにトラフィックを 分散することで、内部バックエンド サービスのスケーリングを容易にします。
ILB を使用してサービス間の内部通信を行うと、内部トラフィック フローがゾーン障害に対して復元力を持ち、効果的なスケーリングが可能になります。これは、外部 ELB と基盤となるコンピューティング分散によって提供される HA を補完します。この戦略は、フロントエンド API が Kubernetes クラスタ内のバックエンド API またはデータベースと通信する必要がある階層型アプリケーションでよく使用されます。
詳細については、 内部ロードバランサを構成するをご覧ください。
非同期ストレージを使用したゾーン間の HA アプリのデプロイ
GDC を使用すると、データソースの近くでインフラストラクチャとアプリケーションを実行できます。復元力のあるデータソースを使用して HA アプリケーションをデプロイするには、データの永続性と障害復旧のために非同期ストレージ レプリケーションを実装します。
ゾーンは、単一のユニバース内の個別の障害発生ドメインを表します。 アプリケーション コンポーネントを分散し、ゾーン間でデータを複製することで、局所的なハードウェア障害やメンテナンス イベントに対する復元力を大幅に向上させることができます。
詳細については、 マルチゾーン ストレージによるデータ保護をご覧ください。
次のステップ
非同期レプリケート ブロック ストレージを使用して、ゾーンに分散された仮想マシン（VM）のコレクションとしてサービスをデプロイするには、 HA VM アプリをデプロイするをご覧ください。
非同期的にレプリケートされた永続ボリュームを使用して、ゾーン間の Kubernetes にコンテナ化されたアプリケーションとしてサービスをデプロイするには、 をご覧ください。 HA コンテナ アプリをデプロイする
ゾーンとユニバースの詳細については、 GDC エアギャップのゾーンをご覧ください。