こんにちは、Sys-Infra Unit の小山です。今回は、AWS Aurora MySQL のメンテナンス準備・実施・振り返りまでを複数チーム横断で行った話を紹介します。
背景と課題
Repro では、AWS Aurora MySQL を利用してサービスを提供しています。Aurora MySQL は、MySQL 互換のリレーショナルデータベースサービスで、Aurora MySQL にも独自のバージョン番号が設定されています。バージョンにはサポート期間が設定されているため、利用しているバージョンのサポート期間が終了する前にはアップデートしておきたいものになります。
今回、Repro で利用している Aurora MySQL のバージョンがサポート終了日に近づいてきたため、バージョンアップデートをする必要がありました。Aurora MySQL のバージョンを上げるには、Aurora MySQL のインスタンスの再起動が伴い、どうしても通信ができなくなってしまう時間が生じてしまいます。弊社のサービスの特性上日本時間の深夜であってもデータの読み書きが発生するため、程度の差はありますが、基本的にどの時間帯にメンテナンスを行ったとしてもサービスに影響を及ぼします。そのため、サービスのどこに影響が出てしまうのか？ メンテナンス前に止めておいた方がいいサービスはあるか？ などを事前に調査しておく必要があります。今まではバージョンアップなどでメンテナンスが必要になるたびに、Sys-Infra Unit にてサービスへの影響調査を行なってきました。しかし、Repro が提供するサービスが増えてきたことで、Sys-Infra Unit で調査を完結するのが現実的ではなくなってきました。具体的には、2024/01/25 現在で本番環境の AWS ECS Cluster が 35 個以上、考慮するべき API エンドポイントの数 が 30 種類以上存在しています。加えて、メンテナンス当日に何かしら問題が起きてしまった際は知見のない各種アプリケーションの対応を自分たちでする必要があり、メンテナンスの準備 ~ 実施の負荷がかなり高いという課題がありました。
チーム横断のアプローチ
この課題を解決するために今回のメンテナンスでは、 Aurora MySQL を利用している関係チームを巻き込んでメンテナンス準備 ~ 実行するというアプローチを取りました。そもそも、少し前まではサービスの担当チームが明確ではなかったため、調査依頼をするのが難しかったのですが、ここ 1 年で全てのサービスの担当チームが明文化されました。そのおかげで、担当チームに自身のコンポーネントに対する影響調査をお願いできるようになりました。メンテナンス時にこのような取り組みをするのは初めてでした。
メンテナンスに関わったチームの紹介
ここで、手短ですがメンテナンスに関わったチームの紹介をします。
- Booster Unit（以下 Booster）: Repro Booster を開発しているチームです。
- Core Unit（以下 Core）: データエンジニア・アーキテクト的な役割を担っているチームです。
- Customer Support Unit（以下 CS）: 弊社のお客さんからの問い合わせに対応しているチームです。今回のメンテナンスでは、顧客連絡の担当をしていただきました。
- Feature Unit（以下 FT）: Repro App / Repro Web の機能を開発しているチームです。2024/01/25 現在のチームは 2 チームあります。
- Sys-Infra Unit（以下 Sys-Infra）: インフラ全般を担当しているチームです。
実際に行なったメンテナンスプロセス
メンテナンスの計画 ~ メンテナンスの振り返りまでのプロセスに関しては、大きく分けて以下のような流れで行いました。
- メンテナンスの計画
- CS への連携
- メンテナンス実施準備
- メンテナンス実施
- メンテナンスの振り返り
メンテナンスの計画
メンテナンスの計画は Sys-Infra が行いました。具体的なメンテナンスの日時を決め、逆算していつまでに何ができていないといけないのかを計画しました。ある程度の計画ができたら、各チームにメンテナンスの内容とそのスケジュール感を共有しました。今回のメンテナンスは、Aurora MySQL のバージョンアップで、数分間 Aurora MySQL の書き込みと読み込みができなくなることが想定でたので、その旨を各チームに伝えました。
各チームは、自身のコンポーネントに対する影響調査を行い、書き込みと読み込みができなくなることでどのような影響が出るのかを調査してもらいました。今回のケースでは、アラートが出ない・ダウンタイムなしでサービスを稼働させ続けられそうではないとの判断の元、メンテナンス直前に一部のサービスを停止するような方針を取りました。
サービス停止に伴ってどの機能に影響がでるのかの一覧に加えて、以下の添付画像のように、具体的にどの API エンドポイントをメンテナンスモードにしたいか？ どの ECS Service の Desired tasks 数を 0 したいか？ をドキュメントで各チームから共有してもらいました。画像には載せていませんが、加えてメンテナンス中に Datadog の Monitor のアラートがならないようにしたいものがあれば、そのリストも記載してもらいました。
CS への連携
各チームから共有を受けたドキュメントをもとに、メンテナンスによる影響範囲をまとめ、メンテナンス実施希望日時と併せて CS に共有しました。影響範囲と日程の合意が取れたら、CS の方で顧客連絡の文章を作成していただき、お客さんに連絡を入れてもらいました。具体的な連絡内容は以下から参照できます。 https://support.repro.io/hc/ja/articles/25701936172569
メンテナンス実施準備
メンテナンスモードにしたい API と止めたいサービスの一覧とアラート通知を一時的に止めたい Datadog の Monitor が明確になったら、Sys-Infra にて当日のメンテナンスの作業手順を作成しました。作業手順は一部抜粋ではありますが以下の添付画像のように用意しました。基本的にリソースへの変更周りは script 化しました。script とこの手順書はチームメンバーに Review をしてらいました。
ちなみに、詳細は割愛しますが、今回は Amazon RDS Blue/Green Deployments を利用して Aurora MySQL のバージョンアップを行いました。
メンテナンス実施
テスト環境で問題ないことを確認した上で本番を迎えました。当日は各 FT から 1 名ずつ、Sys-Infra / Core から 2 名ずつの計 6 名の体制でメンテナンスを実施しました。前回のメンテナンス時の設定が意図せず残り続けてしまっていたことが原因で、メンテナンス手順が進められなかった時間帯がありました。当日待機しているメンバーの中に前回のメンテナンスの経緯についての詳細を知っている人はいなかったので、すぐには原因の特定ができませんでした。そんな状況ではありましたが、当日のメンバーで協力して原因を特定し、何とかトラブル対処ができました。その他は特に問題なく事前の準備通りに進め、メンテナンスを完了できました。
メンテナンス手順が進められたなかった時間帯があったのは、AWS Blue/Green Deployments の切り替え時にエラーが発生してしまい、その原因を特定するのに時間がかかってしまったことが原因でした。AWS Blue/Green Deployments には、以下のような制約事項がります。おそらくこの条件に当てはまったのが原因で RDS クラスターの切り替えに失敗したのではないかと考えています。
For Aurora MySQL, the blue environment can't have subscriptions. A subscription defines a connection to another database and a set of one or more publications to which it wants to subscribe.
今回のメンテナンスの 1 つ前のメンテナンスでは本番の RDS クラスターとは別のクラスターを作成して、本番のクラスターのデータと同期させるために CALL mysql.rds_set_external_source と CALL mysql.rds_start_replication; を実行してから切り替えを行いました。この時の外部レプリケーションの設定が残ってるのが原因ではないかとあたりをつけ、設定を外した後に再度切り替えをおこなうとうまくいきました。具体的には CALL mysql.rds_reset_external_source; を実行することでこの設定を外せました。
メンテナンスの振り返り
メンテナンス完了後、次回以降のメンテナンスをより良くするために、関係チームに集まってもらってこの一連の取り組みの振り返り会を行いました。その場で出た良かった点と問題点並びにその改善策の一部を紹介します。
まず良かった点としては、メンテナンスの影響調査を担当チームにお願いできるようになったことで、自分たちに知見のないアプリケーションの仕様を調査しなくて済むようになり、背景・課題の項目で述べたような Sys-Infra のメンテナンス準備負荷がかなり軽減されたように感じられた点です。軽減された分、自分たちがやらないといけないメンテナンス当日の準備に集中して時間をつかえたのも良かったのではないかと思います。また、当日のメンテナンス中に予期しないトラブルが発生しましたが、Sys-Infra 以外の複数メンバーに待機してもらえたことで、その場で協力してトラブルシューティングすることもできました。改めて振り返ると、メンテナンスの当日にチームの異なる複数のメンバーに待機してもらえてたことは、知見のないアプリケーションにトラブルが起きても Sys-Infra だけで対応しないといけないといったプレッシャーがなくなり、メンテナンスの実施に対する不安が軽減されました。
一方で、この取り組みをやって新しく出てきた問題点が複数見つかりました。まず、各チームに今回のメンテナンスの影響調査の結果をそれぞれのチーム用のドキュメントにまとめてもらうようにお願いしました。しかし、他のメンバーからどの資料を見れば良いのか、それぞれが最新化されているのかが分からなかったという意見をもらいました。これに対しては、次回からは 1 つのドキュメントに各チームの調査結果をまとめ、常にその資料を最新化してく方針にしました。次に、前回のメンテナンスの作業内容を正確に把握しているメンバーがいなかったことから当日のトラブルシューティングに時間がかかってしまったという問題です。こちらに関しては、次回以降のメンテナンスでは必ず 1 回前のメンテナンスの担当者を 1 人含めるようにする方針にしました。最後に、コミュニケーションのコストが高かったという問題です。1 つの原因として、Slack でのやりとり場所が散らばってしまったことが挙げられます。メンテナンス当日の作業時向けに Slack チャネルを作成していましたが、次回からは情報を集約するためにも準備段階から作成し、そちらで基本的にコミュニケーションを完結するように方針として定めました。
まとめ
今回は、AWS Aurora MySQL のメンテナンス準備・実施・振り返りまでを複数チーム横断で行った話を紹介しました。今回のメンテナンスは、メンテナンスの影響範囲を各チームに調査してもらうというアプローチを取りました。このアプローチを取ることで、Sys-Infra のメンテナンス調査の負荷を大きく軽減できたと感じています。また、メンテナンス当日に複数チームのメンバーに待機してもらえたことで、知見のないアプリケーションの対応をしないといけないといったプレッシャーがなくなり、メンテナンスの実施に対する不安が軽減されたように感じました。今回のメンテナンスの振り返りを踏まえて、改善点も複数見つけることができました。今後もこのような取り組みを継続していき、メンテナンスの負荷をより軽減していきたいと思います。
この話が少しでも皆さんのメンテナンスの参考になれば幸いです。
最後に、Sys-Infra ではエンジニアを募集中です！もし興味を持っていただけるようでしたら、是非採用ページからご応募ください。
