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