PUSHCODEのDB移行&更新

この記事はEDOCODE Advent Calendar 2023、12月21日(木)の記事です。

1つ前の記事は、AmeeさんのThe Power of Storytelling in E-commerce Marketing: Transforming Shopify Stores for Successでした。
また、グループ会社　WanoのAdvent Calendarもありますので、そちらもどうぞ！

この記事では、今年の夏に行ったPUSHCODEのDB移行&更新プロジェクトに関して書きます。

移行内容と背景

このプロジェクトではDBの移行(GCP Compute EngineのCentOS上で動いていたMySQL -> Cloud SQL for MySQL)とMySQLのVersion更新(MySQL 5.7 -> MySQL 8.0)を同時に行いました。これに伴うサービスのダウンタイムは30分ほどでした。

DBの移行の背景はインフラに手を回すリソースがあまりないため、managedサービスに移行しました。またMySQLの更新は移行前に利用していたMySQL 5.7のEOFが今年の10月だったためです。他のDBMSも検討をしましたがpartitionに余裕があることもあり、移行前と同じMySQLになりました。

移行前と移行後の構成

移行前と移行後の構成は下記のようになっています。オレンジ色がCompute EngineのCentOS上で動いていたMySQL 5.7です。

※MHA(=Master High Availability Manager and tools for MySQL)
　移行前に利用していたHigh Availabilityのためのツール

※HA(=High Availability)
　Cloud SQLでHigh Availabilityを実現する設定です。これをonにすることで移行前と同程度の可用性を担保することができました。

移行の流れ

移行は以下のステップで行いました。今回説明するのは2と5の太字の箇所です。

1. 公式ドキュメントから更新情報を集める
   • 移行前に利用していたMHAを利用しながらDMSを利用できるかの確認
   • MySQL 5.7->8.0の変更点の確認
   • 移行前と同じavailabilityを担保するのに必要な設定の確認
   • Cloud SQLで使える設定の確認
2. コード修正と設定変更
3. テスト環境での検証&動作確認
4. 移行前準備(下の図の②)
   • 移行前DBと移行先DBをDMSを使ってreplication
5. パフォーマンス計測　＆　移行先のspec決め
6. 移行作業(下の図の③)
   • コード変更をリリース
   • DMSで移行先DBをpromote
7. 移行後の監視設定

移行の流れを図にしたのがこちらです。

※DMS(= Database Migration Service)
　移行時のダウンタイムを少なくするために移行前のDBをreplicatationする必要がありました。その際に利用したGCPのサービスです。これを使うことで移行前にMHAを使いながら同時に移行先DBにreplicationを行うことが出来ました(図の②)。

コード修正と設定変更

変更内容は一つ前のステップで行ったUpgradeのガイド,Upgrade Checker Utility,Cloud SQLのflagを参考にして一覧を作成しました。読むドキュメントの量が多いこと、またこのステップ後に動作確認を行いますが、見落としがあるとincidentに繋がるため神経を使いました。

コード修正

PUSHCODEではORMを使っていないため、コードベース中にSQLがあります。そのため、MySQLのversionアップに伴うSQLの変更に対応する必要がありました。該当する変更は1つでGROUP BY byでの暗黙のソートの廃止のみでした。こちらは今まで暗黙でGROUP BYで指定したカラムでソートがされていましたが、同じ結果を得るためにMySQL 8からはORDER BYをつける必要があります。この変更のため順番が影響する箇所を調査し該当するところにはORDER BYの追加をしました。

設定変更

Cloud SQLではflagで設定を行います。今回、移行に伴って削除したもの、値が変わったもの、追加になったものに分けていくつか紹介します。

• 削除したもの
  移行前はinnodb_buffer_pool_sizeを指定していましたが、Cloud SQLがデフォルトで最大値を設定するため明示的に設定するのをやめて削除しました。

• 値が変わったもの
  max_heap_table_sizeとtmp_table_sizeの値を256M -> 67Mに変更しました。当初は移行前と同じ256Mを設定する予定でしたが最大67Mまでしか設定をすることができませんでした。Tipsにもあるようにこれらに大きな値を設定するとinstanceが再起動する危険があるため設定できる最大値をMemoryに応じて制限していると思われます。

• 追加したもの
  general_logとdefault_time_zoneを追加しました。general_logは移行後にDBが期待通り動いているかの確認のため一時的にonにしました。また。Cloud SQLではデフォルトのtimezoneがUTCのためdefault_time_zoneを-9:00にする必要がありました。

パフォーマンス計測　＆　移行先のspec決め

本番環境相当のデータを試験環境で用意する時間の余裕がなかったため、本番データをreplicationした後にパフォーマンス計測と移行先instanceのスペック決めを行いました。

計測用のクエリ

遅いクエリを探すため、slow queryを有効にしてmysqldumpslowを使ってクエリのリストを参照しました。クエリのリストから多くのtableをjoinしている&partitionを切っていて多くのレコードが入っているものをパラメータとして選びました。
また、キャッシュによる影響を排除するためorder byにrand()を使ったクエリでも計測を行いました。EX: select * from users order by rand() limit 100;

移行先のspec決め

移行前と同等のCPU,MemoryのCloud SQLのinstanceで期待通りのパフォーマンスが出ませんでした(最大2.5倍実行に時間がかかった)。その後調査を行うとEnterprise Plus(Cloud SQL for MySQLのeditionの一つ)の存在を知り、CPU, Memory, Enterprise(defaultのedition) or Enterprise Plusを変えパフォーマンス計測を行いました。最終的にはEnterprise Plusで移行前のCPUの半分のコア数、memoryは6割の量で決まりました。

最後に

本番環境のDB移行をするのは今回が初めてでした。また普段の開発ではDBをあまり意識する機会が少なかったです。このプロジェクトを通してDBの学びや理解が深まる良い機会になりました。今後もキャッチアップをしつつDBのパフォーマンスを最大限に出せるようにスペックや設定の見直しを適宜行う予定です。
今回のプロジェクトを終えるにあたり、@ktatさん、@fujitayyさんに多くのヘルプをしていただきました。ありがとうございました。

明日12/22(金)は、デザイナーのTingyaさんによる「他言語でのuser interview」という記事です。

また、現在Wanoグループでは人材募集をしています。興味のある方は下記を参照してください
JOBS | Wano Group