SOURCE POD Blog ソースポッドブログ

おはようございます、こんにちは。開発課の木本です。
普段は開発業務を担当しており、たまにサービスの運用業務等も行っています。

当社で運用しているサービスは、ふだん無停止でバージョンアップ等を行っていますが、先日はサービスを一時停止してメンテナンスを行う機会がありました。その際に、思っていたよりも便利だった運用方法を見つけたので、今回ブログに寄稿することにしました
（たぶん、基盤業務を行っている人からすると常識かもですが）。

○結論

やったことはこれだけです。

●事前にALBにリスナールールを登録する。
●メンテナンスの開始と終了時にALBのリスナールールの優先度を変更する。

この２つだけで、サービス利用者にはメンテナンスページが表示され、登録したメンバーはサービスにアクセスでき、メンテナンス中の最終確認を行うことができます。カットオーバー前に、sshポートフォワードでアクセスしたら、ホスト名が違うとWebサーバーに怒られたり、急いで/etc/hostsを書き換えたりする必要もありません。ALBに設定を残し、次のメンテナンスで再利用してもいいですね。

※AWS ALBとは・・・
https://aws.amazon.com/jp/elasticloadbalancing/application-load-balancer/

○具体的な設定内容について

メンテナンスの事前準備として、下画像のようにリスナールールを４つ作成しました。
（ロードバランサーやターゲットグループの作成については、本題ではないので省略します）

※分かりやすいように、最低限の設定に絞っていますが、実際には複数の条件を組み合わせて運用しています。
※Webサービスのドメインを *.example.com と読み替えてください。

①Webアプリケーション

最も優先度の高いルールで、リクエストをWebアプリケーションに処理させます。通常時は全てのリクエストが該当します。

②メンテナンス作業者

メンテナンス中でも、Webサービスへアクセスを可能にするための設定です。どのような条件を設定するかは、各々の環境で決めていただくとして、今回は分かりやすくメンテナンス作業者の送信元IPを設定しています。

③メンテナンス中

メンテナンス中にWebサービスへアクセスした場合に、メンテナンスの案内ページを表示するための設定です。今回は画像で確認し易くするために text/plain で設定していますが、text/html でそれらしい見た目のメンテナンスページを設定することをオススメします。

④デフォルト

ALB作成時に、デフォルトで作成されるリスナールールです。今回は使用しませんが、念のため固定レスポンスを返す設定にしています。

これで最も優先度の高い①Webアプリケーションが（ホストヘッダーの条件はあるものの）全てのリクエストを処理することになり、全員がWebサービスへアクセスできる状態となります。

では、メンテナンス作業を実施する際に、どのような変更を行うのかというと、下画像の優先順位の再設定から、①Webアプリケーションの優先度を 109 → 1109 に変更します。

優先度を 109 から 1109 に変更する。

これだけで、メンテナンス作業者には、②メンテナンス作業者のルールが適用される（Webサービスにアクセスできる）一方で、②メンテナンス作業者のルールに一致しない場合は、③メンテナンス中が適用される（メンテナンスの案内ページが表示される）ことになります。

優先度を変更する、たったこの操作のみで、Webサービスを稼働中からメンテナンス中に変更できました。メンテナンスが終了したら優先度を戻すだけで元通りです、とっても簡単。

○最後に・・・

運用には関わらない開発者も多いと思いますが、たまに触れてみると新鮮で面白さがあり、開発だけを行っていたら、身につけられない技術もあります。

仕事を通じて新しい技術に触れる機会があることを、魅力に感じてもらえると嬉しいです。