コンテンツに移動
Containers & Kubernetes

GKE Stateful High Availability(HA)Controller の公開プレビュー版が利用可能に

2023年10月27日
Google Cloud Japan Team

※この投稿は米国時間 2023 年 10 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

アプリケーションの要件に合わせた設計は、Google Kubernetes Engine(GKE)上の本番環境のアプリケーションにとって重要なビジネス上の考慮事項です。このことは、データベースやメッセージ キューなどのステートフル アプリケーションに特に当てはまります。しかし、ステートフル アプリケーションを実行するには、多くの場合、費用対効果か可用性のどちらかを選ばなければなりません。たとえば、単一のレプリカ アプリケーションを単一のゾーンで実行すると、費用を最小限に抑えることはできますが、可用性とはトレードオフになります。あるいは、より高い可用性が必要な場合は、複数のアプリケーション レプリカを実行することで、ノード障害に備えたデータの冗長性を確保できますが、その冗長性を確保するには、コンピューティング インフラストラクチャとネットワーク インフラストラクチャに費用をかける必要があります。

さらに、Kubernetes では、中断イベント(アップグレード、ゾーン障害など)中に、スケジューラが結果整合性アプローチに従います。これはステートレス アプリケーションでは機能しますが、お客様はステートフル アプリケーションに対するよりプロアクティブなアプローチを求めており、フェイルオーバー時間を制御するとともに、中断イベント中のステートフル アプリケーションの動作を可視化したいと考えています。

お客様は中間点、つまり、単一のレプリカ アプリケーションによる費用対効果を維持しながら、複数のレプリカによる可用性も利用できることを望んでいます。これを支援するために、Google はこのたび、GKE の Stateful HA Operator をリリースいたします。これは、費用と可用性のバランスをとりながら、ステートフル アプリケーションにプロアクティブなスケジューリングをもたらす新機能です。Stateful HA Operator はプレビュー版が公開されます。

Stateful HA Operator がステートフル アプリケーションの可用性と費用のバランスをとるうえでどのように役立つかについて詳しく見ていきましょう。

Stateful HA Operator の概要

おおまかに言うと、Stateful HA Operator はステートフル アプリケーションにプロアクティブな制御を提供するもので、リージョン永続ディスク(RePD)との統合を通じて可用性を向上させます。

低費用の可用性ツールの多くは結果整合性のあるフェイルオーバーを提供しますが、そのフェイルオーバー プロセスには 10 分ほどかかります。業界の代表的な目標復旧時間(RTO)である 60~120 秒を達成したい場合、これは長すぎます。Stateful HA Operator を使用すれば、この遅延が軽減されるとともに、ワークロードのレベルごとにフェイルオーバーへのレスポンスをカスタマイズできるため、フェイルオーバー時間をビジネス上の要件に一致させることができます。また、完全なオブザーバビリティも備えているため、フェイルオーバー アクティビティを監査および追跡できます。

一方、リージョン永続ディスクの使用により、費用と可用性の関係に新しい選択肢が生まれます。リージョン永続ディスクは、リージョン内の 2 つのゾーン間でデータの同期レプリケーションを行うストレージ オプションです。一般に、別のストレージを追加することは、追加のコンピューティングを実行するよりも安価であり、かつ、RePD ではゾーンをまたいだネットワーク料金が請求されないため、費用と可用性のバランスをとることができます。Stateful HA Operator を Spare Capacity または PriorityClass と組み合わせることで、どのような障害が発生した場合でも、フェイルオーバーに対応可能なコンピューティング容量をアプリケーションに確保することができます。

図 1. Stateful HA の費用と可用性の相関を表す概念図

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_SQHBdjk.max-1100x1100.png
https://storage.googleapis.com/gweb-cloudblog-publish/images/2_0dbG1rQ.max-1300x1300.png

事例紹介

ユースケース 1: 8% の費用増のみで単一レプリカ PostgreSQL の可用性をアップグレード

正規価格での合計料金が月額 391 ドルの標準的な高可用性単一レプリカ PostgreSQL アプリケーション*を考えてみましょう。単一レプリカ アプリケーションは中断される可能性があり、RTO は数時間から数日かかる場合があります。

Stateful HA Controller をインストールし、リージョン永続ディスクによるフェイルオーバーの調整を許可することで、ゾーン障害などの中断に対する耐性を 8% のわずかな費用増で追加できます。Stateful HA Operator は、事前構成されたタイムアウトの範囲内でレプリカのスケジュールを調整するため、非常に魅力的な費用でアプリケーションの非稼働時間を最小限に抑え、SLA に適合させることができます。可用性がさらに必要な場合は、フェイルオーバーのコンピューティング容量を追加することもできます。

図 2. 単一レプリカ Postgres アプリケーションを GKE Stateful HA に最適化されたインフラに変換する

https://storage.googleapis.com/gweb-cloudblog-publish/images/Stateful_HA_Images-01.max-2200x2200.jpg
https://storage.googleapis.com/gweb-cloudblog-publish/images/4_x4JLtId.max-1000x1000.png

*料金は、3x e2-standard-16 VM シェイプ、200 GiB pd-ssd ストレージ要件、6 MiBps 上り(内向き)を想定。標準 PostgreSQL(1 レプリカ)および Stateful HA(1 レプリカ、リージョン複製ストレージ)の構成と料金の前提条件については、こちらをご覧ください。

ユースケース 2: マルチレプリカ Kafka の費用を削減することで、最大 53% の費用を節約

一部のアプリケーションでは、ノード障害が発生した場合に備えて高い RTO を維持する必要がありますが、ゾーン間のアプリケーションのレプリケーションにより、追加のコンピューティング費用とストレージ費用が発生します。万が一ゾーンに障害が発生した場合は、すべてのレプリカをプライマリ ゾーンからセカンダリ ゾーンに再スケジューリングできます。これにより、アプリケーションは通常の運用下でゾーン間のネットワーク費用の節約を最適化できます。

Kafka はフラットなネットワーク上で実行されるように設計されています。アプリケーションによっては、ゾーン間のデータ レプリケーションがアプリケーションの総費用の 80% を超え、コンピューティングとストレージの双方の費用を大幅に上回る可能性があるものもあります。Kafka は、ゾーン分離と同じ原理で動作できます。6 レプリカの Kafka アプリケーションを考えてみましょう。すべての Kafka ブローカーをゾーン間で均等に分散すると、正規価格での合計料金は月額 3,969.54 ドルになります。Stateful HA Controller をインストールすれば、費用を最大 53% 削減できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Stateful_HA_Images_1-01.max-2200x2200.jpg

図 3. マルチレプリカ Kafka アプリケーションを変換し、Stateful HA に最適化させる

https://storage.googleapis.com/gweb-cloudblog-publish/images/6_wtuSVLR.max-1000x1000.png

*料金は、6x e2-standard-16 VM シェイプ、500 GiB pd-balanced ストレージ要件、20 MiBps 上り(内向き)を想定。標準 Kafka(3 ゾーン)および Stateful HA Kafka(1 ゾーン)の構成と料金の前提条件については、こちらをご覧ください。

Helm 経由で GKE Stateful HA Operator を試す

Stateful HA Operator は完全に自動化されたソリューションで、アプリケーションをカスタマイズする労力を軽減し、可用性のニーズを満たします。今ならテストクラスタでプレビュー版をお試しいただけます。インストールの手順については、ドキュメントをご覧ください。

-ソフトウェア エンジニア Peter Schuurman

-シニア プロダクト マネージャー Akshay Ram

投稿先