Cloud Native PG 使ってみて気づいたことと最新機能の紹介 - 第52回PostgreSQLアンカンファレンス

Transcript

1. Cloud Native PG 使ってみて気づいたことと 最新機能の紹介 第52回PostgreSQLアンカンファレンス 2025/03/27 @YukiSeino 1
2. はじめに • Cloud NativePG 使ってますか？ ◦ 2021年11月にOSS化されてから、3年以上立ちました。 ◦ 運用ナレッジはググってもなかなかでてこない。まだまだこれから？ • Cloud Native PG を使ってみて気づいた点、遭遇した課題を紹介します。 ◦ 特にオンプレPostgreSQLからリフトする際に課題になりそうな観点が中心 • 2025/3/26時点の情報になります。 ◦ ～v1.25で確認 ◦ 最新版のv1.26は3月末リリース予定 本資料は、SpeakerDeck にアップロードしています。 https://speakerdeck.com/seinoyu 2
3. アジェンダ • はじめに • Cloud Native PG について • Cloud Native PG を使う上で（個人的に）留意すべき点 a. アーカイブWALやベースバックアップの保存先制約 b. 拡張機能の利用方法 c. 可用性に係る仕様変更（ WALディスクフル時の挙動） d. ロギング関連のパラメータ e. リリースサイクル (EOLサイクル) f. PostgreSQLのメジャーバージョンアップはサポート外 • 最近の変更点 • まとめ 3
4. Cloud Native PG について 4
5. Cloud Native PG • Kubernetes（コンテナ環境）でPostgreSQLを構築・運用にするための OSSオペレーターの一つ ◦ 他には、CrunchyData社やZalando社がリードするOSSオペレーターなどがある • Cloud Naitive Computing Foundation (CNCF) の Sandbox プロジェクトに登録 • 当初EDB社が開発していたが、2021年11月にOSS化されコミュニティとしても独立した ◦ 現在のコントリビュータ比は、 8:2(EDB:EDB以外)程度とのこと 5 Cloud Native PG のアーキテクチャ Cloud Native PGの役割 e.g. ・クラスタの作成（レプリケーション構 成） ・サービスの作成（コネクションの ルーティング） ・GUCパラメータの最適化 ・定期的なバックアップ ・死活監視 ・ローリングアップデート
6. Cloud Native PG が注目されている理由 • OSSコミュニティの中立性、健全性 ◦ ベンダ中立なコミュニティを形成するためにコミュニティを EDBから完全分離 ◦ Cloud Native Computing Foundation (CNCF) に登録 されていることで、コミュニティ主導のプロジェクトとして中 立性が保証されている • サードパーティ製品に依存しない、 K8sネイティブなクラスタリングアーキテクチャ ◦ 他のオペレータでは、 Patroni等のサードパーティ製品を使っている場合もあるが、 CNPGのインスタンスマネー ジャは Kubelet と連携 して、クラスタリングを構成する。（監視 (probe)、シャットダウン、フェイルオーバー） 6 Patroniベースのクラスタリング Worker-Node Control-Plane Worker-Node Worker-Node DB Pod postgres ｲﾝｽﾀﾝｽﾏﾈｰｼﾞｬ DB Pod postgres ｲﾝｽﾀﾝｽﾏﾈｰｼﾞｬ DB Pod postgres ｲﾝｽﾀﾝｽﾏﾈｰｼﾞｬ api-server kubelet kubelet kubelet Cloud Native PG のクラスタリング
7. Cloud Native PG を使う上で （個人的に）留意すべき点 7
8. Barman アーカイブ WALやベースバックアップの保存先制約 • サードパーティ製のバックアップツール(Barman)の仕様上、バックアップ の格納先として、選択可能な方法は下記の通り。 ◦ WALアーカイブ ▪ オブジェクトストア ◦ ベースバックアップ ▪ オブジェクトストア ▪ Kubernetes ボリュームスナップショット (CNPG推奨) • CSIドライバが本機能に対応している必要がある • アーカイブWALを取得する場合は、オブジェクトストアの用意が必須 と なる • 開発中などアーカイブWALを取得しない場合は、定義済みアノテーション である cnpg.io/skipWalArchiving を enable とすることでアーカイブ WALの無効化が可能。 ◦ GUCパラメータ (archive_mode, archive_command)は Operator に強制さ れて変更できない。 ◦ https://cloudnative-pg.io/documentation/1.25/labels_annotations/ ◦ https://cloudnative-pg.io/documentation/1.25/postgresql_conf/ • v 1.25 ではCNPG-I(インターフェース拡張)が実験的サポート。 ◦ ユーザがプラグインを開発できるようになり、バックアップ／リカバリのワー クフローを変更可能に。（私自身は未検証） 8 オブジェクト ストア (e.g. S3, MinIO) DB Cluster アーカイブ WAL ベースバックアップ K8sボリューム スナップショット
9. 拡張機能の利用方法 • Managed extensions に属する拡張機能(auto_explain, pg_stat_statemenets, pgaudit, pg_failover_slots)は、特に事前準備な く使用可能。 ◦ 拡張機能に関連する GUCパラメータを設定することで、オペレータが検 知し、自動的に拡張機能をインストール する。（shared_preload_libraries 等の設定は自動で行ってくれる） ◦ 例： ◦ https://cloudnative-pg.io/documentation/1.25/postgresql_conf/ • それ以外の拡張機能はカスタムイメージを作成する必要 がある ◦ オフィシャルドキュメントには記載なし ◦ CloudNativePGのブログ ：https://cloudnative-pg.io/blog/creating-container-images/ i. 拡張機能をインストールする Dockerfileを作成し、カスタムイメージ を作成する ii. PostgreSQL クラスターのマニフェストの imageName にカスタムイ メージを設定する 9 Dockerfile DBClusterマニフェスト イメージビルド
10. 可用性に係る仕様変更 (WALディスクフル時の挙動 ) • v 1.23 までは、プライマリのWALディスクがフルとなった場合、レプリカ にフェイルオーバーを実行 していた • v 1.24 から、プライマリのWALディスクがフルとなった場合、プライマリ がシャットダウンされるだけ となり、フェイルオーバーは実行されない ◦ 変更理由 ▪ この事象が発生した場合レプリカに FOしてもレプリカ側でも同様に ディスクフルとなり、問題が解決しないことが想定されるため ◦ ワークアラウンド ▪ WALディスクを拡張する ◦ https://github.com/cloudnative-pg/cloudnative-pg/pull/4404 • （黎明期？）可用性関連の仕様に対して大幅な変更が入る可能性 に注 意。 10 プライマリ レプリカ WAL ディスク ①ディスクフル ②レプリカにFO WAL ディスク プライマリ レプリカ WAL ディスク ①ディスクフル WAL ディスク × ③ディスク拡張 ～v 1.23 v 1.24～ ②シャットダウン
11. ログ収集 Worker Node DB Pod ロギング関連のパラメータ • ロギング関連のパラメータは Fix Parameter となっており、設定変 更できない • PostgreSQL ログ及びインスタンスマネージャの ログはJSON 形式 でコンテナログに出力 • この設計は、Kubernetes ロギング アーキテクチャと親和性が高 い。 • 従来のように、PostgreSQLサーバログをcsvlogやsyslogで運用し ていた場合は、ログ運用を見直す必要 がある。 11 postgres コンテナ コンテナ ログ インスタンスマネー ジャコンテナ kubectl logs ロギングのアーキテクチャ | Kubernetes コンテナ ログ fluentd promtail cnpg plugin stdout, stderr stdout, stderr
12. リリースサイクル（ EOLサイクル） • CloudNaitivePG の EOLサイクルは一つのマイナーリリースごとに約 6カ月となる ◦ https://cloudnative-pg.io/documentation/1.25/supported_releases/ • 機能追従やセキュリティアップデートを受けるために高頻度でアップグレードが必要 • Kubernetesのマイナーリリースのサポートは 1年程度となり、K8sより短い点にも留意が必要 ◦ https://kubernetes.io/ja/releases/ 12 2024. 8 v 1.24.x 2025.3 2024.12 v 1.25.x v 1.26.x 2025.6 2025.8 Release EOL EOL EOL Release Release
13. PostgreSQLのメジャーバージョンアップはサポート外 • PostgreSQLのメジャーバージョンアップは CloudNativePGの機能ではサポートされていないため、利用 者側で対応が必要。 ◦ Cloud Native PG のアップグレード (パッチバージョン、マイナーバージョン )はサポート内 ◦ PostgreSQLのマイナーバージョンアップはサポート内 • Kubernetesから論理レプリケーションを管理するための CRDがv 1.25で追加された。 ◦ メジャーバージョンアップを意識したものと思われる 13
14. 最近の変更点 14
15. 最近の変更点 v 1.26 (https://github.com/cloudnative-pg/cloudnative-pg/blob/main/docs/src/release_notes/v1.26.md) • クラスタ休止手順の変更 ◦ 命令的休止手順が廃止される ▪ kubectl cnpg hibernate on CLUSTER ◦ 今後は宣言的休止手順のみサポート ▪ kubectl annotate cluster <cluster-name> --overwrite cnpg.io/hibernation=on • 拡張機能とスキーマの宣言的管理 ◦ マニフェストから拡張機能とスキーマの作成・変更・削除が可能に v 1.25 • データベースの宣言的管理 ◦ Database CRD が追加され、マニフェストからデータベースが管理可能に • 論理レプリケーションの宣言的管理 ◦ Publication, Subscription CRD が追加され、マニフェストから論理レプリケーションが管理可能に 15
16. まとめ 16
17. まとめ • Cloud Native PG を使ってみた上で気になった点を紹介しました。 • オンプレから Cloud Native PG にリフトする場合は、今回紹介した事案をはじめ勝手 が違うことが多い。制約事項をしっかり検査する必要がありそう。 ◦ https://cloudnative-pg.io/documentation/1.25/troubleshooting/ • リリースサイクル/EOLサイクルが短い中で、大きな仕様変更が入る可能性には留意 (覚悟)が必要。 • 積極的に参入してナレッジを増やそう！ 17