こんにちは。DBRE チーム の飯塚です。
cybozu.com では kintone や Garoon をはじめとする様々なクラウドサービスを提供しており、その多くで MySQL をプライマリデータストアとして利用しています。お客様に安定したサービスを提供するためには、この基盤となるデータベースの設計と運用が非常に重要です。本記事ではサイボウズのプライベートクラウドにおける MySQL の利用形態、マルチテナント SaaS のデータベースとして利用するための付加機能、そして安定稼働のための工夫について紹介します。
サイボウズのプライベートクラウドにおける MySQL の利用形態
サイボウズでは長年にわたり VM ベースの旧プライベートクラウドでサービスを提供してきましたが、近年は Kubernetes を基盤としたコンテナベースの新プライベートクラウド Neco への移行を進めています。MySQL については、ごく一部のレガシーなシステムを除いて、2024 年中に Neco 環境への移行が完了しています。
新しいプライベートクラウドでは、すべての MySQL はサイボウズ製 OSS である MOCO を使ってプロビジョニングされています。MOCO は MySQL の HA 構成の設定やフェイルオーバー、オートヒーリングなどを自動化する Operator です。詳細については以下の資料をご覧ください。
MySQL のデータが書き込まれるストレージとしては、連載第5回で紹介された TopoLVM を利用しています。
TopoLVM を使って Kubernetes Node のローカルディスクにデータを保存することで高い IOPS と低い IO レイテンシの恩恵を受けることができます。TopoLVM はその代償として Kubernetes Node やローカルディスクが故障するとそこに保存されたデータが利用できなくなってしまいますが、MOCO では MySQL の機能を使ってアプリケーションレベルでレプリケーションしてデータを冗長化しているため、レプリカがすべて失われない限りはデータが消えてしまうことはありません。また、失われた冗長度は MOCO のオートヒーリング機能によって回復できます。
Kubernetes 本体が提供している topologySpreadConstraints や TopoLVM が対応している Capacity-Aware Scheduling などの機能と組み合わせることで、MySQL のインスタンスを管理している私たち DBRE チームは、どの物理サーバー上で MySQL を起動するかといった個別のスケジューリングについてほとんど気を取られることなく数百インスタンス規模の MySQL を運用することができています。
マルチテナント SaaS のための付加機能
cybozu.com はマルチテナント型の SaaS です。DBRE チームでは単なる社内 MySQL マネージドサービスを提供するだけでなく、プロダクトチームがマルチテナントアプリケーションを開発・運用しやすくするためのさまざまな補助コンポーネントを開発し、社内に提供しています。
マルチテナント対応のプロビジョニングサービス
お客様が cybozu.com のサービスを申し込むとテナントのオンボーディング処理が動き出します。MySQL に対してはお客様のデータを保存するためのテナント専用の DATABASE 領域とテナント専用のユーザーがプロビジョニングされます。サービスの解約時には逆の処理が行われます。
DATABASE 領域やユーザーのプロビジョニング先は数百以上ある MySQL インスタンスプールの中からリソース使用量が少ないものを選択すべきです。また、テナント専用のユーザーの作成時にはテナント間の isolation のために適切な権限設定を行う必要があります。このように複数の重要な要件を持つ処理を各プロダクトチームで個別に実装することは難易度が高いため、DBRE チームではプロビジョニング処理を引き受ける専用のマイクロサービスを作成し、プロダクトチームに提供しています。このマイクロサービスは個別のプロダクトのコントロールプレーンから利用されています。
テナントごとのリソース使用量に着目したテレメトリ
MySQL の一般的な監視をすることは当然として、マルチテナント SaaS ではテナントごとのリソース使用量についてもメトリクスを取得することが安定稼働に繋がることが少なくありません。MOCO が提供している mysqld_exporter ベースのモニタリングに加えて、DBRE チームでは以下のようなメトリクスを取得するための Prometheus exporter を開発しています。
- テナントごとのディスク使用量: ディスク使用量に応じた課金にも利用されています
- テナントごとの CPU 使用量: MySQL 8.0.28 から performance_schema の events_statements_summary テーブルを通じて MySQL ユーザーごとの CPU 実行時間を取得できるようになりました
これらのメトリクスは VictoriaMetrics に収集して、定期的なリソースプランニングのために利用されています。それに加えて、BI ツールにも取り込むことでビジネスやサポートの文脈でも活用されています。
障害告知システムと連携したモニタリング
DBRE チームが運用している MySQL には SLO ベースのアラートが設定されています。アラートの設定においては Site Reliability Workbook で紹介されているテクニック を参考にしています。
このアラートはオンコールの呼び出しに使われるだけでなく、障害告知システムとも連携しています。ある MySQL インスタンスで障害が発生した際には、そのインスタンスに収容されているテナントを特定し、そのテナントの cybozu.com 稼働状況 の画面に障害を告知できるようになっています。MySQL インスタンスに収容されているテナントの特定には前述のプロビジョニングサービスを利用しています。
安定稼働のための工夫
定期的なリストア試験
MySQL のデータはバックアップを毎日取得し、Rook/Ceph のオブジェクトストレージに保存しています。このバックアップから本当にデータが復元できるのかを検証することは非常に重要です。一見すると当たり前のように思えますが、取得しているはずのバックアップから復元できなかったという悲劇は業界でしばしば見られます。この教訓から、サイボウズが取得している様々な認証や監査（ISMS, ISMAP, J-SOX など）では、バックアップのリストア試験を定期的に実施することが求められています。
この対策として、バックアップデータのリストア試験を実施するためのカスタムコントローラーを開発し、定期的に実行しています。この試験ではオブジェクトストレージのバックアップからリストアした MySQL を作成できること、リストアしたデータベースに含まれているデータが意図通りであること（別のインスタンスと取り違えていないこと、データが古すぎないこと）をチェックしています。
VM ベースの旧プライベートクラウドでは、このリストア試験のためのジョブは VM やボリュームを作成・破棄できる強力な権限を持つ危険な存在でした。Kubernetes ベースの新プライベートクラウドでは Kubernetes の RBAC の仕組みによって、Kubernetes クラスタの管理権限を持たない単なる一つのテナントチームの権限でジョブを開発・実行することができています。
MySQL クラスタ内のデータの一貫性チェック
MOCO で作成した MySQL クラスタに属する個々のレプリカは、レプリカ間でデータが一致していなければなりません（レプリケーション遅延などは除く）。しかし、あってはならないことですが、運用のミスや MySQL の不具合によって一貫性が壊れている可能性を考慮して、データの一貫性をチェックするためのカスタムコントローラーを開発し、定期的に実行しています。この一貫性チェックの手法は以下の講演から着想を得たものです。
おわりに
この記事ではサイボウズのプライベートクラウドにおける MySQL の利用形態、マルチテナント SaaS のデータベースとして利用するための付加機能、そして安定稼働のための工夫について紹介しました。
私たちはこれからも、お客様に安定したサービスを提供できるよう、サービスの運用改善に日々取り組んでいきます。本記事が大規模なデータベース運用に携わる皆様の一助となれば幸いです。
