アプリケーション開発で実績があり、使い慣れたオープンソースのリレーショナルエンジンが必要なとき、MySQLは開発者が最も信頼を寄せるデータベースのひとつです。一方、Kubernetesは、現代的なワークロードを実行しスケールさせるために、採用されるオーケストレーションになりました。この2つを組み合わせると、面白い問いが生まれます。Kubernetesがアプリケーションにもたらすような、宣言的で再現可能な運用モデルで、MySQLをどう動かすのか、という問いです。
Kubernetes上でMySQLを実行することはデプロイから始まりますが、真の価値は運用サイクル全体が再現可能になったときに発揮されます。Kubernetes上でアプリケーションとデータベースを運用するチームには、アプリケーションのトラフィックをルーティングし、障害から復旧し、構成を変更し、バックアップでデータを保護し、リストアが実際に機能することを証明するための、一貫した方法が必要とされています。こうした運用管理（Day 2 Operations）こそが、データベースの配置を信頼できる運用モデルへと変えるのです。
Kubernetesは、データベースのライフサイクルが宣言的かつ再現可能になると、MySQLの操作性をさらに向上させます。MySQL Operator for Kubernetesを使用すると、手作業やスクリプト、ランブックを調整する代わりに、Kubernetesリソースを通じてMySQL InnoDB Clusterの望ましい状態を表現できます。
Oracle Kubernetes Engine（OKE）では、データベース実行環境、アプリケーション実行環境、イメージレジストリ、バックアップ先をすべてクラウドネイティブなワークフローに組み込めるため、このモデルは特に実用的になります。
デモリポジトリ: k-jaw/mysql-kubernetes
運用上の課題
実用的なMySQL デモは、プロビジョニングだけでなく、運用ループそのものを示す必要があります。
- レプリケーションされたMySQL実行環境をデプロイする
- アプリケーショントラフィックを安定したエンドポイント経由で振り分ける
- 書き込み可能なプライマリが失われたときに復旧する
- 設定変更を再現可能な方法で適用する
- データベースを永続性のあるストレージへバックアップする
- バックアップアーティファクトから新しいクラスタへリストアする
最初のMySQL PodがReadyになった時点でデモが終わるなら、それはインストールが終了しただけで、本当の運用はその後に始まります。
実務上の問題は、データベースの実行状態を、意図した実行状態とどのように一致させるか、ということです。
手動運用では構成のずれが生じたり、設定時のコマンドが後から忘れられることもあります。一時的な修復で、基盤となるランブックを更新せずにインシデントを解決できる場合もあります。バックアップは存在していても、復元が検証されていない場合もあります。宣言型操作は、プラットフォームが収束するための具体的な基準を提供します。
オペレーターモデル
MySQL Operatorは、望ましい状態の定義を、管理されたInnoDB Clusterの実行環境へ変換します。
中心となるオブジェクトは InnoDBCluster カスタムリソースです。このリソースには、何台のMySQLインスタンスを用意すべきか、Routerをどう配置するか、どの認証情報とシークレットを使用するか、ストレージをどう接続するか、バックアップをどのように構成するか、どのMySQL設定を適用するかといった、意図するデータベースの構成を記述します。
そこからオペレーターは標準的なKubernetesコントローラのパターンに従って動作します。
- YAMLで意図した状態を宣言する。
- Pod、Service、PVC、Secret、関連リソースの実際の状態を観察する。
- リソースを作成・パッチ適用・修復によって差分を収束させる。
- 障害後にデータベース・トポロジーを健全な状態へ戻す。
重要なのは、オペレーターが一度だけ実行されるスクリプトではないという点です。オペレーターは継続的に監視を行い、宣言されたクラスタと実際のクラスタを比較し、実行環境をその状態に合わせるように修正し続けます。
MySQLでは、ポッド、サイドカー、Router、サービス、シークレット、永続ボリューム要求(PVC)、バックアッププロファイルが、宣言されたクラスタ構成と結び付いた状態を維持します。データベースについては引き続きデータベースの知識が必要ですが、再現可能な運用メカニズムはKubernetesネイティブになります。
OKE上のリファレンスアーキテクチャ
この記事のデモアーキテクチャは、アプリケーションデータ、オペレーター制御、イメージ配信、バックアップ/リストアという4つの経路を分けています。
OKEクラスタの内部では、orders-api という小さなアプリケーションが、読み取りと書き込みの動作を可視化します。このアプリケーションは意図的にシンプルにしてあり、オーダーを書き込み、運用中のデータベースの挙動を観察できる程度のトポロジー情報を公開することが役割です。
アプリケーションは、demo-mysql-0 のような特定のMySQLポッドに直接接続しません。それではアプリケーションにデータベーストポロジーが漏れてしまいます。代わりにMySQL Router経由で接続し、背後のInnoDB Clusterがプライマリとレプリカの役割を担いつつ、アプリケーションには安定した読み取り/書き込みエンドポイントを提供します。
Routerの背後にはInnoDB Clusterそのものが存在しています。
demo-mysql-0demo-mysql-1demo-mysql-2
これらのMySQLインスタンスは永続ボリュームを使用し、レプリケートされたトポロジーに参加します。
MySQL Operatorは、Kubernetesのカスタムリソースを監視し、実行環境を調整します。InnoDBCluster や MySQLBackupリソースが変更されると、オペレーターはその宣言された状態を、実際のKubernetesオブジェクトとMySQLのライフサイクル操作へ変換します。
クラスタの外側では、2つのOCIサービスが重要です。
- OCIRは、OKEノードが取得するアプリケーションイメージを保持します
- OCI Object Storageはバックアップダンプを保存し、リストア元として使用されます
この分離は重要です。アプリケーションの経路はRouterを通ります。制御経路はKubernetesリソースとオペレーターを通ります。イメージ経路はOCIRを通ります。保護経路はオブジェクトストレージを通ります。結果として得られるのは、特別なブラックボックスではなく、MySQLの運用がKubernetesの状態として表現されたごく普通のクラウドアーキテクチャです。
Day 2運用デモの流れ
実際の運用を想定したデモとして、デプロイからリストアまでの一連の運用ストーリーとして構成できます。
実際の自動化内容は変わることもありますが、流れは次のようになります。
make prereqs
make operator
make mysql
make app
make failover
make config
make backup
make restoremake prereqs は、ローカルツール、コンテナランタイムへのアクセス、OCI設定、Kubernetesへのアクセスを検証します。
make operator は、mysql-operator 名前空間にMySQL Operatorをインストールまたは検証します。これにより、MySQLのカスタムリソースを理解するコントローラがクラスタに提供されます。
make mysql は、InnoDBCluster リソース、関連するシークレット、ストレージ設定、バックアップ構成を投入します。その後の待機処理で、MySQLポッドとRouterがReadyになることを確認します。
make app はデモアプリケーションをビルドしてデプロイします。これにより、単なる静的なターミナル出力よりも分かりやすい、データベースに対する実際の読み取り/書き込み動作を示せます。
make failover は、現在の書き込み可能なプライマリを特定し、そのポッドを削除します。Kubernetesはポッドを置き換え、InnoDB Clusterが書き込み可能なプライマリを選出または報告し、オペレーターが実行環境を正常な状態へ収束させるのを支援します。
make config は、宣言されたMySQL設定にパッチを適用します。重要なのは設定を変更できることはありません。もちろん変更もできますが、重要なのは、ポッド内のファイルを手動で編集するのではなく、クラスタ仕様として宣言できることです。
make backup はMySQLBackup リソースを作成し、完了を待ちます。バックアップはOCI Object Storageに保存されます。
make restore は、バックアップダンプを元に初期化された別のMySQLクラスタを作成します。これはより強い証明です。バックアップが完了しただけでなく、そのバックアップを使って別のオペレーター管理クラスタを起動できることを示します。
各ステップはKubernetesの状態を変更し、オペレーターは実行環境を調整します。
確認するポイント
オペレーターの価値は、リソースの状態とアプリケーションの動作を合わせて評価したときに見えてきます。
宣言された状態
1つのInnoDBClusterは、期待される実行環境、つまりMySQLポッド、サービス、PVC、Router、シークレット、バックアップ設定が生成されている必要があります。
確認すべきコマンドは次のとおりです。
kubectl get innodbcluster
kubectl get pods,svc,pvc証拠となるのは、Kubernetesにポッドがあることだけではありません。オブジェクトが宣言されたデータベース構成と一致していることです。
トポロジーの復旧
フェイルオーバーテストでは、まず現在の書き込み可能なプライマリを特定するところから始めます。その後、そのプライマリのポッドを削除し、システムが復旧する様子を観察します。
make primary
make failover
make primaryここで、データベース運用はコンテナ運用以上のものになります。ポッドを置き換えることは必要ですが、それだけでは十分ではありません。データベーストポロジーも、書き込み可能なプライマリを持つ正常な状態に戻らなければなりません。
バックアップとリストアの証明
バックアップは話の半分にすぎません。リストアによって、バックアップアーティファクトが新しい実行環境を初期化することが確認できます。
make backup
make restoreバックアップでは、MySQL Shell ダンプユーティリティを使い、ダンプファイルをOCI Object Storageに出力します。リストアは、そのダンププレフィックスから初期化された、demo-mysql-restore のような名前の別クラスタを作成する必要があります。
これにより、保護は付随的なワークフローではなく、観察可能なKubernetesの操作になります。
MySQL Operatorで何が変わるのか
オペレーターはデータベース運用を不要にするものではありません。運用をどのようにまとめ、繰り返し、観察し、修復するか、その方法を変えるものです。
オペレーターがない場合、プロビジョニングは手作業の構成やスクリプトに依存しがちです。MySQL Operatorがあれば、プロビジョニングはInnoDBCluster の宣言になります。
オペレーターがなければ、ルーティングは手作業で管理されるエンドポイント群になりがちです。MySQL Operatorがあれば、MySQL Routerは望ましいクラスタ状態の一部として収束されます。
オペレーターがなければ、復旧は人が主導する修復手順に依存することがあります。MySQL Operatorがあれば、Kubernetesのポッド置き換えとInnoDB Cluster のトポロジーの調整が連携して、実行状態を正常な状態へ戻します。
オペレーターがなければ、バックアップはデータベース実行環境設定の外側にある別ワークフローになりがちです。MySQL Operatorがあれば、オブジェクトストレージのバックアッププロファイルとMySQLBackup リソースにより、バックアップとリストアが同じ運用モデルの一部になります。
まとめ
データベースとして引き続きMySQLを利用しながら、Kubernetesネイティブの運用モデルになります。
このことは、すでにKubernetesをアプリケーションプラットフォームとして利用している方々にとって、OKE上でMySQL Operatorを利用する実用的なメリットになります。データベースのライフサイクル運用を、アプリケーションスタックと同じプラットフォームAPIで、宣言し、監視し、繰り返し、監査できるのです。
Kubernetesは、MySQLのライフサイクル、耐障害性、バックアップ、リストアのための運用APIになります。
それによって MySQL の理解が不要になるわけではありません。日常的な運用タスクのすべてを、壊れやすい手作業の連続として記述する必要をなくすものです。オペレーターはプラットフォームに収束すべき状態を与え、運用担当者にはデータベース実行環境が宣言通りに動作していることを証明する、より明確な方法を提供します。