初めてのMariaDBバージョンアップのメンテナンスで大変だったこと、工夫したこと

はじめに

　2023年4月に新卒で入社したバックエンドエンジニアの冨家です。現在は、全国の医師が経験やナレッジを「集合知」として共有し合う医師専用コミュニティサイト「MedPeer」の開発を行っています。
　「MedPeer」ではAmazon RDSのMariaDBを一部使用しています。最近まで10.6.11バージョンを使用しており2024年3月にRDS 標準サポート終了を迎えるので、私が主にバージョンアップ作業を担当することになりました。しかし、私自身初めてのデータベースバージョンアップ作業だったため、どのような点に気をつけるべきかわからず対応に苦労しました。
　そこで今回は、次回バージョンアップする方の参考になるように、実際に行ってみて大変だったことや工夫したところ、次回改善したほうが良いことなどを紹介していきます。

MariaDBバージョンアップに関連する「MedPeer」のAWS構成図

メンテナンス日時の選定の仕方

　まず大変だったことが、メンテナンスの日時を選定することでした。メンテナンスモードに切り替えると全てのユーザーがサービスを使用できなくなります。日時によっては大きな機会損失を出す可能性があるので、実施する日時を見極めることがとても重要でした。
　最終的には、2024年2月26日の23:00から24:00の間にメンテナンスモードに切り替えました。メンテナンスする日時は7つの条件から選定しました。

リスト1 メンテナンス日時を選定したときの7つの条件

1.1. バージョンアップのプロジェクト開始日から1ヶ月以上後であること

1.2. サポート期間が終了する1ヶ月以上前であること

1.3. メンテナンス当日と翌日が休日・祝日ではないこと

1.4. バッチ処理が少ない時間帯であること

1.5. ユーザーのアクセスが低い時間帯であること

1.6. メンテナンス実施日から翌日まで重要な処理がないこと

1.7. ステージング環境で実際にかかったメンテナンス作業時間以上を本番のメンテナンス時間として確保できること

1.1. バージョンアップのプロジェクト開始日から1ヶ月以上後であること

　データベースをバージョンアップするためには他チームとの日程調整やユーザーにメンテナンスを実施する告知が必要です。そのため、余裕を持って行えるようにプロジェクト開始から1ヶ月以上後にしました。

1.2. サポート期間が終了する1ヶ月以上前であること

　もしサポート期間終了直前でバージョンアップを試みて失敗した場合、再チャレンジする時間がありません。そこで、余裕を持って再チャレンジできるようにサポート終了日から1ヶ月以上余裕を持たせるようにしました。

1.3. メンテナンス当日と翌日が休日・祝日ではないこと

　メンテナンス当日や翌日は想定外のことが起きやすく障害が発生しやすいです。もし休日に障害が発生した場合対応が遅れやすくなるので、当日と翌日が休日・祝日ではない日程にしました。

1.4. バッチ処理が少ない時間帯であること

　バッチ処理が多いと考慮することが多くなり、想定外のことが発生しやすくなります。
　現在の「MedPeer」では、22時から24時の間で1時間あたり3件程度バッチ処理が起動します。しかし、24時以降は1時間あたり数十件のバッチ処理が起動するように設定されているので、日程が変わる前にメンテナンスをすることにしました。

1.5. ユーザーのアクセスが低い時間帯であること　

　もしユーザーがメンテナンス中でアプリを使えなかった場合、サービスに対して不満を感じて、問い合わせ数の増加やアクティブユーザー率の低下に繋がります。そのため、トラフィックが少ない時間帯にメンテナンスを実施して、ユーザーへの影響を最小限にすることが大切です。
　調査した結果、「MedPeer」では比較的月曜夜のトラフィックが少なめで、22時と23時では数万のアクセス数差があることが判明したので、選定しました。

1.6. メンテナンス実施日から翌日まで重要な処理がないこと

　深夜にアップデートした場合、利用者が増える翌朝に問題が発覚することが多いです。そのためメンテナンス日から翌日の夕方まで、ユーザー影響の大きなイベントが開催されないように他チームと調整を行いました。開催日時が定まっている「Web講演会」機能を筆頭に、特定日時での処理が必要な機能がメンテナンス前後で実行されないように周知・調整を徹底しました。

1.7. ステージング環境で実際にかかったメンテナンス作業時間以上を本番のメンテナンス時間として確保できること

　本番環境のインスタンスはステージング環境と比較してデータ量が多く、より時間がかかる可能性があります。
　ステージング環境でメンテナンス時間を計測してみた結果、メンテナンスモードに切り替えてから通常モードに戻すまで1時間かかりました。そのため、1時間以上切り替えられる日時を選定しました。

実際に選定した日時にバージョンアップした結果

　大きな問題は発生しませんでした。しかし、「メンテナンス中でアクセスできずデイリーボーナスポイントやログインボーナスポイントが獲得できなかった」という問い合わせが1件入ったので、次メンテナンスする方は、メンテナンス中に締切があるイベントやキャンペーンがある時間帯をできる限り避けるように選定できると良さそうです。

バージョンアップ作業の手順

　次に大変だったことは、バージョンアップの手順を作成することでした。もしプライマリーインスタンスで大きな障害が発生してしまうと、長時間サービスが止まってしまい大きな損失を出してしまいます。そのため、「どうすればプライマリーインスタンスで障害を起こさないようにできるのか」、「もし障害が発生した場合どのようにすれば最小限に抑えることができるのか」という視点を持ってバージョンアップの手順を考える必要がありました。
　リスト2 は、MariaDBをバージョンアップしたときの手順を表しています。手順のポイントは7つあります。

リスト2 MariaDBバージョンアップ手順

2.1 事前準備

2.1.1. バージョンアップに失敗した場合の復旧手順を確認しておく

2.2 メンテナンス作業

2.2.1. 社内に向けて作業開始連絡

2.2.2. リードレプリカのバージョンアップ

対象インスタンスのリードレプリカのバージョンアップ
追加されたデータがDBに反映できていることを確認

2.2.3. サービスメンテナンス開始

アプリケーションをメンテナンスモードに切り替え
外部のユーザーがアクセスできないことを確認

2.2.4. プライマリーインスタンスのバージョンアップ

対象のプライマリーインスタンスのスナップショットの取得および結果確認
プライマリーインスタンスをバージョンアップ

2.2.5. バージョンアップ後の確認

バージョンアップ後にデーターベースの読み書きができることを確認
プライマリーインスタンスのバージョンアップ後にRedashからリードレプリカのデータを取得できるかを確認
コンテナログ、監視ツールのアラート確認

2.2.6. サービスメンテナンス終了

アプリケーションのメンテナンスモードを解除
外部のユーザーがアクセスできることを確認

2.2.7. 社内に向けて作業終了連絡

2.3 メンテナンス後の残作業

2.3.1. 不要になったコードの削除

2.3.2. 1週間程度バージョンアップ後のメトリクス（CPU使用率など）に異常がないか確認

Point1. バージョンアップに失敗した場合の復旧手順を確認しておく

　もしバージョンアップに失敗した場合、慌てず迅速に対処できるように事前に確認するようにしました。

Point2.リードレプリカをバージョンアップしてからプライマリーインスタンスをバージョンアップする

　リードレプリカでバージョンアップして問題が起きないことを確認することで、プライマリーインスタンスの障害発生率を低くするように工夫しました。

Point3. バージョンアップ後にデーターベースの読み書きができることを確認する

　閲覧ログを登録しているテーブルがあるため、そのページを表示し閲覧ログが書き込まえることを確認しました。

Point4. プライマリーインスタンスのバージョンアップ後にRedashからリードレプリカのデータが取得できるかを確認する

　プライマリーインスタンスをバージョンアップするとリードレプリカも置き換わります。プライマリーインスタンスのバージョンアップ後にリードレプリカが正常に動作しているか確認するため、Redashからリードレプリカのデータが取得できることを確認しました。

Point5. コンテナログ、監視ツールのアラート確認する

　バージョンアップ中やバージョンアップ後でアプリケーションにエラーが起きていないことを確認するために行いました。もしメンテナンス関連で問題がないエラー通知が来ていた場合（DBのコネクションエラー等）、その通知がメンテナンス作業のものであることを表明して、バージョンアップに携わっていない人にも問題がないことを伝えるようにしました。

Point6. 1週間程度バージョンアップ後のメトリクス（CPU使用率など）に異常がないか確認する

　バージョンアップ直後は想定外のことでメトリクスが変化しやすく、パフォーマンス悪化に繋がりやすいです。そのため、1週間程度異常がないか確認するようにしました。

2/26から3/4までのMariaDB CPU使用率の推移

Point7. 各手順でかかった時間を計測しておく

　各手順でかかった時間がわかると「次回バージョンアップ作業する時にスケジュールを立てやすくする」、「時間がかかった作業を分析して、次回以降の作業時間を短縮できる」などのメリットがあるので、計測するようにしました。

実際に手順通りバージョンアップした結果

　問題なくバージョンアップすることができました。バージョンアップによる障害が発生せず、予定よりも10分早くメンテナンスを終えてスムーズに行うことができました。

作業が終了したときの社内連絡

最後に

　以上、MariaDBをバージョンアップさせる上で大変だったことや工夫したこと、次回改善した方が良いことなどについて、紹介しました。
　実際にバージョンアップ作業を進めていくと、他社ではどのように行っているのか何度も気になりました。もし親切な方がいらっしゃいましたら貴社の事例を記事にしていただけると大変参考になります。
　また、今回のバージョンアップ方法で改善案がありましたら、コメントいただけると嬉しいです。

是非読者になってください

メドピアでは一緒に働く仲間を募集しています。ご応募をお待ちしております！

■募集ポジションはこちら medpeer.co.jp

■エンジニア紹介ページはこちら engineer.medpeer.co.jp

■メドピア公式YouTube　 www.youtube.com