MySQLバージョンアップでやったことと振り返り

こんにちは。テクノロジーグループの木村です。
クラシコムではリモートワークで働いています。1歳3ヶ月の娘が私の仕事部屋にノックをして入ってくるようになりました。成長を感じます。

最近までMySQLのバージョンアップ（クラシコムではAmazon Auroraを利用しているので、Auroraのバージョンアップ）というプロジェクトを担当していました。どのように進めたのか、プロジェクトを通じて感じた良かった点、課題についてご紹介します。

目次

1. プロジェクトの流れ
2. 検証環境の作成
3. 検証環境で動作確認
4. 深夜メンテナンスでバージョンアップ
5. 振り返り
6. 良かった点
7. 課題
8. 次のアクション
9. 最後に

プロジェクトの流れ

MySQLのバージョンアップは次のような流れで進んでいきました。

• MySQLのバージョン差分、AuroraとMySQLの差分調査
• CIのMySQLバージョンを上げて既存のテストコードがパスするか確認
• 動作確認シートの作成
• 検証環境の作成
• 検証環境で動作確認
• 深夜メンテナンスでバージョンアップ
• 振り返り

その中でも「検証環境の作成」「検証環境で動作確認」「深夜メンテナンスでバージョンアップ」「振り返り」についてご紹介したいと思います。

検証環境の作成

動作確認をするため、MySQLのバージョンを上げた検証環境を準備しました。インフラで利用しているAWSリソースはTerraformで管理しています。

私はインフラ周りやAWSに詳しくなく、検証環境を作る上で必要なAWSリソース、アプリケーションの修正箇所が明確ではありませんでした。

そこで他メンバーと相談しながら、必要なリソースと変更点を洗い出しました。テクノロジーグループには週に１度、わからないことを他メンバーに相談できる「相談会」というものがあります。「ちょっと相談したいです。。。」と伝えると、全員相談会に参加してくれます。

検証環境を作るにあたって、次のような環境にしたいと考えていました。

• 他のプロジェクトなどバージョンアップとは関係ない修正もあるため、既存のデプロイフローは変えず、いつでもリリースできる状態にしたい
• バージョンアップとは関係ない修正がバージョンアップ後に動作しないことを防ぐため、検証環境に取り込み、バージョンアップ前後の環境で動作確認ができるようにしたい
• ECSのサービス定義、タスク定義を検証環境用に用意するなど、検証環境を作成する上で必要なアプリケーション側の変更も、MySQLのバージョンアップを待たずにリリースできるようにしたい

すでに特定のブランチにコードの変更がマージされるとステージング環境にデプロイされる仕組みは存在しました。

そこでデプロイするワークフローを２つに分け、特定のブランチにマージされると、ステージング環境と検証環境の両方でテストコードを実行し、デプロイするようにしました。そうすることでバージョンアップと関係のない変更のデプロイを邪魔することなく、検証環境には変更を反映させながら、動作確認できるようにしました。

メンバー全員で確認して必要なリソースと変更点が明確になったおかげで、どんな構成の環境を用意するのかという認識をあわせることができ、タスクの分割もしやすくなったので、本当に良かったです。

検証環境で動作確認

検証環境が完成した後、アプリケーションごとに分担して、動作確認を行いました。事前に動作確認方法をスプレッドシートにまとめ、それをもとに動作確認をしました。

動作確認をすることによって、今回のバージョンアップでアプリケーション側のコード修正は必要ないと判断することができました。

深夜メンテナンスでバージョンアップ

事前にバージョンアップの手順書を作成し、他メンバーからレビューしてもらっていました。

手順書には次のような内容が記載されています。

• 作業日時
• 作業予定者
• 事前作業
• 当日の作業内容
• もしメンテナンス中に不具合が見つかった場合の切り戻し手順
• バージョンアップ後の残作業

クラシコムには本番環境とステージング環境があります。本番環境とステージング環境の対応を同じ日の深夜メンテナンスで行うと、時間がかかり、作業手順に不具合があってもメンテナンスが始まるまで気が付きません。

そのためステージング環境のバージョンアップは前日の日中に行いました。これにより、深夜メンテナンスでは本番環境のみ対応し、時間を短くできます。また作業手順の考慮漏れなどを事前に把握することも可能です。

また今回のバージョンアップは、次のような理由から既存環境を直接更新するインプレースアップグレードを採用しました。

• アプリケーション側のコード変更が少ない
• アプリケーション側で接続先を変える必要がない
• 他の方法より作業時間が短時間でできる
• 他の方法（例えば別のインスタンスを用意して接続先を変更する）でもバージョンアップ後にデータが入った場合、切り戻しが大変なのでリスクは変わらない

また以前は深夜作業メンバーがメンテナンス明けもそのまま仕事を続け、問題が無いか監視をしていました。しかし深夜メンテナンスをするメンバーの負担が大きいため、朝方に他メンバーと交代する運用となっています。

例えば次のようなスケジュールで深夜メンテナンスを行っています。

• 3:00 深夜メンテナンス開始
• 5:00 深夜メンテナンス終了、引き続き見守り
• 7:00 メンバー交代、深夜メンテナンスメンバーは休憩
• 9:00 メンバー全員が始業、深夜メンテナンスメンバーも復帰
• 13:00 深夜メンテナンスメンバーは終業
• 15:00 朝方に交代したメンバーは終業

振り返り

テクノロジーグループでは１つのプロジェクトが終わったとき、「振り返り」を必ず実施しています。振り返りはプロジェクトの担当メンバーだけではなく、全員参加します。

KPTの方式で、よかったところ、課題を洗い出し、次のアクションにつなげます。

MySQLバージョンアップの振り返りで出た良かった点、課題、次のアクションをご紹介します。

良かった点

• Terraformに触れる機会になった
• タスクの洗い出しをグループ全体でできて良かった
• 相談できる場所が用意されていてよかった
• バージョンアップの手順書がしっかり用意されていて、他のプロジェクトにも使えそうで良かった

課題

• 検証環境を用意するのが大変だった、環境ごとに差分があった
• Terraformのapplyが多くて、大変だった
• コードレビューや権限を持っている人に作業をお願いするなど、プロジェクトの担当者だけで完結できないことがあり、他プロジェクトのメンバーにも協力いただく部分が多かった。その分、他プロジェクトの進みが悪かった。
• バージョンアップ後の残作業をリストアップできておらず、終わってから「あれも、これも直さないと」となった

次のアクション

• 検証環境を用意しやすくするため、まずは環境ごとの差分をなくす
• 他のプロジェクトを担当している権限を持っている人に作業依頼することが多かったので、プロジェクトメンバーに権限のある人を必須にする
• 他のプロジェクトの進みが悪かったので、同時に進められるプロジェクトの上限数を見直す
• リリース後のCI・開発環境への対応を事前にリストアップしておく

最後に

MySQLのバージョンアップをどのように進めたのか、プロジェクトを通じて感じた良かった点、課題、次のアクションについて紹介しました。いかがでしたでしょうか？

検証環境をパッと用意できるようにしたいとか、他プロジェクトのメンバーの協力いただく必要があり、複数のプロジェクトを同時に進めることが難しいなど、課題はたくさんあります。

クラシコムは採用を強化しております。「ちょっとお話してみたいな、一緒に働いてみたいな」と興味を持っていただいた方、ぜひカジュアル面談をさせてください。