コンテンツに移動
データベース

AlloyDB ホットスタンバイ: 高速なフェイルオーバー、安定したパフォーマンス

2026年6月12日
Emir Okan

Senior Product Manager

Ramkumar Vadali

Engineering Manager

Try Gemini Enterprise Business Edition today

The front door to AI in the workplace

Try now

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

AlloyDB for PostgreSQL は、特に要求の厳しいエンタープライズ データベース ワークロード向けに設計された、PostgreSQL 互換のフルマネージド データベース サービスです。PostgreSQL の優れた機能と Google の強みを組み合わせ、卓越したパフォーマンス、スケーラビリティ、可用性を実現します。Google は、AlloyDB のレジリエンスをさらに高めるべく絶えず革新を続けており、このたび、高可用性(HA)アーキテクチャの重要なアップグレードであるホットスタンバイを発表しました。

AlloyDB の HA アーキテクチャ

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_SeSBztp.max-1100x1100.png

高可用性用に構成された AlloyDB プライマリ インスタンスは、レジリエンスを確保するために、リージョン内の異なるゾーンに配置されたアクティブ ノードとスタンバイ ノードで構成されています。AlloyDB のクラウドネイティブ アーキテクチャでは、コンピューティングとストレージが分離されているため、各リソースを個別にスケールできます。データベースの write-ahead log(WAL)は、耐久性を確保するためにリージョン ログ永続化レイヤに同期的に書き込まれます。一方、データブロックは AlloyDB のリージョン ストレージ サービスに保存されます。ロードバランサは、固定 IP アドレスを使用して、現在アクティブなノードにトラフィックを転送します。

従来の HA モデルでは、アクティブ ノードが使用できなくなった場合、AlloyDB が自動的にフェイルオーバーを開始し、スタンバイ ノード(PostgreSQL からはアイドル状態に見えている)が、データベースを起動し、残りのログを処理し、アクティブ ノードを引き継ぎます。これにより高可用性が確保されますが、データベースの起動時間とそれに続くキャッシュ ウォーミング期間が、アプリケーションの復旧時間やパフォーマンスに影響を与える可能性がありました。

新しいアーキテクチャ: AlloyDB ホットスタンバイ

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

このたび新たに提供を開始したホット スタンバイ機能により、スタンバイ ノードの役割は大きく変わります。スタンバイ ノードは、受動的なノードではなくなり、プライマリからストリーミングされる WAL レコードを継続的に適用するようになります。このアーキテクチャの変更により、2 つの大きなメリットがもたらされます。

  1. フェイルオーバー時間の劇的な短縮: スタンバイ側では PostgreSQL がすでに実行、初期化されており、アクティブにレプリケートされているため、障害発生時にスタンバイをプライマリに昇格させるために必要な時間が大幅に短縮されます。システムは障害を検出(通常は 30 秒以内)し、スタンバイを昇格させて接続をリダイレクトします。スタンバイ側でのデータベース起動フェーズが不要になるため、全体的なダウンタイムや目標復旧時間(RTO)を短縮できます。

  2. フェイルオーバー後の安定したパフォーマンス: ホットスタンバイ ノードはログをアクティブに再生するため、そのメモリ キャッシュ(PostgreSQL バッファ キャッシュなど)は「ウォーム」な状態に保たれます。このキャッシュには、プライマリ ノードのキャッシュと同様に、アクセス頻度の高いデータが多く含まれています。フェイルオーバーが発生すると、新しいプライマリはほぼ即座に最適な速度でリクエストを処理できます。これにより、キャッシュがディスクからウォームアップする間に通常見られるパフォーマンスの「ブラウンアウト」を回避し、アプリケーションのパフォーマンスを安定させることができます。

そして何よりすばらしいのは、この可用性とレジリエンスの大幅な向上は、追加費用なしで実現できます。

ホットスタンバイの仕組み

新しいホット スタンバイ HA と従来の HA 構成の違いを示す簡単なデモをご用意しました。この動画では、2 つの AlloyDB インスタンスでベンチマーク負荷を実行し、両方で同時にフェイルオーバーをトリガーしています。

https://storage.googleapis.com/gweb-cloudblog-publish/original_images/AlloyDB_Hot_Standby_Final_Video_v1_-_GIF.gif

デモの概要:

  • ホットスタンバイのインスタンスは、約 15 秒でフェイルオーバーを完了します。重要なのは、1 秒あたりのトランザクション数(TPS)がフェイルオーバー前のレベルにほぼ即座に戻ることです。

  • 従来の HA のインスタンスでは、フェイルオーバーの完了に明らかに時間がかかっています。オンラインに戻った後も、TPS は大幅に低下したままであり、キャッシュがウォームアップし、元のパフォーマンス レベルに戻るまで数分を要しています。

このように並べて比較すると、ダウンタイムを最小限に抑え、フェイルオーバー後のパフォーマンスへの影響を排除できるホットスタンバイのメリットが明確にわかります。

強化された HA を使ってみる

ホットスタンバイは、PostgreSQL 18 で新規作成される AlloyDB インスタンスに順次ロールアウトされ、アップグレードされた HA エクスペリエンスを自動的に提供します。また、以前のメジャー バージョンも、今後数か月以内にロールアウトされる予定です。AlloyDB の 99.99% の SLA は引き続き確保され、フェイルオーバーが高速化されたほか、フェイルオーバー後のパフォーマンスの予測可能性も向上しています。

この機能強化は、最高水準のエンタープライズ グレードのマネージド PostgreSQL エクスペリエンスを提供するという Google のコミットメントをさらに明確に示すものです。

AlloyDB の高可用性機能の詳細については、公式ドキュメントをご覧ください。AlloyDB をまだご利用でない場合は、今すぐお試しください。

- シニア プロダクト マネージャー、Emir Okan

- エンジニアリング マネージャー、Ramkumar Vadali

投稿先