Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
データベースをMySQL8.0へ移行を実行する上で考えてたこと
Search
Takeshi Suzuki
September 25, 2023
1
870
データベースをMySQL8.0へ移行を実行する上で考えてたこと
Takeshi Suzuki
September 25, 2023
Tweet
Share
More Decks by Takeshi Suzuki
See All by Takeshi Suzuki
アソビューSREでこの1年間で実際に実施した各種効率化について
takesuz
0
29
データベースをMySQL8.0へ移行を実行する上で考えてたこと
takesuz
0
86
Featured
See All Featured
Designing for Performance
lara
601
67k
Six Lessons from altMBA
skipperchong
22
3k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
660
120k
The Cult of Friendly URLs
andyhume
74
5.7k
Raft: Consensus for Rubyists
vanstee
133
6.3k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
501
140k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
117
18k
Optimizing for Happiness
mojombo
370
69k
It's Worth the Effort
3n
180
27k
Designing with Data
zakiwarfel
96
4.8k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
21
1.6k
Web Components: a chance to create the future
zenorocha
306
41k
Transcript
データベースをMySQL8.0へ移行を実行する上で考えてたこと 2023/9/26 アソビュー株式会社 SREユニット 鈴木剛志
© ASOVIEW Inc. 2 About Me Name : 鈴木剛志(すずきたけし) Company:アソビュー株式会社 SRE
ユニット Twitter: @takesuzu90 DB経験(前職含む) • Oracle • DB2(IBM) • PostgreSQL • MySQL それぞれの特徴を掴むくらいまでは触ってました。
© ASOVIEW Inc. 3 本日のLTでお話しすること 本日は、下記のような内容を話していこうと思っています。 • 弊社サービスの概要と今回の移行の流れ • DB移行検討前に考えるべき観点
• 実際にやったことの概略 • 移行後の運用状況
© ASOVIEW Inc. 4 弊社サービス概要 遊び予約サイト「アソビュー!」を運営しています。 toC向けには、電子チケットの販売などを行う一方、 toB向けには、それに関連する業務を サポートする機能を提供しています。
© ASOVIEW Inc. 5 サービス規模感 • サービスローンチ: 2012年(12年目) • 会員数:
約1,000万人 • 契約施設数: 約10,000施設 • 全プロダクトコード(有効コードベース): 4,000,000+ step • テーブル数: 2,000+ table • ピークトラフィック: 4,000+ rps • プロダクト部門: 約100名 • チーム数: 15 team
© ASOVIEW Inc. 6 移行元DBと移行先DB 移行元 • MySQL(5.6) • PostgreSQL
(10) 移行先 • MySQL(8.0) • PostgreSQL (13) 同じMySQL同志の移行でしたが8.0系は2つは結構大きな仕様の変更などがあり 通常のバージョンアップよりも、重点的な確認が必要でした。
© ASOVIEW Inc. 7 DB移行検討前に考えるべき観点 一般的に、データベースの移行を行うときには下記の観点により戦略を考えていきます。 • 移行の前後における仕様変更点にはどのようなものがあるのか。 ◦ SQLなどの構⽂の差異がどの程度あるか。
◦ 組み込み関数などの差異がどの程度あるのか。 ◦ パフォーマンスの変化がどの程度あるのか。 ◦ などなど • サービス停止の可否について/移行に必要な時間 ◦ 可能な場合には、どの程度の時間停⽌が可能なのか ◦ 移⾏の完了には、どの程度の時間が必要なのか ▪ 移⾏に、停⽌可能時間を上回る場合には、移⾏の難易度が⼤幅に上がってきます 当社の場合には、1:00 - 6:00の5時間までならメンテナンスによる停止可能 だったので、まずは、この時間内に終わるかという観点で移行時 間の調査から初めていきました。この結果次第によって移行戦略が左右されるためです。 なるべく少ない工数で移行を計画できるようにしていくのが大切かと感じます。
© 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へバージョンアップする 検証結果として、Step2の時点で4時間以上かかってしまうケースがあることが判明。この時間だと、ダウンタイムをもうけての戦略が利用 できないので、原因を調査。 結果として、未コミットのデータが多い場合に、時間がかかってしまうことが判明。バージョンアップの数時間前から対応するバッチ処理を停 止するなどすれば、回避できることがわかった。
© ASOVIEW Inc. 9 仕様変更の調査方法について 最初は、ドキュメントベースでの仕様の差異を調査して、仕様変更の箇所をソースコードの Grepなどをベースに確認していきます。ある程度 まで、影響範囲の規模感をドキュメントベースでつかんだ後に、実際に影響のある変更点を洗い出す方法として、移行をシミュレーションす ることによって課題を洗い出していく方式が効率的だと思います。当社の場合には、 1.
旧バージョンでの実行クエリの記録 2. 新バージョンでの実行クエリの再生 というのを実行して、事前に下記をリストアップしておきました。 • 移行先でエラーになってしまうSQL • 移行先でパフォーマンスが劣化してしまう SQL ここも、それほど大掛かりな仕組みを用意したわけではなく、標準機能のクエリログを出力して、それを読み込んで実行するということを愚直 に実行しました。 サーバのバージョンによってライブラリが勝手に実行するクエリなども記録側には含まれていたので、そこら辺を一つ一つ目視でフィルタして いく必要はありましたが、リストアップはこちらの方法でもほぼ問題なく実施できました。 結果、何が見つかったかなどは、ブログに記述しています。
© ASOVIEW Inc. 10 移行後の運用状況 利用頻度の低い機能については、パフォーマンスの劣化などの部分がありましたが、普段のサービスを提供するにおいては支障が発生す るような問題は起きませんでした。 実際に、この移行ポイントを押さえておけば、必要最低限の工数で移行をしていくことができるのではないかと思います。
© ASOVIEW Inc. 11 こちらの発表の元になっているブログ紹介 本発表は、下記のブログを元に作成しています。 Aurora MySQL 5.6->8.0/PostgreSQL 10・11
-> 13へバージョンアップした 話。アソビューのDB移行戦略 https://tech.asoview.co.jp/entry/2022/12/19/090450
© ASOVIEW Inc. 12 まとめ • 移行を考えるにあたってサーバをどの程度止められるかをまず確認することが大事 • 停止しての移行が可能な場合には、移行時間内に治るかどうかを最初に確認する。 •
移行前後での、使用の差異は、ドキュメントベースで確認して規模感を想像した後は、実際に流れているクエリを記録して再生して互 換性を確かめると言うのが一番効率が良いと思われる。 • 上記の課題をリストアップして、課題が全て解決したら移行作業を実施していく。 ◦ Staging環境で検証後に本番環境で確認していく流れ
© ASOVIEW Inc. 13 最後に ご清聴いただきありがとうございました。 一緒に働く仲間を募集しています! 詳細は、「アソビュー 採用」まで https://findy-code.io/companies/822