Trusted Postgres Architect（TPA）23.42.0
日本語訳｜Trusted Postgres Architect（TPA）23.42.0
※GoogleのAutoML Translationを使用して翻訳しております。
 |
 |
英語原文｜Trusted Postgres Architect（TPA）23.42.0
 |
 |
概要
1. TPAとは？
Trusted Postgres Architect (TPA) は、EnterpriseDB (EDB) によって開発されたオープンソースのオーケストレーションツールです。Ansibleを使用して、EDBの厳格なベストプラクティスの推奨事項に従い、PostgreSQLクラスターのプロビジョニング、デプロイ、および管理を行います。TPAは、手軽なローカルのテスト環境から、非常に複雑で可用性の高い本番環境まで、信頼性の高いPostgres環境を構築できるように設計されています。
2. TPAのメリット
TPAは、データベース管理者や組織にいくつかの大きなメリットを提供します。
- 専門知識の組み込み (Built-in Expertise): EDBの長年の実績と経験が具現化されています。高可用性、レプリケーション、ディザスタリカバリ（災害復旧）のベストプラクティスが自動的に適用されるため、ユーザーがゼロから構成を考える必要はありません。
- 「単なるPostgres」であること (“It’s Just Postgres”): 複雑なアーキテクチャを構成できるにもかかわらず、TPAは隠された魔法のような処理や独自の難読化に依存しません。最終的に構築されるのは、通常通りに操作・対話できる標準的で一般的なPostgreSQL環境です。
- 冪等性（べきとうせい）と安全性 (Idempotency and Safety): プロビジョニング、デプロイ、テストの各段階は冪等性を持つように設計されています。設定ファイルを変更した後にコマンドを安全に再実行でき、既存のセットアップを壊すことなく、変更された差分のみを適用します。
- 宣言的な構成 (Declarative Configuration): ユーザーは「プライマリ1台、レプリカ2台、Barmanバックアップノードを持つPostgres 15クラスター」のように「何が欲しいか」を宣言するだけでよく、「どのように構築するか」はTPAがすべて処理します。
- インフラストラクチャに依存しない (Infrastructure Agnostic): クラウドプロバイダー (AWS)、コンテナ (Docker)、または既存のインフラストラクチャ (ベアメタル/VM) にシームレスにデプロイできます。
3. メリットを実現するTPAの仕組みと機能
TPAは、厳格な4段階のライフサイクルと強力な機能セットによってその目的を達成します。
4段階のワークフロー:
- 構成 (tpaexec configure): 高度な選択（アーキテクチャ、Postgresのバージョン、プラットフォーム）を指定します。TPAは、クラスターの設計図として機能する宣言型のYAMLファイル (config.yml) を生成します。
- プロビジョニング (tpaexec provision): 必要なインフラストラクチャを作成します。例えばAWSの場合、EC2インスタンス、VPC、サブネット、セキュリティグループを立ち上げます。Dockerの場合はコンテナを構築します。
- デプロイ (tpaexec deploy): Ansibleのプレイブックを使用して、OSパッケージのインストール、カーネル/システムの設定、PostgreSQLのインストール、および関連するすべてのソフトウェア（コネクションプーラー、フェイルオーバーマネージャー、バックアップツールなど）のセットアップを行います。
- テスト (tpaexec test): アーキテクチャに固有の自動化された機能テストおよびパフォーマンステスト（pgbench など）を実行し、クラスターが正常かつ完全に稼働していることを検証します。
主な機能:
- 定義済みのアーキテクチャ: 厳密にテストされたアーキテクチャ構成が同梱されています。
- M1: フェイルオーバー管理を備えた標準的なプライマリ/スタンバイの物理レプリケーションクラスター。
- PGD-Always-ON / PGD-X / PGD-S: マルチリージョンおよびマルチマスターレプリケーション向けの高度なEDB Postgres Distributedアーキテクチャ。
- 統合されたソフトウェアスタック: Patroni、repmgr、EFM（フェイルオーバー）、Barman（バックアップ）、PgBouncer/HAProxy（コネクションプーリング/ルーティング）、etcdなど、Postgres周辺のエコシステムを自動的に構成します。
- Day-2 クラスター管理: ゼロダウンタイムのマイナーバージョンアップグレード (tpaexec upgrade)、制御されたフェイルオーバー (tpaexec switchover)、ダウンタイムを最小限に抑えながら基盤となるOSやハードウェアを置き換える機能 (tpaexec rehydrate) などの組み込みコマンドが含まれています。
- セキュリティとコンプライアンス: STIGおよびCISセキュリティ基準に準拠したクラスターの生成、SSL/mTLS証明書の自動生成、およびVaultパスワード用の安全なキーリングバックエンドをサポートします。
- 拡張性: 「TPA hooks（フック）」を使用して、デプロイの特定の段階でカスタムAnsibleタスクを挿入したり、カスタムテストや独自のコマンドを記述したりできます。
4. バージョン 23.42.0 の新機能
リリース 23.42.0（2026年2月25日）では、プラットフォームにいくつかの新機能、セキュリティの強化、およびバグ修正がもたらされました。
ハイライトと主な強化点:
- RHEL 10の実験的サポート: Red Hat Enterprise Linux 10 (およびRocky、AlmaLinux、Oracle Linux 10) を実行しているノードへのデプロイをサポートしました。(注: RHEL 10用のEDBパッケージが提供されるまでは、オープンソースクラスターのみが対象となります)
- 代替の権限昇格コマンド (privilege_escalation_command): 以前のTPAは sudo に強く依存していましたが、厳格なセキュリティポリシーを持つ環境に対応するため、代替の権限昇格コマンドを設定できるようになりました。TPAはsudoのインストールをスキップし、フェイルオーバーマネージャーや各種サービスが指定されたツールを使用するように適応します。
- ロギング制御の改善: syslog 以外のPostgresログ出力先（jsonlog や csvlog など）を完璧に処理できるようになりました。自動的にPostgresのロギングコレクターを有効にし、正しいパスを構成し、postgres_log_directory_mode でディレクトリ権限を設定し、それに応じて logrotate を構成します。
- エアギャップ環境でのメタデータ更新: download-packages コマンドに新しい –refresh-repository オプションが追加されました。これにより、オフラインのローカルリポジトリに新しいパッケージバージョンを配置した際に、メタデータを自動的に更新できます。
重要な変更とセーフガード:
- 安全性の検証: Postgres 13とPGD 6（互換性がないため）を組み合わせた構成の試みを積極的にエラーとして弾くようになりました。また、サービスの起動競合を防ぐため、複数のEFM（Failover Manager）バージョンの同時インストールをブロックします。
- PGD-Sリポジトリのデフォルト化: PGD-Sアーキテクチャを使用するように構成されたクラスターは、必要なサブスクリプションレベルに合わせるため、デフォルトで「enterprise」リポジトリを正しく指定するようになりました。
- ローカル専用デプロイの緩和: –use-local-repo-only フラグが有効な場合、（パッケージがすでにローカルにダウンロードされていれば）デプロイの実行に EDB_SUBSCRIPTION_TOKEN を厳格に要求しなくなりました。
主なバグ修正:
- mTLSアップグレードの修正: アップグレードフェーズ中にTLS変数が欠落していたため、相互TLS (mTLS) を使用するクラスターでPatroniのアップグレードが失敗する問題を解決しました。
- レプリケーションスロット計算の修正: max_replication_slots を自動計算する際、PGD 5の「Parallel Apply（並列適用）」を正確に考慮するようになり、スロットの枯渇を防ぐようになりました。(注：これにより、更新された計算を適用するために、次回のデプロイ時にPostgresの再起動がトリガーされる可能性があります)。
- 重複するPGD-Xノードグループ: PGD-XクラスターのConnection Managerポートを指定すると、config.yml にエントリが重複して作成されるバグを修正しました。
- テスト実行ユーザーの修正: Ansibleユーザーが root ではない場合でも、become_user 属性を利用してSSL証明書を正しく読み取ることで、tpaexec test がデータベースクエリの実行を適切にサポートするようになりました。
