2023年10月30日、複数のCloudflareサービスが37分間利用できませんでした。これは、Workers KVが使用しているデプロイツールの設定ミスが原因でした。Cloudflareは自社製品群に依存していたため、本インシデントはより困難なものとなりました。お客様に多大なご迷惑をおかけしたことを深くお詫び申し上げます。以下では、何が問題だったのか、インシデントはどのように解決されたのか、そして再発防止に向けた取り組みについてまとめています。
Workers KVは、グローバルに分散されたキーバリューストアです。設定データ、ルーティングルックアップ、静的アセットバンドル、認証トークン、その他低遅延アクセスを必要とするデータを管理するために、お客様とCloudflareチームの双方に使用されています。
このインシデントにおいて、KVは、KVが使用する新しいデプロイツールのバグにより、要求されたキーと値のペアの代わりに、HTTP 401（Unauthorized）ステータスコードと思われるものを返しました。
これらのエラーは、KVが各サービスでどのように使用されているかによって、各製品で異なる形で現れ、その影響を以下に詳しく記載します。
影響を受けたもの
多くのCloudflareサービスは、設定、ルーティング情報、静的アセットサービス、認証状態をグローバルに配布するためにWorkers KVに依存しています。これらのサービスでは、KVネームスペースに対してget、put、delete、またはlist操作を実行すると、代わりにHTTP 401（Unauthorized）エラーが発生しました。
以下のCloudflare製品をご利用のお客様は、インシデントが発生している間、エラー発生率の上昇や、一部またはすべての機能にアクセスできない可能性がありました。
| 製品 | 影響 |
|---|---|
| Workers KV | KVを活用したアプリケーションをお使いのお客様では、このインシデントの期間中、Workers内のKV APIとREST APIの両方を含め、これらのアプリケーションに障害が発生しました。 Workers KVを使用していないアプリケーションに影響はありませんでした。 |
| Pages | Cloudflare Pages上でホストされているアプリケーションは、インシデントが発生している間アクセスできず、ユーザーにHTTP 500エラーが返されました。また、Cloudflare Pagesの新規デプロイでは、インシデント中、ユーザーにHTTP 500エラーが返されました。 |
| Access | 認証されていないユーザーはログインできませんでした。/certsエンドポイントを使用してJWTを検証しようとするオリジンは失敗しました。いずれのユーザーでも、デバイスポスチャーを持つアプリケーションで障害が発生しました。 /certsエンドポイントまたはポスチャーチェックを使用しない既存のログインセッションは影響を受けませんでした。全体として、既存のセッションの大部分は依然として影響を受けました。 |
| WARP / Zero Trust | ユーザーが新しいデバイスを登録できなかったり、デバイスポスチャーチェックやWarpセッションタイムアウトを強制するポリシーの対象となるリソースに接続できませんでした。 すでに登録されているデバイス、デバイスポスチャーを使用しないリソース、またはこのウィンドウ外で再認証されたリソースは影響を受けませんでした。 |
| 画像 | インシデントの間、Images APIはエラーを返しました。既存の画像配信に影響はありませんでした。 |
| キャッシュのパージ（単一ファイル） | 一部のデータセンターがKVの設定データにアクセスできなかったため、インシデントの間、単一ファイルのパージを部分的に利用できませんでした。既存の設定データをローカルにキャッシュしていたデータセンターは影響を受けませんでした。 タグによるパージを含む他のキャッシュのパージメカニズムは影響を受けませんでした。 |
| Workers | ダッシュボード、Wrangler、またはAPIを使用してWorkersをアップロードまたは編集すると、インシデント中にエラーが返されました。デプロイ済みのWorkersは、KVを使用していない限り影響を受けませんでした。 |
| AI Gateway | AI Gatewayはインシデントの間、リクエストのプロキシができませんでした。 |
| Waiting Room | Waiting Roomの設定はWorkers KVでエッジに保存されます。インシデントの間、Waiting Roomの設定や設定変更が利用できず、サービスを開くことができませんでした。 KVへのアクセスが回復したとき、一部のWaiting Roomユーザーはサービス回復時にキューに入ることがありました。 |
| Turnstileとチャレンジページ | TurnstileのJavaScriptアセットがKVに保存されており、Turnstileのエントリーポイント（API.js）を提供できませんでした。インシデントの間、Turnstileを使用してページにアクセスするクライアントが、Turnstileウィジェットを初期化できず、障害が発生しました。 チャレンジページ（カスタム、マネージド、レート制限ルールなどの製品が使用する）も、特定の条件下でユーザーにチャレンジページを提示するためのTurnstileインフラストラクチャを使用しており、その期間中にチャレンジが提示されたユーザーはブロックされました。 |
| Cloudflareダッシュボード | Turnstileや（設定にKVを使用する）内部機能フラグツールを使用するCloudflareダッシュボードの一部は、インシデントの間、ユーザーにエラーを返しました。 |
タイムライン
参照されるタイムスタンプはすべて協定世界時（UTC）です。
| 時間 | 説明 |
|---|---|
| 2023-10-30 18:58 UTC | Workers KVチームは、新しいKVビルドの本番環境へのプログレッシブデプロイを開始しました。 |
| 2023-10-30 19:29 UTC | 内部プログレッシブデプロイAPIは、本番ビルドを一覧表示する呼び出しに対してステージングビルドGUIDを返しました。 |
| 2023-10-30 19:40 UTC | プログレッシブデプロイAPIは、リリースを継続的に展開するために使用されました。このため、トラフィックの何割かが誤った宛先にルーティングされ、警告が発せられ、ロールバックの決定につながりました。 |
| 2023-10-30 19:54 UTC | プログレッシブデプロイAPIによるロールバックを試みましたが、規模が大きくなるにつれてトラフィックに障害が発生しました。—影響開始— |
| 2023-10-30 20:15 UTC | Cloudflareのエンジニアは、（break-glassメカニズムを使って）デプロイルートを手動で編集し、大部分のトラフィックについては、直近の正常なビルドに戻すことができました。 |
| 2023-10-30 20:29 UTC | Workers KVのエラー率はインシデント前の通常のレベルに戻り、影響を受けたサービスは次の数分以内に復旧しました。 |
| 2023-10-30 20:31 UTC | 影響解決 —影響終了— |
上記のタイムラインに示されているように、19:54 UTCに問題を認識してから、20:15 UTCに実際にロールバックを実行できるようになるまでには遅れがありました。
これは、Cloudflare内の複数のツールが、Cloudflare Accessを含むWorkers KVに依存していることが原因でした。Accessは、リクエスト検証プロセスの一環として、Workers KVを使用しています。このため、内部ツールを活用することができず、通常のツールをバイパスするためにbreak-glassメカニズムを使用せざるを得ませんでした。後述するように、Cloudflareはロールバックメカニズムのテストに十分な時間を費やしていませんでした。今後、これを強化していく所存です。
解決方法
Cloudflareのエンジニアは、（break-glassメカニズムを使用して）本番用ルートを以前の作業バージョンのWorkers KVに手動で切り替えました。これにより、失敗したリクエストパスがすぐに解消され、Workers KVのデプロイに関する問題が解決されました。
分析
Workers KVは、Cloudflareのネットワーク上で、可能な限りユーザーの近くに永続的なデータを保存することを可能にする、遅延の少ないキーバリューストアです。この分散型キーバリューストアは多くのアプリケーションで使用されており、その中にはCloudflare Pages、Access、Zero TrustのようなCloudflareのファーストパーティ製品もあります。
Workers KVチームは、専用のデプロイツールを使って新しいリリースのプログレッシブデプロイを進めていました。デプロイメカニズムには、ステージング環境と本番環境が含まれ、すべての本番環境が最新の本番ビルドにアップグレードされるまで、本番環境が新しいバージョンにプログレッシブデプロイの割合に従ってアップグレードされるプロセスが利用されます。デプロイツールには、リリースとそれぞれのバージョンを返す方法に潜在的なバグがありました。このツールは単一の環境からリリースを返すのではなく、意図したよりも幅広いリリースのリストを返し、その結果、本番リリースとステージングリリースが一緒に返されました。
このインシデントでは、サービスはステージングでデプロイされ、テストされました。しかし、デプロイ自動化のバグにより、本番環境へのデプロイ時に、本番アカウントのプレプロダクションバージョンではなく、ステージングアカウントにデプロイされたスクリプトが、誤って参照されました。その結果、デプロイメカニズムは、本番環境のどこにも実行されていないバージョンを本番環境に指し示し、トラフィックをブラックホールにルーティングしました。
このような事態が発生すると、本番稼動中のWorkers KVは、製品へのアクセスが許可されていないバージョンに誘導され、HTTP 401エラーコードを返すため、アクセス不能となりました。このため、KVにキーバリューペアを保存している製品では、そのキーバリューペアがローカルにキャッシュされているかどうかに関係なく、障害が発生しました。
自動アラートは問題をすぐに検出しましたが、問題の発生を認識してから実際にロールバックを実行できるまでに時間がかかりました。これは、Cloudflare内の複数のツールが、Cloudflare Accessを含むWorkers KVに依存していることが原因でした。Accessは、ユーザーJWT（JSON Webトークン）の検証プロセスの一部として、Workers KVを使用しています。
これらのツールには、変更を戻すために使用されたダッシュボードや、継続的インテグレーション（CI）システムにアクセスするための認証メカニズムが含まれます。Workers KVがダウンしたため、これらのサービスもダウンしました。CIシステムによる自動ロールバックは以前にもテストされていましたが、今回のインシデントによる認証の問題（AccessはKVに依存しているため）により、デプロイをロールバックするために必要なシークレットにアクセスすることができませんでした。
最終的な修正は、本番用ビルドパスを既知の良好なものに手動で変更することで行われました。このパスはデプロイされたことが知られており、デプロイを試みる前の本番ビルドでした。
次のステップ
Cloudflareのより多くのチームがWorkersを基盤とするにつれ、私たちは「有機的に」Workers KVが今や私たちの製品やサービスの膨大な部分を支えるに至っています。このインシデントにより、私たちは重要な依存関係の広範な影響を小さくする方法を再検討する必要性がさらに強まりました。これには、デプロイツールの洗練度の向上、社内チームにとっての使いやすさ、これらの依存関係にある製品レベルでの制御などが含まれます。私たちは、このようなインシデントを繰り返さないために、これらの取り組みに優先順位をつけて対応中です。
これはまた、Cloudflareが社内およびお客様向けにWorkersアプリケーションのプログレッシブデプロイの際のツールの改善と、当該ツールの安全性を向上させる必要性を補強するものでもあります。
これには、今四半期の主なフォローアップ活動の以下のリスト（順不同）が含まれます（ただし、これに限定されません）。
- 標準化されたWorkersデプロイモデルにKVを搭載し、影響の検出と復旧に自動システムを使用する。
- ロールバックプロセスが既知の正常なデプロイ識別子にアクセスできること、およびCloudflare Accessがダウンしているときにロールバックプロセスが機能することを確認する。
- デプロイに事前チェックを追加し、入力パラメーターを検証することで、バージョンの不一致が本番環境に伝播しないようにする。
- プログレッシブデプロイツールを強化し、マルチテナント用に設計された方法で動作するようにする。現在の設計では、シングルテナントモデルを想定しています。
- プログレッシブデプロイスクリプトに新たな検証を追加し、デプロイがアプリ環境（本番環境、ステージング環境など）と一致していることを検証する。
繰り返しになりますが、この件がお客様に与えた影響を非常に深刻に受け止めており、このような事態が発生したことを深くお詫びいたします。