【ITニュース解説】Bug in CloudFront's Continuous Deployment Feature

今回のニュースは、AWSが提供するコンテンツ配信ネットワークサービスであるCloudFrontの「継続的デプロイメント」機能で発生した、稀なHTTP 500エラーに関するものである。システムエンジニアを目指す初心者でも理解できるよう、その詳細を解説する。

まず、CloudFrontはウェブサイトやアプリケーションのコンテンツをユーザーに高速に届けるためのサービスである。よくAmazon S3というストレージサービスに保存された静的ウェブサイト（HTML、CSS、JavaScriptなどで構成される、サーバー側で動的な処理を行わないウェブサイト）と組み合わせて利用される。今回の問題は、このような静的ウェブサイトをS3に配置し、CloudFrontを通じて配信する一般的な構成で発生した。

問題の核心は、CloudFrontの「継続的デプロイメント」機能にある。これは、ウェブサイトの変更を本番環境に直接適用するのではなく、まず「ステージング」と呼ばれるテスト用の環境で検証し、その後に本番環境に適用できる非常に便利な機能である。この機能を使うと、二つのCloudFrontディストリビューション（コンテンツ配信の設定をまとめたもの）を設定する。一つはユーザーが通常アクセスする「プロダクション」環境、もう一つは変更をテストする「ステージング」環境である。

この機能には、本番トラフィックの一部（例えば15%）をステージング環境に振り分ける「加重ルーティング」や、特定のヘッダー値に基づいてルーティングを変える方法がある。加重ルーティングでは、ユーザーが一貫した体験を得られるように、一度ステージング環境に振り分けられたユーザーを常にその環境に留めておく「スティッキーセッション」という設定も可能である。

しかし、この設定でウェブサイトを運用していたユーザーが、断続的にHTTP 500というサーバー内部エラーに遭遇した。これは、ウェブサイトが正常に動作していないことを示すエラーコードである。ヘッダーベースのルーティングでは問題が発生しなかったため、権限設定に起因するものではないと考えられた。

当初、この問題は再現が難しかった。しかし、ユーザーが「カスタムエラーレスポンス」という設定を使用しているという重要な情報が提供されると、状況は一変した。カスタムエラーレスポンスとは、CloudFrontが返すデフォルトのエラーページ（例えば、ページが見つからないことを示す404エラーや、アクセスが拒否されたことを示す403エラー）を、ユーザーが用意した独自のページに置き換えたり、エラーのステータスコードを変更したりできる機能である。

このカスタムエラーレスポンスを有効にすると、例えば存在しないページにアクセスした場合（本来なら404エラーになる状況）に、間欠的にHTTP 500エラーが発生することが確認された。このタイプのエラーは特定の条件でしか発生せず、頻度も不安定なため、デバッグが非常に困難である。

問題の原因を特定するため、まず、ウェブサイトからのレスポンスがプロダクションとステージングのどちらの環境から送られてきたのかを区別できるように、レスポンスヘッダーに環境情報を追加する設定を行った。次に、Artilleryというロードテストツールを使い、自動的に多数のリクエストを送り、エラーの発生頻度と条件を詳しく調べた。

ロードテストでは、存在しないページへのアクセスを毎秒50回、2分間続ける設定がされた。これにより、S3オリジンが403エラーを返し、それがCloudFrontのカスタムエラーレスポンスによって処理される状況を意図的に再現した。Artilleryのスクリプトは、レスポンスのステータスコードと、レスポンスヘッダーに含まれる環境情報（プロダクションまたはステージング）を記録し、エラーの発生数をカウントするように設計された。継続的デプロイメントポリシーは、最大である15%のトラフィックをステージング環境に振り分けるように設定された。

このテストの結果、非常に興味深い現象が明らかになった。カスタムエラーレスポンスをプロダクションとステージングのどちらに、あるいは両方に設定するかによって、HTTP 500エラーの発生率が大きく変動したのである。特に、プロダクションとステージングの両方でカスタムエラーが有効な場合、ステージング環境では約83%もの高いエラー率が観測された。プロダクション側のみ有効な場合でも、ステージング側で約47%、ステージング側のみ有効な場合でもプロダクション側で約13%のエラーが見られた。どちらも無効な場合はエラーは発生しなかった。スティッキーセッションを有効にしても、このエラー発生率は大きく変わらなかったため、根本的な問題はセッションの永続性とは無関係であると推測された。

さらに驚くべきことに、このエラーは時間帯によっても挙動が変わった。CloudFrontの継続的デプロイメント機能には、トラフィックが集中するピーク時間帯にはステージング環境へのトラフィック転送を停止するという制限がある。金曜日や土曜日の夜のようなピーク時間帯にテストを行うと、エラーが全く発生しなかったのである。一方で、同じ設定でも非ピーク時間帯には大量のエラーが発生した。これは、CloudFrontがピーク時には継続的デプロイメントのルーティングを停止し、結果としてバグのトリガーとなる条件が満たされなかったためと考えられる。

また、このエラーはカスタムエラーレスポンスをトリガーするような、エラー状態を引き起こすリクエストにのみ関連していることも確認された。正常なページへのアクセスでは、常に問題なく動作した。S3へのアクセスを制御するOrigin Access Controlの設定を変更しても、状況は改善されなかった。

このように、このバグは非常に複雑な条件が重なって発生し、その挙動も時間帯によって変化するという、デバッグが困難な性質を持っていた。この問題はAWSにバグとして報告され、AWSのチームでも再現が確認されたため、将来的には修正されることが期待されている。