2025年3月21日に、R2オブジェクトストレージを含む複数のCloudflareサービスで、1時間7分にわたってエラー率上昇が見られました（21:38 UTCに開始、22:45 UTCに終了）。このインシデントウィンドウでは、世界全体でR2への書き込み操作が100%失敗し、読み込み操作は約35%が失敗しました。このインシデントはR2から始まりましたが、Cache Reserve、Images、Log Delivery、Stream、Vectorizeなど、他のCloudflareサービスにも影響を及ぼしました。
R2 Gatewayサービス（R2のAPIフロントエンド）が当社ストレージインフラストラクチャでの認証に使用する認証情報をローテーションしている間に、R2のエンジニアリングチームが誤って新しい認証情報（IDとキーペア）を、サービスの本番インスタンスではなく開発インスタンスにデプロイしてしまいました。（キーローテーションプロセスの一環として）古い認証情報が当社のストレージインフラストラクチャから削除された時、本番用のR2 Gatewayサービスは新しい認証情報にアクセスできませんでした。この最終的な結果として、R2のGatewayサービスはストレージバックエンドで認証不可能となりました。このインシデントで発生したデータの損失や破損はありませんでした。未了のアップロードやミューテーションは、成功のHTTPステータスコードを返したものは続けられました。
根本的な原因を特定し、本番用のR2 Gatewayサービスに新しい認証情報をデプロイしていないことに気づいた後は、更新後の認証情報をデプロイし、サービスの可用性を回復しました。
このインシデントは人為的なミスによって発生し、想定より長く続きました。Gateway Workerがストレージインフラストラクチャの認証にどの認証情報を使用しているかを、当社が適切に可視化できていなかったためです。
このインシデントによりお客様やお客様のユーザーに多大なご迷惑をおかけしたことを、深くお詫び申し上げます。当社では高水準の維持を心掛けており、今回のような事態は許容されるものではありません。このブログ記事では、インシデントの影響、いつ何が起こったのか、この障害（および類似の障害）を二度と起こさないようにするために当社が講じている措置を正確に説明します。
プライマリインシデントのウィンドウは21:38 UTCから22:45 UTCでした。
次の表では、R2と、R2に依存するかR2と対話するCloudflareサービスへの具体的な影響について詳しく説明します：
| 製品/サービス |
影響 |
| R2 |
Cloudflare R2をご利用のすべてのお客様が、プライマリインシデントウィンドウでエラー率上昇を経験しました。具体的には：
* オブジェクトの書き込み操作のエラー率は100%でした。
* オブジェクトの読み取りは、グローバルで約35%のエラー率でした。このウィンドウにおける個々のお客様のエラー率は、アクセスパターンによって異なります。カスタムドメインでパブリックアセットにアクセスするお客様では、キャッシュされたオブジェクトの読み取りに影響がなかったため、エラー率は抑えられました。
* メタデータのみの操作（例：ヘッド操作やリスト操作）は影響を受けませんでした。
R2のストレージサブシステム内では、データの損失やデータの完全性へのリスクはありませんでした。このインシデントは、R2のAPIフロントエンドと当社のストレージインフラストラクチャの間で発生した一時的な認証の問題だけでした。 |
| 請求に関する問い合わせ |
Billingは、R2を使用してお客様へのインボイスを保存しています。プライマリインシデントウィンドウでは、お客様がCloudflareの過去のインボイスのダウンロードやアクセスを試みると、エラーが発生する場合がありました。 |
| Cache Reserve |
Cache Reserveのお客様では、このインシデントウィンドウでオリジンへのリクエストが増加しました。これはR2の読み取りの失敗率が上がったためで、その間にCache Reserveで利用できないアセットの取得をオリジンにリクエストする件数が増えました。
Cache Reserveを使うサイトに対するユーザー向けのアセット要求リクエストは、キャッシュミスがオリジンにフェイルオーバーしたため、故障は観測されませんでした。 |
| メールセキュリティ |
Email Securityは、顧客向けのメトリクスをR2に依存しています。プライマリインシデントウィンドウでは、顧客向けメトリクスが更新されませんでした。 |
| Images |
プライマリインシデントウィンドウでは、すべて（100%）のアップロードが失敗しました。保存された画像の配信成功率は約25%に低下しました。 |
| Key Transparency Auditor |
R2の書き込みや読み取りに依存していたために、プライマリインシデントウィンドウではすべて（100%）の操作が失敗しました。インシデントが解決すると、サービスはすぐに通常の運用に戻りました。 |
| Log Delivery |
プライマリインシデントウィンドウではログ（LogpushとLogpullの）の配信が遅れ、ログ処理に大幅な遅延（最大70分）が発生しました。インシデント解決後はすべてのログが配信されました。 |
| Stream |
プライマリインシデントウィンドウでは、すべて（100%）のアップロードが失敗しました。 Streamの動画セグメント配信の成功率は94%でした。実際の影響はさまざまでしょうが、視聴者は約1分ごとに動画が停止するのを経験したかもしれません。
Stream Liveはオブジェクトの書き込みに依存するため、プライマリインシデントウィンドウではダウンしていました。 |
| Vectorize |
このインシデントウィンドウでは、Vectorizeインデックスに対するクエリーや操作も影響を受けました。Vectorizeは永続ストレージをR2に依存しているため、Vectorizeをご利用のお客様ではインシデントウィンドウに、インデックスのクエリで読み取りエラー率が上がり、インサートとアップサートの操作はことごとく（100％）失敗しました。 |
参照されるタイムスタンプはすべて協定世界時（UTC）です。
| 時間 |
イベント |
| 2025年3月21日 - 19:49 UTC |
R2のエンジニアリングチームが、認証情報のローテーションプロセスを開始しました。ストレージインフラストラクチャ用の新しい認証情報セット（IDとキーペア）が作成されました。認証情報変更中のダウンタイムを回避するため、古い認証情報は維持しました。 |
| 2025年3月21日 - 20:19 UTC |
更新後の本番シークレットを設定（wrangler secret put）し、wrangler deployコマンドを実行して、更新後の新しい認証情報を使ってR2 Gatewayサービスをデプロイしました。
注：その後、両方のwranglerコマンドで--envパラメータをうっかり省略していたことがわかります。そのため、認証情報はデフォルト環境（本番環境ではなく）に割り当てられたWorkerにデプロイされました。 |
| 2025年3月21日 - 20:20 UTC |
デフォルト環境に割り当てられたR2 GatewayサービスWorkerはこの時点で、更新後のストレージインフラストラクチャ用認証情報を使用しています。
注：このWorkerは間違いで、本番環境を明示的に設定しておくべきでした。しかし、当社はこの時、認証情報が正しい本番Workerで更新されたという誤った認識をもっていました。 |
| 2025年3月21日 - 20:37 UTC |
古い認証情報をストレージインフラストラクチャから削除し、認証情報のローテーションプロセスを完了しました。 |
| 2025年3月21日 - 21:38 UTC |
– 影響開始 –
R2の可用性メトリクスにサービス低下の兆候が表れ始めます。古い認証情報の削除がストレージインフラへ伝わるまでに伝播遅延があるため、R2の可用性メトリクスへの影響は徐々に表れ、一見して明らかなものではありませんでした。 |
| 2025年3月21日 - 21:45 UTC |
R2のグローバル可用性アラートがトリガーされます（エラー予算の消費率の2%を表示）。
R2のエンジニアリングチームは、影響を理解するために運用ダッシュボードやログを調べ始めました。 |
| 2025年3月21日 - 21:50 UTC |
内部インシデントが宣言されました。 |
| 2025年3月21日 - 21:51 UTC |
R2のエンジニアリングチームは、読み取り操作と書き込み操作の両方でR2の可用性メトリクスが徐々にではあるが一貫して低下していることを確認します。メタデータだけを対象とする操作（ヘッド操作やリスト操作など）には影響はありませんでした。
可用性メトリクスが徐々に低下していたため、R2のエンジニアリングチームは、ストレージインフラストラクチャにおける新しい認証情報の伝播で回帰が起こっている可能性を疑いました。 |
| 2025年3月21日 - 22:05 UTC |
パブリックインシデントステータスページが公開されました。 |
| 2025年3月21日 - 22:15 UTC |
R2のエンジニアリングチームは、ストレージインフラストラクチャ用の新しい認証情報セット（IDとキーペア）を作成し、強制再伝播を試みました。
運用ダッシュボードとログを引き続き監視しました。 |
| 2025年3月21日 - 22:20 UTC |
可用性メトリクスの改善は見られませんでした。他の根本原因がある可能性を引き続き調査しました。 |
| 2025年3月21日 - 22:30 UTC |
R2のエンジニアリングチームは、R2 GatewayサービスWorkerに新しい認証情報セット（IDとキーペア）をデプロイしました。これは、ゲートウェイサービスにプッシュした認証情報に問題があるかどうかを検証するためのものでした。
デプロイとシークレットプットのコマンドで環境パラメーターが省略されていることに変わりはなかったため、デプロイ先は依然として誤った非本番Workerでした。 |
| 2025年3月21日 - 22:36 UTC |
– 根本原因の特定 –
R2のエンジニアリングチームは本番Workerのリリース履歴を確認し、認証情報が非本番Workerにデプロイされていることが判明しました。 |
| 2025年3月21日 - 22:45 UTC |
– 影響終了 –
正しい本番Workerに認証情報をデプロイしました。R2の可用性が回復しました。 |
| 2025年3月21日 - 22:54 UTC |
このインシデントは解決済みと判断されました。 |
R2のアーキテクチャは主に3つの部分で構成されています。本番用R2 Gateway Worker（S3 API、REST API、Workers APIからのリクエストを処理）、メタデータサービス、ストレージインフラストラクチャ（暗号化されたオブジェクトデータを格納）です。
R2 Gateway Workerは、分散ストレージインフラストラクチャでセキュアに認証を行うのに認証情報（IDとキーペア）を使用します。当社では、ベストプラクティスのセキュリティ対策として、これらの認証情報を定期的にローテーションしています。
キーローテーションのプロセスには、おおまかには以下のステップが含まれます：
ストレージインフラストラクチャ用の新しい認証情報セット（IDとキーペア）を作成します。この時点では、認証情報変更中のダウンタイムを回避するために、古い認証情報を維持します。
wrangler secret putコマンドを使用して、本番R2 Gateway Workerの新しい認証情報シークレットを設定します。
wrangler deployコマンドを使用して、更新後の新しい認証情報ID を、本番R2 Gateway Workerで環境変数として設定します。この時点から、Gateway Workerは新しいストレージの認証情報を使用し始めます。
ストレージインフラストラクチャから古い認証情報を削除し、認証情報のローテーションプロセスを完了します。
運用ダッシュボードやログを監視して、変更を確認します。
R2のエンジニアリングチームはWorkers環境を使用して、R2 Gateway Workerの本番環境と開発環境を隔離します。それぞれの環境は、別々に分離されたCloudflare Workerを別々の環境変数とシークレットで定義します。
重要なのは、もし--envコマンドラインパラメータが含まれていなければ、wrangler secret putコマンドとwrangler deployコマンドの両方がデフォルト環境をデフォルトにしてしまうということです。今回の場合は、人為的なミスで--envパラメータをうっかり省略し、新しいストレージ認証情報を間違ったWorker（--env productを指定する必要があります。
上記のステップ4でストレージインフラストラクチャから古い認証情報を削除するアクションを実行したところ、認証エラーが発生しました。本番R2 Gateway Workerの認証情報が古いままだったからです。このエラーが最終的に可用性低下を引き起こしました。
古い認証情報の削除がストレージインフラへ伝播するまでに遅延があったため、R2の可用性メトリクスの低下は徐々に進行し、すぐには明確になりませんでした。最初の問題発見が遅れたのはこのためです。古い認証情報セットを更新した後、可用性メトリクスに頼るのではなく、R2 GatewayサービスがR2のストレージインフラストラクチャの認証にどのトークンを使用しているかを明示的に検証するべきでした。
全体的に見て、読み取りについては、ストレージの前に配置された中間キャッシュがリクエストに対応し続けたおかげで、可用性への影響はかなり抑えられました。
根本的な原因を特定した後は、本番R2 Gateway Workerに新しい認証情報をデプロイし、迅速にインシデントを解決することができました。R2の可用性は即時に回復しました。
このインシデントは人為的ミスによって発生し、R2 Gateway Workerがストレージインフラストラクチャの認証にどの認証情報を使用しているかを適切に可視化していなかったために、予想以上に長引きました。
この故障（や類似の故障）が二度と起こらないよう、当社は直ちに再発防止策を講じました：
R2 Gateway Workerがストレージインフラストラクチャの認証に使用する認証情報IDのサフィックスを含むログ用タグを追加しました。この変更により、どの認証情報が使用されているかを明示的に確認することができます。
上記の対策に関連する内部プロセスとして、新しいトークンIDのサフィックスがストレージインフラストラクチャのログと一致することを、古いトークンを削除する前に明示的に確認するよう義務付けています。
人為的ミスの可能性がある手動のwranglerコマンド入力に依存するのではなく、ホットフィックスのリリースツールによってキーローテーションを行うように義務付けています。当社のホットフィックスリリースデプロイツールは、環境設定を明示的に強制するほか、他の安全性チェックも含まれています。
このプロセスでは、次の段階へ進む前に少なくとも2人の人間が変更の検証に関与することが暗黙の基準でしたが、関連するSOP（標準的業務手順書）を更新してこれを明示化しました。
作業中：エンドポイントを監視する既存のクローズドループヘルスチェックシステムを新しいキーのテストにも拡張し、アラートプラットフォームを通じてステータス報告を自動化し、Gateway Workerをリリースする前にグローバルな伝播を確認します。
作業中：分散ストレージエンドポイントで今後問題が発生した場合のトリアージを迅速化するため、可観測性プラットフォームを更新し、キャッシュをバイパスするアップストリームの成功率のビューを含めることで、理由は何であれリクエスト処理の問題が発生していることが明確にわかるようにします。
上のリストはすべてを網羅しているわけではありません。上記の項目を進めていく中で、システム、制御、プロセスの他の改善点が見つかる可能性があります。当社は、通常の改善業務はもちろん、新たに見つかった改善点にも取り組んで、R2の耐障害性を高めていきます。上述した一連の変更により、この故障と関連する認証情報ローテーション故障モードの再発を防止できると確信しています。繰り返しになりますが、この件によりお客様やお客様のユーザーに多大なご迷惑をおかけしたことを、深くお詫び申し上げます。