Movatterモバイル変換

© 2025 NTT DATA Japan Corporation 2今日話すこと⚫ Database（PostgreSQL） on Kubernetesを構築する際に気にするべきポイントや、実際の運用で発生するかも知れない障害とその対応を紹介する。• 「壊して」というより「壊れて学ぶ」のやり方⚫ Operatorはここ数年で進化したが、やはりDBには固有の運用があり、理解が難しい。• 例えば、バックアップやリストア• 急なDBクラスターの停止、など⚫ Kubernetesのストレージ周りの機能を使いながら、Database on Kubernetesを運用する際にそうした機能をどう活かすかについても、一緒に学んでいこう。

© 2025 NTT DATA Japan Corporation 3アジェンダ1. はじまり - DB on Kubernetesは突然に -2. つくって学ぶDatabase on Kubernetes3. 壊して直して学ぶDatabase on Kubernetes4. 問い合わせ#1 「晴れ時々エラー！？」5. 問い合わせ#2 「生き返らないクラスター！？」6. 問い合わせ#3 「消えないで！テーブル！？」7. まとめ

© 2025 NTT DATA Japan Corporation 6データベース要件の確認制定日：2024/8/10 DB種別 ■ PostgreSQL □ MySQL □ Oracle（ライセンスは持ち込みのみ） ※必須1 インスタンス数 □ 1 （冗長性なし。開発環境での利用を想定） ※必須□ 2 （冗長性あり。非同期を前提とするため、ラグ・データ損失を許容）■ 3 （冗長性あり。同期を前提とするため、データ損失はゼロ）2 バックアップ □ コールドバックアップ ※必須□ オンラインバックアップ■ オンラインバックアップ＋アーカイブログ（PITRに対応可能）3 保持期間 30 日間 ※必須4 申請日西暦 2025 年 4 月 1 日 ※必須5 申請承認者 ※必須金融第一事業部部長 xxxxx6 記入者事業部等・担当名金融第一事業部 ※必須氏名 yyyyy ※必須7 連絡先事業部等・担当名■ 記入者と同じ場合はこちらをチェック2024.8版DBクラスター作成申請書担当・グループ名役職氏名担当・グループ名

© 2025 NTT DATA Japan Corporation 7想定するPostgreSQLの構成⚫ 3インスタンスで同期レプリケーションを構成し、バックアップとアーカイブを取得する。プライマリスタンバイ① スタンバイ②Data WALアーカイブWAL Data WAL Data更新参照WALをスタンバイに転送①、②のうち1台に、同期レプリケーションが完了すればOK定期的にWALをアーカイブバックアップ

© 2025 NTT DATA Japan Corporation 8（参考）RDSのMulti-AZ DB Cluster⚫ 3インスタンスの構成。⚫ それぞれのインスタンスが、別AZに配置される。⚫ Write以外のインスタンスでも、読み取りクエリの処理が可能。但し、更新ラグが発生する。⚫ エンドポイントは下記の3種類。• Read/Write• Readのみ• 個別インスタンスhttps://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html#multi-az-db-clusters-concepts-overview

© 2025 NTT DATA Japan Corporation 10KubernetesにおけるPostgreSQL Operatorとは⚫ Kubernetes上でのデータベース運用を補助する機能が実装されている。• レプリケーションを使った高可用性構成、障害時切り替え等をYAMLで簡単に設定できる。• バックアップ/リストアも設定可能で、クラウドストレージと連携できる。PostgreSQL Operatorプライマリスタンバイスタンバイプライマリ向けService

© 2025 NTT DATA Japan Corporation 11PostgreSQL Operatorの比較⚫ PostgreSQL向けにも複数のOperatorが存在。今回はCloudNativePGを利用する。名称開発主体ライセンス備考PGO Crunchy Data Apache 2.0 *• 古参Operatorの1つ。機能は十分揃っている。• 従来のPostgreSQL向けOSSを組み合わせた構成。• コンテナイメージの商用利用が実質できない。postgres-operator Zalando MIT• 古参Operatorの1つ。機能は十分揃っている。• 従来のPostgreSQL向けOSSを組み合わせた構成。• Kubernetesに詳しいエンジニアが利用しやすい。CloudNativePG EDB Apache 2.0• PostgreSQL開発で有名なEDBによるOperator。• EDBが提供されているマネージドサービス内部でも利用されている。• 2025年、CNCF Sandbox Projectに。StackGres OnGres AGPL 3• 充実した管理UIを提供。• ライセンスがネックとなる可能性あり。Percona Operatorfor PostgreSQLPercona Apache 2.0• MySQLやPostgreSQLの開発で有名なPerconaのOperator。• PGOをフォークして開発。完全OSSでの利用が可能。• 比較的新しいOperator。

© 2025 NTT DATA Japan Corporation 16①Primary Podの疑似障害⚫ クラスタの状態を確認⚫ Primary Podを削除$ kubectl cnpg status test-dbInstances statusName Current LSN Replication role Status QoS Manager Version Node---- ----------- ---------------- ------ --- --------------- ----test-db-1 0/6055A58 Primary OK BestEffort 1.25.1 gke-cluster-bb3caaa1-hdsvtest-db-2 0/6055A58 Standby (sync) OK BestEffort 1.25.1 gke-cluster-bb3caaa1-2swntest-db-3 0/6055A58 Standby (sync) OK BestEffort 1.25.1 gke-cluster-bb3caaa1-zpcm$ kubectl delete pod test-db-1pod "test-db-1" deleted

© 2025 NTT DATA Japan Corporation 17①Primary Pod障害の確認と復旧⚫ CloudNativePGのログ⚫ クラスタの状態を確認$ kubectl cnpg status test-dbInstances statusName Current LSN Replication role Status QoS Manager Version Node---- ----------- ---------------- ------ --- --------------- ----test-db-2 0/70066E0 Primary OK BestEffort 1.25.1 gke-cluster-bb3caaa1-2swntest-db-1 0/70066E0 Standby (sync) OK BestEffort 1.25.1 gke-cluster-bb3caaa1-hdsvtest-db-3 0/70066E0 Standby (sync) OK BestEffort 1.25.1 gke-cluster-bb3caaa1-zpcm{"level":"info","ts":"2025-05-19T00:54:27.598548554Z","msg":"Current primary isn't healthy, initiating afailover","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"test-db","namespace":"default"},"namespace":"default","name":"test-db","reconcileID":"a90e0a46-6bf1-4f36-9dca-b83f6bb5567e"}{"level":"info","ts":"2025-05-19T00:54:27.740028855Z","msg":"Failing over","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"test-db","namespace":"default"},"namespace":"default","name":"test-db","reconcileID":"a90e0a46-6bf1-4f36-9dca-b83f6bb5567e","newPrimary":"test-db-2"}

© 2025 NTT DATA Japan Corporation 19②Standby Podの疑似障害⚫ クラスタの状態を確認⚫ Standby Podを削除$ kubectl delete pod test-db-1pod "test-db-1" deleted$ kubectl cnpg status test-dbInstances statusName Current LSN Replication role Status QoS Manager Version Node---- ----------- ---------------- ------ --- --------------- ----test-db-2 0/9000000 Primary OK BestEffort 1.25.1 gke-cluster-bb3caaa1-2swntest-db-1 0/9000000 Standby (sync) OK BestEffort 1.25.1 gke-cluster-bb3caaa1-hdsvtest-db-3 0/9000000 Standby (sync) OK BestEffort 1.25.1 gke-cluster-bb3caaa1-zpcm

© 2025 NTT DATA Japan Corporation 20②Standby Pod障害の確認と復旧⚫ CloudNativePGのログ⚫ クラスタの状態を確認{“level”:“info”,"ts":"2025-05-19T01:06:20.510661896Z","msg":"Creating new Pod to reattach a PVC","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"test-db","namespace":"default"},"namespace":"default","name":"test-db","reconcileID":"9812324d-b86d-4d21-a43d-39fb6ac7f77b","pod":"test-db-1","pvc":"test-db-1"}{"level":"info","ts":"2025-05-19T01:06:31.80588422Z","msg":"Setting replica label","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"test-db","namespace":"default"},"namespace":"default","name":"test-db","reconcileID":"eb962e67-b7a2-4ba0-9bce-29b5c4de5049","pod":"test-db-1"}{"level":"info","ts":"2025-05-19T01:06:37.768017501Z","msg":"Cluster has become healthy","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"test-db","namespace":"default"},"namespace":"default","name":"test-db","reconcileID":"c47b81a5-dc5b-4c9c-9673-edfbd7dfac6e"}$ kubectl cnpg status test-dbInstances statusName Current LSN Replication role Status QoS Manager Version Node---- ----------- ---------------- ------ --- --------------- ----test-db-2 0/9000000 Primary OK BestEffort 1.25.1 gke-cluster-bb3caaa1-2swntest-db-1 0/9000000 Standby (sync) OK BestEffort 1.25.1 gke-cluster-bb3caaa1-hdsvtest-db-3 0/9000000 Standby (sync) OK BestEffort 1.25.1 gke-cluster-bb3caaa1-zpcm

© 2025 NTT DATA Japan Corporation 21⚫ CloudNativePGはデフォルトでノード障害に耐えられる設定となっている。ゾーン障害に備えたPodの配置戦略（podAntiAffinity）ノードPSSゾーンノードPゾーンSSノードPSSノード障害で全滅ノード障害に耐性ゾーン障害に耐性enablePodAntiAffinity:truetopologyKey:kubernetes.io/hostnameenablePodAntiAffinity:false enablePodAntiAffinity:truetopologyKey:topology.kubernetes.io/zone

© 2025 NTT DATA Japan Corporation 22⚫ 特定のラベルをもつノードにスケジューリングする。⚫ データベースは特定HWが設定されたノードにスケジューリングしたい場合などに有用。• DB高速化のためにメモリ増強、高速SSDを搭載など• 今後はGPU搭載なども要件として登場するかもしれない性能も考慮したPodの配置戦略（nodeSelector）nttdata.com/role: db nttdata.com/role: app

© 2025 NTT DATA Japan Corporation 23CloudNativePGでの設定方法apiVersion: postgresql.cnpg.io/v1kind: Clustermetadata:name: pgcluster-prodspec:affinity:enablePodAntiAffinity: truetopologyKey: kubernetes.io/hostnamepodAntiAffinityType: requirednodeSelector:nttdata.com/role: db⚫ podAntiAffinityを有効化⚫ ホスト名で分散⚫ 条件を満たすことが必須⚫ データベース用ノードに⚫ GKEノードプールにラベルを設定済み

© 2025 NTT DATA Japan Corporation 25③Nodeの疑似障害⚫ クラスタの状態を確認⚫ Primary Podのあるノードを削除$ kubectl delete node gke-cluster-bb3caaa1-2swnnode "gke-cluster-kato-default-pool-bb3caaa1-2swn" deleted$ kubectl cnpg status test-dbInstances statusName Current LSN Replication role Status QoS Manager Version Node---- ----------- ---------------- ------ --- --------------- ----test-db-2 0/9000000 Primary OK BestEffort 1.25.1 gke-cluster-bb3caaa1-2swntest-db-1 0/9000000 Standby (sync) OK BestEffort 1.25.1 gke-cluster-bb3caaa1-hdsvtest-db-3 0/9000000 Standby (sync) OK BestEffort 1.25.1 gke-cluster-bb3caaa1-zpcm

© 2025 NTT DATA Japan Corporation 26③Node障害の確認と復旧⚫ CloudNativePGのログ⚫ クラスタの状態を確認{"level":"info","ts":"2025-05-19T01:33:40.453415481Z","msg":"Current primary isn't healthy, initiating afailover","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"test-db","namespace":"default"},"namespace":"default","name":"test-db","reconcileID":"3e4c576c-1e4a-4b0d-9bd0-3fd129e86716"}{"level":"info","ts":"2025-05-19T01:33:40.718655379Z","msg":"Failing over","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"test-db","namespace":"default"},"namespace":"default","name":"test-db","reconcileID":"3e4c576c-1e4a-4b0d-9bd0-3fd129e86716","newPrimary":"test-db-1"}$ kubectl cnpg status test-dbInstances statusName Current LSN Replication role Status QoS Manager Version Node---- ----------- ---------------- ------ --- --------------- ----test-db-1 0/B000000 Primary OK BestEffort 1.25.1 gke-cluster-bb3caaa1-hdsvtest-db-2 0/B000000 Standby (sync) OK BestEffort 1.25.1 gke-cluster-bb3caaa1-td3ttest-db-3 0/B000000 Standby (sync) OK BestEffort 1.25.1 gke-cluster-bb3caaa1-zpcmｚ

© 2025 NTT DATA Japan Corporation 27ここまでのまとめ⚫ PostgreSQL Operatorは複数あるので、要件に合わせて選択しましょう。• 机上での比較だとあまり差異がわからないので、実際に使ってみることも重要⚫ すべての障害への対策は不可能だが、何が許容できる・できないかを整理することが重要。• Pod障害/ノード障害/ゾーン障害/リージョン障害• RPO/RTO⚫ パフォーマンスの観点からデータベースPodはアプリケーションPodとは別のノードにスケジューリングすることも考える。• 大容量メモリ・高いIO性能/低遅延・広帯域の安定したネットワークが必要• 他Podとのリソース競合を避ける

© 2025 NTT DATA Japan Corporation 32#1 Podのラベルを確認する⚫ プライマリを指すためのSelectorは cnpg.io/instanceRole=primary⚫ cnpg.io/podRole=instance は全てのインスタンスを指す。⚫ cnpg.io/podRole=instance も「読取可能な何処かに繋がる」エンドポイントで使われている。（プライマリPodのラベル）（スタンバイPodのラベル）

© 2025 NTT DATA Japan Corporation 33#1 まとめ⚫ データベースのクラスターにおいて、各インスタンスの役割理解は重要。⚫ Database on Kubernetesでは、それらの役割はLabelで表現され、Operatorが管理する。• カスタムエンドポイントを追加する場合には、Operatorの仕様を理解しないと、今回のようにトラブルが発生する可能性あり。⚫ Read/Write、Read、ReadOnlyなどのエンドポイントは、殆どのOperatorで生成されるため、アプリケーションはどのクエリを何処に投げるかをきちんと考えて設計する。• 全てRead/Writeというのも良くない。• Readを分散するために、ReadOnlyエンドポイントの活用は重要。

© 2025 NTT DATA Japan Corporation 36#2 CloudNativePGでWAL領域があふれると、⚫ 基本的に同じディスク構成となるため、フェイルオーバしてもそちらもあふれる。⚫ そのため、CloudNativePGではWALあふれでフェイルオーバしない仕様となっている。プライマリスタンバイ① スタンバイ②Data WAL WAL Data WAL Dataこの仕様がない場合、プライマリからスタンバイへフェイルオーバして、切り替わり先で障害が発生する。それが再度フェイルオーバを引き起こし、クラスター内でぱたぱた切り替わるような状態となる。DBではもっとも避けるべき状況の1つ。

© 2025 NTT DATA Japan Corporation 38#2 PVCの拡張作業$ kubectl patch pvc production-db-2-wal -p "{¥"spec¥":{¥"resources¥":{¥"requests¥":{¥"storage¥": ¥"5Gi¥"}}}}"• PVCの確認。WAL用PVCは全て2Gi。• kubectl patchでPVCを拡張PVCの確認。• PVC、PVともに拡張されていることを確認。

© 2025 NTT DATA Japan Corporation 39#2 まとめ⚫ データベースで高可用性構成を組んでも、フェイルオーバされないケースは存在する。• （今回のような）ディスクあふれのケース• 全インスタンスに関わる致命的なパラメータの誤り⚫ そうした際、Kubernetesリソースを変更する正しい手順を理解しておくことは重要。• ボリューム拡張では、PVのサイズを直接編集してはいけない。• ファイルシステムの拡張等、一連の処理が動かない可能性あり• PVCのサイズを拡張し、以降はKubernetesおよびCSIドライバーが担当。⚫ こんなことにならないように、そもそもディスク使用量の監視をしましょう。

© 2025 NTT DATA Japan Corporation 43#3 CloudNativePGにおけるPITRの注意点⚫ ベースバックアップの保存先として、オブジェクトストレージとVolumeSnapshotを選択できる。⚫ インプレースのPITRはサポートしておらず新規クラスターとしてリカバリされるバックアップ既存クラスター新規クラスターバックアップクラスタークラスターSnapshotVolumeSnapshotインプレースリカバリ新規クラスターとしてリカバリ

© 2025 NTT DATA Japan Corporation 44#3 バックアップ設定とテーブル削除日時⚫ 毎日0時00分00秒にVolumeSnapshotを取得⚫ 2025年5月23日15時00分01秒にテーブル削除⚫ オブジェクトストレージにWALを保存apiVersion: postgresql.cnpg.io/v1kind: ScheduledBackupmetadata:name: production-db-backupspec:schedule: "0 0 0 * * *"backupOwnerReference: selfcluster:name: production-db5月22日0時00分00秒5月23日0時00分00秒5月23日15時00分01秒VolumeSnapshotVolumeSnapshotテーブル削除backup.yaml

© 2025 NTT DATA Japan Corporation 45#3 リカバリのフローproduction-dbのバックアップ削除したテーブルのダンプファイル1. 新規クラスターをテーブル削除直前にPITRproduction-dbrecovery-db2. テーブルデータをpg_dumpで抽出3. 抽出したデータを元のクラスターにpg_restoreで復旧⚫ pg_dump：PostgreSQLデータベースのバックアップを取得するツール⚫ pg_restore：pg_dumpで作成したバックアップをリストアするツール

© 2025 NTT DATA Japan Corporation 46#3 リカバリー用DBのYAMLapiVersion: postgresql.cnpg.io/v1kind: Clustermetadata:name: recovery-dbspec:instances: 1bootstrap:recovery:backup:name: production-db-backuprecoveryTarget:targetTime: "2025-05-23 15:00:00.000000+09"recovery-db.yaml⚫ テーブルデータを抽出するだけなので1インスタンスで作成⚫ bootstrapセクションにバックアップとリストアの情報を設定⚫ 新規クラスター名

© 2025 NTT DATA Japan Corporation 47#3 PITR実行時のログ⚫ recovery-dbのログ⚫ recovery-dbの状態$ kubectl logs recovery-db-1{"level":"info","ts":"2025-05-20T12:20:03.561931773Z","logger":"postgres","msg":"record","logging_pod":"recovery-db-1","record":{"log_time":"2025-05-20 12:20:03.561UTC","process_id":"26","session_id":"682c7373.1a","session_line_num":"3","session_start_time":"2025-05-2012:20:03 UTC","transaction_id":"0","error_severity":"LOG","sql_state_code":"00000","message":"redo starts at 0/3000028","backend_type":"startup","query_id":"0"}}…{"level":"info","ts":"2025-05-20T12:20:03.562299787Z","logger":"postgres","msg":"record","logging_pod":"recovery-db-1","record":{"log_time":"2025-05-20 12:20:03.561UTC","process_id":"26","session_id":"682c7373.1a","session_line_num":"5","session_start_time":"2025-05-2012:20:03 UTC","transaction_id":"0","error_severity":"LOG","sql_state_code":"00000","message":"redo done at 0/30000F8 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00s","backend_type":"startup","query_id":"0"}}$ kubectl get pod recovery-db-1NAME READY STATUS RESTARTS AGErecovery-db-1 1/1 Running 0 35s

© 2025 NTT DATA Japan Corporation 49#3 正常にリストアできているかを確認⚫ customersテーブルのレコード数を取得⚫ 今回は1つのテーブルをリストアするだけで復旧したが、複数のテーブルをリストアしたり、テーブル間の整合性を保ちつつリカバリーするなど、様々な復旧パターンがある。$ psql –c "SELECT COUNT(*) FROM customers"count-------1352(1 row)

© 2025 NTT DATA Japan Corporation 50#3 まとめ⚫ オペミスが発生しにくい設定をしたうえで、リカバリできるようにしておくことが重要。• 自動コミット機能をオフにして、ロールバックできるようにする（PostgreSQL限定）。• オペミスをしたとしても、リカバリできるように手順をドキュメント化しておく。⚫ バックアップ・リカバリの適切な手段は環境や要件によって異なる。• それぞれの環境や要件に合わせた適切な方法を確認しておく。• バックアップを取得するだけではなく、リカバリまで必ず確認しておく。⚫ CloudNativePGではインプレースのPITRは不可。• 他のトランザクションデータを消してしまったりするので、そもそもIn-placeのリカバリは避けるべきケースが多い。

記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です。

Movatterモバイル変換

Change Language

つくって壊して直して学ぶ Database on Kubernetes (CloudNative Days Summer 2025 発表資料)

Embed presentation

Recommended

More Related Content

What's hot

Similar to つくって壊して直して学ぶ Database on Kubernetes (CloudNative Days Summer 2025 発表資料)

More from NTT DATA Technology & Innovation

つくって壊して直して学ぶ Database on Kubernetes (CloudNative Days Summer 2025 発表資料)