Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

hmatsu47
PRO
November 21, 2022

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

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

hmatsu47
PRO

November 21, 2022
Tweet

More Decks by hmatsu47

Other Decks in Technology

Transcript

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

    View Slide

  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

    View Slide

  3. レシピ?
    3

    View Slide

  4. レシピ?
    4

    View Slide

  5. 今日のレシピ(嘘)
    5

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide