https://zenn.dev/yktakaha4/articles/how_to_make_sorry_page
LAPRAS株式会社でSREをしております、yktakaha4と申します🐧
最近、LAPRASにポートフォリオをユーザー自身でカスタマイズする機能がリリースされたのですが、 こちらに関連してSREとしてSorryページ（メンテナンスページ）を表示する機能を開発したので、 設計・実装にあたって意識した点などについて書き遺したいと思います✍
弊社では毎朝エンジニア全員（10数名程度）で集まって朝会を実施しているのですが、 ある日、スクラムチームの naga3 から以下のようなアジェンダが出ました
今回の機能を実装するにあたって、そこそこレコード量が多くユーザー影響の大きいテーブルにカラム追加のマイグレーションをおこなう必要があり、
これについて作業手順上の不安があったので、夜間リリースで対処したい…という議題だったのですが、
そこから マイグレーションの失敗等に伴い本番環境の動作に支障するような状況に陥った際に、メンテナンス画面を表示できないか という議論に発展しました
過去に実装を検討していたこともあったのですが、その時は運用に乗るものとして完成するには至らず、以降 問題があったら何とかする というマインドで凌いできましたが、
システムが長期運用される中で利用者やトランザクション量も増えてきており、何よりもエンドユーザーに安心感をもって利用してもらえるシステムにより近づくため、
（個人的に こんなこともあろうかと と他のタスクを進めながらIssueを育てていた）Sorryページ開発プロジェクトを始動することとしました…🚀
ちなみにIssue Createdは2021年12月頃だった模様
早速、実装に入る前に検討していた仕様について列挙していきます 弊社のアプリケーションはAWS + Kubernetes(EKS)のインフラ上で稼働しているため、話の切り口はそういった観点が中心ですが、 恐らく他の技術スタックで構築されたものであっても有効な内容でないかと思います🐬
基本的な要件ながらケアレスミスをしやすい点として HTTPステータスを200で返却してはいけない ということは有名な話と思います
以下のように検索エンジンにキャッシュされてしまい、メンテナンス後にも尾を引くことになるようです⚰️
ではどのようなステータスコードで返却すべきか…というと、 503 Service Unavailable が推奨されるそうです
ステータスそのものに 一時的な状態であり、レスポンスは頻繁にキャッシュされるべきではない ということで、botや対外システムからのアクセスがあるようなケースでも先方に考慮した挙動をしてもらえそうです
ただ、もしも本当に503ステータスしか返却しないと、以下のようなブラウザごとの素朴なエラー画面を見せることになるので、 サービスがメンテナンス中であることがユーザに伝わるHTML + 503ステータスをユーザーに返すのが一般的と思います
素朴なエラー画面の一例