基本的な考え方
ローリングアップデートで対応できれば「ダウンタイム0で更新、ロールバックが可能」というのがクラウドの基本デザインパターンです。
しかし、金融系や医療系など「異常動作が許されない」というシステムも存在します。
また、データベース系の変更作業の場合は「ユーザーからのアクセスを全て拒否し、作業が終わってからサービスを開始する」という仕組みを作る必要があります。
日本だと、品質に厳しいユーザーが多いのでこのような対応を行う事が多いのではないでしょうか。
DNSサーバー設定で切り替える
よく使われる方式としてはDNSサーバーで別サーバーに向き先を変更する手法があります。
DNSレコードを別サーバーに向けてメンテナンス画面を表示させる方法です。
昔は専用のWebサーバーをEC2で作成していましたが、S3での静的ホスティング機能を使ってメンテナンスページを表示させることが多いでしょうか。
DNSレコードを変更する方式にはいくつか問題点があります。
・DNS情報の浸透時間を考慮する場面が出てくる
・経路を遮断しているわけではないので、IPアドレスや変更前のDNS情報でアクセスが継続される場合がある。
・DNS情報を変更しているので、サービス開始前の動作確認が難しい。
(IPアドレスでアクセスしたり、hostsファイルで名前解決を行う必要がある)
昔は選択肢がありませんでしたが、現在は他の対応方法がありますので個人的にDNSレコードでの切り替えはおすすめしません。
ALBのルールでリダイレクトする
Elastic Load Balancing で Application Load Balancer のリダイレクトおよび固定レスポンスのサポートを発表
メンテナンス用に、通信を別サーバー(S3など)に転送するルールを作成しておき、メンテナンス作業時にこのルールの優先度を上げてメンテナンス表示に切り替えます。
現在はALBで簡単なHTMLも書けるようになりましたのでシンプルな画面であればALBだけでメンテナンス表示を行う事が可能となります。
この方式の良いところは、メンテナンス表示を行う条件を指定できることです。
全ての通信を遮断することもできますし、特定のIPアドレスはそのまま通信を継続させることができます。
そうすることにより「一般ユーザーはメンテナンス表示、エンジニアの環境からは通常アクセス可能とする」という動作を実現することができます。
また、ロードバランサーで制御を行うので、DNS情報を変更する場合のように「抜け道」が存在しなくなります。
NLBでは実現できないので、そこが欠点でしょうか。
CloudFront+WAFで制御する
可能ではありますが、ALBの方式に比べると複雑になります。
AWS WAF での Amazon CloudFront 機能の使用方法
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/cloudfront-features.html
まず、AWS WAFで特定IPを許可し、そのほかのIPは拒否するルールを作ります。
この場合は、エンジニア環境のIPアドレスを許可してその他のIPアドレスを拒否します。
WAFで拒否された場合は「403 (Forbidden)」をクライアントに返します。
これを、CloudFrontのカスタムエラーページで拾ってメンテナンス画面を表示させます。
ここまで聞くと、使えそうな気もしますが考慮すべき点がいくつかあります。
・403のカスタムエラーページを設定したままだと、メンテナンス作業以外でも403のエラーを拾ってメンテナンス画面を表示してしまう。
・CloudFront/WAFの2つのサービスをきちんと設定しておかないといけない。
サーバーの調子が悪い時などに403エラーが出た場合でもCloudFront配下にいる状態だとメンテナンスページを表示してしまうので、
メンテナンス作業時以外の方が検討項目が増えてきます。
これでは本末転倒ですのであまりお勧めしません。
コメント