【CNDS2025】つくって壊して直して学ぶDB on Kubernetesの実践で見つけた、PostgreSQL運用の勘所
無茶ぶりから始まるPostgreSQL on Kubernetes構築プロジェクト
CloudNative Days Summer 2025のセッション「つくって壊して直して学ぶDB on Kubernetes -初夏の日の2025-」では、データベースの意図的な障害検証を通じて「運用のリアル」を明らかにしていった。構築と検証を積み重ねた現場視点の知見が詰まっていた。
ある日、NTTデータの技術者である小林隆浩氏のもとに、上司から突然のビデオメッセージが届いた。「Kubernetesに本番環境として使えるPostgreSQLを立てておいてよ。Database on Kubernetesって言うんでしょ？ できるよね？」。
まさに「無茶ぶり」だった。こうしてKubernetes上にPostgreSQLクラスタを構築するというプロジェクトが、突如として始動することになる。本セッションでは、この唐突な依頼を発端に、小林氏と、同じくNTTデータグループのDatabase Engineerである加藤慎也氏のタッグによる実践的な取り組みが描かれる。
つくって学ぶDatabase on Kubernetes：OperatorとGKEでつくる本番運用想定のPostgreSQLクラスタ
上司の「無茶ぶり」によって始まったDatabase on Kubernetesプロジェクト。次のステップは、具体的な構成の検討とクラスタ構築である。ここから小林氏と加藤氏による技術的な検討と設計が本格化する。
Kubernetes上でPostgreSQLを構築・運用するにあたり、中心的な役割を果たすのが「Operator」である。Operatorとは、Kubernetesの思想である「宣言的な管理」を踏襲し、レプリケーション設定やフェイルオーバー、バックアップといった複雑な処理を、YAMLで記述するだけで自動的に実現する仕組みだ。
想定するPostgreSQLの構成
今回選んだのは、CNCFのSandboxプロジェクトにも登録されている「CloudNativePG」である。信頼性と柔軟性のバランスに優れ、完全なOSSとしても安心して利用できる点が評価された。
一方インフラにはGoogle CloudのマネージドKubernetesサービスであるGKE（Google Kubernetes Engine）を採用。クラスタ構成は、Primaryと2台のStandbyによる3インスタンス構成。同期レプリケーションを採用し、スタンバイのうち1台に書き込みが完了すればクエリ応答を返す仕組みにより、RPO（Recovery Point Objective）ゼロ、すなわちデータ損失ゼロを目指す。高可用性という観点では、AWS RDSのMulti-AZ構成に近いアーキテクチャであり、読み取り処理をスタンバイ側に振り分ける構想も視野に入れているという。
PostgreSQL on Kubernetesのシステム構成
バックアップの設計にも工夫がある。ストレージにはGKEのPersistent Diskを用い、CSI（Container Storage Interface）経由でマウント。CloudNativePGの機能を活用し、ボリュームスナップショットによる定期バックアップを行うとともに、WAL（Write-Ahead Logging）をGoogle Cloud Storageにアーカイブすることで、特定時点までの復元も実現している。「CloudNativePGでは、スナップショットとWALアーカイブを組み合わせてPITR（Point-in-Time Recovery）も実現できます」と加藤氏は説明する。
こうして、CloudNativePGとGKEを組み合わせたPostgreSQLクラスタが完成する。だが、小林氏はこう語る。「設定値はドキュメントを見る限りでは問題なさそうなんだけど、実際に動かしてみないと不安は残るよね」
それに対して加藤氏も同意し、次のフェーズが始まった。そう「壊して直して、クラスタの挙動を確かめてみよう」という次の段階である。
壊して直して学ぶDatabase on Kubernetes：意図的に壊して試す障害設計とCloudNativePGの復旧力
構築が完了したPostgreSQLクラスタが、本当に設計通りの可用性を備えているか――それを確かめるために、小林氏と加藤氏は、あえて障害を「仕込む」という検証フェーズに突入した。「本番利用を想定してという念押しがありましたから、障害を発生させて、今回のPostgreSQLクラスタが品質を担保できているかを確かめてみましょう」。その言葉を合図に、さまざまな障害シナリオが段階的に試された。
まず試されたのは、Primary Podの削除といった最小単位の障害である。CloudNativePGはすぐに異常を検知し、スタンバイインスタンスを新たなPrimaryへと昇格。アプリケーションも、エンドポイントの自動更新により即座に再接続され、サービス継続性が確保された。その後、削除されたPodと同名のスタンバイが自動再作成され、クラスタへの再参加も完了。Standby Podの障害時も同様に自動復旧され、システム全体への影響は最小限にとどまった。
（1）壊して直して学ぶ： Podの障害
次に、Podが稼働するノードそのものをダウンさせるシナリオが実行された。ここで鍵を握ったのが、CloudNativePGに標準で備わるpodAntiAffinityの設定である。これにより、複数のPodが同一ノードに偏在するのを防ぎ、ノード障害によるクラスタ全体の停止を回避する設計がなされている。さらにnodeSelectorを利用してDB専用ノードに適切にPodを配置する工夫も施されており、実際のノード削除時にもスムーズな昇格と再構築が確認された。
加えて、ゾーン障害やリージョン障害といった広域の障害に対しても、設計上の備えが用意されていた。具体的には、AWSのRDS Multi-AZ構成を参考に、複数のAZにインスタンスを分散させることで、単一障害点の排除を図っている。小林氏と加藤氏は「すべての障害に備えることはできません。何が許容できて、何が許容できないかを整理することが重要です」と語り、現実的な可用性設計のためには、RPOとRTO（Recovery Time Objective）といった指標を明確に定義しておくことの重要性を強調した。
検証が教えてくれた3つの落とし穴とCloudNativePGを安全に運用するための工夫
CloudNativePGを用いたPostgreSQLクラスタの構築と障害検証を終え、次にアプリケーションチームによる接続テストが始まった。「先日作ったクラスタをアプリに接続して試してもらっているんですけど、うまく動かないみたいなんです」。そんな一言から、トラブルシューティングが始まった。
最初に発覚したのは、更新処理が成功したり失敗したりする不安定な動作だった。原因は、外部向けに定義したServiceのラベル設定ミスで、リードオンリーのスタンバイにもリクエストが送られていた点にある。「CloudNativePGが自動生成するServiceの仕様を把握していなかった」と小林氏は語る。Operatorの意図を理解しないまま独自に構成を追加するリスクが浮き彫りになった。
二つ目は、WAL領域のディスク逼迫によりクラスタ全体が応答不能となった事例である。CloudNativePGでは、WAL溢れに対してはフェイルオーバーが発生しない設計となっており、影響が全インスタンスに波及した。PVCのリサイズと設定の修正によって復旧に至ったが、「そもそも監視が甘かった」と振り返る。
そして三つ目が、本番環境で重要なテーブルを誤って削除してしまうヒューマンエラーだった。PITRを活用し、削除直前の状態を別クラスタに再現、該当テーブルだけを抽出して復元することで事なきを得た。「CloudNativePGではインプレースでの復元ができない点にも注意が必要です」と補足があった。
小林氏は最後にこう語った。「CloudNativePGにはいろんな機能がありますが、ちゃんと中身を見て、壊して直して、運用で困らないようにすることが大事だと思います。皆さんもぜひ試してみてください」。──現実に起きる障害と向き合い、自ら検証して理解を深める姿勢こそが、安全なDB運用の土台となるのである。
