こんにちは。エンジニアの塚原（@AkitoTsukahara）です
ECサイトや自社サービスを運用していると、サービスを一時停止しなければならないケースがあります。そのためにはサービス形態やインフラ構成に適したメンテナンス運用方法を事前に用意しておく必要があります。ほとんど利用することはありませんが、サービス信頼に関わる仕組みになります。
M&Aクラウドでは２通りの方法でメンテナンスページを表示する仕組みを準備しております。
今回の記事では運用方法とその運用に至った経緯をご紹介させていただきます。
メンテナンスに切り替える方法
| 切り替え手法 | 操作ページ | メリット | デメリット | |
|---|---|---|---|---|
| 1 | 管理ページからメンテナンスに切り替え | 管理ページ（プラットフォーム独自のもの） | 切り替えが簡単 | バックエンドサーバーが停止したら利用できない |
| 2 | メンテナンス用のCloudFrontに切り替え | AWSコンソール | サーバー稼働状態に依存しない | 切り替えに必要な操作が多い |
１の「管理ページからメンテナンスに切り替え」は、フラグを切り替えるだけでメンテナンスページに切り替えられるようになっています。 プラットフォームの管理ページからフラグの切り替え機能を用意しているため、運用コストを低く抑えることができています。 通常の切り替えではこちらを採用しています。
もしもプラットフォームサーバーが停止してしまったら
１の方法は操作が簡単なのですが、万が一プラットフォームが稼働しているサーバーが停止してしまうと利用することができません。この不測の事態に備えて、稼働しているサーバよりも手前でメンテナンスに切り替える必要がありました。
上の図はプラットフォームのインフラ構成になっています。この構成を考慮してCloudFrontを活用してメンテナンスに切り替える方法を模索しました。
CloudFrontを活用したメンテナンス切り替えを模索する
バックエンドサーバーを必要としないメンテナンスページの運用方法については、AWSサポートセンターにご質問させていただきました。M&Aクラウドのインフラ構成を考慮して、４つも運用方法をご提案いただきました。いつも丁寧な対応ありがとうございます！🙇♂️
４つの運用方法
- CloudFrontのカスタムエラーレスポンス機能を利用する
- メンテナンス用のCloudFrontディストリビューションへの切り替え
- Lambda@Edge を使った静的ウェブサイトコンテンツの提供
- CloudFront 以外のリソースへの切り替え
４つの運用方法と実際に試して得られた知見をメリットとデメリットに分けて簡単にまとめさせていただきます。
CloudFrontのカスタムエラーレスポンス機能を利用する
運用方法
CloudFrontのカスタムエラーレスポンス機能でHTTP Error Codeを受け取った際に、指定したページにレスポンスさせるメリット
- CloudFrontの更新だけで対応することができる
- レスポンスを上書きすることができる（404エラーを503エラーにしたり）
- デメリット
- システムからのHTTPレスポンスを受け取らないとカスタムエラーレスポンスが働かないため、システムからのレスポンスが遅れた場合に何も表示されない時間が発生する
- メンテナンス切り替えの度にカスタムエラーレスポンスを設定する必要がある
メンテナンス用のCloudFrontディストリビューションへの切り替え
運用方法
メンテナンス用のCloudFrontディストリビューションを作成しておき、Route53のレコードを変更するメリット
- 稼働中のCloudFrontの設定を変更しないため、メンテナンス後の復旧は容易
- デメリット
- CNAMEの削除・登録（CloudFront）、レコード変更（Route53）と複数のアプリの設定変更が必要
- CNAME切り替えが反映されるまでに少々時間がかかる可能性がある
Lambda@Edge を使った静的ウェブサイトコンテンツの提供
運用方法
Lambda@Edgeを適用させることで、メンテナンスページにリダイレクトさせる。メリット
- 任意のレスポンスにすることができる（メンテナンスページを表示して、503エラーを返す）
- デメリット
- CloudFrontのビヘイビア１つ１つに「Lambda Function Associations」を適用する必要がある（ビヘイビアが複数あるとその数だけ変更が大変に）
- 新しくビヘイビアを追加するたびにLambda@Edgeの設定が必要になる
参考
チュートリアル: シンプルな Lambda@Edge 関数の作成
レスポンスの生成 - 例: 静的コンテンツの提供 (生成されたレスポンス)
「CloudFront 以外のリソースへの切り替え」
運用方法
切り替え先のリソースにCloudFront以外のサービス (例: ロードバランサー、EC2、ドメイン名と同じ名前を持つ S3バケット 等) を使用し、Route53のレコードを変更するメリット
- 稼働中のCloudFrontの設定を変更しないため、メンテナンス後の復旧は容易
- デメリット
結果的に採用した運用方法
４つの運用方法を試した結果、「カスタムエラーレスポンス機能」と「メンテナンス用ディストリビューションへの切り替え」の良いとこ取りしたハイブリットな運用方法となりました。
メンテナンス時の処理フローは以下の図のようになっております。
ポイント
- CloudFrontはどのようなURLを受けても、S3のindex.htmlをリクエストする
- S3にはindex.htmlを用意しない（必ず404を返却する）
- カスタムエラーレスポンスでレスポンスを503にする（SEOを考慮）
懸念していたディストリビューション切り替え時のダウンタイムですが、２の運用を実施するのはサーバー停止してしまっている時なので、多少のダウンタイムは考慮しないことになりました。
色々と試行錯誤しましたが、プラットフォームに適したメンテナンス運用方法をまとめることができました。
「もっと良い方法があるよ！」、「もっと詳しく知りたい！」という方はお気軽にご意見いただけると嬉しいです。
@AkitoTsukahara
