Trusted Postgres Architect（TPA）23.44.0

日本語訳｜Trusted Postgres Architect（TPA）23.44.0

※GoogleのAutoML Translationを使用して翻訳しております。

英語原文｜Trusted Postgres Architect（TPA）23.44.0

概要

1. TPAとは？
TPA (Trusted Postgres Architect) は、EnterpriseDB (EDB) が開発したオーケストレーションツールであり、Ansible を使用して EDB 推奨のベストプラクティスに沿った Postgres クラスターのデプロイおよび管理を行います。

TPA は、主に config.yml ファイルを介した宣言的な構成管理メカニズムを採用しており、クラスターのアーキテクチャ、トポロジ、および詳細な設定内容を定義できます。簡易的なテスト環境から本番環境まで幅広く適用可能な、EDB が培ってきたベストプラクティスが反映されています。

2. TPA による EDB 高可用性のデプロイ方法とメリット

EDBの高可用性（HA）製品をセットアップする仕組み
TPA は、堅牢な Postgres アーキテクチャ（M1 マスタ・レプリカ構成や複数リージョンの PGD Postgres Distributed 構成など）のデプロイを以下の4つの段階で調整します。

• 構成設定 (tpaexec configure): PGD、EFM (EDB Failover Manager)、Patroni などの採用を含む、ハイレベルなアーキテクチャの選択に基づいて、標準の YAML 構成ファイル (config.yml) を生成します。
• プロビジョニング (tpaexec provision): 対象のインスタンスや必要なインフラリソース（AWS EC2 インスタンス、VPC、サブネット、Docker コンテナなど）を作成するか、既存のベアメタルサーバーを登録します。
• デプロイ (tpaexec deploy): OS の設定、Postgres、および高可用性/バックアップコンポーネント（pglogical、Barman、EFM、PgBouncer、Connection Manager など）のインストールと設定を行います。
• テスト (tpaexec test): アーキテクチャおよびプラットフォームに特化したテストを実行し、フェイルオーバーメカニズムやデータベース接続が意図した通りに動作することを確認します。

TPAを使用するメリット

• べき等性 (Idempotency): プロビジョニング、デプロイ、およびテストは、べき等（同一の操作を何度繰り返しても同じ結果になること）になるよう設計されています。構成を変更せずに同じデプロイパイプラインを繰り返し実行しても、稼働中のクラスターに影響を及ぼしません。
• 一貫したベストプラクティス: EDB が蓄積してきた知見を自動的に取り入れ、推奨されるカーネルの調整、セキュリティルール、およびフェイルオーバー設定を確実に適用します。
• ライフサイクル管理の容易化: デプロイ後の複雑なタスク（設定変更、制御されたスイッチオーバー、ダウンタイムなしのマイナーバージョンアップグレードなど）を簡素化します。
• 拡張性: 独自の Ansible フック、テスト、プレイブックを作成して、既存のインフラとの統合や特別な環境要件へ対応することができます。

3. TPA リリース 23.44.0 の新機能・変更点
リリース 23.44.0 では、セキュリティ、プラットフォームのサポート、およびアップグレード管理に関するいくつかの改良が行われています。

主なハイライトおよびセキュリティ強化

• PGD-X コンポーネントのアップグレード: クラスター全体をアップグレードすることなく、PGD-X アーキテクチャ内の個別のコンポーネント（PgBouncer、pg-backup-api、Barman、PEM サーバーなど）をアップグレードできるようになりました。
• EFM ユーザーの最小権限化: デフォルトでは、新規デプロイ時に EFM データベースユーザーに SUPERUSER 権限が付与されなくなりました。新しい変数 efm_user_is_superuser のデフォルト値は false となり、必要な最小限のカタログおよびモニター権限を持つ専用の efm_role に属する通常のログインユーザーとして EFM ユーザーをデプロイします。
• Ansible Automation Platform (AAP) 2.6: AAP 2.6 との互換性が正式にテスト・確認されました。

注目すべき機能強化・変更点

デフォルト以外の Hugepage サイズ: huge_page_size および nr_hugepages 変数を使用して、個々のインスタンスでカスタムの Hugepage サイズ（例: 1GB ページ）を設定するためのネイティブサポートが追加されました。

• プロキシ監視の拡張: PGD 5 から PGD 6 へのアップグレード、および PGD 5 と PGD 6 のマイナーアップグレード時に、プロキシ監視 (enable_proxy_monitoring=yes) をサポートするようになりました。これにより、アップグレード中における pgd-proxy または Connection Manager 経由の接続の可用性を追跡しやすくなります。
• repmgr サービスの環境変数: repmgr の systemd サービスユニットテンプレートに直接、独自の環境変数（カスタムライブラリパスや認証情報など）を定義できる repmgr_service_environment が導入されました。
• 一貫したタスク除外 (Excluded Tasks) の適用: Barman、Patroni、EFM、Postgres などのすべての systemd 管理対象ロールにおいて、再起動とサービス操作が一貫して保護されるようになり、デプロイ時に excluded_tasks によって不要なサービス再起動が確実に抑制されるようになりました。
• BDR パッケージのバージョン管理: tpaexec reconfigure コマンドが –bdr-package-version フラグを受け付けるようになり、バージョンを記録してそのバージョン固有の必要な構成を適用できるようになりました。

主なバグ修正

• AWS AMI の更新: 最近ベンダーによって登録解除されたイメージ（Ubuntu、RHEL、SLESなど）が原因でプロビジョニングに失敗するのを防ぐため、tpaexec configure で使用されるデフォルトの AWS AMI が、現在利用可能なイメージに更新されました。
• ウィットネスノードの自動追加: PGD-X 構成において、拠点（location）ごとに偶数個のデータノードが指定された場合に、ウィットネスノードが自動的に追加されない問題が修正されました。
• BDR 4 から BDR 5 へのリポジトリ追加修正: BDR 4 から BDR 5 へのアップグレード中に、tpaexec reconfigure が postgres_distributed リポジトリを追加できない問題が解決されました。

---