データベースをMySQL8.0へ移行を実行する上で考えてたこと

Transcript

1. データベースをMySQL8.0へ移行を実行する上で考えてたこと 2023/9/26 アソビュー株式会社　SREユニット 鈴木剛志
2. © ASOVIEW Inc. 2 About Me Name :　鈴木剛志（すずきたけし） Company：アソビュー株式会社 SRE ユニット Twitter: @takesuzu90 DB経験（前職含む） • Oracle • DB2(IBM) • PostgreSQL • MySQL それぞれの特徴を掴むくらいまでは触ってました。
3. © ASOVIEW Inc. 3 本日のLTでお話しすること 本日は、下記のような内容を話していこうと思っています。 • 弊社サービスの概要と今回の移行の流れ • DB移行検討前に考えるべき観点 • 実際にやったことの概略 • 移行後の運用状況
4. © ASOVIEW Inc. 4 弊社サービス概要 遊び予約サイト「アソビュー！」を運営しています。 toC向けには、電子チケットの販売などを行う一方、 toB向けには、それに関連する業務を サポートする機能を提供しています。
5. © ASOVIEW Inc. 5 サービス規模感 • サービスローンチ: 2012年(12年目) • 会員数: 約1,000万人 • 契約施設数: 約10,000施設 • 全プロダクトコード(有効コードベース): 4,000,000+ step • テーブル数: 2,000+ table • ピークトラフィック: 4,000+ rps • プロダクト部門: 約100名 • チーム数: 15 team
6. © ASOVIEW Inc. 6 移行元DBと移行先DB 移行元 • MySQL(5.6) • PostgreSQL (10) 移行先 • MySQL(8.0) • PostgreSQL (13) 同じMySQL同志の移行でしたが8.0系は２つは結構大きな仕様の変更などがあり 通常のバージョンアップよりも、重点的な確認が必要でした。
7. © ASOVIEW Inc. 7 DB移行検討前に考えるべき観点 一般的に、データベースの移行を行うときには下記の観点により戦略を考えていきます。 • 移行の前後における仕様変更点にはどのようなものがあるのか。 ◦ SQLなどの構⽂の差異がどの程度あるか。 ◦ 組み込み関数などの差異がどの程度あるのか。 ◦ パフォーマンスの変化がどの程度あるのか。 ◦ などなど • サービス停止の可否について/移行に必要な時間 ◦ 可能な場合には、どの程度の時間停⽌が可能なのか ◦ 移⾏の完了には、どの程度の時間が必要なのか ▪ 移⾏に、停⽌可能時間を上回る場合には、移⾏の難易度が⼤幅に上がってきます 当社の場合には、1:00 - 6:00の５時間までならメンテナンスによる停止可能 だったので、まずは、この時間内に終わるかという観点で移行時 間の調査から初めていきました。この結果次第によって移行戦略が左右されるためです。 なるべく少ない工数で移行を計画できるようにしていくのが大切かと感じます。
8. © ASOVIEW Inc. 8 DBのバージョンアップにかかる時間の検証 弊社では、Aurora MySQLを利用していましたので下記の手順で実行しました。 1. 本番環境DBのSNAPSHOTから、DBを複製し、AuroraMySQL 5.6のDBを立てる 2. 起動後に、コンソールから、AuroraMySQL 5.6⇨5.7へバージョンアップする 3. 動後に、コンソールから、AuroraMySQL 5.7⇨8.0へバージョンアップする 検証結果として、Step２の時点で４時間以上かかってしまうケースがあることが判明。この時間だと、ダウンタイムをもうけての戦略が利用 できないので、原因を調査。 結果として、未コミットのデータが多い場合に、時間がかかってしまうことが判明。バージョンアップの数時間前から対応するバッチ処理を停 止するなどすれば、回避できることがわかった。
9. © ASOVIEW Inc. 9 仕様変更の調査方法について 最初は、ドキュメントベースでの仕様の差異を調査して、仕様変更の箇所をソースコードの Grepなどをベースに確認していきます。ある程度 まで、影響範囲の規模感をドキュメントベースでつかんだ後に、実際に影響のある変更点を洗い出す方法として、移行をシミュレーションす ることによって課題を洗い出していく方式が効率的だと思います。当社の場合には、 1. 旧バージョンでの実行クエリの記録 2. 新バージョンでの実行クエリの再生 というのを実行して、事前に下記をリストアップしておきました。 • 移行先でエラーになってしまうSQL • 移行先でパフォーマンスが劣化してしまう SQL ここも、それほど大掛かりな仕組みを用意したわけではなく、標準機能のクエリログを出力して、それを読み込んで実行するということを愚直 に実行しました。 サーバのバージョンによってライブラリが勝手に実行するクエリなども記録側には含まれていたので、そこら辺を一つ一つ目視でフィルタして いく必要はありましたが、リストアップはこちらの方法でもほぼ問題なく実施できました。 結果、何が見つかったかなどは、ブログに記述しています。
10. © ASOVIEW Inc. 10 移行後の運用状況 利用頻度の低い機能については、パフォーマンスの劣化などの部分がありましたが、普段のサービスを提供するにおいては師匠が発生す るような問題は起きませんでした。 実際に、この移行ポイントを押さえておけば、必要最低限の工数で移行をしていくことができるのではないかと思います。
11. © ASOVIEW Inc. 11 こちらの発表の元になっているブログ紹介 本発表は、下記のブログを元に作成しています。 Aurora MySQL 5.6->8.0/PostgreSQL 10・11 -> 13へバージョンアップした 話。アソビューのDB移行戦略
 https://tech.asoview.co.jp/entry/2022/12/19/090450
12. © ASOVIEW Inc. 12 まとめ • 移行を考えるにあたってサーバをどの程度止められるかをまず確認することが大事 • 停止しての移行が可能な場合には、移行時間内に治るかどうかを最初に確認する。 • 移行前後での、使用の差異は、ドキュメントベースで確認して規模感を想像した後は、実際に流れているクエリを記録して再生して互 換性を確かめると言うのが一番効率が良いと思われる。 • 上記の課題をリストアップして、課題が全て解決したら移行作業を実施していく。 ◦ Staging環境で検証後に本番環境で確認していく流れ
13. © ASOVIEW Inc. 13 最後に ご清聴いただきありがとうございました。 一緒に働く仲間を募集しています！ 詳細は、「アソビュー　採用」まで https://findy-code.io/companies/822