トップ > AlloyDB > AlloyDB for PostgreSQLを徹底解説！

AlloyDB for PostgreSQLを徹底解説！

AlloyDB Google Cloud 徹底解説シリーズ
記事タイトルとURLをコピーする

G-gen の杉村です。Google Cloud (旧称 GCP) の PostgreSQL 互換のフルマネージドサービスである AlloyDB for PostgreSQL について解説します。

概要

AlloyDB とは

AlloyDB for PostgreSQL とは Google Cloud が提供する PostgreSQL 互換のフルマネージドサービスです。2022年5月11日に Preview 公開され、その後、2022年12月13日に GA となりました。

Cloud SQL と同じく DBaaS (DB as a Service) として分類することができますが、AlloyDB はパフォーマンス・可用性・スケーラビリティの面で通常の PostgreSQL よりも優れており、特に厳しい非機能要件があるエンタープライズシステムに対応できるデータベースとして位置づけられています。

AlloyDB はストレージ機構などに独自の技術が使用されており、その性能は標準の PostgreSQL と比較してトランザクション処理では「4倍以上高速」、分析処理では「最大100倍高速」と公称されています。

またバックアップ、パッチ適用、ストレージの拡張など多くの運用タスクが自動化されており、運用の容易さも特徴です。可用性 SLA は 99.99% です。

サービスの位置づけ

フルマネージドのデータベースサービスとしては他に Cloud SQL がありますが、AlloyDB は特に高いパフォーマンスが求められるシステムに対応できるデータベースとして位置づけられています。

なおこの立て付けは Amazon Web Services (AWS) において Amazon RDS と Amazon Aurora が別個に存在するのと似ています。Google Cloud サービスとしての位置づけは Amazon RDS が Cloud SQL、Amazon Aurora が AlloyDB にそれぞれ対応していると考えて良いでしょう。

なお名前に for PostgreSQL と冠してはいますが、他の DB エンジン版の AlloyDB の提供は今のところありません。

PostgreSQL との互換性

AlloyDB は PostgreSQL との「100% 互換」を謳っています。2024年1月現在では、PostgreSQL 14 または 15 との互換性を持った AlloyDB クラスタを構築できます。

データベースの接続に psql コマンドラインなどの PostgreSQL 用クライアントを用いることができるほか、PostgreSQL の各種パラメータや拡張機能 (extension) に対応しています。

通常の PostgreSQL では postgresql.conf 等で設定する各種パラメータは、AlloyDB では データベースフラグ と呼ばれる設定値として管理され、Web コンソールや gcloud コマンドで管理します。

既存の PostgreSQL データベースから AlloyDB への移行を検討する際、パラメータや拡張機能が AlloyDB でも利用可能なのか、以下の公式ドキュメントで確認する必要があります。

料金

AlloyDB は、利用した分だけ料金が発生する従量課金です。以下の軸で課金されます。

  • 割り当てた CPU/Memory
  • 利用したストレージ (バックアップ用含む)
  • ネットワーク (他リージョンへの egress のみ)

AlloyDB には「プライマリインスタンス」と「リードプールノード」が存在し、それぞれスペック (CPU/Memory) を指定できます。インスタンスが存在した時間に応じ、時間単位で課金が発生します。

またストレージはデータベースに必要な分のサイズが自動的に割り当てられ、自動でスケールアップ・ダウンします。利用したデータサイズ分だけの課金が発生します。

以下は 2 vCPU / 16 GB のプライマリインスタンス + スタンバイインスタンスという構成で、ストレージ利用が 100 GB の場合の利用料金の試算です (2024年1月時点、東京リージョン)。

  • vCPU: $0.08458 * 2 vCPU * 730h * 2 VMs = $246.9736 /月
  • Memory: $0.01434 * 16 GB RAM * 730h * 2 VMs = $334.9824 /月
  • Storage: $0.000526 * 100 GB * 730h = $38.398 /月

→ 計 $620.354 /月

さらに、バックアップストレージにも課金が発生します。

上記は記事執筆時点の単価で試算しています。最新の料金は、以下の公式ページをご参照ください。

アーキテクチャ

クラスタ

AlloyDB for PostgreSQL の基本の管理単位は クラスタ です。クラスタの全体像は以下の図の通りです。

クラスタの全体像

プライマリインスタンス

クラスタは プライマリインスタンス を持ちます。プライマリインスタンスはクラスタに一つだけですが「高可用性」設定にするとフェイルオーバ用のレプリカ (スタンバイインスタンス) を持つことができます。

クライアントは読取・書込アクセスをこのプライマリインスタンスに向けて行います。そのための単一の IP アドレスが発行されます。IP アドレスはフェイルオーバしても変わりません。

プライマリインスタンスのスタンバイインスタンスが存在するクラスタを「高可用性 (High available) クラスタ」と呼び、単一のプライマリインスタンスしか持たないクラスタを「基本 (Basic) クラスタ」と呼びます。なおサービスリリース当初は高可用性クラスタのみでしたが、2023年9月21日のアップデートにより、基本クラスタが作成可能になりました。

リードプールインスタンス

リードプールインスタンスは、読取専用アクセスを提供するノードの 集合体 です。つまりリードプールインスタンスという語は単一のノードを指すのではなく、読取専用ノードのグループを指します。

リードプールインスタンスには読取用の IP アドレスが発行され、その IP アドレスへのアクセスはリードプールインスタンスのいずれかのノードに割り振られます。ノードの数を増減することで、読取ワークロードを負荷分散することが可能です。

プライマリインスタンスは必須ですが、リードプールインスタンスの作成は任意です。作成すると利用料金が発生する代わりに、分析的な用途を含む読取ワークロードを分散させることができます。

ネットワーク

AlloyDB のクラスタはユーザが管理する VPC (Virtual Private Cloud : 仮想ネットワーク) の中ではなく Google Cloud が管理する VPC の中に作成されます。

ユーザの VPC ではなく Google Cloud が管理するマネージドな VPC であるという点がポイントです。これは プライベートサービスアクセス という仕組みであり、クラスタが配置される Google Cloud 管理の VPC を サービスプロデューサーのネットワーク と呼びます。これは Cloud SQL や Cloud Memorystore などと同じ仕組みです。

サービスプロデューサーのネットワークとユーザの VPC は VPC ピアリングで接続することになります。

AlloyDB のネットワーク構成

クロスリージョン・レプリケーション

AlloyDB ではオプションとして クロスリージョン・レプリケーション を利用可能です。クロスリージョン・レプリケーションを有効化すると、メインのクラスタ (プライマリ・クラスタ) とは別のリージョンにセカンダリ・クラスタが作成され、非同期でデータがレプリケーションされます。

セカンダリ・クラスタは読み取り専用のクラスタであり、手動でプライマリに昇格させることができます。

クロスリージョン・レプリケーションは災害対策目的のほか、ユーザやアプリケーションに近いリージョンに読み取り専用のセカンダリ・クラスタを置くことで読み取りレイテンシの改善にも用いることができます。

可用性

スタンバイインスタンス

前述の通り、プライマリインスタンスは任意でフェイルオーバ用レプリカ (スタンバイインスタンス) を持つことができます。

アクティブ系のプライマリインスタンスに異常が検知されると、自動的にスタンバイインスタンスにフェイルオーバが発生します。

フェイルオーバしても、読取・書込用の IP アドレスは変わりませんので、アプリケーションからは一定時間のダウンタイムのあと、設定変更なしで再度コネクションを張ることができます。

またフェイルオーバをテストするため、手動でフェイルオーバを発生させることも可能です。

読取ワークロードの可用性

リードプールインスタンスには複数のノードを含むことができます。

読取専用 IP アドレスが一つ払い出され、この単一の IP アドレスにアクセスすれば、いずれかのノードに割り振られます。リードプールインスタンスに複数のノードを作成することで、読取専用ワークロードの可用性を高めることが可能です。

可用性 SLA

AlloyDB for PostgreSQL の可用性 SLA は 99.99% です。

所定の計算方法に従った月間稼働率がこれを下回った場合、Financial Credits が還元されます（要申請）。

なお SLA が適用されるには、クラスタが「Multi-zone instance」である必要があります。これは「プライマリインスタンスの高可用性設定が有効化されている」または「最低2ノードのリードプールインスタンスを持っている」状態を指します。

災害対策 (DR)

前述のクロスリージョン・レプリケーションを用いることで、リージョンをまたいだ災害対策 (Disaster Recovery) を実現できます。

クロスリージョン・レプリケーションを有効化すると、別リージョンのセカンダリ・クラスタ (読み取り専用) にデータが非同期でレプリケーションされます。プライマリ・クラスタのリージョンがダウンした際には、セカンダリ・クラスタを読み書き用のプライマリクラスタに昇格させることができます。

スケーラビリティ

AlloyDB のスケーラビリティの概念を整理すると、大まかに以下のようになります。

対象 垂直スケール 水平スケール
プライマリインスタンス 可 (マシンタイプ変更) 不可
リードプールインスタンス 可 (マシンタイプ変更) 可 (ノード数変更)

プライマリインスタンスは読み書きを司る単一のインスタンスのため、水平にスケールすることはできませんが、スペック変更による垂直スケールは可能です。

リードプールインスタンスは読み取り専用のノード集団ですので、ノード数を増やして水平にスケールすることも、スペックを上げて垂直にスケールすることも可能です。

分析 (OLAP)

AlloyDB カラムナエンジンとは

AlloyDB は業務用データベースとして OLTP (Online Transaction Processing) 処理に向いたデータベースです。しかし AlloyDB カラムナエンジン を搭載しており、分析的処理 (OLAP - Online Analytical Processing) も高速に行うことができます。

なおこのように OLTP と OLAP の両方のワークロードを処理できる特性を持つデータベースを HTAP (Hybrid Transaction Analytical Processing) データベースと呼ぶこともあります。

カラムナとは「列指向」を意味しており BigQuery を始めとする多くの分析用データベースが列指向データベースです。AlloyDB ではカラムナエンジンにより、テーブルの特定データを列志向でメモリ上に保持することで、集計等の分析的なクエリを高速に処理できます。

カラムナエンジンはデータベースフラグ (AlloyDB の設定パラメータ) google_columnar_engine.enabled を on にすることで有効化されます(インスタンス再起動が発生)。デフォルトだとインスタンスのメモリの 30% が割り当てられますが、この値もデータベースフラグで設定可能です。

カラムナエンジンによりメモリ上に保持される領域はカラムストア (column store) と呼ばれます。カラムストアには特定の型のデータしか入りませんが、一般的な型はサポートされています。詳細は以下のドキュメントをご参照ください。

自動カラムナ化

カラムナエンジンでは 自動カラムナ化 (auto-columnarization) が利用可能です。

自動カラムナ化はアプリケーションのワークロードを自動で分析し、現在のカラムナストア割り当て容量も考慮しつつ、カラムストアに入れるべき列を決定します。

新規インスタンスでは自動カラムナ化はデフォルトで有効で、1 時間に一度、カラムストアの内容を更新・最適化します。

自動カラムナ化は無効化したり、頻度を変更したり、あるいは即時実行することが可能です。

手動でのカラムストア管理

前述の自動カラムナ化のほか、手動でカラムストアを管理することもできます。

google_columnar_engine.relations フラグに DATABASE_NAME.SCHEMA_NAME.TABLE_NAME(COLUMN_LIST) の形式で定義することで、明示的にカラムストアに入れるべき列名を指定できます。

バックアップ・リストア

バックアップの種類

AlloyDB のバックアップは、バックアップ という名称のクラウドリソースとして取得することができます。バックアップには以下の3種類があります。

なおバックアップの取得はストレージレイヤで完結するため、実行してもパフォーマンス影響は無いとされています。

名称 説明
継続バックアップ (Continuous backups) デフォルトは有効化。ポイントインタイムリカバリを可能にするバックアップ
オンデマンドバックアップ (On-demand backups) 手動で採取されたバックアップ。Google Cloud コンソールや gcloud コマンド等で実行
自動バックアップ (Automated backups) 自動スケジュールで取られたバックアップ。デフォルトで有効 (日次・14日保持)

継続バックアップとそのリストア

継続バックアップ (Continuous backup) はポイントインタイムリカバリ (クラスタを任意の時点に巻き戻すリカバリ) を可能にするバックアップです。デフォルトで有効化されています。

継続バックアップが有効化されていると、1日に1回、データの変更に対する変更ログが増分でバックアップされるようになります。このバックアップを使い、既存クラスタを任意の時点まで巻き戻す (ポイントインタイムリカバリ) ことが可能です。マイクロセカンドの粒度で、最大で過去 35 日まで巻き戻すことができます。

継続バックアップは1〜35日間分のバックアップ取得するよう設定できます。デフォルトでは14日間の設定になっています。

オンデマンドバックアップ・自動バックアップとそのリストア

オンデマンドバックアップと自動バックアップは、クラスタのある時点のスナップショットを取得するバックアップです。これら2つの違いは取得契機が手動か自動か、の違いです。

オンデマンドバックアップまたは自動バックアップからのリストアは、新しいクラスタとして 行われます。つまり、既存クラスタの中身がバックアップの時点に巻き戻るのではなく、バックアップを取った時点のデータを使って新規クラスタを作成することになります。なおこれは Compute Engine や Cloud SQL のバックアップ（スナップショット）と同様です。

最長1年の期限を設定可能で、期限が過ぎたバックアップは自動的に削除されます。

なおオンデマンドバックアップは毎回フルバックアップになるのに対して、自動バックアップは増分バックアップ (incremental backup) です。これは、データ保存料金に影響するため、料金試算に留意が必要です。

接続

クライアント

AlloyDB for PostgreSQL へは psql コマンドなど、通常の PostgreSQL のクライアントソフトウェアから接続することができます。

ネットワーク

クライアントから、プライマリインスタンスもしくはリードプールインスタンスが提供する単一のプライベート IP アドレスに接続します。なおこれらの IP アドレスはインターネットには公開されません。

VPC ファイアウォールで TCP ポート 5432 への Egress (外向き) 通信が許可されている限り、AlloyDB クラスタを作成したサービスプロデューサーネットワークと接続されている VPC 内の VM からは、AlloyDB クラスタに接続することができます。

認証・認可

後述の AlloyDB Auth proxy を使わない限り、データベースユーザの考え方は PostgreSQL と同様です。

クラスタ作成直後は postgres ユーザでログインすることができます。ログイン用パスワードはクラスタ作成時に指定します。開発やアプリケーションからの接続のためには、管理特権を持たないユーザを新規作成することが推奨されます。

AlloyDB Auth proxy

AlloyDB Auth proxy とは

AlloyDB Auth proxy は AlloyDB を利用するアプリケーション側のローカルにインストールする、プロキシソフトウェアです。AlloyDB Auth proxy の利用は必須ではありませんが、推奨されています。

AlloyDB Auth proxy 経由で AlloyDB に接続することで、AlloyDB に IAM 権限で認証・認可 (ログイン) することができます。またアプリケーションからデータベースへの通信が TLS (TLS 1.3, 256-bit AES cipher) で暗号化されます。

AlloyDB Auth Proxy の概要図

アプリケーションからは、ローカルで動作する AlloyDB Auth proxy クライアントソフトウェアに向けて TCP 5432 ポートで接続します ( 127.0.0.1:5432 もしくは localhost:5432 。複数リードプールインスタンスなど複数インスタンスをターゲットするときポート番号が1ずつ増える)。すると AlloyDB Auth proxy クライアントは、AlloyDB に向けてコネクションを張ります。

アプリケーションが Compute Engine や Cloud Run など Google Cloud 環境で動作している場合、インスタンス等にアタッチされているサービスアカウントの権限 ( roles/alloydb.client ロール) でデータベースにログインすることが可能です。

通信要件

アプリケーションの動作環境からは以下の外向き (Egress) ネットワーク通信要件が存在します。

  • 0.0.0.0/0 への 443/TCP (alloydb.googleapis.com への接続のため)
  • AlloyDB インスタンスの IP アドレスへの 5433/TCP

Cloud Run における Auth proxy 利用

Cloud Run のサイドカーコンテナ機能を利用して AlloyDB Auth Proxy を使用する方法については、以下の記事もご参照ください。

blog.g-gen.co.jp

データのインポート・エクスポート

インポート

以下のフォーマットのファイルを、AlloyDB にインポートすることができます。

  • CSV（1テーブル = 1ファイル。psql コマンドライン使用）
  • DMP（PostgreSQL のバイナリアーカイブファイル。pg_restore 使用）
  • SQL （psql コマンドライン使用）

インポートするには、ファイルを Cloud Storage に配置して、コマンドラインを実行します。

エクスポート

AlloyDB のデータは、以下のフォーマットでエクスポートできます。

  • CSV (1テーブル/1ファイル。psql 使用)
  • DMP (PostgreSQL のバイナリアーカイブファイル。pg_dump 使用)
  • SQL (pg_dump 使用)

コマンドライン等を用いて AlloyDB からローカルマシンへデータをエクスポートする方法が公式ドキュメントで紹介されています。

移行ツール

Database Migration Service を利用することで、他のデータベースエンジンのデータベースから、AlloyDB にデータを移行することができます。Database Migration Service は、データベースのデータを移行するための Google Cloud サービスです。

詳細は以下のリンクから公式ドキュメントをご参照ください。

ソース（移行元） ドキュメントリンク 備考
PostgreSQL Database Migration Service for PostgreSQL to AlloyDB Amazon Aurora にも対応
Oracle Database Database Migration Service for Oracle to AlloyDB 2024年1月現在、Preview

セキュリティ・監査

暗号化

AlloyDB のストレージのデータは、他の Google Cloud サービスと同様に、デフォルトで透過的に暗号化されています。つまり何もしなくても、AlloyDB のストレージのデータは暗号化で保護されており、ストレージ機器の盗難等には対処されています。このデフォルト暗号化の暗号鍵は、Google Cloud によって管理されています。

オプションで Cloud KMS で管理する、顧客管理の鍵 (Customer-managed Encryption Key = CMEK) を用いてストレージを暗号化することもできます。CMEK で暗号化することにより、鍵の管理（作成、廃止、ローテーション等）をコントロールすることができ、厳しい監査要件に耐えることができます。

監査ログ

クラスタ管理オペレーションの監査ログ

AlloyDB は Cloud Audit Logs と統合されており、クラスタの管理系オペレーションの監査ログが出力されます。

クラスタの作成・削除、設定値の編集、バックアップの作成・削除などの更新系オペレーションは「管理アクティビティ監査ログ」と呼ばれ、デフォルトで記録される設定になっています。オフにはできません。

一方でクラスタ一覧の表示やクラスタ設定の取得などの参照系オペレーションは「データアクセス監査ログ」と呼ばれ、明示的に有効化する必要があります。

Cloud Audit Logs で採取されたログは Cloud Logging のログエクスプローラ等で閲覧することができます。

なおこれらはあくまでクラスタの管理系オペレーションに関する監査ログであり、データベースの中身の操作に対する監査ログは次に紹介する pgAudit で取得することになります。

DB オペレーションの監査ログ

PostgreSQL データベースの中身の操作に対する監査ログはオープンソースの拡張機能 (extension) である pgAudit により提供されます。

pgAudit で採取される情報は SELECT INSERT UPDATE DELETE などの各種 SQL (DDL/DML/DCL) です。記録する対象のオペレーションはデータベースフラグで定義できます。

有効化するにはデータベースフラグ alloydb.enable_pgaudit を on にセットしたうえでデータベースに接続して CREATE EXTENSION で拡張機能を有効化します。

pgAudit により生成されたログは データアクセス監査ログとして Cloud Audit Logs 経由で Cloud Logging に送信されます 。よって、ログを閲覧するためにはデータアクセス監査ログを有効化する必要があります。有効化後、Cloud Logging のログエクスプローラ等でログを閲覧することができます。

モニタリング

AlloyDB は Cloud Monitoring と統合されており、何も設定しなくても、CPU 使用率やメモリ使用率、ストレージの使用量などをグラフで閲覧することができます。

Cloud Monitoring のコンソール画面から各種メトリクス (採取されたパフォーマンス情報) を閲覧できるほか、AlloyDB のコンソール画面からもプレフィクスされたダッシュボードを確認できます。

チューニング

Query Insights

Query Insights は AlloyDB に組み込まれたクエリ分析ツールです。実行されているクエリのパフォーマンス情報を分析し、チューニングに活かすことができます。

Google Cloud の Web コンソールから閲覧できるほか、Cloud Monitoring API を経由してプログラマブルに情報を取得できるので、既存の APM (Application Monitoring) ツール等に情報を連携することも可能です。

Query Insights ではクエリの user, database, IP address, time range, CPU capacity, CPU and CPU wait, IO Wait, Lock Wait といった情報を閲覧できます。情報は1週間前のものまでが保存されます。

なお、Query Insights 自体に料金は発生しません。Cloud Monitoring API 経由で情報を取得した場合は、API 呼び出し回数に応じた 課金 は発生します。

adaptive autovacuum

AlloyDB には adaptive autovacuum (適応的オートバキューム) という機能があります。

PostgreSQL には VACUUM (バキューム) の概念があります。PostgreSQL ではデータを update したり delete しても、そのデータには削除フラグが付くだけで、実際にはまだ存在しています。この不要領域を回収して使えるようにするのが VACUUM です。また VACUUM コマンドにオプションに応じて統計情報の更新やトランザクション ID のラップアラウンド防止のための処理などがされています。

AlloyDB ではデフォルトで adaptive autovacuum が有効化されており、パフォーマンス影響を最小限に抑えながら VACUUM 処理が自動化されています。

enable_google_adaptive_autovacuum フラグにより、有効化/無効化を設定することができます。

インデックスアドバイザ

インデックスアドバイザ (index advisor) は、AlloyDB で処理されるクエリを分析し、パフォーマンス改善のためのインデックスを推奨してくれる機能です。2023/05/08 に GA となりました。

google_db_advisor.enabled フラグを on にすることで有効化できます (再起動が発生)。有効化してから1日程度経過して以降、定期的に分析が走ります。

アドバイザによる推奨事項は SELECT * FROM google_db_advisor_recommended_indexes; のように SQL で照会することができます。

詳細は以下のドキュメントをご参照ください。

AlloyDB Omni

AlloyDB Omni は Linux サーバ上で動作する、AlloyDB for PostgreSQL のダウンロード版です。

カラムナエンジンや adaptive autovacuum、インデックスアドバイザなど、クラウド版 AlloyDB の持っている機能の一部を搭載しています。

Linux で動作するコンテナベースであり、ハイブリッドクラウド (オンプレミスとクラウドをミックスして使うアーキテクチャ) や検証用途などのユースケースが想定されます。

詳細は以下のドキュメントをご参照ください。

実際に使ってみる

トップゲート社のブログにて、具体的な使い方等の実践的な記事連載がされています。こちらも併せてご参照ください。

www.topgate.co.jp

杉村 勇馬 (記事一覧)

執行役員 CTO / クラウドソリューション部 部長

元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。