これはなに
こんにちは、レバテック開発部のもりたです。
先日、担当システムでのAWS Aurora→TiDB Cloud移行プロジェクトが完了しました。特に事故や不具合なく移行完了できたのですが、プロジェクト管理の観点で見たとき、なにをすれば良いのか分からず難儀する場面も多かったです。今回は自分のような人向けに、データベース移行プロジェクトでアプリケーションチームの人間が何をすればいいのか簡単にまとめていきたいと思います。
構成
構成
今回の構成は以下の通り
- プロジェクトの概要
- 移行プロジェクトで実施すべき３つのタスク
- 思い出深いもの
まず、どんなプロジェクトだったのか解説し、その後に具体的な内容について触れていきます。最後に今回のプロジェクトで思い出深いもの・仕様などについて書きます。
プロジェクトの概要
はじめにこの移行プロジェクトがどのような形式で行われたのかについて簡単に説明しておきたいと思います。
概要は以下のとおりです。
- AWS Aurora→TiDB Cloudへの移行
- レバテック開発部全体の取り組みとして実施
- 作業を共通化できるデータ移行部分はSREチームが担当し、アプリケーションチームはアプリケーションに依存する箇所を担当
- 具体的には、個別クエリの検証まわりやメンテナンス作業など
- アプリケーション側は途中で担当を引き継いで進行した
- わたしは後半担当
なおSREチームの担当したデータの移行周りに関しては、以下の記事に工夫がまとめられています。気になる人は読んでみてください。
移行プロジェクトで実施すべき３つのタスク
ではここからは、具体的に実施したタスクについて解説します。
データベース移行に限らず、基本的にシステムを構成する何かを入れ替える時は３つの要素を含んだプロジェクトになります。それが「調査と組み込み」と「メンテナンス実施」、「移行後の運用整備」です。
以下にそれぞれ、今回どんなタスクを実施したのか整理します。
調査と組み込み
まず最初にやるのが調査と組み込みです。
調査フェーズでは、移行先のデータベース製品と現在使っているものにどんな差分があるかを調べます。例えばトランザクション分離レベルの違いだったり、AUTO_INCREMENTの挙動の違いだったり[1]、そういった代表的な懸念点に関して、自社システムではどんな影響があるか考えます。
次は組み込みフェーズです。これは調査で洗い出した懸念点に関して、実際にテスト環境などで組み込んで試してみる段階です。ここで「これ動かんやんけ...」みたいなのが見つかったりします[2]。
メンテナンスの実施
懸念が払拭されて移行できそうだとなった時点で、メンテナンスの予定を組み始めます。
具体的には以下のようなことをやります。
- メンテナンス方式の決定（停止型なのか無停止型なのか、など）
- 影響範囲の確定（どのサービスに影響があるか）
- ステークホルダー相手に影響範囲と日程の合意
- メンテナンス手順の整理・テスト
- 実施
データベース移行プロジェクトっていうとメインは調査とか組み込みってイメージがあったんですが、半分くらいはここら辺の調整にあたっていたような気がします。案外工数を必要とするので、スケジュールを組むときは計算に入れておきたいですね。
移行後の運用整備
そして最後に実施するのが移行後の運用整備です。
移行プロジェクトではシステムの一部を取っ替えるわけですから、そのとっかえた先の製品の使い方は当然誰も知りません。その状態でも移行前と同じような運用を実現するべく、マニュアル作りやルール整備等をする必要があります。
今回のTiDB移行であれば、監視用ダッシュボードの場所やマイグレーションファイルの作成方針などを決める必要がありました[3]。
思い出深い仕様、所感
ここからは思い出深いTiDBの仕様や所感などをまとめます。
/!Ti記法
移行プロジェクトの推進中、環境ごとにMySQLとTiDBが混在してしまうことは往々にして発生します。こういった場合、アプリケーションで管理するスキーマファイルはふたつのデータベースどちらもに対応したスキーマファイルを作成する必要があります。
TiDBはMySQL互換のデータベースですが、TiDBにしか使えないオプションなども存在し、そのためプロジェクト中は、TiDBでは有効に動く一方MySQLではコメントとして認識される書き方をしなければなりませんでした。
ちなみに以下です。
/*T! AUTO_ID_CACHE=1 */;
この記法なんですが、地味に見つけるのが大変でした。あるだろ、、と思ってググっても見つからず、やり方ないのかと思っていたらチームのメンバーが見つけてきてくれました。半信半疑で実行してみて実行できたので、どうやら本当らしいなと思いながら使っています。
MySQL互換モード
続いてはMySQL互換モードです。
MySQLではオートインクリメント指定したIDは１ずつ順増していきますが、TiDBは分散データベースの特性上、IDが飛んだり、順番が入れ替わったりということがあります。
この仕様は、MySQL互換モードというオプションをテーブルの作成時に指定することで回避可能です。ただし、TiDBのメリットを潰しているわけなので、パフォーマンス影響があると言われています。
わたしの運用しているシステムではIDがインクリメントすることが前提の実装が複数箇所あり、またパフォーマンス要件も厳しくなかったためMySQL互換モードを採用することにしました。
妥当なラインを決めるのがたいへん
今回もっとも頭を悩ませたのは、非機能要件の妥当なラインを引くところだったと思います。機能要件ははっきりと合格不合格が分かりますが、パフォーマンスに関してはなにをもって合格とするかの基準がなく、開発者があらかじめ機能一覧の中から重要な機能を抜き出し、それらに影響がないことを確認して進めました。
また、わたしの管理するシステムは元々が負荷の低いシステムであり、データベースのパフォーマンスが問題になったことも数えるほどしかありませんでした。そのためパフォーマンステストで比較するための指標などをあまりとっておらず、とりあえずスロークエリの比較をする程度でした。
本来望ましいのは、普段からプロダクトのどの機能が重要で、どのようにユーザに価値を提供しているのかをビジネスサイドと共有しておくことなんだろうなと思います。これはプロダクトマネジメントの考え方ですが、アプリケーション開発含めこういったデータベース移行の際にも意思決定の支えになるため、今後は導入していきたいなと考えています。
おわりに
初めてのデータベース移行プロジェクトでしたが、なにはともあれ大きな事故もなく移行が成功してよかったです。一回やったら次はもっとスムーズにやれると思うので、次の機会があれば胸はってやろうと思います。
以上！！
Discussion