Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Cloud Native PG 使ってみて気づいたことと最新機能の紹介 - 第52回Post...

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

Yuki Seino

March 27, 2025
Tweet

More Decks by Yuki Seino

Other Decks in Technology

Transcript

  1. はじめに • Cloud NativePG 使ってますか? ◦ 2021年11月にOSS化されてから、3年以上立ちました。 ◦ 運用ナレッジはググってもなかなかでてこない。まだまだこれから? •

    Cloud Native PG を使ってみて気づいた点、遭遇した課題を紹介します。 ◦ 特にオンプレPostgreSQLからリフトする際に課題になりそうな観点が中心 • 2025/3/26時点の情報になります。 ◦ ~v1.25で確認 ◦ 最新版のv1.26は3月末リリース予定 本資料は、SpeakerDeck にアップロードしています。 https://speakerdeck.com/seinoyu 2
  2. アジェンダ • はじめに • Cloud Native PG について • Cloud

    Native PG を使う上で(個人的に)留意すべき点 a. アーカイブWALやベースバックアップの保存先制約 b. 拡張機能の利用方法 c. 可用性に係る仕様変更( WALディスクフル時の挙動) d. ロギング関連のパラメータ e. リリースサイクル (EOLサイクル) f. PostgreSQLのメジャーバージョンアップはサポート外 • 最近の変更点 • まとめ 3
  3. 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パラメータの最適化 ・定期的なバックアップ ・死活監視 ・ローリングアップデート
  4. 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 のクラスタリング
  5. 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ボリューム スナップショット
  6. 拡張機能の利用方法 • 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マニフェスト イメージビルド
  7. 可用性に係る仕様変更 (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~ ②シャットダウン
  8. ログ収集 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
  9. リリースサイクル( 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
  10. PostgreSQLのメジャーバージョンアップはサポート外 • PostgreSQLのメジャーバージョンアップは CloudNativePGの機能ではサポートされていないため、利用 者側で対応が必要。 ◦ Cloud Native PG のアップグレード

    (パッチバージョン、マイナーバージョン )はサポート内 ◦ PostgreSQLのマイナーバージョンアップはサポート内 • Kubernetesから論理レプリケーションを管理するための CRDがv 1.25で追加された。 ◦ メジャーバージョンアップを意識したものと思われる 13
  11. 最近の変更点 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
  12. まとめ • Cloud Native PG を使ってみた上で気になった点を紹介しました。 • オンプレから Cloud Native

    PG にリフトする場合は、今回紹介した事案をはじめ勝手 が違うことが多い。制約事項をしっかり検査する必要がありそう。 ◦ https://cloudnative-pg.io/documentation/1.25/troubleshooting/ • リリースサイクル/EOLサイクルが短い中で、大きな仕様変更が入る可能性には留意 (覚悟)が必要。 • 積極的に参入してナレッジを増やそう! 17