こんにちは、かたいなかです。
以前、マッハバイトのメインDB(MySQL)にRidgepoleを使ってDDLを実行する基盤を構築しました。
これを転職会議にも横展開する際に、実行しようとしているDDLがオンラインDDLに対応しているかを事前にチェックできるようにしました。
備忘録的に仕組みを記事にまとめます。
前提
今回DDLを実行する対象のDBはMySQLです
Ridgepoleとは
宣言的にデータベースのスキーマを定義し、マイグレーションを行うためのツールです。
ほしいテーブル構造をDSLで宣言的に定義すると、現在のスキーマ構造との差分を計算し、必要なALTER TABLE文を計算して発行してくれます。
Ridgepoleを使うことで、どのようなDDLを実行するかではなく、どのようなスキーマが必要かを記述することに集中することができるようになります。
マッハバイトでも、このRidgepoleを利用してDDL実行のしくみを構築し、宣言的なスキーマ管理ができるようになっています。
今までのDDL実行基盤での課題
Ridgepoleを使うことで、必要なスキーマを考えることに集中できるようになる一方で、どのようなDDLがどのようなアルゴリズムで実行されるかは気にしておきたいです。
特に、大きなテーブルに対してDDLを実行するケースなどでは、サービスダウンにつながってしまう可能性があるため、オンラインDDLとして実行できない場合は慎重に実行するようにしたいです。
これまでは、マッハバイトのDDL実行の仕組みでは、オンラインDDLに対応しているかなどのアルゴリズムのチェックはできていませんでした。
リブセンス内でも過去に大きなテーブルに対してのDDL実行で障害起こしてしまった事例があり、心配がある変更を検知できるようになっていないのは不安が残っていました。
改良後のDDL実行基盤
実行されるアルゴリズムをチェックするために、開発用DBとして利用しているMySQLのコンテナイメージを利用することにしました。
この開発用DBは、mainブランチ上のRidgepoleが定義するスキーマが適用されています。
この開発用DBコンテナに対してPull RequestのRidgepole DSLを適用することで、どのアルゴリズムでDDLが実行されるかを調べます。
具体的には、Ridgepoleのオプションを以下のように、制約が強い順に指定して実行し、どこで成功するかを調べることで、どのアルゴリズムなら実行できるのかを調べます。
--alter-extra ALGORITHM=INSTANT--alter-extra ALGORITHM=INPLACE LOCK=NONE--alter-extra ALGORITHM=COPY
この処理をGitHub Actionsのワークフローで実行し、結果をPRのコメントに出力するようにしました。
出力されたPRのコメントをもとに、夜間の実行にする、pt-online-schema-changeを使って適用する、などの対応を検討してもらうようにしています。
まとめ
Ridgepoleで宣言的なスキーマ管理を実現しながら、危なそうなアルゴリズムで実行しているDDLを事前にチェックできるようにすることで、利便性と安全性を両立したDDL実行の仕組みを構築することができました。
これからも、DDL実行にとどまらず、利便性と安全性を両立した仕組みを構築していくことで、開発者の生産性を支えていければと思います。
参考
今回の記事の仕組みの構築にあたっては、こちらのLegalOn Technologiesさんの記事で紹介されている仕組みを大いに参考にさせていただきました！ tech.legalforce.co.jp
MySQLの公式ドキュメントのオンラインDDL関連の箇所 dev.mysql.com
