今回は、メンテナンス画面の導入についてお話ししたいと思います。導入自体は、一昨年(2022 年)の話になりますが、去年、導入後、初運用を行いました。
メンテナンス画面の使用頻度は高くはないが、重要な機能であるのは間違いありません。また、障害時などのトラブル時には、メンテナンス画面を利用して、ユーザに対して適切な情報を提供することで、ユーザの不安を和らげることができます。
導入の経緯や、設計時に考慮したことなどをお話ししたいと思います。
導入経緯
そもそも助太刀の API は、Laravel の機能の一つとして提供されているメンテナンスモードを利用するような運用になっていました。
ただ、私が入社後確認したところ、チームメンバ自体、この機能の存在を知らず、また機能として利用したこともなく、何よりクライアントサイド（iOS/Android/Frontend）がメンテナンスモードに対応していないため、メンテナンスモードを利用することができませんでした。という経緯から、ゼロベースでメンテナンス画面を導入することにしました。
メンテナンス画面の設計
メンテンス画面導入にするにあたり、以下のような要件を考慮しました。
- Frontend(主に Next.js)、iOS、Android に対応すること
- メンテナンス画面の表示/非表示を アプリケーションレイヤで制御せず、インフラレイヤで制御すること
- メンテナンス画面表示時は、社内からのアクセスのみ許可すること
2 の理由として、トラフィックを完全に遮断するためには、アプリケーションレイヤで制御することは難しいと考え、また、インフラレイヤで制御することで、アプリケーションのコードにメンテナンス画面の表示/非表示のロジックを含める必要がなくなります。弊社助太刀 API は、全て AWS ALB を利用しているため、ALB の機能を利用することで、メンテナンス画面の表示/非表示を制御することが可能です。
3 の理由として、メンテナンス画面時、社内からは確認したいケースが多いため、社内からのアクセスのみ許可することで、社内での確認を容易にすることができます。
メンテナンス画面の表示/非表示を制御する仕組み
ALB のリスナールール、ターゲットグループの設定を利用しました。
以下のような、ステータスコード 503 の固定レスポンスを返す設定をターゲットグループに追加しました。また、ホワイトリスト形式で IP アドレスを設定し、社内からのアクセスのみ通常のレスポンスを返すようにしました。
{
"error_code": "E503_MENTAINACE",
"reason": "メンテナンス期間 2024/01/01 00:00 ~ 2024/01/01 06:00"
}
"error_code"キーは、クライアントサイドでハンドリングするためのエラーコードです。
"reason"キーは、ユーザに対して表示するメンテナンス期間の情報です。
Frontend(Next.js) はメンテナンス画面にリライトするようにしました。
また、iOS/Android は、レスポンス情報からメンテナンス画面を描画するようにしてます。
一連のこのメンテナンス画面に関する表示/非表示の制御は、terraform で管理しています。
まとめ
メンテナンス画面の導入により、障害や大規模メンテナンスが発生した際に、ユーザーへ適切な情報を提供することが可能になり、ユーザーの不安を和らげる効果が得られました。
また、我々開発チームとしては、安心して、メンテナンス作業を行うことができるようになりました。
助太刀について
「建設現場を魅力ある職場に。」というビジョン・ミッションを基に、事業者間マッチングサービス「助太刀」、正社員採用「助太刀社員」を開発、運営しています。
最後に
助太刀では一緒に開発してくれるメンバを募集してます！
少しでもご興味を持っていただけたら下記よりお気軽にご連絡ください！
Discussion