Cloudflare DDoS脅威レポート2026年上半期、1Tbps攻撃が935件に急増
Cloudflareが2026年8月11日、DDoS脅威レポートの2026年上半期版を公開した。今回で通算25回目の発行となる。四半期ごとの発表を統合し、1月から6月までを単一のレポートにまとめた形式だ。
レポートによれば、Cloudflareは上半期で2,320万件のネットワーク層DDoS攻撃と29兆6,400億件のHTTP DDoSリクエストを軽減した。1時間あたり約5,343件、1日あたり約12万8,000件の攻撃に相当する。
なかでも1Tbps（テラビット毎秒）を超える超大規模攻撃の急増が目を引く。攻撃ベクトルはボットネット直撃型から反射・増幅型へ移行しつつあり、防御側の自動化がこれまで以上に重要になっている。
2026年上半期のDDoS攻撃概況
4月にピーク、国際摘発作戦で減少へ
4月は攻撃のピーク月だった。攻撃リクエストは6兆4,600億件、通信量は165PB（ペタバイト）に達した。この量は大手動画プラットフォームが1日で処理するデータ量に匹敵する規模だ。
その後、攻撃件数と通信量は減少に転じた。同時期に実施された国際法執行作戦「Operation PowerOFF」が影響したとみられる。21カ国が参加し、DDoS攻撃代行サービスの利用者7万5,000人超を標的に、53のドメインを停止、25件の家宅捜索、4人の逮捕という成果を上げた。
法執行の直接的な抑止効果は計測しにくい。ただし摘発の直後に攻撃数が減少した事実は、DDoS攻撃代行サービス（いわゆるブートストレスサービス）の利用層がインターネット全体の攻撃量に与える影響の大きさを示している。個人が安価に攻撃を「注文」できる構造が、この規模の攻撃増加を支えている構図だ。
1Tbps超の攻撃が6倍以上に急増
1Tbps超の超大規模攻撃は第2四半期だけで805件に達した。前期比で6倍以上の増加だ。上半期全体では935件の1Tbps超ネットワーク層攻撃を軽減している。
DDoS対策の世界では「ハイパーボリュメトリック攻撃」という分類がある。1Tbps以上、または毎秒10億パケット（Bpps）以上、または毎秒100万リクエスト（Mrps）以上のいずれかを満たす攻撃だ。2026年はこの分類に入る攻撃が順調に増えている。
ただし攻撃の中央値は小規模だ。ネットワーク層攻撃の96.62%が500Mbps未満、90.60%が10分未満で終了している。「小規模」といっても相対的な話だ。100Mbpsの攻撃だけで一般的なサーバーやWebサイトは十分にダウンし得る。100Gbpsなら無保護のデータセンターを停止させる威力がある。
攻撃者は帯域とパケットレートの組み合わせも工夫する。高パケットレート（Mpps単位）と低帯域幅（Gbps単位）を組み合わせ、ネットワーク機器の処理限界と回線容量の限界という異なる弱点を同時に狙う手口が観測されている。
攻撃ベクトルの変化とCLDAP急増
DNS系攻撃がネットワーク層の3分の1を占める
攻撃の中心はボットネット直撃型から反射・増幅型へ移っている。DNS系攻撃が上半期のネットワーク層攻撃全体の34.3%を占めた。第2四半期にはDNSフラッドの割合が25.7%から40.0%へ急拡大している。
DNSフラッドは、ボットネットが被害者の権威DNSサーバーへ大量のクエリを直接送りつける攻撃だ。このドメインの「電話帳」に当たるDNSサーバーが応答不能になると、そのドメインに依存するサービスはすべて機能を失う。
DNSアンプリフィケーションは別の仕組みだ。攻撃者は送信元IPを偽装した小さなクエリを公開DNSリゾルバへ送る。リゾルバは元のクエリよりはるかに大きな応答を、偽装されたIP（つまり被害者）へ返す。少ない帯域で大きな攻撃を生み出せるため、攻撃者にとって効率がよい。
上の図は3つの攻撃ベクトルの違いを整理したものだ。直撃型は攻撃者自身の帯域がそのまま攻撃力になる。反射・増幅型は第三者のサーバーを踏み台にするため、攻撃者側の帯域が少なくても大きな打撃を与えられる。
CLDAPフラッドが580%増
CLDAPフラッドの伸びは顕著だ。前期比580%増となり、第2四半期だけで第3位の攻撃ベクトルに浮上した。
CLDAP（Connectionless Lightweight Directory Access Protocol）はLDAPのUDP版だ。UDPはTCPと違いハンドシェイクが不要で、送信元IPの偽装が容易になる。攻撃者はUDPポート389で公開されたドメインコントローラーへ偽装クエリを送り、元の数十倍から数百倍の応答を被害者へ反射させる。
CLDAPの急増が示すのは、公開されたUDPサービスの危険性だ。ポート389が外部に開いている組織は、自覚のないまま攻撃者の踏み台にされている可能性がある。インフラ管理者にとっての実務的な教訓は「UDPポートの露出を監査し、不要なら閉じる」という基本対策の重要性が再確認されたことにある。
標的産業と地域の動向
メディア産業が最大の標的に
メディア・制作・出版産業が両四半期で最も攻撃された産業になった。全HTTP DDoSリクエストの14.2%を占め、2位の約4倍に相当する。イランとウクライナの戦況報道、そしてワールドカップ関連の報道が攻撃対象になったとみられる。
報道機関へのDDoS攻撃は、単なる金銭目的や愉快犯ではなく、情報の流れを止める意図を持つことが多い。特定の報道を続けるメディアのサイトを落とすことで、世論に影響を与えようとする動機が背景にある。
この図が示すように、標的と攻撃元の分布は対称ではない。標的は中国・米国など経済規模の大きい国に集中し、攻撃元はブラジル・インドネシアなどボットネット感染端末が多いとされる国に偏る。
政府部門が29位から9位へ急浮上
政府部門の動きは今年最大のトピックだ。2026年2月28日にイスラエルと米国が「Operation Epic Fury」を開始。その72時間以内に、16カ国110組織に対する149件のハクティビストDDoS攻撃が記録された。標的組織の47.8%が政府部門だった。
この結果、政府部門のシェアは第1四半期の29位から第2四半期には9位へ急上昇した。単一セクターの移動幅としては2026年最大だ。地政学的な緊張がDDoS攻撃の規模と方向性に直接影響を与える構図が、データとして明確に現れた。
国別では中国が最多の標的になった。第2四半期に全世界のHTTP DDoSリクエストの22.4%を吸収した。米国は18.8%で2位を維持している。トルコは攻撃シェアが倍増し、第3位に浮上した。6月から7月にかけてのアンカラNATOサミット準備期間中、治安当局が209人以上を逮捕する大規模な事前摘発を行った時期と重なる。
攻撃元の国ではブラジルが米国を逆転して1位になった。上半期のシェアはブラジル14.9%に対して米国13.4%だ。ブラジルは第2四半期に21.4%まで急伸した。インドネシアは両四半期とも3位を維持し、複数四半期連続で上位3カ国に入る常連になっている。
短時間攻撃と自動防御の重要性
90%以上が10分未満で終了
DDoS攻撃の大半は驚くほど短い。上位の超大規模攻撃ですら秒単位で終了する。過去には開始から終了までわずか35秒という記録的な攻撃も観測されている。
攻撃が30秒でも10分でも、人間が介入する実質的な時間窓は存在しない。セキュリティ担当者にアラートが届いた時点で、攻撃はすでに完了しているからだ。手動での軽減策やオンデマンド型の防御はこの現実に対して遅すぎる。
この図のとおり、攻撃の持続時間と人手による対応時間は圧倒的に乖離している。従来型の「監視して手動で対応する」運用モデルは、DDoS対策においては成立しない。
自動防御が唯一の実効策
さらに、短い攻撃の余波は長引く。ルーティングの不安定化、TCP再送、アプリケーションのタイムアウト、下流サービスの劣化などが数時間から数日続くことがある。サービス停止や品質低下は攻撃の終了後も継続するのだ。
この環境では、常時稼働する自動防御が「あったほうがよい」ものではなく必須の要件になる。Cloudflareは330以上の都市に分散したネットワーク全体で、人間の介入なしに攻撃を検知・軽減する仕組みを運用している。ネットワーク容量は500Tbps規模だ。
同社はさらに、DDoS攻撃を仕掛けるIPアドレスやアカウントを特定する無料のフィードをホスティング事業者やISP向けに提供している。世界800以上のネットワークが登録しており、ボットネットノードの撤去に一定の成果を上げている。
日本の事業者にとっての示唆は明確だ。自社サイトが直接の標的でなくても、反射型攻撃の踏み台にされたり、同じホスティング上の他サイトへの攻撃に巻き込まれたりするリスクは常にある。小規模サイトでも「攻撃を受けたら止まる」前提ではなく、自動防御を標準装備する発想が必要になる。
この記事のポイント
- 1Tbps超のネットワーク層DDoS攻撃が上半期で935件に達した
- DNS系攻撃がネットワーク層全体の34.3%を占め、反射・増幅型への移行が進む
- CLDAPフラッドが前期比580%増で第3位の攻撃ベクトルに浮上
- メディア・制作・出版が最も攻撃され、政府部門は29位から9位へ急上昇
- 攻撃の90.60%が10分未満で終了し、自動防御が実質唯一の対策になる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Amazon Bedrock AgentCoreにランタイムインスタンス発表、本番AIエージェント向け永続コンピューティング
AWSは2026年8月6日、Amazon Bedrock AgentCoreに新たな計算オプション「ランタイムインスタンス」を追加した。AIエージェントのプロトタイプを本番環境に移行する際、長時間の状態維持やマルチエージェント協調、GPUアクセスといった要求に応える、永続的なマネージドインフラだ。
従来のAgentCore Runtimeでは、マイクロVM上で最大8時間のステートフルな呼び出しが可能だったが、日をまたぐワークフローやOSレベルへの直接アクセスが必要なシナリオには限界があった。ランタイムインスタンスは、14日間のセッション永続化とEC2ベースのフルマネージド環境を提供し、本格的なエージェント運用基盤を実現する。
ランタイムインスタンスが解決する本番運用の3つの課題
AIエージェントをプロダクションに投入するとき、開発者はインフラの壁にぶつかる。ランタイムインスタンスはその3つの主要な課題を解消する。
長時間の状態維持とセッション永続化
通常のサーバーレス実行環境では、処理が終わるとメモリやストレージが破棄される。エージェントが数時間〜数日にわたる複数ステップのワークフローを扱う場合、途中結果を外部ストレージに退避させるなどの手間が生まれる。ランタイムインスタンスでは、最大14日間の共有セッションストレージが標準で提供される。セッションは停止・再開が可能で、アイドル期間のコストを抑えながら、必要なときに前回の状態から処理を再開できる。
マルチエージェントの同一ホスト協調
現実の複雑なタスクは、コード生成・レビュー・テスト・デプロイといった複数の専門エージェントが連携して初めて完結する。ランタイムインスタンスでは、複数のエージェントを同一のEC2ホストにデプロイし、共有ファイルシステムを介して直接データをやり取りできる。API呼び出しやネットワーク越しのストレージを挟むオーバーヘッドがなく、シームレスな協調が可能だ。
GPUとOSへの直接アクセス
画像認識や動画解析、重い数値計算を伴うエージェントはGPUを必要とする。ランタイムインスタンスはGPUアクセラレーテッドなインスタンスタイプに対応し、OSレベルへのアクセスも提供する。コードのコンパイル、セキュリティスキャン、GUI自動操作など、コンテナだけでは実現しにくいタスクをエージェントに任せられる。
コードライターとレビュアーの連携を実際に見る
公式デモでは、自然言語でPythonコードを生成する「コードライターエージェント」と、生成されたコードのバグやスタイルをレビューする「コードレビュアーエージェント」を同じランタイムインスタンス上にデプロイし、協調動作させる手順が紹介された。
このデモのポイントは、2つのエージェントが完全に独立したアプリケーションでありながら、セッションIDで紐づく共有ディレクトリを経由してファイルをやり取りする点にある。外部APIを呼び出すことなく、同一ホストのファイルシステム上で完結するため、レイテンシが極めて小さい。
/tmp/agentcore-session/{session_id}/code.py に書き込む各エージェントはStrands Agentsフレームワークと好みのモデル（デモではClaude Sonnet）を使い、単一のPythonファイルに @app.entrypoint デコレータを付けるだけで実装できる。パッケージングもzipまたはコンテナイメージで済み、インフラ管理の負担は大きく軽減される。
セットアップから初回実行までの流れ
ランタイムインスタンスの利用は、大きく3つのステップで完了する。AWSマネジメントコンソールを使う場合の手順を簡潔にまとめた。
- 容量プロバイダの作成 、 エージェントが稼働するEC2インスタンスのスペックとネットワークを定義する。OS（ARM64またはx86_64）、インスタンスタイプ、VPC、サブネット、セキュリティグループを設定。ストレージはgp3ボリュームがデフォルトで用意される。
- ランタイムの作成とエージェントのデプロイ 、 コンピュートタイプに「Instances」を選び、先ほど作成した容量プロバイダを紐づける。エージェントのコードをzipでアップロードし、ランタイム（Python 3.11〜3.14）とエントリポイントを指定。IAMロールもコンソールが自動生成する。
- エージェントの呼び出しと協調 、 デプロイ完了後、コンソールの「Runtime playground」からテスト用のJSONペイロードを送信できる。セッションIDを明示的に指定し、同じIDで別のエージェントを呼び出せば、両者が同一の共有ストレージを使ってシームレスに連携する。
容量プロバイダは一度作成するとOSやインスタンスタイプの変更ができない。本番用と検証用を分けるなど、事前の設計が求められる。
主要スペックと料金モデル
- 対応OS 、 Linux（ARM64、x86_64）。Windowsは現時点ではサポート外
- セッション持続 、 最大14日間。停止・再開が可能で、アイドル中のコスト削減に有効
- ランタイム 、 Python 3.11〜3.14（ネイティブコードに対応）。コンテナイメージのデプロイもサポート
- GPU 、 対応インスタンスタイプを選択すれば、GPUを使った推論や計算が可能
- 統合 、 既存のAgentCore API、IAM、監視機能と完全互換。マイクロVMとのハイブリッド構成も取れる
- 料金 、 使用したEC2インスタンスの標準料金に、AgentCoreオーケストレーションの管理手数料が加算される
- リージョン 、 米国東部（オハイオ、バージニア北部）、米国西部（オレゴン）、アジアパシフィック（ムンバイ、シンガポール、シドニー、東京）、欧州（フランクフルト、アイルランド）
マイクロVMベースの従来のAgentCore Runtimeとランタイムインスタンスは、同じAPIセットで併用できる。軽量なオーケストレーターエージェントをマイクロVM側に置き、重い処理や永続状態が必要なワーカーエージェントをインスタンス側に委譲するハイブリッド構成が、現実的なアーキテクチャパターンとして紹介されている。
始め方と最初の一歩
ランタイムインスタンスを試すには、Amazon Bedrock AgentCoreのドキュメントに掲載されているランタイムインスタンスの公式ガイドを参照し、容量プロバイダの作成から始めるのが近道だ。コンソールの左ナビゲーションから「Runtime」→「Capacity providers」を選び、今回紹介した手順に沿って設定すれば、最初のエージェントデプロイまで数分で到達できる。
この記事のポイント
- ランタイムインスタンスは、最大14日間のセッション永続化とEC2ベースのマネージド環境を提供するAgentCore新オプション
- 同一ホスト上でのマルチエージェントファイル共有により、APIを介さないシームレスな協調が可能
- GPUインスタンスやOS直接アクセスが必要な高度なエージェントワークロードに対応
- 従来のマイクロVMと組み合わせたハイブリッド構成で、軽量なオーケストレーションと重いバックエンド処理を分離できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GKE Agent Sandboxが一般提供開始。エージェント向け基盤Agent Substrateも発表
Google Cloudが2026年5月20日、エージェント実行環境「GKE Agent Sandbox」の一般提供（GA）を開始した。合わせて、超大量エージェントの高密度実行を目指す新たなOSSプロジェクト「Agent Substrate」を発表している。
2025年11月のKubeCon NAでプレビューが公開されて以降、Agent Sandbox上のサンドボックス数は5か月足らずで16倍以上に成長した。LangchainやLovableといった顧客がすでに数百万単位のエージェントを本番環境で動作させている。
自律的にコードを実行するAIエージェントにとって、インフラの安全性と起動速度は実用化の鍵となる。今回のGAで安定版APIが提供され、エージェント実行基盤としての成熟度が一段と上がった。
GKE Agent Sandbox GAの主要な機能強化点
GKE Agent SandboxはKubernetes上に構築されたOSSの実行環境だ。AIエージェントが信頼できないコードを安全かつ高速に実行するための基盤として設計されている。今回のGAでは、実運用で課題となるアイドル状態の効率化と、起動レイテンシの低減に焦点が当てられた。
Pod Snapshotによるアイドルリソースの削減
エージェントのワークロードは、短いバースト的な処理の後に長いアイドル時間が続くという特徴を持つ。従来のようにアイドル中もPodを起動したままにしておくと、コンピュートリソースを無駄に消費してしまう。
GKE Agent SandboxはPod Snapshot機能と統合されている。アイドル状態のエージェントワークロードを一時停止（サスペンド）し、リクエストが来たときに数秒で再開できる。Google Cloudの発表によれば、この仕組みで不要なコンピュートコストを大幅に削減できるという。
Pod Snapshotの最大の利点は、エージェントワークロード特有の「使うときだけ高速に起動したい」という要求に応えられる点だ。サスペンド状態からの復帰は数秒で完了するため、ユーザーの待ち時間を最小限に抑えられる。
ウォームプールによる低レイテンシプロビジョニング
エージェントのリクエストが来るたびに新しいサンドボックスを作成すると、コールドスタートによる数秒の遅延が発生する。この遅延はエージェントの応答性を損ない、ユーザー体験を悪化させる要因となる。
GKE Agent Sandboxは、サンドボックスAPIにウォームプールを統合した。あらかじめ準備されたサンドボックスレプリカをプールしておき、リクエスト発生時に即座に割り当てる仕組みだ。これにより、1クラスタあたり毎秒300のサンドボックスを割り当て可能で、割り当ての90パーセントが200ミリ秒以内に完了する。
ウォームプールのコスト最適化も考慮されている。プール内のレプリカは常時稼働しているが、スタンバイキャパシティバッファと統合することで、一部のサンドボックスをサスペンド状態で待機させられる。ウォームプールが枯渇した際には、この「コールドプール」から素早く補充され、大幅なコスト削減につながる。
gVisorとネットワークポリシーによる強固な隔離
セキュリティ面では、gVisorをネイティブサポートし、デフォルト拒否のKubernetesネットワークポリシーを採用している。gVisorはユーザースペースで動作するカーネルであり、ホストOSから隔離された環境を提供する。コンテナ内のプロセスがホストカーネルに直接アクセスできないため、悪意あるコード実行のリスクを大幅に低減できる。
さらにKata ContainersのようなOSSサンドボックスにも対応するプラグイン可能なインターフェースを備えている。利用者は自社のセキュリティ要件に合わせてカーネル隔離レベルを選択できる。
コンピュートの選択肢も広がった。Google Cloud独自のAxionプロセッサ上でAgent Sandboxを実行すると、同等のハイパースケーラークラウドプロバイダと比較して最大30パーセント優れた価格性能比を達成すると発表されている。
Agent Substrateがもたらす次の変革
エージェントワークロードは今後、数千万から数億インスタンス規模へとスケールアップしていく。同時に、人間の操作やイベントを待つアイドル時間もますます長くなる。カーネルとネットワークの隔離を維持しながら高密度にスケジュールするのは、既存のKubernetesコントロールプレーンでは限界が近づいている。
この課題に対してGoogle Cloudが発表したのが、新たなOSSプロジェクト「Agent Substrate」だ。
Kubernetesの限界を超える最小限のコントロールプレーン
Agent Substrateは、Agent Sandboxの安全なランタイムとSnapshot機能を中核に据えつつ、Kubernetesの制約を部分的に回避する最小限のコントロールプレーンを組み合わせる。標準のKubernetesが数千の長時間稼働サービスを扱うのに最適化されているのに対し、Agent Substrateは数百万単位のサブ秒ツール呼び出しの「チャタリング」に耐えられるよう設計されている。
新たな抽象化レイヤーを導入し、Kubernetes上で稼働するコンピュートキャパシティに対して、エージェントをリアルタイムに乗せたり外したりする。Google Cloudの発表では、従来のコントロールプレーンでは処理しきれない高頻度の短命ワークロードに対して、レイテンシを低減しつつスケールと効率を最適化できるとしている。
Agent Substrateの目標は、現在のコンピュートインフラの限界を押し広げることにある。一例として、エージェントの状態とスケジューリングが協調して動作するようデータの局所性をスケジューラの中核に組み込む構想も示された。オーバーヘッドを1ミリ秒単位で削り取るため、あらゆる可能性を探求する姿勢が打ち出されている。
Agent HarnessやAgent Executorとの関係
Agent Substrateは、単独で動作するものではなく、エージェントエコシステム全体の基盤レイヤーとして位置づけられている。Agent HarnessやAgent Runtime、さらにはGoogle Cloudが別途発表している分散エージェントランタイム「Agent Executor」プロジェクトを支える役割を担う。
Google Cloudのブログ記事では、Agent Substrateを「エージェントネイティブなインフラストラクチャの次の章」と表現している。Kubernetesが登場初期に多様なコントリビューターの知見を集めて成功したように、エージェントインフラも同じ転換点にあるという認識が示された。
この記事のポイント
- GKE Agent Sandboxが一般提供開始。安定版APIでエージェント実行の本番運用に対応
- Pod Snapshotでアイドル時のリソース消費を抑え、リクエスト時に数秒で復元可能
- ウォームプールにより毎秒300サンドボックスをサブ秒で割り当て。コスト最適化も統合
- 新OSSプロジェクトAgent Substrateは数百万規模の短命ワークロードに特化した設計
- Axionプロセッサ利用時に最大30パーセントの価格性能比向上を達成
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
500 Tbpsに達したCloudflareのネットワーク網！DDoS防御とAI時代のインフラを徹底解説
Cloudflareのグローバルネットワークが、外部接続容量500 Tbps（テラビット毎秒）という大きな節目を超えた。2010年にパロアルトの小さなオフィスから始まった同社のインフラは、16年の歳月を経て世界330以上の都市に広がる巨大なデジタル基盤へと成長している。
この「500 Tbps」という数字は、単なるピーク時のトラフィック量ではない。トランジットプロバイダーやピアリングパートナー、インターネットエクスチェンジ（IX）などと接続された外部ポートの総容量を指している。この膨大な余剰キャパシティこそが、日々発生する大規模なDDoS攻撃を吸収するための「防御予算」として機能しているのだ。
現代のインターネットにおいて、これほどの規模を持つネットワークがどのように構築され、どのように自律的な防御を実現しているのか。最新の技術スタックと、急増するAIトラフィックへの対応策を含めて詳しく紐解いていく。
500 Tbpsの衝撃〜Cloudflareが到達した巨大ネットワークの現在地
Cloudflareのネットワーク容量が500 Tbpsに達したことは、インターネットの歴史における一つの到達点といえる。2010年の設立当初、同社はたった一つのトランジットプロバイダーと契約し、ネームサーバーを2つ書き換えるだけで利用できるリバースプロキシとしてスタートした。それが今や、全ウェブサイトの20％以上を保護する巨大インフラへと変貌を遂げている。
世界330都市以上に広がる物理インフラの重み
「インターネットはクラウドである」と表現されることが多いが、その実体はケーブルとサーバーが詰まった物理的な部屋の集合体だ。Cloudflareはシカゴ、アッシュバーン、サンノゼ、アムステルダム、東京といった主要都市から始まり、カトマンズ、バグダッド、レイキャビクといった地域まで網羅してきた。
データセンターを一つ開設するごとに、コロケーション契約の交渉、光ファイバーの敷設、サーバーのラッキングといった地道な作業が繰り返される。2018年には、わずか24日間で31都市に拠点を展開するという驚異的なスピードで拡張を続けた。この物理的な拠点の多さが、ユーザーに近い場所でコンテンツを配信し、攻撃を水際で食い止めるための鍵となっている。
外部キャパシティ500 Tbpsが意味するもの
500 Tbpsという数字は、すべての外部接続ポートの合計値だ。日常的なトラフィックのピークは、この数字のほんの一部に過ぎない。残りの広大な帯域は、DDoS攻撃が発生した際にその衝撃を和らげるためのバッファとして確保されている。
かつては国家レベルのリソースがなければ対抗できなかったような大規模な攻撃も、この巨大なパイプラインの中では「日常的なイベント」として処理される。ネットワークの規模そのものが、セキュリティにおける最強の武器となっているのだ。
攻撃を呼吸するように受け流す〜31.4 TbpsのDDoSを防ぐ仕組み
2025年、Cloudflareのネットワークは秒間31.4 Tbpsという猛烈なDDoS攻撃を検知し、わずか35秒で完全に無害化した。この攻撃には、感染したAndroid TVなどで構成された「Aisuru-Kimwolf」と呼ばれるボットネットが関与していた。驚くべきは、この規模の攻撃に対してもエンジニアが呼び出されることなく、システムが自律的に対処した点だ。
eBPFとXDPによる超高速パケット処理
この自律的な防御を支えているのが、Linuxカーネル内で動作する「eBPF（extended Berkeley Packet Filter）」と「XDP（eXpress Data Path）」という技術だ。パケットがネットワークカード（NIC）に到着した瞬間、OSの通常のネットワークスタックを通過する前に、XDPプログラムがそのパケットを評価する。
これにより、不正なパケットはCPUサイクルをほとんど消費することなく、入口で即座に破棄される。アプリケーション層に到達する前に処理が終わるため、サーバーの負荷を極限まで抑えることが可能だ。この仕組みを視覚化すると、以下のようになる。
このデモは、パケットがどのように段階を経て処理されるかを示したものだ。XDPレイヤーでのフィルタリングが、後続のシステムをいかに保護しているかがわかる。
自律分散型の防御システム「dosd」
Cloudflareのすべてのサーバーには「dosd」と呼ばれるDDoS対策用のデーモンが常駐している。各サーバーは流入するトラフィックをサンプリングし、異常な通信パターンを検出すると、その情報を同じデータセンター内の全サーバーにブロードキャストする。
データセンター内のすべてのサーバーが同じデータに基づいて判断を下すため、特定のサーバーに負荷が集中することなく、拠点全体で一貫した防御が可能になる。さらに、決定されたルールは同社の分散型キーバリューストア「Quicksilver」を通じて数秒以内に全世界の拠点へ伝播される。これにより、ある拠点で検知された攻撃手法が、瞬時に地球の裏側の拠点でも通用しなくなる仕組みだ。
ネットワーク自体が開発プラットフォームへ〜Edge Computingの進化
ネットワークを保護するためにすべてのサーバーでコードを実行できる環境を整えた結果、そのリソースを顧客に開放するという自然な流れが生まれた。これが「Cloudflare Workers」の始まりだ。現在では、単なるスクリプトの実行にとどまらず、より複雑なワークロードをエッジで動かすことが可能になっている。
WorkersからContainersへ
2025年、CloudflareはWorkersに「Containers」機能を追加した。これにより、V8アイソレートでは難しかった、より重量級のアプリケーションもエッジで動作させることができるようになった。独自のファイルシステムレイヤーにより、コールドスタート（起動時の遅延）を最小限に抑えつつ、ユーザーのすぐそばで計算リソースを提供する。
開発者が書いたコードは、前述のDDoS防御と同じサーバー上で動作する。つまり、攻撃トラフィックがl4dropによって破棄された直後の、クリーンな環境でアプリケーションが実行されるわけだ。インフラのセキュリティとパフォーマンスを同時に享受できるこの構造は、従来の中央集約型クラウドとは一線を画している。
インターネットの信頼性を担保する〜RPKIとASPAの重要性
ネットワークの規模が大きくなるほど、ルーティングの安全性に対する責任も増大する。BGP（Border Gateway Protocol）の脆弱性を突いたルートハイジャックは、インターネットの通信を誤った方向へ誘導し、大規模な障害やセキュリティ侵害を引き起こす原因となる。Cloudflareはこれらのリスクを低減するため、最新のプロトコル採用を強力に推進している。
ルートハイジャックを防ぐRPKI
RPKI（Resource Public Key Infrastructure）は、IPアドレスの所有者が誰であるかを証明するための仕組みだ。Cloudflareは早期からRPKIを導入し、無効なルートからのトラフィックを拒否する設定を徹底している。現在、グローバルなルーティングテーブルのうち、86万7,000件以上のプレフィックスが有効なRPKI証明書を持っており、10年前のほぼゼロに近い状態から劇的に改善された。
パスの正当性を検証するASPA
次に同社が注力しているのが「ASPA（Autonomous System Provider Authorization）」だ。RPKIが「誰が所有しているか」を検証するパスポートチェックだとすれば、ASPAは「どのような経路を通ってきたか」を検証するフライトマニフェスト（搭乗名簿）チェックに相当する。
ASPAが普及すれば、設定ミスによるルート漏洩や、悪意のある経路誘導をより確実に防げるようになる。Cloudflareのような巨大ネットワークが先行して導入することで、インターネット全体のエコシステムを健全な方向へ導く狙いがある。
AIエージェントが変えるトラフィック構造〜4％の衝撃
近年、インターネット上のトラフィックに大きな変化が起きている。人間がブラウザでリンクをクリックして発生する通信に加え、AIクローラーや自律型エージェントによるアクセスが急増しているのだ。現在、Cloudflareのネットワークを流れるHTMLリクエストの4％以上が、AI関連の通信で占められている。
ブラウザとクローラーの挙動の違い
AIクローラーは、人間が操作するブラウザとは根本的に異なる動きを見せる。ブラウザはページを読み込んだ後に一時停止するが、クローラーはリンクされたリソースを最大スループットで、休むことなく次々と取得していく。この挙動は、インフラ側から見るとDDoS攻撃と区別がつきにくい場合がある。
Cloudflareは、正規のAIクローラーと悪意のある攻撃を識別するために、TLSフィンガープリントや行動分析を組み合わせた高度な検知システムを運用している。例えば、ブラウザを装いつつもTLSのライブラリが不自然な構成であれば、それをシグナルとして検出し、サイト所有者が適切な判断を下せるようにデータを提供している。
独自の分析〜500 Tbps時代に企業が備えるべきインフラ戦略
Cloudflareが500 Tbpsという驚異的な容量を確保したことは、一企業のリリースの枠を超えた意味を持っている。これは、インターネットが「物理的な限界」を技術と規模で克服しつつあることを象徴している。しかし、インフラが強力になる一方で、攻撃の質も変化している点には注意が必要だ。
「防御の自動化」が企業の必須条件になる
31.4 Tbpsという攻撃を人間が介在せずに防いだという事実は、もはや「人間がログを見て遮断ルールを書く」という旧来の運用が通用しないフェーズに入ったことを示している。今後の企業インフラには、eBPF/XDPのようなカーネルレベルでの高速処理と、AIを活用した自律的なパターン認識が欠かせなくなるだろう。
エッジシフトとセキュリティの統合
Cloudflareの事例が示すように、これからは「セキュリティ対策」と「アプリケーション実行環境」を切り離して考えるべきではない。攻撃を捨てる場所でコードを動かすという「エッジコンピューティング」の思想は、パフォーマンス向上だけでなく、攻撃の爆風をアプリケーションに届かせない最強の盾となる。企業は、中央集約的なサーバー構成から、分散型のエッジインフラへの移行を真剣に検討すべき時期に来ているといえる。
この記事のポイント
- Cloudflareの外部ネットワーク容量が500 Tbpsの大台を突破した
- eBPFとXDPを活用し、31.4 Tbpsもの巨大DDoS攻撃を自動的に無害化している
- 世界330以上の都市に分散された拠点が、ユーザーに近い場所でセキュリティと計算リソースを提供している
- RPKIやASPAといった次世代プロトコルの導入により、ルーティングの安全性を世界規模で向上させている
- トラフィックの4％を占めるようになったAIクローラーに対し、高度な識別技術で対応している
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflare Gen13サーバーの設計思想 192コアAMD EPYCで2倍のスループットを実現
Cloudflareが第13世代サーバー「Gen13」の設計詳細を公開した。192コアのAMD EPYC Turin 9965プロセッサを搭載し、前世代比で最大2倍のスループットを実現している。
Gen13は768GBのDDR5-6400メモリ、24TBのPCIe 5.0 NVMeストレージ、デュアル100GbEネットワークインターフェースを備える。特に注目すべきは、Rustで書き直された新リクエスト処理層「FL2」への移行により、大容量L3キャッシュへの依存を解消した点だ。これによりコア数を2倍に増やしながら、レイテンシの増加を抑えることに成功した。
この記事では、Cloudflare Blogの記事を基に、Gen13サーバーの各コンポーネント選択の背景と設計思想を解説する。
CPU設計の転換：キャッシュからコアへ
Gen13の最大の特徴は、AMD EPYC Turin 9965プロセッサの採用だ。192コア/384スレッドを備え、前世代のGen12（96コア）からコア数を2倍に増やしている。
L3キャッシュ依存からの脱却
興味深いのは、コア数が2倍になった一方で、コアあたりのL3キャッシュ容量が83.3%減少している点だ。Gen12のAMD EPYC Genoa-X 9684Xはコアあたり12MBのL3キャッシュを持っていたが、Gen13のTurin 9965はコアあたり2MBしかない。
この一見逆行するような選択の背景には、Cloudflareのソフトウェアスタックの根本的な変化がある。Cloudflareはリクエスト処理層をFL1からFL2へ移行した。FL2はRustで書き直された新アーキテクチャで、大容量L3キャッシュへの依存度が大幅に低減されている。
Cloudflare Blogの記事によると、FL2ワークロードはコア数に対してほぼ線形にスケールする特性を持つ。このため、コア数を増やすことが直接的なスループット向上につながる。L3キャッシュ容量の減少による潜在的なパフォーマンス低下は、FL2の効率的なメモリ使用によって相殺された。
3つの候補から9965を選んだ理由
Cloudflareのエンジニアチームは、Gen13のCPU候補として3つのAMD Turinプロセッサを評価した。128コアの9755、160コアの9845、そして192コアの9965だ。
評価の結果、9965が選ばれた理由は明確だ。生産環境でのテストにおいて、9965の192コアは最高の総合リクエスト処理性能を示した。さらに、500WのTDP（熱設計電力）における性能/ワット効率も優れており、ラックレベルでの総所有コスト（TCO）が最も低くなると判断された。
運用面でも、192コアという高密度構成はメリットがある。同じ計算能力を提供するために必要なサーバー台数が減るため、プロビジョニング、パッチ適用、監視にかかる運用オーバーヘッドを削減できる。
メモリとストレージの拡張
12チャネルDDR5-6400で帯域幅33%向上
CPUコア数が2倍になったことで、メモリサブシステムにもより高い要求が課せられた。Gen13は12個のDDR5-6400メモリチャネルすべてを活用する構成を採用している。
各チャネルに64GB DIMMを1枚ずつ配置する「1DIMM per channel」構成で、合計768GBのメモリ容量を実現。ピークメモリ帯域幅はソケットあたり614GB/sに達し、Gen12から33.3%向上した。
すべてのチャネルを均等に使用する構成は、メモリインターリーブの観点から重要だ。AMD Turinプロセッサは、同じDIMMタイプ、同じ容量、同じランク構成のメモリチャネル間でインターリーブを行う。インターリーブにより、連続したメモリアクセスが単一のチャネルではなくすべてのチャネルに分散され、実効的なメモリ帯域幅が向上する。
コアあたり4GBの「適正容量」を維持
メモリ容量の決定において、Cloudflareは「コアあたり4GB」という比率を維持することを選択した。Gen12でも同じ比率が採用されており、実績のあるバランスだ。
設計初期には、コアあたり4GBから6GBの範囲が検討された。192コアの場合、768GBから1152GBに相当する。実際のDIMM容量の粒度を考慮すると、選択肢は12x48GB（576GB）、12x64GB（768GB）、12x96GB（1152GB）の3つだった。
12x48GB構成は容量が不足し、メモリを多く消費するワークロードを飢餓状態にするリスクがある。一方、12x96GB構成はコアあたり50%の容量増加となるが、電力消費の増加とコストの大幅な上昇（現在のメモリ価格は1年前の10倍）が問題だ。
12x64GBの768GB構成は、コアあたり4GBという実績のある比率を維持しつつ、サーバーあたりの総容量をGen12の2倍に拡大する。FL2はFL1と比べてメモリ使用効率が大幅に向上しており、ソフトウェアスタックの移行によって生じた余剰容量が、今後数年間のCloudflareの成長を支えるヘッドルームとなる。
ストレージ：PCIe 5.0と容量50%増
ストレージサブシステムも大幅に強化された。Gen13はPCIe Gen 5.0 NVMeドライブを採用し、レイテンシの改善と増大するストレージ帯域幅要求に対応する。
物理的なストレージ容量も、3台のNVMeドライブにより24TBに拡張された。Gen12サーバーは4つのE1.Sストレージスロットを備えていたが、実際に使用されていたのは2スロットのみだった。Gen13では同じ4スロット設計を維持しつつ、3スロットに8TBドライブを実装している。
3台目のドライブ追加により、サーバーあたりのストレージ容量は16TBから24TBへ50%増加した。これはCDNキャッシュ性能の維持・向上に加え、Durable Objects、Containers、Quicksilverサービスなどの成長予測を支えるためだ。
さらにGen13シャーシには、最大10台のU.2 PCIe Gen 5.0 NVMeドライブを収容できるフロントドライブベイが追加された。この設計により、同じシャーシをコンピュートプラットフォームとストレージプラットフォームの両方で使用できる柔軟性が生まれる。必要に応じてコンピュートSKUをストレージSKUに変換することも可能だ。
ネットワークと電源の刷新
8年ぶりのネットワークアップグレード：25GbEから100GbEへ
Gen13で最も大きな変化の一つが、ネットワークインターフェースの刷新だ。8年以上にわたりCloudflareフリートの基盤となってきたデュアル25GbEから、デュアル100GbEへと移行する。
この変更の必要性は明白だ。192コアという高性能CPUがより多くのリクエストを処理できるようになると、ネットワーク帯域幅がボトルネックになる。実際、世界中のコロケーション施設から収集した1週間分の本番データによると、Gen12ではポートあたりのP95帯域幅が利用可能帯域幅の50%を一貫して超えていた。
Gen13ではサーバーあたりのスループットが2倍になるため、NIC帯域幅が飽和するリスクが高まる。100GbEへの移行は、このボトルネックを解消するための必然的な選択だ。
50GbEではなく100GbEを選んだ理由は、産業界の経済性にある。50GbEトランシーバーの市場規模は依然として小さく、サプライチェーン上のリスクが高い。デュアル100GbEポートによりサーバーあたり200Gb/sの集約帯域幅を実現し、今後数年間のトラフィック成長に対応できる将来性も確保した。
電源：800Wから1300Wへ拡張
コンピュート能力とネットワーク能力の向上に伴い、サーバーの電力エンベロープも自然に拡大した。Gen13は必要な電力を供給するため、より大型の電源装置を搭載する。
Gen12ノードは800W 80 PLUS Titanium CRPS（共通冗長電源装置）で十分に動作していたが、Gen13では1300W 80 PLUS Titanium CRPSを選択した。
Gen13の通常動作時の電力消費は850Wに達する。Gen12の600Wから250Wの増加だ。主な要因は、TDPが400Wから500Wに上がったCPU、メモリ容量の2倍化、追加のNVMeドライブである。
1000Wではなく1300Wを選んだ理由は、現在のPSUエコシステムに1000Wの高効率オプションがほとんどないためだ。サプライチェーンの信頼性を確保するために、産業界標準の次の階層である1300Wに移行した。
EU Lot 9規制は、欧州連合に展開するサーバーが、負荷10%、20%、50%、100%において規制で指定された効率率閾値を満たす電源装置を備えることを要求する。この閾値は80 PLUS Power Supply認証プログラムのチタニウムグレードPSU要件と一致する。Gen13ではEU Lot 9に完全準拠するためチタニウムグレードPSUを選択し、欧州のデータセンターをはじめとする全世界での展開を可能にした。
セキュリティと管理の継続性
Project Argus DC-SCM 2.0の継承
Gen13では、Gen12で導入された管理機能とセキュリティ関連コンポーネントをマザーボードから分離するアーキテクチャを維持する。これらは「Project Argus」データセンターセキュアコントロールモジュール2.0（DC-SCM 2.0）に集約されている。
DC-SCMモジュールには、サーバーのセキュリティの中枢となる重要なコンポーネントが収められている。
- 基本入出力システム（BIOS）
- ベースボード管理コントローラ（BMC）
- ハードウェアルートオブトラスト（HRoT）とTPM
- 冗長性のためのデュアルBMC/BIOSフラッシュチップ
このアーキテクチャをGen13でも継続する決定は、前世代で実証されたセキュリティ上の利点に基づく。管理機能を専用モジュールにオフロードすることで、以下のメリットを維持できる。
迅速な回復機能は、デュアルイメージ冗長性により、偶発的な破損や悪意のある更新が検出された場合にBIOS/UEFIおよびBMCファームウェアをほぼ瞬時に復元できる。
物理的耐性については、Gen13シャーシでは侵入検知メカニズムをシャーシの平坦な端からさらに遠ざけ、物理的な傍受を難しくしている。
PCIe暗号化は、Gen10プラットフォームから有効化されていたCPUとメモリ間の暗号化（TSME）に加え、AMD Turin 9965プロセッサがPCIeトラフィックにも暗号化を拡張する。これにより、システム内のすべてのバスを通過するデータが転送中も保護される。
運用的一貫性も重要だ。Gen12管理スタックを維持することで、セキュリティ監査、展開、プロビジョニング、運用標準手順が完全に互換性を保つ。
ドロップインアクセラレータサポートの強化
フリートのモジュール性維持は、Cloudflareのサーバー設計における中核的な要件だ。この要件により、Cloudflareは2024年にGPUを世界中の100以上の都市に迅速に改造・展開できた。
Gen13では、高性能PCIeアドインカードのサポートを継続する。Gen13の2Uシャーシレイアウトは更新され、より要求の厳しい電力と熱要件をサポートするように構成されている。Gen12がシングル幅GPU1枚に制限されていたのに対し、Gen13アーキテクチャはダブル幅PCIeカード2枚をサポートする。
この記事のポイント
- Cloudflare Gen13サーバーは192コアAMD EPYC Turin 9965を採用し、前世代比最大2倍のスループットを実現
- FL2（Rust製新リクエスト処理層）への移行により、大容量L3キャッシュへの依存を解消。コア数増加による性能向上を可能にした
- メモリは12チャネルDDR5-6400構成で768GBを実装。帯域幅33%向上とコアあたり4GBの適正容量を維持
- ネットワークは8年ぶりに刷新。デュアル25GbEからデュアル100GbEへ移行し、帯域幅ボトルネックを解消
- セキュリティはProject Argus DC-SCM 2.0アーキテクチャを継承。PCIe暗号化を追加し、データ転送中の保護を強化
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Kubernetesの1行修正で年600時間を削減——Cloudflareが直面したPVマウントの罠
Kubernetesの設定ファイルをたった1行書き換えるだけで、年間600時間ものエンジニア工数を削減した事例がある。Cloudflare（クラウドフレア）のインフラチームが直面したこの問題は、システムの規模が拡大するにつれて静かに忍び寄る「デフォルト設定の罠」を浮き彫りにした。
原因は、ストレージの権限管理を行うKubernetesの標準的な振る舞いにあった。数百万ものファイルを抱えるボリュームにおいて、再起動のたびに30分ものダウンタイムが発生していた事態を、彼らはどのように特定し、解決したのだろうか。
本記事では、CloudflareのエンジニアであるBraxton Schafer氏が公開したデバッグの過程と、大規模なKubernetes運用において見落としがちなパフォーマンスのボトルネックについて詳しく解説する。
Atlantisの再起動がなぜか「30分」もかかる謎
Cloudflareでは、Terraform（テラフォーム）によるインフラ管理の自動化ツールとして「Atlantis（アトランティス）」を利用している。Terraformはコードでインフラを定義するツールだが、Atlantisを導入することで、GitHubやGitLabのプルリクエスト上で実行計画（Plan）の確認や適用（Apply）が可能になる。
AtlantisはKubernetes上で「StatefulSet（ステートフルセット）」として動作しており、リポジトリの状態を保持するためにPV（Persistent Volume / 永続ボリューム）を使用している。StatefulSetとは、Pod（ポッド）の再起動後もデータの永続性を保証するための仕組みだ。
頻繁な再起動がエンジニアの時間を奪う
問題は、このAtlantisを再起動するたびに発生していた。新しいプロジェクトの設定を読み込ませたり、認証情報を更新したりするために、Cloudflareでは月に約100回ほどの再起動を行っていた。しかし、再起動を開始してからPodが正常に立ち上がるまで、毎回30分もの時間がかかっていたという。
この間、エンジニアはインフラの変更を行うことができず、作業が完全にブロックされてしまう。月100回の再起動で毎回30分待機が発生すれば、月間で50時間、年間では600時間もの時間が「ただの待ち時間」として消えていく計算だ。これは、一人のエンジニアが数ヶ月間フルタイムで働く時間に匹敵する大きな損失である。
「inode不足」がきっかけで表面化した問題
この遅延が決定的な問題として認識されたのは、ストレージの「inode（アイノード）」が枯渇した際だった。inodeとは、ファイルシステム上でファイルやディレクトリの情報を管理するためのデータ構造だ。ファイルが大量に作成されると、ディスク容量が残っていてもinodeが足りなくなり、新しいファイルが作成できなくなる。
Cloudflareの環境では、ファイルシステムを拡張することでしかinodeを増やせない仕様だった。拡張を反映させるにはPodの再起動が必要となり、そのたびに30分のダウンタイムが発生する。チームは当初、アラートの通知設定を調整して「見かけ上の問題」を回避することも検討したが、根本的な原因の調査に乗り出すことを決めた。
Kubernetesのログを深掘りして見えてきたボトルネック
調査を開始したBraxton Schafer氏は、まずkubectl rollout restartコマンドを実行し、新しいPodが立ち上がる様子を観察した。Pod自体はすぐにスケジュールされるものの、ステータスが「Init（初期化中）」のまま30分間も停止していることが判明した。
Podのイベントログを確認しても、イメージのプルが開始されるまでに不可解な空白時間があることしかわからなかった。そこで氏は、より低レイヤーのログを確認するため、各ノードで動作するコンポーネント「kubelet（クブレット）」のログを調査した。
kubeletのログに隠された「空白の時間」
kubeletは、各ノードでPodの実行を管理し、ボリュームのマウントなどを制御する重要なエージェントだ。システム管理ツールであるKibana（キバナ）を使ってログを分析したところ、PVのマウント自体は成功しているものの、その直後にタイムアウトエラーが発生し、リトライを繰り返している様子が記録されていた。
ログには「context deadline exceeded（処理時間の制限を超過した）」というメッセージが並んでいた。何らかの処理が異常に時間を要しており、Kubernetesの監視機構がそれを「失敗」とみなして処理を中断、再試行するというループに陥っていたのだ。
数百万個のファイルが引き起こす権限変更の罠
さらに詳細なログを追うと、決定的なメッセージが見つかった。そこには「Setting volume ownership（ボリュームの所有権を設定中）」という記述があった。実はこれが、30分もの時間を浪費させていた真犯人だった。
Kubernetesには、Pod内のプロセスがボリュームにアクセスできるように、マウント時に所有権を自動で調整する機能がある。具体的には、PodのsecurityContextで指定されたfsGroupのIDに合わせて、ボリューム内の全ファイルに対して再帰的にchgrp（グループ変更）を実行する。Atlantisのようなツールは運用期間が長くなるほど管理するファイル数が増大し、Cloudflareの環境では数百万個ものファイルが蓄積されていた。高速なストレージであっても、数百万個のファイルに対して一つずつ権限を確認・変更していく処理には膨大な時間がかかるのは必然だ。
わずか1行の修正でパフォーマンスが劇的に改善
原因が「再帰的な権限変更」であると特定できれば、解決策は非常にシンプルだった。Kubernetes 1.20以降、この振る舞いを制御するための新しい設定項目が追加されている。それがfsGroupChangePolicy（エフエスグループ・チェンジ・ポリシー）だ。
デフォルトでは、このポリシーはAlways（常に実行）に設定されている。つまり、Podが起動するたびに、すでに権限が正しく設定されていようがいまいが、すべてのファイルをスキャンして権限を上書きしようとする。これが大規模なボリュームにおいて致命的な遅延を引き起こす。
fsGroupChangePolicyの設定とは
解決策は、このポリシーをOnRootMismatch（ルートディレクトリが不一致の場合のみ実行）に変更することだ。この設定にすると、Kubernetesはまずボリュームのルートディレクトリの権限を確認する。もしルートの権限がすでに正しく設定されていれば、配下のファイルに対する再帰的なスキャンをスキップする。
spec:
template:
spec:
securityContext:
fsGroupChangePolicy: OnRootMismatchこの1行をマニフェストファイルに追加するだけで、権限変更のプロセスが大幅に簡略化される。Cloudflareのケースでは、これまで30分かかっていた再起動時間が、わずか30秒にまで短縮された。実に60倍の高速化だ。
30分から30秒へ、驚異的な短縮効果
この修正により、エンジニアがデプロイの待ち時間に拘束されることがなくなった。また、再起動が長引くことによって発生していた「Podが正常に起動しない」という偽のアラートに、オンコール担当者が夜中に叩き起こされることもなくなったという。技術的には極めて単純な変更だが、組織全体の生産性に与えたインパクトは計り知れない。
大規模システムにおける「デフォルト設定」の落とし穴
今回の事例から学べる最も重要な教訓は、Kubernetesの「安全なデフォルト設定」が、規模の拡大とともに牙を向く可能性があるということだ。fsGroupによる自動的な権限変更は、初心者が権限エラーに悩まされないようにするための親切な機能として設計されている。
しかし、エンタープライズレベルの運用において、数テラバイトのデータや数百万のファイルを扱うようになると、その「親切心」がシステムの可用性を損なう要因へと変わる。これは、小規模なプロジェクトでは決して表面化しない問題だ。
小規模なら問題ないが、スケールするとボトルネックになる
多くのインフラエンジニアは、マウントが遅い場合にネットワークやストレージ装置の性能を疑う。しかし、今回のケースのように「OSレベルのファイル操作」がバックグラウンドで走っていることに気づくには、深いオブザーバビリティ（観測性）が必要だ。Braxton Schafer氏が、Kubernetesのイベントログだけでなく、kubeletのシステムログまで掘り下げたことが早期解決の鍵となった。
SRE的視点での教訓
SRE（Site Reliability Engineering / サイト信頼性エンジニアリング）の観点では、「なぜシステムはこのように振る舞うのか？」という問いを持ち続けることの重要性が再確認された。30分の待ち時間を「そういうものだ」と受け入れてしまえば、年間600時間の損失は永遠に解消されなかっただろう。
もし読者の環境でも、特定のPodの起動が異常に遅かったり、ボリュームをマウントする際にInitコンテナで止まっていたりする場合は、securityContextの設定を見直してみる価値がある。特に、大量の静的ファイルを保持するCMSや、データベースのバックアップファイルを扱うPodなどは、同様の問題を抱えている可能性が高い。
この記事のポイント
- 原因の特定: Atlantisの再起動に30分かかっていたのは、Kubernetesがマウント時に全ファイルの所有権を再帰的に変更していたため。
- 1行の修正:
fsGroupChangePolicy: OnRootMismatchを設定することで、不要な権限変更をスキップできる。 - 劇的な改善: Cloudflareはこの修正により、再起動時間を30分から30秒に短縮し、年間600時間の工数を削減した。
- 教訓: 安全のためのデフォルト設定が、大規模環境では深刻なパフォーマンス低下を招くことがある。
- 推奨アクション: 大容量PVを使用するPodでは、
securityContextの設定を監査し、不必要な再帰処理を避ける設定を検討すべきだ。
出典
- Cloudflare Blog「A one-line Kubernetes fix that saved 600 hours a year」（2026年3月26日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験