Recruit Tech Blog
目次
はじめに
こんにちは、『Airレジ オーダー』の開発に携わっている岡本です。
『Airレジ オーダー』は、飲⾷店の業務をカンタンにするオーダーシステムです。 お店のオペレーションや予算から、注⽂⽅法と調理・配膳の管理⽅法を選んで利用できます。
本記事では、DBマイグレーションツールをFlywayからsqldefに移行した経緯と、その過程で得られた知見について共有します。
Flywayでの課題
『Airレジ オーダー』では、もともと一般的なDBマイグレーションツールであるFlywayを採用していました。Flywayは手続き型のマイグレーションツールで、マイグレーションファイルを時系列順に実行することでDBスキーマの変更を管理します。
Flyway自体は優れたツールですが、私たちのプロジェクトでは以下のような課題が発生していました。
-
複数環境で開発することによるマイグレーションの衝突 : 複数の案件を複数の環境で並行して開発しており、環境を切り替えるたびにマイグレーションの衝突が発生していました
-
設計変更時のマイグレーション適用の煩雑さ : 案件開発中にDBの設計変更が発生するたびにマイグレーションファイルの変更が必要になり、その場合のマイグレーションの適用手順がFlywayでは煩雑になっていました
-
開発順序とリリース順序のズレ : Flywayはマイグレーションファイルの番号が若い順に適用しますが、作成された順番と実際に適用する順番でズレが発生する場合がありました
-
マイグレーション履歴の管理複雑化 : 長期間の開発で膨大な数のマイグレーションファイルが蓄積され、管理するファイル数がプロダクトの歴史と共にどんどん増えていきました
図1. Flywayでのマイグレーション衝突の課題
これらの問題は、特に複数の大型機能を並行開発している時期に顕著でした。DBマイグレーションを正しく行うことに多くの時間を使ってしまっており、開発効率の低下につながっていました。
sqldefの採用
sqldefは、宣言型のDBマイグレーションツールで、Flywayで感じていた課題を解決できそうだと考え、移行を決断しました。
より具体的には、1と2の課題については現在とDBの状態と定義されたスキーマ定義の差分を比較してマイグレーション用のSQLを発行するため、カラムの追加や削除といった単純なマイグレーションであれば手間なく実施ができます。
3と4の課題についてはDBのスキーマ定義を単一ファイルで管理するため、マイグレーションファイルの数が膨れ上がることや、ファイルの名称を気にしなくてもよくなります。
『Airレジ オーダー』に導入する上での課題と解消
sqldefへの移行を進める中で、『Airレジ オーダー』固有の課題が浮上しました。『Airレジ オーダー』では検品環境では同じクラスター、異なるデータベースで同じビュー名を使用していました。 sqldefの既存実装では異なるDBに同名のビューがあった場合に特定のDBのビュー定義を取得してきてしまい、想定の差分が得られませんでした。
図2. 同名ビューによるsqldefの課題
この課題を解決するため、sqldefにコントリビュートし、ビュー名に加えてDB名で対象を絞る実装に修正しました。
これにより、異なる環境間でも同じビュー名を持つビューを正しく処理できるようになり、『Airレジ オーダー』に無事導入することができました。
他プロジェクトへの展開
『Airレジ オーダー』でsqldefを導入し、Flywayで感じていた開発での負を解消できました。 開発体験が好評だったため、関連プロジェクトである『Airレジ オーダー モバイルオーダー』でもFlywayからsqldefに移行しました。
移行後、モバイルオーダーのチームから新たな要望としてALTER TABLE文実行時にALGORITHMオプションを指定したいというニーズが開発チームから上がりました。 この要件に対応するため、再度sqldefにオプションを付与できるようにコントリビュートを行い、対応することができました。
運用の工夫
sqldefの利用をより安全で効率的にするため、シェルスクリプトで各操作をラップしました。具体的には以下のシェルスクリプトを用意しました
- dry-run用シェル : スキーマを変更せずに適用されるSQLを確認するためのスクリプト
- apply用シェル : スキーマの変更を適用するスクリプト。ロールバック用にバックアップを取得します
- rollback用dry-runシェル : スキーマを変更せずにバックアップした状態に戻すためのSQLを確認するためのスクリプト
- rollback用シェル : バックアップした状態に戻すためのスクリプト
- export用シェル : 現在のDBの状態を出力するスクリプト
コマンドをシェルスクリプトにラップすることでコマンドが標準化され、リスクの高いDB操作でもdry-runでSQLの確認もでき、適用時のヒューマンエラーリスクも低減する工夫をしています。
本件から得た学び
ツールのポピュラーさでいえばFlywayだと思いますが、今回はsqldefが課題を解決すると考え移行を行いました。
今回の事例では必要としていた機能の一部がsqldefでは未実装であったため、そのままでは導入できませんでした。 しかし、OSSであるsqldefへコントリビュートすることで導入のネックを解決することができました。これはOSSならではの1つの利点だと感じました。
副次的効果として、機能追加により他の方の導入ネックも解決できる可能性があり、採用しているOSSがさらに盛り上がる利点もあると考えています。 実際に、ALGORITHMオプション付与できる機能追加後にLOCKオプションも付与できるようにしたいとプロジェクトで議論になったのですが、既に他の方が対応してくれていました。
まとめ
『Airレジ オーダー』では、DBマイグレーションツールをFlywayからsqldefに移行することで、開発効率の向上とエンジニアの満足度向上を実現しました。また、sqldefにコントリビュートすることで、プロジェクト固有の要件にも対応できました。
宣言型のDBマイグレーションツールは、複数の開発者が並行して開発するプロジェクトでは特に有効であり、検討する価値があると考えています。