みなさんこんにちは！UUUMシステムユニットの ぶち です。
桜の季節ですね。4月になり新しい環境に変わった方もいらっしゃるのではないでしょうか。 実はUUUMのサービスの中にも新しいバージョンに生まれ変わっていた DB がいました🌸
はじめに
少し遡り雪解の候、 MySQL のメジャーバージョンアップを実施しました。 具体的なオペレーションについては素晴らしい記事が世の中に多数ありました(大変お世話になりました)。
本記事では、実作業レベルの具体的なバージョンアップ手順については述べません。
サービス提供やステークホルダーとの擦り合わせなどの観点で実施した、周辺業務を主題に記載します。
対象の DB 環境
今回のバージョンアップ対象の環境について軽く触れておきます。
- AWS RDS に構築している DBインスタンス
- レプリカ無し
- MySQL 5.6 から 5.7 へのアップグレード
- アプリケーションのテストカバレッジは向上途中
事前に準備したもの
バージョンアップ情報ドキュメントの作成
作業全体像の把握と他メンバーへの共有を主目的として、バージョンアップ手順を作成しました。 最終的に把握した項目は以下の通りです。
DB について
- バージョンアップ後に変更される仕様の概要
- DB のみで必要なダウンタイム
- 公式バージョンアップドキュメント等の情報
- 事前構築すべきリソース( Parameter Group 等)
アプリについて
- テストの必要な機能
バージョンアップオペレーションについて
- バージョンアップ作業内容
- 万一バージョンアップ失敗した場合の切り戻し
バージョンアップ後の注意事項について
- 不要なリソースの処理(旧DBやオペレーション用に構築したものなど)
- IaCの修正
- モニタリング対応
この中で特に、「万一バージョンアップ失敗した場合の切り戻し」は大切だと感じています。 その理由は2点あります。
まず、当然のことですが、メンテ時間の延長はユーザーの予定を狂わせる可能性があります。 サービスの信頼性や継続性は事業を継続する上で非常に重要な要素です。
また、切り戻しが必要な場面に遭遇する時点で、既に想定外の事態と対面していることでしょう。 事前に準備しておけば、想定外の上さらに想定外のオペレーションを重ねず済みます。
勇気ある撤退の判断も視野に入れられるよう、可能な範囲で準備はしておきたいですね。
作業チェックリストの作成
正直手間がかかるため、チェックリストまではやらないケースも多い印象はあります。 ですが作成することで受けた恩恵があったため記載しておきます。
バージョンアップのオペレーションを、実作業レベルでスプレッドシートにリストアップしました。 実際に利用した項目(と作業サンプル)を以下に記載します。
| 実施チェック | 手順No. | 概要 | 予定開始時刻 | 備考欄 |
|---|---|---|---|---|
| ぶち | 1 | Terraformからメンテイン | 18:00 | - |
| ぶち | 2 | DBスナップショット取得 | 18:05 | - |
特に「実施チェック」と「予定開始時刻」は記載して良かったです。
「実施チェック」は、作業分解することのメリットがありました。 まず各メンバーに分担できるレベルに落とし込むため、作業が明確になります。 また分担の結果全員が作業者として関わることになるため、事前の打ち合わせを同じ目線で細かく議論することができました。
「予定開始時刻」は、タイムマネジメントと実績としてのメリットがありました。 現在の作業が予定時刻に対してどの程度順調か理解できる上、今後類似作業が生じた際の参考値になります。
もし次回があれば、実績の精度を上げるため「作業完了時刻」を追加してもいいかもしれません。
作業内容
開発環境でバージョンアップの実施
準備した内容を踏まえ、実際にオペレーションを行いました。 この時点で、バージョンアップがプロダクトに対してどう影響するのかを判明させました。
実施結果を受けて、ドキュメントに必要事項があれば追記します。
今回は、念のため主要機能を手動テストするようチェックリストに追加することになりました。 全機能の手動テストは現実的に不可能に近いため、事業的なインパクトの大きい部分を重点的に確認するようにしました。
サービスダウンの事前周知
作業チェックリストからバッファを含めた所要時間を見積もり、関係者にダウンタイムをアナウンスしました。
本番環境でバージョンアップの実施
ここまでの流れを踏まえて作業を実施します。 準備の甲斐もあり、予定より早めに完了できました。
バージョンアップ後の残タスク処理
一番気を遣う作業が終わり安心しがちですが、ここでミスすると大変なことになる可能性があります。
例えば DB を Terraform で構築している場合、新しいものに修正しないと差分として認識されます。 バージョンアップのやり方次第では、修正しないまま誤って apply してしまい、、、という状況の発端になりかねません。
また、 DB は比較的コストが大きくなりがちな部分だと思います。 利用しなくなった古いインスタンスなどは折を見てコストのかからない形にしましょう。
そしてもう一つ。一定期間は予期しない挙動をしていないか普段よりモニタリングに気を遣うと良いと思います。
さいごに
今回担当したバージョンアップは、概ね以上のように実施しました。
こうした業務の一部を取り上てげも様々な進め方があると思います。 当然組織やシステム構成に応じて必要な対応は異なりますが、安全性を高める取り組みは大切だと感じています。
また、今回はプロジェクトやチームにとっても良い方法を模索しながらの業務だったため、組織で取り組むという点でも勉強になりました。
本ブログが何かの参考になれば幸いです。