GKEストレージ設計｜DBを載せる判断とバックアップ

第6回で道具が決まりました。次に決めるのは、その上で扱うデータをどこに置くかです。

「Kubernetesでデータベースを動かすのは避けたほうがいい」という話は、よく聞きます。ただし、どういう条件で避けるべきなのか、避けた場合はどこへ置くのか、避けずに載せる場合は何を設計するのかまで説明されることは多くありません。

本記事は、その判定の後の行き先まで示します。そして重要な点を先に述べます。配置の判定そのものは、第1回で既に終わっています。本記事はその再判定をしません。判定結果を実装に落とす回です。

扱う範囲を明確にしておきます。本記事は平常時の設計です。どこにデータを置き、どのStorageClassで払い出し、毎日どうバックアップを取るか。リージョンが落ちたときにどう復旧するか、RPOとRTOをいくつに置くかは第17回の管轄です。「バックアップ」という語が両方にまたがるため、この線引きを設計書でも守ってください。

本記事も第1回以降と同様、Google Cloud（GKE）を前提に数値と製品名を記載します。

目次

1. 配置の判断は、第1回で終わっている
   1. Persistent Disk はネットワークストレージである
   2. StatefulSetのPodとPVCは番号で結ばれている
   3. 逃げ道は2つ、そのうち1つは別の条件に落ちる
   4. 載せない場合の行き先を決める
2. マネージドDBを却下できる理由は何か
   1. 公式が認めている制約は1つ
   2. この却下理由は「時間が経てば変わる」
   3. StatefulSetを選ぶと、自分で設計する項目が増える
3. StorageClassを設計する
   1. 既定のStorageClassをそのまま使わない
   2. プロビジョナーの選定にはサポート境界がある
   3. 3つの設定で事故が決まる
   4. PVCを消す事故と、消さない事故
4. アクセスモードで構成が決まる
   1. Persistent Disk は ReadWriteMany に対応しない
   2. ReadWriteManyが要る場合の選択肢
5. バックアップは、取ることより戻せることを設計する
   1. 課金はNamespaceの数で決まる
   2. バックアップされないもの
   3. 完了条件を「復元できたこと」にする
6. 【実務テンプレート】データ・ストレージ設計書
7. 次回予告

配置の判断は、第1回で終わっている#

第1回の条件1（ローカルI/O依存）は、「コミットごとのWAL・redoログのfsync」を理由にKubernetes不採用と判定する条件でした。該当したのは、セルフホストのRDBMS、SQLiteをデータストアに使うアプリ、レガシー基幹バッチ、セルフホストのElasticsearch、大量の小ファイル処理です。

この判定を、いまここで覆すことはしません。むしろ、なぜその判定になったのかを、ストレージの側から確認します。

Persistent Disk はネットワークストレージである#

GKEのドキュメントは、Persistent Disk をこう説明しています。「Compute Engine によって管理される耐久性の高いネットワーク ストレージ デバイス」です。そしてデフォルトではゾーンリソースであり、リージョン内の単一のゾーンに保持されます。

ここが第1回の条件1と直結します。第1回の判定は、Persistent Disk に載せることを前提に下された判定でした。ローカルディスクのつもりで設計されたワークロードを、ネットワーク越しのブロックデバイスに載せる。それが条件1で問題にした構造です。

したがって、条件1に該当したワークロードをそのままPersistent Diskに載せても、判定は変わりません。

もう1つ、ゾーンリソースであることの帰結を押さえてください。ディスクが特定のゾーンに存在する以上、そのゾーンが落ちるとPodは起動できません。別のゾーンにノードが空いていても、そこからそのディスクは見えないためです。リージョンPersistent Diskという選択肢もありますが、可用性の要件は第3回で決めたSLA目標から降りてきます。ここでゾーンの話を独自に判断しないでください。第3回で「リージョンとゾーンのSLA差は10倍」と確認した、その判断の下流にあります。

StatefulSetのPodとPVCは番号で結ばれている#

設計に入る前に、StatefulSetの性質を1つ確認します。StatefulSetのPodは、序数（0、1、2…）ごとに固有のPVCを持ち、Podが再作成されても同じPVCに接続されます。これがDeploymentとの決定的な違いで、ステートフルなワークロードが成立する理由です。

ここから2つの設計上の含意が出ます。

1つ目、既定ではレプリカ数を減らしてもPVCは消えません。3から1に減らした場合、序数1と2のPVCは残り、課金も続きます。増やし直せばそのデータに再接続されるので、これは意図された挙動です。ただし「減らしたのに費用が下がらない」という形で現れます。この挙動を変える設定もあるため、自分たちのクラスタでどうなるかを設計時に確認し、設計書に書いてください。

2つ目、PVCの数はレプリカ数の履歴上の最大値になります。後述する棚卸しの対象は、ここで生まれます。

逃げ道は2つ、そのうち1つは別の条件に落ちる#

第1回では、機械的に不採用と判定させないために逃げ道を2つ示しました。ここでその帰結を確認します。

2つ目を読み飛ばさないでください。Local SSD で条件1を回避すると、条件3が立ちます。

理由は単純です。ディスクがノードに固定されている以上、そのPodも特定のノードから動かせません。Podを別のノードへ移せないということは、水平にスケールできないということであり、それが条件3の定義そのものです。

逃げ道を1つ塞ぐと、別の失格条件が立つ。この構造を理解していないと、「Local SSDを使えばI/Oの問題は解決する」という部分最適な結論に至り、半年後に別の問題として顕在化します。第1回で7条件を2つの関門に分けたのは、条件同士がこう繋がっているためです。

載せない場合の行き先を決める#

載せないと判定したワークロードには、行き先が要ります。空欄にしないでください。選択肢は2つです。

1. マネージドデータベース。GKEが接続をサポートしているのは AlloyDB for PostgreSQL、Cloud SQL、Spanner、Memorystore for Redis です
2. Compute Engine に残す。第1回の条件3で示したハイブリッド構成です。該当するコンポーネントだけをクラスタの外に置きます

どちらを選ぶ場合も、クラスタの外に出たデータストアへ、クラスタの中からどう接続するかを設計する必要があります。接続情報の置き場所は第5回のシークレット管理（Secret Manager アドオン）、通信の許可は第5回のNetworkPolicyのegressルールです。クラスタの外に出した時点で設計が終わるわけではありません。

マネージドDBを却下できる理由は何か#

ここからは、載せると判定したワークロード、あるいは条件1に該当しなかったワークロードの話です。

第6回で確立した原則をここにも適用します。マネージドの選択肢があるなら、それを却下する理由が書けない限り選びません。

公式が認めている制約は1つ#

GKEのストレージ概要は、マネージドデータベースについてこう書いています。バックアップ、パッチ適用、スケーリングなどのメンテナンスタスクを自動化できる一方で、「正確なバージョンのデータベース、拡張機能、または目的のデータベースの正確なバージョンにアクセスできない可能性がある」と。

これが、StatefulSetを選ぶ再現性のある唯一の理由です。特定のバージョンに固定する必要がある、あるいはマネージド版が対応していない拡張機能に依存している。この2つだけが、第三者に説明できる却下理由になります。

逆に、却下理由にならないものを挙げます。

この却下理由は「時間が経てば変わる」#

第6回で、却下理由を「時間が経てば変わるもの」と「変わらないもの」に分類しました。判定方法は「その理由を、開発元が次のリリースで解消できるか」でした。

バージョンと拡張機能への依存は、「変わる」に分類されます。マネージド側がそのバージョンや拡張機能に対応すれば、却下理由は消えるためです。

したがって、再検討の条件を書けます。「Cloud SQL が拡張機能Xをサポートしたとき」「AlloyDB がバージョンYに対応したとき」という形です。

ここから、本章の結論が出ます。StatefulSetでデータベースを運用するという判断は、恒久的な決定ではなく、期限付きの決定です。ADRのStatusは「承認」でよいのですが、再検討の条件を必ず明記してください。この条件がないと、5年後も誰も見直さないまま自前運用が続きます。

なお、どのマネージドデータベースを選ぶかという比較そのものは第6回の管轄です。本記事は「マネージドに置くか、StatefulSetにするか」までを扱います。

StatefulSetを選ぶと、自分で設計する項目が増える#

却下理由が書けたとして、その先に何が待っているかを確認します。マネージドを却下するということは、マネージドが肩代わりしていた作業を自分で設計するということです。

例としてCloud SQLのバックアップ機能を見ます。自動バックアップの保持は1日から10年の範囲で設定でき（インスタンスのバックアップオプションによる）、ポイントインタイムリカバリにも対応します。バックアップ自体は課金対象です。

StatefulSetを選ぶと、これに相当するものを本記事の後半で自分で設計することになります。

この表は、第6回の3費目でいう③運用工数にあたります。金額に換算せず、工数のまま設計書に書いてください。そして第6回の合格ライン（一次対応できる人が2名以上）を、このデータベースについても満たせるかを確認します。満たせないなら、却下理由が書けていてもStatefulSetは選べません。

StorageClassを設計する#

StatefulSetで載せると決めたなら、次はストレージの設定です。

既定のStorageClassをそのまま使わない#

GKEは、バランス永続ディスクタイプ（ext4）を使う既定のStorageClassを作成します。PersistentVolumeClaim が storageClassName を指定していない場合、この既定のStorageClassが使われます。既定として指定されているStorageClassは、独自のものに置き換えられます。

ディスクタイプの選択肢は4つあります。

性能諸元を並べることはしません。第6回と同じ形で書きます。既定はバランス。変える理由が書けるときだけ変える。そして変えた場合は、なぜ変えたのかを設計書に残してください。

プロビジョナーの選定にはサポート境界がある#

StorageClassを定義するときは、プロビジョナーを指定します。GKEが推奨しているのは2つです。

• Compute Engine 永続ディスクの CSI
• Kubernetes Filestore CSI

そしてドキュメントには、設計判断に直結する注記があります。「上記以外のプロビジョナーは Cloud カスタマーケアのサポート対象外です」

これはCSIドライバーの選定基準そのものです。第6回で「追加料金なしのマネージドを却下する理由が書けるか」という判断をしましたが、ストレージではさらに強い制約がかかります。推奨外のCSIドライバーを選ぶと、障害時にクラウド側のサポートを受けられません。

ADRに書くべきことは明確です。推奨外のプロビジョナーを選ぶ場合、「サポート対象外であることを承知したうえで選ぶ理由」と、「障害時に誰が一次対応するか」を明記してください。第6回で定めた合格ライン（一次対応できる人が2名以上）が、ここでは事実上の必須条件になります。

3つの設定で事故が決まる#

volumeBindingMode の意味を補足します。Persistent Disk は既定でゾーンリソースです。ディスクを先に作ってしまうと、そのゾーンにPodをスケジュールできない状況（そのゾーンに空きがない、ノードプールが別ゾーンにある）で詰みます。Podの配置を先に決めてからディスクを作る、という順序を強制するのがこの設定です。

そして本節の結論です。既定のStorageClassを使うということは、これら3つを自分たちで決めないまま本番に出すということです。設計書には、環境ごと・用途ごとに用意するStorageClassの一覧を書いてください。少なくとも「本番のデータ用（Retain）」と「一時データ用（Delete）」は分ける価値があります。

PVCを消す事故と、消さない事故#

ここが本章で最も見落とされる点です。PVCをめぐる事故は、方向が逆の2種類あります。

方向が逆なので、片方だけ対策すると必ずもう片方で事故ります。「PVCを消せないようにしました」という対策は、使われないディスクが増え続ける状態を作ります。「不要なPVCを消す運用にしました」という対策は、消してはいけないものを消す事故につながります。

設計書には両方を書いてください。そしてpersistentvolumeclaims の delete を開発者に渡すかどうかは、第5回で作った開発者向けカスタムRoleの内容をここで確定させるということです。第5回では「含めない」側に secrets や serviceaccounts を挙げましたが、PVCの扱いはこの回で決まります。

そしてもう1つ、権限の前に決めるべきことがあります。データを失う事故が起きたとき、その結果責任を負うのはどのチームかです。第2回のRACIに、ステートフルデータの管理という行があるかを確認してください。行がないまま権限だけを配ると、事故のときに「開発チームが消した」「運用チームが権限を渡した」という押し付け合いになります。権限の設計（第5回）の前に、責任の設計（第2回）があります。

アクセスモードで構成が決まる#

設計の初期に確認すべきことが1つあります。複数のPodから同じボリュームに書き込む必要があるかどうかです。

Persistent Disk は ReadWriteMany に対応しない#

Persistent Disk ボリュームがサポートするのは ReadWriteOnce です。通常は単一のPodにアタッチされます。ReadOnlyMany と ReadWriteOncePod にも対応しますが、ReadWriteMany には対応していません。

ここで誤解されやすい点を1つ整理します。ReadWriteOnce は「単一のPod」ではなく「単一のノード」を意味します。同じノードにスケジュールされた複数のPodからは、同時に読み書きできてしまいます。本当に1つのPodだけに限定したい場合は ReadWriteOncePod を使います。

この差が問題になるのは、データの整合性を単一書き込み者の前提に置いているアプリケーションです。ReadWriteOnce で「1つのPodからしか書かれない」と考えていると、ローリングアップデート中に新旧のPodが同じノードに載った瞬間に前提が崩れます。第1回の条件3（水平分散不可・排他制御を外部化できない）に該当したワークロードをStatefulSetで運用する場合、ここは確認すべき箇所です。

つまり「複数Podから同じボリュームに書き込む」設計は、Persistent Disk では成立しません。この確認を後回しにすると、実装の直前に構成の作り直しが発生します。

そして最初に検討すべきは、アプリケーション側で回避できないかです。共有ファイルシステムを使っている理由が「複数のPodが生成したファイルを1箇所に集めたい」であれば、オブジェクトストレージに書く設計に変えられることが多くあります。これが最も安く、運用も軽い解決策です。

ReadWriteManyが要る場合の選択肢#

費用面の具体策があります。GKE向けFilestoreマルチシェアを使うと、10 GiB以上のFilestoreエンタープライズティアのインスタンスを、最大80のPersistentVolumeで共有できます。小さなPVを多数必要とする構成では、インスタンスを個別に立てるより費用を抑えられます。

ただし、ここに次章へつながる制約があります。Filestore のボリュームは、Backup for GKE のバックアップ対象外です。ReadWriteMany を選ぶと、バックアップの設計が変わります。この接続を見落とすと、バックアップを設定したつもりで対象から漏れます。

バックアップは、取ることより戻せることを設計する#

本記事で扱うのは、平常時の運用としてのバックアップと世代管理です。リージョン障害が起きたときの復旧手順とRPO/RTOの定義は第17回の管轄です。この線引きを設計書でも守ってください。

課金はNamespaceの数で決まる#

Backup for GKE の料金は2つの軸で発生します。

公式の計算例があります。1つのバックアッププランで、1か月に8つの非システムNamespaceをバックアップし、200 GiB のバックアップストレージを保存した場合、請求額は月$81です。内訳は管理料金$72（8 × $9.00）とストレージ$9（200 × $0.045）になります。

ここに、連載を通じた設計の接続があります。

Namespaceの数が、そのまま課金の単位です。第3回でNamespaceを細かく切る設計をした場合、第4回で按分の粒度を上げるためにNamespaceを増やした場合、その判断がここで費用として現れます。Namespace設計は、コストの設計でもあります。

第1回で確定したK8s税は、3環境で月約$407でした。バックアップ対象のNamespaceが20あれば、それだけで月$180が加算されます。Namespaceを増やす判断をするときは、按分の利便性だけでなく、この費用も同じ表に載せてください。

なお、バックアップをソースのクラスタと別のリージョンに保存する場合、ネットワーク下りのデータ転送料金が別途発生します。

バックアップされないもの#

ここが本章の核です。Backup for GKE がバックアップしないものが、ドキュメントに明記されています。この一覧を読んでいないバックアップ設計は、戻せません。

2番目について補足します。これは第9回で設計するレジストリのライフサイクルポリシーと正面から衝突します。古いイメージを自動削除する設定と、古いバックアップを保持する設定が矛盾していると、「30日前のバックアップは残っているが、それが参照するイメージは20日前に削除済み」という状態が生まれます。設計書で両者の期間を突き合わせてください。

4番目について補足します。Filestore のワークロードについては、Backup for GKE では構成のバックアップのみがサポートされます。ボリュームの中身は対象外です。ボリュームを保護するには、CSIドライバー経由のボリュームスナップショットAPI（VolumeSnapshot、VolumeSnapshotClass）を使います。

1番目は、見方を変えると重要な示唆になります。クラスタ構成はバックアップ対象外である以上、それを再現できるかどうかは第8回のIaCの品質に依存します。バックアップとIaCは補完関係にあります。

完了条件を「復元できたこと」にする#

設計書に書くべき項目を挙げます。対象（Namespace単位）、頻度、保持世代、保存先リージョン、暗号化の要否です。

頻度と保持世代の決め方は、第5回のシークレットローテーションと同じ形にします。慣習の数字を置かず、3つの入力から導いてください。

1. どこまで戻れれば業務が成立するか。これが取得頻度の上限を決めます。1日1回なら、最大24時間分の更新が失われます。それを業務が許容できるかは、インフラ側では決められません
2. 誤操作に気づくまでの時間。データを壊したことに1週間後に気づく運用なら、1週間分の世代が要ります。「直近3世代」では足りません
3. 保持世代 × ストレージ量 × $0.045。前節の課金です。世代を増やすと直線的に増えます

2番目を見落とさないでください。バックアップの世代設計は、障害からの復旧だけを想定して作られがちです。しかし実際に世代が必要になる場面の多くは、障害ではなく誤操作や不正なデータ投入で、これは気づくまでに時間がかかります。「何日前まで戻れるか」を、検知にかかる時間から逆算してください。

ゾーン障害への耐性は確認できています。Backup for GKE のアーティファクトはリージョン内の複数ゾーンに複製され、サービス自体も各リージョン内の少なくとも3つのゾーンに複製されます。ただしこれはゾーン障害への耐性であって、リージョン障害の話ではありません。そちらは第17回です。

そして最も重要な設計判断です。

バックアップの完了条件を「取得できたこと」にしないでください。「復元テストに成功したこと」にします。

これは第5回でNetworkPolicyの完了条件を「default-denyを入れたこと」ではなく「拒否ログがゼロであること」に置いたのと同じ形です。前者は設定した事実、後者は意図どおりに動いている事実です。前章の対象外リストを見れば分かるとおり、取得が成功していても復元が失敗する経路がいくつもあります。

設計書には復元テストの周期を書いてください。ここでも日数を慣習で置かず、「復元手順が壊れる要因が発生したか」で決めます。

• クラスタのバージョンを上げたとき（第14回）
• StorageClassやCSIドライバーの構成を変えたとき
• バックアップ対象のNamespaceを増減させたとき
• レジストリのライフサイクルポリシーを変えたとき（第9回）

これらはすべて、前節の対象外リストに関係する変更です。定期的な実施日を決めたうえで、上記のいずれかが起きたら次の定期実施を待たずにテストする、という二段構えにしてください。第6回でADRの見直しを「日付と条件の併用」にしたのと同じ形です。

実際にどういうシナリオでテストするかは第12回のカオスエンジニアリング・E2Eテスト計画で扱います。本記事は周期と完了条件を決めるところまでです。

【実務テンプレート】データ・ストレージ設計書#

第1回から第6回の成果物が入力になります。

次回予告#

データの置き場所が決まりました。次に決めるのは、ここまでの設計をどうコードとして管理するかです。

次回の第8回「IaC・リポジトリ構成設計書」では、Terraformのモジュール分割方針、リモートステートのバックエンド設計、環境分離の実装方式、IaCのCI/CD、そしてリポジトリ構成を扱います。

本記事で「GKEクラスタの構成情報はBackup for GKEの対象外」だと確認しました。つまりクラスタそのものを再現できるかどうかは、第8回で設計するIaCの品質に依存します。バックアップとIaCは、どちらか一方では足りません。両方が揃って初めて、失われたものを取り戻せます。