吉祥寺.pm31【オンライン】 2022/11/22
Aurora MySQL一段飛ばしのバージョンアップとその他もろもろの話吉祥寺.pm31【オンライン】 2022/11/22まつひさ（hmatsu47）
View Slide
自己紹介松久裕保（@hmatsu47）● https://qiita.com/hmatsu47名古屋で Web インフラのお守り係をしています今日のレシピ（？）○ Zenn の本：https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-bookhttps://zenn.dev/hmatsu47/books/aurora-mysql-do-book2
レシピ？3
レシピ？4
今日のレシピ（嘘）5
[1] 今年やったこと：Aurora MySQL v1 → v3 移行● 10/15 に完了○ 正確には、移行対象のシステムがまだ一つ残● コード修正担当の開発チームと、インフラ移行担当の（われわれ）SRE チームの共同作業6
バージョンアップの原則● 一つずつ順番にバージョンを上げていくべき○ 他社事例も大体そう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
なのに、なぜ v2 を飛ばしたのか？● DB のマイグレーションだけに時間を割く余裕がなかった○ レガシーなアプリケーションゆえ、フレームワークや DB 以外の環境のマイグレーションも必要（いっぱい）○ もちろん、提供するサービスの向上も大事● そして、われわれには強い味方が（誇張表現）○ 2021 年 1 月の吉祥寺.pm25 でもちょっとだけ触れたやつ8
ちょっと懐かしのアレ● 2021 年春に更新終了したが MySQL 8.0.24 対応版まで出していた○ Aurora MySQL v3 は MySQL 8.0.23 ベースからのスタートなのでセーフ9
実際にはそれなりに追加調査した（約 1 ヶ月）● そのあたりは前掲の「今日のレシピ（嘘）」を参照○ 主に下のほう10
続いてコードの先行調査＆修正＆動作確認● コードの先行調査は 5 日ほどで完了○ それなりに出てきたし、さらに範囲を広げると無限に…■ 割り切れば大丈夫（なはず）● コードの修正はちょっと手こずる○ 一括置換ができない・lint も中途半端（つらい）● 案の定 SRE チーム内の動作確認では修正ミスを多数発見○ 頑張って直した11
そして、開発チームにコード修正タスクを渡す● 修正箇所が無限に湧いてきそうで大変だった模様○ マネージャー指示は「対象を絞れ」だったが■ うまく伝わらなかった？（スキルの問題も）● 結果としては、ほぼ先行調査＆修正→差分提示した範囲に収まった○ ただし「他に対象がないか？」「正しく抽出できているか？」を後追い確認するのが大変だった様子（要仕組み化）12
一方、インフラのお守りをしている SRE チームは● データベース自体の移行準備をしていた○ 手順書とか移行作業で使う差分確認ツールとか● 大筋では以前から移行作業でやってきたことと同じ○ ただし一点大きな違いが13
一方、インフラのお守りをしている SRE チームは● 手慣れた「binlog レプリケーション」はサポート外○ バージョン飛ばし（v1 → v3）はサポート外○ 3 バージョン間多段レプリケーションもサポート外14
当初の予定：DMS（CDC）でレプリケーション15● これならサポート対象
当初の予定：DMS（CDC）でレプリケーション16● これならサポート対象● でも回避不能な問題で NG○ 特定条件で異常値が発生● 諦めた
● 自己責任でサポート外構成● できるだけ短期間で○ 数日間だけなら止まらないはず○ 実際に止まらなかった実際の移行では：多段 binlog レプリケーション17
移行当日● 事件が 3 つ○ 直前の夜間バッチが終わらない事件😱○ 主キーのないテーブルが突然現れた事件😱○ サービス再開直前にサービス再開してた事件😱18
移行当日● 事件が 3 つ○ 直前の夜間バッチが終わらない事件😱○ 主キーのないテーブルが突然現れた事件😱○ サービス再開直前にサービス再開してた事件😱● 切り戻しが必要になるような致命的な事件は発生せず○ ↑の 3 つもバージョン飛ばしとは無関係なものばかり19
[2] 書いたコード：いくつか● アプリケーション（プロダクト）のフロントエンド○ ページ送り操作のたびに DB に重いクエリを投げていた画面をReact で部分的に SPA 化20
[2] 書いたコード：いくつか● アプリケーション（プロダクト）のフロントエンド○ ページ送り操作のたびに DB に重いクエリを投げていた画面をReact で部分的に SPA 化○ バックエンドの開発が間に合わないというオチで来年に持ち越し■ フロントエンドは 6 月中にはほぼ出来上がっていたけれど🤔21
[2] 書いたコード：いくつか● アプリケーションリリース作業の地味な改善○ CLI 操作が苦手な開発担当者のために SolidJS & Go で簡単なGUI を用意22
改善したところ23● 複数のテスト環境・ステージング環境に、別環境のパイプラインで作ったコンテナイメージをデプロイすることがある● 本番環境には、必ずいずれかの環境で動作確認したコンテナイメージをデプロイする● デプロイには KAYAC fujiwara さん作の ecspresso をありがたく使わせていただいている● ただ、使うメンバーの一部が CLI の操作に不慣れ
コンテナイメージ URI の指定で● コピペミスが怖いとか、もろもろ意見があったので24
こんな感じ● フロントエンドは 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-api25
ポイント● 変な拘りは持たない○ ✖エンジニアが使うツールは CLI じゃなきゃダメ■ 本業のプロダクトコード書きに集中してもらったほうがプラス● 過度に依存されることは避ける○ 「このツールがないと仕事ができない」→業務がツールと密結合■ メンテナンス地獄● 要らなくなったら捨てる26
[3] 来年に向けて : ただいま格闘中● メールサーバー廃止✉○ お守りをしたくないので API で送信＆バウンス管理へ27
まとめ：今年の振り返りと、来年に向けて● Aurora MySQL v1 → v3 移行が（ほぼ）完了した○ バージョンアップ 1 回分の時間と労力を節約● DB 移行の合間にフロントエンドのコードを書いた○ バックエンド待ち（来年に持ち越し）● 地味な改善のためにコードを書いた○ お手軽コードで作業支援● メールサーバー廃止に向けて格闘中28
hmatsu47
yoshikieguchi
hiboma
k1low
lefred
microcms
yoyakoba
hosimesi11
takashi1029
dzeyelid
charmichokshi
tsutaj
jordihofc
brettharned
morganepeng
ddemaree
akmur
thoeni
yeseniaperezcruz
swwweet
cherdarchuk
philnash
maggiecrowley
roundedbygravity
bryan