AlloyDB for PostgreSQL は、トランザクションと分析のハイブリッド処理など、特に要求の厳しいワークロード向けに設計された、PostgreSQL 対応のフルマネージド データベース サービスです。AlloyDB は Google が構築したデータベース エンジンと、クラウドベースのマルチノード アーキテクチャを組み合わせたもので、エンタープライズ グレードのパフォーマンス、信頼性、可用性を提供します。
AlloyDB の仕組み
アプリケーションは、標準の PostgreSQL プロトコルと手法を使用して AlloyDB インスタンスに接続します。その後、アプリケーションは PostgreSQL クエリ構文を使用してデータベースを操作します。
AlloyDB は、データの可用性を最大化し、クエリのパフォーマンスとスループットを最適化するように設計された、クラウドベースのコンポーネントと機能の階層を利用しています。 Google Cloud管理ツールを使用すると、AlloyDB デプロイの状態をモニタリングし、ワークロードの変化する需要に最適なスケールとサイズを調整できます。
クラスタ
特定の Google Cloudリージョン内の単一の AlloyDB デプロイメントでは、すべてのリソースが 1 つのクラスタに編成されます。これには、すべてのデータベース、ログ、その他のメタデータが含まれます。AlloyDB は、1 つのクラスタのすべてのリソースを単一の Virtual Private Cloud（VPC）内にデプロイし、Google が設計し AlloyDB 用に最適化されたクラウドベースのファイル システムを使用します。
ノードとインスタンス
クラスタには複数のnodesが含まれます。ノードは、アプリケーションがクラスタのデータのクエリに使用する PostgreSQL 互換データベース エンジンの実行専用の仮想マシン インスタンスです。AlloyDB は、ノードをインスタンスに編成します。各インスタンスには、VPC 内のプライベート静的 IP アドレスがあります。実際には、アプリケーションは PostgreSQL プロトコルを使用してこれらの IP アドレスのインスタンスに接続します。インスタンスは、SQL クエリをノードに渡します。
AlloyDB には次の 2 種類のインスタンスがあります。
プライマリ インスタンス: 各クラスタには 1 つのプライマリ インスタンスがあり、データへの読み取りまたは書き込みアクセス ポイントを提供します。プライマリ インスタンスは、高可用性（HA）または基本のいずれかです。
HA プライマリ インスタンス: HA プライマリ インスタンスには、アクティブ ノードとスタンバイ ノードの 2 つのノードがあります。AlloyDB はアクティブ ノードの可用性をモニタリングし、必要に応じてスタンバイ ノードをアクティブ ノードに自動的に昇格させます。
基本インスタンス: 高可用性が不要な非本番環境では、必要に応じて基本インスタンスを使用できます。基本インスタンスにはノードが 1 つしかなく、スタンバイ ノードはありません。詳細については、基本インスタンスを使用してコストを削減するをご覧ください。
読み取りプール インスタンス: クラスタには、必要に応じて 1 つ以上の読み取りプール インスタンスを含めることができます。各読み取りプール インスタンスには、クラスタ全体で最大 20 個の読み取り専用ノードを含めることができます。AlloyDB は、読み取りプール インスタンスに送信されたすべてのリクエストを自動的にロード バランシングし、インスタンスのノードに転送します。
シンプルなユースケースでは、クラスタにプライマリ インスタンスのみを配置し、読み取りプールを使用せず、すべてのクエリにプライマリ インスタンスを使用するようにします。負荷の高い作業の場合は、読み取りプール インスタンスをクラスタに追加できます。次に、読み取りリクエストを送信するようにレポート アプリケーションまたは分析アプリケーションを構成します。この方法では、プライマリ インスタンスの負荷が軽減され、負荷が複数のノードに分散されるため、スケーラビリティが向上します。
アプリケーションのニーズに応じて、読み取りプール インスタンスのノード数をいつでも追加、削除、調整できます。また、必要に応じて、インスタンスの構成ノードのメモリと vCPU の数を最小限のダウンタイムで変更することもできます。AlloyDB はデータをインスタンスではなくクラスタの柔軟なストレージ レイヤに保存するため、インスタンスのスケーリングでデータが失われるリスクはありません。
この図は、負荷の高いワークロードを処理するようにスケーリングされたクラスタの例を示しています。このクラスタには、複数のロード バランシング リードオンリー インスタンスが含まれています。
主な機能
AlloyDB は、前述のマルチノード アーキテクチャに固有の垂直方向と水平方向のスケーリングの利点を超えて、さまざまな点で標準の PostgreSQL インストールと区別されます。以降のセクションでは、AlloyDB の主な機能について詳しく説明します。
自動化と適応型のデータベース機能
すべての AlloyDB ノードに搭載されている PostgreSQL と完全に互換性のあるデータベース エンジンには、インスタンスが処理するクエリの構造と頻度を継続的に分析する機能がいくつかあります。この情報を使用して、スキーマの改善を提案したり、最適化を自動的に適用したりします。
インデックス アドバイザーは、使用パターンに基づいて新しいインデックスを使用してデータベース スキーマを最適化する機会を見つけるのに役立ちます。
カラム型エンジンは、カラム形式を使用してデータをメモリに保存することで、分析クエリのパフォーマンスを高速化できます。これにより、AlloyDB は高度な処理手法を使用して、必要に応じて大量のテーブルデータを効率的にスキャンできます。
PostgreSQL の古いデータの自動バキューム機能の適応型バリエーションは、ワークロードの形状に最適なようにバキューム関連のパラメータを自動的に調整します。
自動メモリとストレージ管理システムは、AlloyDB が動作する Google が構築したクラウドベースの環境を活用し、必要に応じてメモリとストレージを継続的に割り当て、解放して、最適なパフォーマンスとリソース効率でクラスタを継続的に実行します。
高可用性
デフォルトでは、AlloyDB クラスタは、2 つの異なるゾーンに配置されたプライマリ インスタンスの冗長ノードを通じて、自動フェイルオーバーで可用性（HA）を提供します。
HA を必要としない非本番環境で動作するクラスタでは、必要に応じて基本的な単一ゾーンプライマリ インスタンスを使用できます。
2 つ以上のノードを含む読み取りプール インスタンスを追加すると、データへのロードバランスされたマルチゾーン高可用性アクセス ポイントがさらに作成されます。すべての読み取りプール インスタンスは、プライマリ インスタンスから独立して実行されます。
リージョン固有の考慮事項の詳細については、地域とリージョンをご覧ください。
データのバックアップと障害復旧
AlloyDB には、調整可能な保持期間内の任意の時点に基づいて新しいクラスタを作成できる継続的なバックアップと復元システムが用意されています。これにより、データ損失の事故から迅速に復旧できます。
AlloyDB ではさらに、オンデマンドで、または定期的に、クラスタのデータの完全なバックアップを作成して保存できます。バックアップから新しい AlloyDB クラスタに復元できます。このクラスタには、バックアップの作成時点で元のクラスタのすべてのデータが含まれています。
詳細については、バックアップについてをご覧ください。
障害復旧の追加方法として、別々の Google Cloudリージョンにセカンダリ クラスタを作成することで、クロスリージョン レプリケーションを実現できます。AlloyDB は、指定されたプライマリ クラスタから各セカンダリ クラスタにデータを非同期でストリーミングします。必要に応じて、セカンダリ クラスタをプライマリ インスタンスと読み取りプール インスタンスを含む完全な機能の AlloyDB クラスタに昇格できます。
詳細については、クロスリージョン レプリケーションについてをご覧ください。
セキュリティとアクセス制御
安全な AlloyDB Auth Proxy への接続を必須にするようにクラスタを構成できます。このプロキシは、アクセス制御に Google Cloud Identity Access and Management（IAM）を使用します。詳細については、承認をご覧ください。
AlloyDB は、認証に標準の PostgreSQL ユーザーロール システムを使用し、AlloyDB に固有のロールもいくつか追加しています。詳細については、AlloyDB ユーザーロールを管理するをご覧ください。
暗号化
AlloyDB は、デフォルトで Google の暗号化方法を使用してすべての保存データを保護します。指定した鍵を使用してデータを暗号化する必要がある場合は、クラスタの作成時に顧客管理の暗号鍵（CMEK）を指定できます。AlloyDB は、CMEK 鍵を使用して、そのクラスタに書き込まれたすべてのデータを暗号化します。
CMEK はバックアップにも適用されます。CMEK 鍵は、オンデマンド バックアップの作成、バックアップ スケジュールの構成、バックアップからの復元時に指定できます。
詳細については、CMEK についてをご覧ください。
スムーズなメンテナンス
AlloyDB のメンテナンス オペレーションは、データベースの中断を最小限に抑えるように設計されています。プライマリ インスタンスとセカンダリ インスタンスのダウンタイムは 1 秒未満ですが、読み取りプールはダウンタイムなしで継続的に使用できます。これは、交換用サーバーを準備し、準備ができたらアクティブなサーバーとすばやく入れ替えることで実現します。このプロセス中、データベースへのアクティブな接続は一時的に破棄されます。このプロセス全体を通して、データベースを通常どおり使用できます。
この交換プロセスではダウンタイムを最小限に抑えますが、 Google Cloud コンソールと Google Cloud CLI に示されているように、全体的なオペレーションには数分かかることがあります。
これらのメンテナンス オペレーションには、Google が実行する定期的なメンテナンス タスクと、フラグの構成やインスタンスのサイズ変更など、手動で実行するタスクが含まれます。ダウンタイムが長くなる場合でも、更新をすぐに適用する場合は、FORCE_APPLY データベース フラグを使用します。
拡張機能のサポート
AlloyDB には、一般的な PostgreSQL 拡張機能が多数サポートされています。完全なリストについては、サポートされているデータベース拡張機能をご覧ください。
セルフホストの代替手段: AlloyDB Omni
Google Cloud内で AlloyDB を実行する代わりに、Google は AlloyDB Omni を提供しています。このシンプルな AlloyDB ダウンロード版を使用すると、強力なデータベース エンジンを独自の Linux ベースのコンピューティング環境で実行できます。
詳細については、AlloyDB Omni についてをご覧ください。