Aurora MySQL 一段飛ばしのバージョンアップとその他もろもろの話

891 Views

November 21, 22

スライド概要

吉祥寺.pm31【オンライン】 2022/11/22

profile-image

Qiita や Zenn でいろいろ書いてます。 https://qiita.com/hmatsu47 https://zenn.dev/hmatsu47 MySQL 8.0 の薄い本 : https://github.com/hmatsu47/mysql80_no_usui_hon Aurora MySQL v1 → v3 移行計画 : https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

Aurora MySQL 一段飛ばしのバージョンアップと その他もろもろの話 吉祥寺.pm31【オンライン】 2022/11/22 まつひさ(hmatsu47)

2.

自己紹介 松久裕保(@hmatsu47) ● https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています 今日のレシピ(?) ○ Zenn の本: https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book https://zenn.dev/hmatsu47/books/aurora-mysql-do-book 2

3.

レシピ? 3

4.

レシピ? 4

5.

今日のレシピ(嘘) 5

6.

[1] 今年やったこと:Aurora MySQL v1 → v3 移行 ● 10/15 に完了 ○ 正確には、移行対象のシステムがまだ一つ残 ● コード修正担当の開発チームと、インフラ移行担当の (われわれ)SRE チームの共同作業 6

7.

バージョンアップの原則 ● 一つずつ順番にバージョンを上げていくべき ○ 他社事例も大体そう https://tech.andpad.co.jp/entry/2022/06/02/100000 (ANDPAD) https://tech.readyfor.jp/entry/2022/07/13/181825 (READYFOR) ○ 例外 https://dev.classmethod.jp/articles/upgrade-aurora-mysql-5-6-to-8-0-simple-stupid/ (クラスメソッド) ※小規模社内システム・長時間停止可・アプリケーション動作確認済み 7

8.

なのに、なぜ v2 を飛ばしたのか? ● DB のマイグレーションだけに時間を割く余裕がなかった ○ レガシーなアプリケーションゆえ、フレームワークや DB 以外の 環境のマイグレーションも必要(いっぱい) ○ もちろん、提供するサービスの向上も大事 ● そして、われわれには強い味方が(誇張表現) ○ 2021 年 1 月の吉祥寺.pm25 でもちょっとだけ触れたやつ 8

9.

ちょっと懐かしのアレ ● 2021 年春に更新終了したが MySQL 8.0.24 対応版まで出していた ○ Aurora MySQL v3 は MySQL 8.0.23 ベースからのスタートなのでセーフ 9

10.

実際にはそれなりに追加調査した(約 1 ヶ月) ● そのあたりは前掲の「今日のレシピ(嘘)」を参照 ○ 主に下のほう 10

11.

続いてコードの先行調査&修正&動作確認 ● コードの先行調査は 5 日ほどで完了 ○ それなりに出てきたし、さらに範囲を広げると無限に… ■ 割り切れば大丈夫(なはず) ● コードの修正はちょっと手こずる ○ 一括置換ができない・lint も中途半端(つらい) ● 案の定 SRE チーム内の動作確認では修正ミスを多数発見 ○ 頑張って直した 11

12.

そして、開発チームにコード修正タスクを渡す ● 修正箇所が無限に湧いてきそうで大変だった模様 ○ マネージャー指示は「対象を絞れ」だったが ■ うまく伝わらなかった?(スキルの問題も) ● 結果としては、ほぼ先行調査&修正→差分提示した範囲 に収まった ○ ただし「他に対象がないか?」「正しく抽出できているか?」を 後追い確認するのが大変だった様子(要仕組み化) 12

13.

一方、インフラのお守りをしている SRE チームは ● データベース自体の移行準備をしていた ○ 手順書とか移行作業で使う差分確認ツールとか ● 大筋では以前から移行作業でやってきたことと同じ ○ ただし一点大きな違いが 13

14.

一方、インフラのお守りをしている SRE チームは ● 手慣れた「binlog レプリケーション」はサポート外 ○ バージョン飛ばし(v1 → v3)はサポート外 ○ 3 バージョン間多段レプリケーションもサポート外 14

15.

当初の予定:DMS(CDC)でレプリケーション ● これならサポート対象 15

16.

当初の予定:DMS(CDC)でレプリケーション ● これならサポート対象 ● でも回避不能な問題で NG ○ 特定条件で異常値が発生 ● 諦めた 16

17.

実際の移行では:多段 binlog レプリケーション ● 自己責任でサポート外構成 ● できるだけ短期間で ○ 数日間だけなら止まらない はず ○ 実際に止まらなかった 17

18.

移行当日 ● 事件が 3 つ ○ 直前の夜間バッチが終わらない事件😱 ○ 主キーのないテーブルが突然現れた事件😱 ○ サービス再開直前にサービス再開してた事件😱 18

19.

移行当日 ● 事件が 3 つ ○ 直前の夜間バッチが終わらない事件😱 ○ 主キーのないテーブルが突然現れた事件😱 ○ サービス再開直前にサービス再開してた事件😱 ● 切り戻しが必要になるような致命的な事件は発生せず ○ ↑の 3 つもバージョン飛ばしとは無関係なものばかり 19

20.

[2] 書いたコード:いくつか ● アプリケーション(プロダクト)のフロントエンド ○ ページ送り操作のたびに DB に重いクエリを投げていた画面を React で部分的に SPA 化 20

21.

[2] 書いたコード:いくつか ● アプリケーション(プロダクト)のフロントエンド ○ ページ送り操作のたびに DB に重いクエリを投げていた画面を React で部分的に SPA 化 ○ バックエンドの開発が間に合わないというオチで来年に持ち越し ■ フロントエンドは 6 月中にはほぼ出来上がっていたけれど🤔 21

22.

[2] 書いたコード:いくつか ● アプリケーションリリース作業の地味な改善 ○ CLI 操作が苦手な開発担当者のために SolidJS & Go で簡単な GUI を用意 22

23.

改善したところ ● ● ● 複数のテスト環境・ステージング環 境に、別環境のパイプラインで作っ たコンテナイメージをデプロイする ことがある 本番環境には、必ずいずれかの環境 で動作確認したコンテナイメージを デプロイする デプロイには KAYAC fujiwara さん 作の ecspresso をありがたく使わせ ● ていただいている ただ、使うメンバーの一部が CLI の 操作に不慣れ 23

24.

コンテナイメージ URI の指定で ● コピペミスが怖いとか、もろもろ意見があったので 24

25.

こんな感じ ● フロントエンドは SolidJS + SUID / TypeScript ○ SUID : SolidJS 版の MUI ○ https://github.com/hmatsu47/select-repository-frontend-app ● バックエンドは oapi-codegen で Gin の API を生成 ○ Stoplight Studio で OpenAPI 3.0 の .yaml を生成 ○ Go の oapi-codegen でコードの枠組みを自動生成 ○ https://github.com/hmatsu47/select-repository-api 25

26.

ポイント ● 変な拘りは持たない ○ ✖エンジニアが使うツールは CLI じゃなきゃダメ ■ 本業のプロダクトコード書きに集中してもらったほうがプラス ● 過度に依存されることは避ける ○ 「このツールがないと仕事ができない」→業務がツールと密結合 ■ メンテナンス地獄 ● 要らなくなったら捨てる 26

27.

[3] 来年に向けて : ただいま格闘中 ● メールサーバー廃止✉ ○ お守りをしたくないので API で送信&バウンス管理へ 27

28.

まとめ:今年の振り返りと、来年に向けて ● Aurora MySQL v1 → v3 移行が(ほぼ)完了した ○ バージョンアップ 1 回分の時間と労力を節約 ● DB 移行の合間にフロントエンドのコードを書いた ○ バックエンド待ち(来年に持ち越し) ● 地味な改善のためにコードを書いた ○ お手軽コードで作業支援 ● メールサーバー廃止に向けて格闘中 28