徹底解説！Insight SQL Testingを活用したデータベース移行の実践ポイント

by coconala_engineer

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Copyright coconala Inc. All Rights Reserved. ひとことで言うと、スケーラビリティが確保できていなかった 11 設定したKPIより、AWS RDSのSLAの方が低い KPIとして設定している目標はリクエスト成功率が99.96%以上。一方で、Amazon RDS（マルチAZ クラスタ）のSLAは99.95%となっており、そもそも自社でコントロールできないところで、KPI達成が難しい状況 … イコール、意図せずKPIとして無理がある設定になっていた。

Slide 12

Slide 12 text

Copyright coconala Inc. All Rights Reserved. IOPS（1秒あたりのI/Oアクセスの数）も限界が迫っていた 12 このままだと、近い未来にIOPSの上限に抵触する Amazon RDSのインスタンスサイズは適切なものを利用していたので、CPU やメモリなどは問題なかったが、 IOPSの上限に抵触しそうになった。暫定的にデータベースのデータ量と無関係にストレージを拡張することで、IOPSの上限を上げていったが、一時しのぎであった。

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Copyright coconala Inc. All Rights Reserved. Amazon Auroraへの移行 15 設定したKPIの達成に向けてAmazon Auroraを採用 Amazon AuroraのSLA（マルチ AZクラスタ）は99.99%なので、定めているリクエスト成功率（99.96%）よりも高い。また、IOPSの上限も撤廃されるため、2つの課題を一気にクリアできることを期待して、Amazon Auroraへ移行することに意思決定した。 Amazon Aurora Amazon RDS

Slide 16

Slide 16 text

Copyright coconala Inc. All Rights Reserved. DB移行は一大プロジェクトなので、マイルストーンを設定し、経営層と合意形成 16 MySQL5.7 EOL期限をデッドラインとして、計画を策定経営層に「技術課題として、一番リスクと難易度が大きいもの」とインプットするために対応するタスクの整理と、マイルストーン設定から着手。 MySQL5.7 EOL期限から逆算して、1年半がかりのプロジェクトを立ち上げ、ナレッジを徐々に蓄積できるように5つのデータベースを影響が少ないところから順に対応していく計画とした。

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Copyright coconala Inc. All Rights Reserved. プロダクトで利用しているDBのなかでも「メインDB」は常時膨大な量のSQLが流れており、 MySQLメジャーバージョンアップ＆Auroraへの移行後（AuroraMySQL3化）に問題なく動作するか懸念されていた。検証環境ではワークロードが違いすぎて網羅的にSQL動作の確認がしきれない点が浮き彫りになった。そのため、メインDBは本番環境相当のSQLを使った性能テストを実施して移行時の品質向上を狙う。重厚に性能テストを行うワケ 21 メインDBは桁違いに難易度の高い移行対象

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Copyright coconala Inc. All Rights Reserved. 事前にPoCを行うことで、一発本番のリスクを軽減させる 25 進めるなかで「クエリログのサイズが大きいとInsight SQL Testing側のクエリログ取り込みに失敗してしまう」問題に直面ただ、PoCでありながらインサイトテクノロジー社が親身にサポートくださり、回避策に切り替えることで先に進めた。その後の正式利用時にはパッチが適用され、この問題は解消された。 PoCの機会をいただき、一連の流れを経験

Slide 26

Slide 26 text

Copyright coconala Inc. All Rights Reserved. ただ、都合によりPoC時点では本番相当のクエリログを充分に用意できていなかった😭 そのため今後イレギュラーが起きることを考慮して、予定よりも性能テストフェーズの開始時期を前倒して更に2段階に分けて性能テストを実施できるよう計画を変更した。また、本来は1週間分取得して行う予定だったが、・1時間分のクエリログのテスト実行だけで4時間かかる・取得したクエリログの保管コストがバカにならないことがわかったため、取得範囲を狭めた。 26

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Copyright coconala Inc. All Rights Reserved. ただ、正式に性能テストを実施していくなかで問題が出た。 PoCはGUIベースで性能テストを試していたが、・性能テストの実施オプションを毎回入力する必要があり非効率・単一クエリログサイズが大きく（≒SQL本数が多い）、時短のために　性能テストの「SQL並列実行数」オプションを大きくすると　途中でInsight SQL TestingのインスタンスがOOM 　になってしまい、テストがFailしてやり直しに本番相当の性能テスト構成での詰まりポイント 29

Slide 30

Slide 30 text

Copyright coconala Inc. All Rights Reserved. REST APIが提供されていたので bashスクリプトを作成してテスト実行・結果取得の処理を効率化した。 ※APIリファレンス参照にはライセンスが必要なため具体スクリプト内容は割愛本番相当の性能テスト構成での詰まりポイント（対策） 30 テストのオプションを毎回入力途中でInsight SQL TestingのインスタンスがOOM インスタンスのメモリを増設しても解消しなかったので、インサイトテクノロジー社サポートを頼りつつ、 1回のテストに使うクエリログ時間を1時間→1分に分割して回すことで、性能テストが失敗したときの影響を軽減させた

Slide 31

Slide 31 text

Copyright coconala Inc. All Rights Reserved. 最終的にテスト対象のSQLは約8億本、「新DBのみ失敗、2DBで取得結果が異なる、新 DBで性能劣化」結果から重複排除などを行い影響調査が必要だったのは約200本、事前に改修が必要だったのは約30本となった。事前に改修を終えることができ、「その他は問題なし」と言い切れる安心感ができた。性能テストを実施してどうなったか？ 31 事前に注力するべきSQLの本数は激減した

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Copyright coconala Inc. All Rights Reserved. 影響の大きいメインDBのAuroraMySQL3化が無事故で終えられたのは性能テストで事前に問題点を洗い出せたから。 Insight SQL Testingを利用することで性能テストの品質を担保しつつかける工数を削減できた。また、サポートという正式に頼るルートがあったおかげで、詰まったときにも自分たちだけで抱え込まずに済んだ。メインDBのAuroraMySQL3化はココナラ史上最大の課題だった 34

Slide 35

Slide 35 text

Copyright coconala Inc. All Rights Reserved. 社内外さまざまな協力・支援があったおかげで、1年半という期間を計画的かつ大きな問題なく進めることができた。途中でイレギュラーが起きた際にも計画を見直すことで死守するべき期限を変えずに完遂できた。ただ、性能テストはPoC前にMTGなどでイメージ感や具体ユースケースのすり合わせなど、もう少し解像度高く取り組むことができたはず。こちらからもう少し熱量を持ってコミュニケーションできれば良かった。対応してみてどうだったか？ 35 確実に自分たちだけでは完遂できなかった

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Copyright coconala Inc. All Rights Reserved. データベース移行はやっぱり事前の準備が大事 38 集められる情報は集めて、自社としての最適解を見つける「データベース移行」といっても、システム構成やシステム特性によって、考慮するポイントはさまざま。類似したアーキテクチャーを採用しているシステムの情報を参考に「自社のベストプラクティス」を探すことが重要。なんといっても、数年に一度は必ず訪れるイベント・・・

Slide 39

Slide 39 text

Copyright coconala Inc. All Rights Reserved. システムメンテナンスの無い世界を目指していきたい 39 無停止でメンテナンスイベントをこなす最適解を見つけるクラウドサービスを使っている限り、「基盤のメンテナンス」は切っても切れないイベントになる。（全てがライブマイグレーションになれば、みんなHappyだけど…）ココナラは「全てがそろうスキルマーケット」を目指しているので、極力システムメンテナンスがない世界を実現するための机上 / 実機検証を続ける。