Cloud

概要 Google Kubernetes Engine(GKE)は10月16日、Standard CPUノードプールにおけるインプレースアップグレードの提供を発表した。従来、GKEのノードアップグレードはCompute Engine VMを削除して新規VMを作成する方式が基本だったが、新方式では既存のVMをそのまま更新する。これにより、アップグレード中もノードの計算容量が維持され、VM再作成に伴うアップグレードの失敗やノードのスタール(停止)、リソース不足によるトラブルのリスクを低減できる。 技術的な詳細 インプレースアップグレードは、ノードプールの「surge upgrade」設定においてmaxUnavailableフィールドを0より大きい値に設定することで有効になる。これはすべてのGKEバージョンに適用される変更で、ユーザー側で新たな機能フラグを明示的に有効化する操作は不要とみられる。対象はStandard CPUノードプールであり、GPUやTPUを利用するノードプールについては今回のリリースノートでは言及されていない。 従来のVM削除・再作成方式では、アップグレードのたびにインスタンスがゾーンのリソース在庫に依存して再スケジュールされるため、ゾーンのキャパシティ不足時にアップグレードが失敗したり、ノードの入れ替えが完了しないままクラスタの処理能力が一時的に低下したりするケースがあった。インプレース方式はVMそのものを維持するため、こうしたキャパシティ依存のリスクを構造的に回避できる点が特徴だ。 影響と展望 この挙動変更を望まないユーザー向けには、Cloud Customer Careへ連絡することでオプトアウトできる経路も用意されている。大規模クラスタやリソースが逼迫しがちなリージョンを運用するチームにとっては、アップグレード時の容量確保の不確実性が減ることで、メンテナンスウィンドウの計画や自動アップグレードポリシーの運用がより安定しやすくなりそうだ。GPU/TPUノードプールへの対応拡大や、今回の変更に伴う挙動の違いについては、今後のリリースノートの更新を注視する必要がある。

概要 PostgreSQLコミュニティは10月15日、メジャーバージョン19の最初のリリース候補(RC1)を公開した。正式リリース(GA)は11月19日に予定されており、その前に11月12日には定例の更新リリースに合わせてRC2もリリースされる計画だ。同日、Amazon RDSの「Database Preview Environment」でもPostgreSQL 19 RC1が利用可能になり、ユーザーは本番導入前にUS East (Ohio)リージョンで新バージョンの動作を事前検証できるようになった。世界で広く使われるオープンソースデータベースの次期メジャーリリースが、着実に最終段階へと進んでいることを示す節目といえる。 RC1での主な修正点 Beta 4以降、RC1では複数の不具合修正が加えられている。テーブルやインデックスを再構築するREPACK (CONCURRENTLY)、クエリ実行計画のヒント機能であるpg_plan_adviceに関する修正のほか、NULL式の扱いに関するクエリプランナの最適化も行われた。論理レプリケーションでは、wal_levelがreplicaに設定されている場合の自動有効化に関する修正が入っている。また、postgres_fdwの統計情報収集が、従来のANALYZE実行ユーザーではなく外部テーブルの所有者権限で実行されるよう変更された。並列autovacuumについても複数の修正が加えられ、AWSの発表でも「複雑なテキスト検索式のエラー処理の改善」「並列autovacuumの堅牢化」「GINインデックスメンテナンスの信頼性向上」が安定性強化のポイントとして挙げられている。細かな変更点として、COPY (query) TO ... (FORMAT json)でJSON出力する際のキー名が、テーブルの列名ではなくクエリ側の列名・エイリアスを使用するようになった点も実務上の影響が大きい。 検証方法とAmazon RDSでの提供 PostgreSQLコミュニティはRC1の実機検証を呼びかけており、公式ダウンロードページから入手できるほか、不具合はバグ報告フォームから報告できる。リリース告知自体への訂正提案はpgsql-wwwメーリングリストで受け付けている。未解決の課題は「PostgreSQL 19 Open Items」のWikiページで追跡されている。アップグレードにはpg_upgradeまたはpg_dump/pg_restoreによるメジャーバージョンアップグレード手順を用いる。 一方、AWSはAmazon RDS Database Preview Environment経由でRC1を提供し、通常のRDS for PostgreSQLと同料金で試用できるようにした。ただしプレビュー環境のDBインスタンスは最大60日間で自動削除され、作成したスナップショットもプレビュー環境内でのみ利用可能という制約がある。データを環境外に持ち出す場合はPostgreSQLのダンプ・ロード機能を使う必要がある。 今後の見通し RC2が11月12日、GAが11月19日とスケジュールが明示されたことで、PostgreSQL 19は最終準備段階に入ったことが明確になった。クラウド各社がGA前からプレビュー環境を用意し始めている点は、ユーザー企業にとって本番移行前の検証期間を確保しやすくなるという意味で歓迎される動きだ。今後RC2までに追加の修正が入る可能性もあるため、本番導入を検討しているユーザーはOpen Itemsページや公式アナウンスを継続的にチェックしておくとよいだろう。

概要 Microsoftは10月15日、AIエージェント時代に向けたクラウドネイティブ基盤の進化について発表した。従来のワークフロー型システムとは異なり、自律的に判断し動作するエージェント型アプリケーションを支えるには、コンピュート・ストレージ・ネットワーキングを一体として連携させる基盤が不可欠だとし、Azure Kubernetes Service(AKS)向けの新機能「Flex Nodes」、運用自動化を担う「Azure SRE Agent」、Azure Container Appsの分離実行環境「Sandboxes」、デプロイを簡素化する「Azure Container Apps Express」など複数の新機能を投入した。AIワークロードは作業の内容によって求める資源特性が大きく異なり、アクセラレータ、CPU、高速なデータアクセス、アプリケーション間接続性を柔軟に組み合わせる必要があるとMicrosoftは説明している。 Kubernetesがエージェント基盤の中心に Microsoftは、Gartnerの予測として2028年までに新たに展開されるAIエージェントの95%がKubernetes上で稼働するとの見通しを引用し、AKSの進化がAIエージェント基盤にとって重要な位置を占めるとしている。今回追加された「Flex Nodes」は、オンプレミスや他リージョン、エッジ環境のコンピュートリソースをAKSクラスタのノードプールとして組み込み、容量制約やデータレジデンシー要件に対応できるようにする機能だ。あわせて発表された「Azure SRE Agent」は、従来は分断されていた運用システム間をインテリジェンスでつなぎ、問題の予兆を捉えて環境のパフォーマンスを改善することを目指す。Microsoftは、エージェントAIを組み込んだクラウドネイティブ運用によって、チームが事後対応型の問題解決から予兆管理型の運用へ移行しつつ、重要な意思決定については人間が責任を持つ体制を維持しながら自動化を進められると位置づけている。 分離実行環境とコスト最適化 Azure Container Appsに追加された「Sandboxes」は、AIエージェントが外部から渡されたコードや生成したコードを実行する際に、安全に分離された実行環境を提供する機能だ。エージェントは信頼できない入力に基づいて動的にコードを生成・実行する場面が多く、こうした分離環境の重要性が増している。また「Azure Container Apps Express」はアプリケーションのデプロイ工程を簡素化し、開発者がより迅速にAIワークロードを本番環境へ展開できるようにする。Microsoftはこれらの基盤整備と並行して、AIへの投資対効果を事業成果と結び付けて評価するFinOpsの考え方の重要性も強調しており、モデルの利用コストとプラットフォームコストを合わせて管理し、得られた成果の証拠に基づいて最適化判断を行うべきだとしている。 導入事例と今後の展望 実際の活用例として、生命科学スタートアップのBasecamp Researchが紹介されている。共同創業者のGlen Gowers氏は「データをスケールさせる役割は我々が担うが、モデルとコンピュートを本当にスケールさせる方法を知っているのはMicrosoftだ」と述べ、コンピュート・ストレージ・ネットワーキングが一体となった基盤の必要性を強調した。同社は治療薬設計モデルのために9.7兆個のヌクレオチド配列を集約し、Azureの統合的な基盤を活用することで、3つの治療応用分野にわたる検証結果を約3週間という短期間で実験室レベルで得たという。Microsoftはこうした事例を通じて、AIエージェントの普及に合わせてクラウドネイティブ基盤そのものを継続的に進化させていく方針を示している。

概要 Google DeepMindとGoogle Cloudは10月14日、欧州の研究イニシアチブ「RAISE」を通じて、欧州の科学研究者最大200名にフロンティアAIモデルへの直接アクセスと合計300万ドル相当のコンピュートクレジットを提供する取り組みを発表した。提供対象には、タンパク質の構造予測モデル「AlphaFold 3」、気象予測モデル「WeatherNext」、ゲノム解析モデル「AlphaGenome」に加え、アルゴリズム発見モデル「AlphaEvolve」、地球観測モデル「AlphaEarth Foundations」が含まれる。Googleはこの取り組みの目的を「欧州のイノベーションのペースを加速させる」こと、そして「欧州の科学的競争力」を維持することにあると説明している。 提供されるモデルと狙い 今回アクセスが提供される5つのモデルは、いずれもGoogle DeepMindが科学研究向けに開発してきたフロンティアAIの中核をなすものだ。AlphaFold 3はタンパク質や分子の立体構造予測、WeatherNextは extreme weather(異常気象)を含む気象予測、AlphaGenomeはゲノム配列の機能解析、AlphaEvolveはアルゴリズムの自動発見、AlphaEarth Foundationsは地球観測データの解析をそれぞれ担う。Googleは、これらのモデルを研究者が直接利用できるようにすることで、「異常気象パターンの予測から分子構造のマッピングまで、複雑な課題により速く取り組める」と述べている。ただし、研究者の具体的な選定基準や応募方法、300万ドル分のコンピュートクレジットの配分方法といった運用面の詳細は、現時点では明らかにされていない。 欧州のAI研究エコシステムとの関係 この発表は、欧州においてAI研究基盤への投資や独自のAI研究機関設立の動きが相次ぐ中で行われた。元Google DeepMindの研究者らが設立した欧州のAI研究機関では、Ineffable Intelligenceが11億ドル規模のシード資金を獲得し、Inherentも5,000万ドルを調達するなど、欧州発のAI研究への機運が高まっている。こうした流れの中で、Googleが自社のフロンティアモデルとコンピュート資源を欧州の研究者に開放する動きは、米国の大手テック企業が主導するAI基盤と、欧州独自で育成しようとするAI研究エコシステムとの関係性にも影響を与える可能性がある。今後、RAISEを通じた具体的な研究成果や、対象研究者の選定プロセスの詳細が明らかになるかが注目される。

概要 Microsoftは10月13日、サンノゼで開催されたOCP Global Summitにおいて、MarvellおよびOracle、Open Compute Project(OCP)と共同で「Project Tessera」を発表した。これはAzureサーバーに組み込まれている統合ハードウェアセキュリティモジュール(HSM)のアーキテクチャ、仕様、プロトコル、ドライバ、ソフトウェア、ファームウェア、さらには再現可能なビルド環境までを完全にオープンソース化する取り組みである。3社はOCPのSecurity Track傘下に新たなワーキンググループを設立し、NIST FIPS 140-3 Level 3準拠を目標とする統合HSMの業界標準仕様の策定に着手した。仕様の初版はOCP Global Summit(10月12〜15日)で公開され、バージョン1.0はこの後に発表される予定で、関連する仕様・ソフトウェア・ファームウェアはGitHubの「TesseraHSM」リポジトリで公開されている。 統合HSMが解決する課題 従来のクラウドおよびハイパースケールデータセンターでは、ネットワーク接続型のHSM、あるいはソフトウェアのみによる鍵管理に依存するのが一般的だった。この方式では暗号鍵がネットワークを経由して移動したり、保護されていないメモリ上に存在したりするリスクが避けられない。Project Tesseraが採用する「ワークロード・アタッチド」型の統合HSMは、暗号処理をデータが実際に処理される場所の近くで実行しつつ、鍵自体はハードウェアのセキュリティ境界内に留め続ける設計を取る。これによりサーバーレベルでの安全な鍵キャッシングとライフサイクル管理が可能になり、ネットワーク遅延の削減とスケーラビリティの向上も見込めるという。展開モデルとしては、最大限の保証を提供する専用ハードウェア型のほか、AMD SEV-SNP環境上でユニカーネル型ファームウェアを動かす機密コンピューティング型、専用HSMを持たないシステムにも保護を拡張する仮想化型の3種類が想定されている。 標準化の狙いと技術実証 この取り組みの背景には、AIによる攻撃で脆弱性発見から悪用までの時間が急速に短縮されていることと、将来の量子コンピュータが既存の暗号方式を無効化しうるという2つの脅威への備えがある。MicrosoftのCTOであるMark Russinovich氏は、「AIと量子技術の進展により、デジタルインフラの中核である鍵と認証情報を守ることがこれまで以上に重要になっている」と述べた。MarvellのシニアバイスプレジデントであるCary Ussery氏も、統合HSMによって暗号鍵操作をワークロードの実行箇所そのもので行えるようにし、この機能を業界全体に提供すると説明している。実証として、MicrosoftとMarvellはTesseraと同社のLiquidSecurity 2との間でHSMパーティションのクローニングを行い、異なるベンダーのHSMがポスト量子暗号プロトコルを用いて単一のセキュリティドメイン内で相互運用できることを示した。 今後の見通し Project Tesseraは、ゼロトラストアーキテクチャの要件や各種規制コンプライアンスに対応しながら、業界全体でのポスト量子暗号移行を後押しすることを目指している。仕様やファームウェアが完全にオープンソース化されることで、特定ベンダーに依存しないハードウェア鍵管理の実装がデータセンター事業者やハードウェアベンダーに広がる可能性がある。OCPでの標準化作業は今後も継続し、バージョン1.0仕様の発表に向けてMicrosoft、Marvell、Oracleを中心とするワーキンググループでの議論が進められる見通しだ。

概要 AWSは10月12日、「AWS Lambda Web Functions」の一般提供(GA)を開始した。これはExpress、Hono、Fastify、Next.jsなど、ポートをリッスンする標準的なNode.jsのHTTPフレームワークを、コード変更やアダプター層を介さずそのままLambda上にデプロイできる新しいサーバーレスのコンピュートフォームファクターだ。従来のイベントハンドラ形式の「Lambda Event Functions」や、新しい「Lambda MicroVMs」と並ぶ選択肢として位置づけられており、サーバーレス環境でもこれまでのWebアプリケーション開発の体験を損なわずに済む点が特徴となる。デプロイはaws lambda-web deploy --name my-web-app --code ./my-appという単一のCLIコマンドで完結し、ソースコードのバンドル、関数の作成、リビジョンの発行、エンドポイントの割り当てまでを自動化し、おおむね1分以内に完了する。 スケーリングと課金の仕組み Web Functionsの大きな特徴は、1つの実行環境が最大128件の同時リクエストを処理できる点にある。これにより、トラフィックのバーストに対して都度新しい実行環境を立ち上げるのではなく、ウォームな環境を複数リクエストで共有できるようになる。また複数リージョンへのデプロイも単一コマンドで行え、LambdaがグローバルURLを通じて最も低レイテンシーなリージョンへベストエフォートでルーティングする、レイテンシーベースのルーティングも自動で設定される。課金面では「アクティブCPU課金」という新しいモデルを採用し、アプリケーションコードが実際に消費したCPU時間のみを計測する。データベースへの問い合わせや外部API呼び出しなどI/O待ちの時間はほとんどCPUを消費しないため、I/O負荷の高いワークロードではコスト削減につながる可能性がある。現時点での提供リージョンは米国東部(バージニア北部・オハイオ)、米国西部(オレゴン)、アジアパシフィック(東京)、欧州(アイルランド)の5リージョンで、ランタイムはNode.js 24、アーキテクチャはArm64となっている。 東京リージョンでの検証結果 Classmethodによる検証では、東京リージョン(ap-northeast-1)でExpressアプリケーションを実際にデプロイし、変換アダプターを使わずに直接動作することを確認している。aws lambda-web deployコマンドによるhello-worldサンプルおよびカスタムExpressアプリのデプロイは、いずれも24〜26秒程度で完了し、公開URLが即座に発行された。HTTPリクエストは正しいヘッダーとともに適切なレスポンスを返し、Server-Sent Events(SSE)でも約1秒間隔(実測993〜1002ms)で安定した配信が確認できたという。東京リージョンの料金は、リクエスト数が100万件あたり0.30ドル、アクティブvCPUが1vCPU秒あたり0.0000322421ドル、メモリが1GB秒あたり0.0000042688ドルで、従来のLambdaがメモリとCPUをまとめて課金するのに対し、Web FunctionsはアクティブなCPU時間のみを課金対象とする点が異なる。 今後の展望 AWSはWeb Functionsについて「アダプターも不要、インフラ管理も不要、フレームワークのロックインもない」と説明しており、グローバルな利用者にサービスを提供する際に複数のインフラ構成要素を組み合わせたり、Lambdaの制約に合わせてコードを書き換えたりする複雑さを解消することを狙いとしている。想定される用途としてはサーバーサイドレンダリング、APIバックエンド、AI推論エンドポイントなどが挙げられている。一方でClassmethodの検証者は、リクエスト頻度が高いワークロードでは実行環境の効率が向上するものの、コールドスタートが問題にならないようなアクセス頻度の低いシナリオでは、従来型のLambdaの方がコスト面で有利な場合があると指摘しており、ワークロードの特性に応じた選択が今後の実運用における検討点になりそうだ。

概要 Microsoftは10月12日、自社開発AIアクセラレータの第3世代となる「Azure Maia 300」を発表した。2027年に本番展開を開始し、データセンターでマルチギガワット規模の大規模展開を計画しているという。同社はMaiaファミリーをMicrosoft製品・サービス全体における主要な推論ハードウェアと位置づけており、2023年から進めてきたシリコンの内製化戦略を次の段階へと進める発表となった。現行世代のMaia 200は既に米国・欧州・オーストラリアのデータセンターでMicrosoft Copilotの本番環境を支えており、GitHub CopilotとMicrosoft Foundryについても2026年内の対応開始を予定している、GPUシステム比で1ワットあたり1.7倍のトークン処理を実現しているとされる。Maia 300はこの効率をさらに引き上げ、GPUシステムに対して1メガワットあたり約40%多いトークンを処理できるとしている。 技術的な詳細 Maia 300はTSMCのN2Pプロセスで製造されるチップレット設計を採用し、演算チップレット・メモリコントローラー・I/O機能を分離することで効率性・拡張性・コスト構造を改善している。メモリ面では8スタックのHBM4を搭載し、ピークメモリ帯域幅は18.0TB/sに達する。消費電力(TDP)はMaia 200から200ワット増の950ワットとなった。推論コンテキスト長を拡大するためMXFP4などの低精度フォーマットへの対応を強化し、KVキャッシュのメモリ消費を抑える設計も特徴だ。ラック構成では96基のアクセラレータを搭載し、ラック全体の消費電力は167キロワット、集約HBM容量は27.6TB、集約帯域幅は1.7PB/sに達するという。Microsoftはアクセラレータ同士を自社開発のEthernetベースAI伝送プロトコルで接続し、単一ラックから1万2,000基超のアクセラレータを擁する「スーパーポッド」規模まで一貫した計算・メモリ資源を提供できる点を強調している。 性能面では、ラックスケールのトークンスループットが前世代Maia 200比で最大7倍に達するとされ、計算能力自体も36%向上したとの報道がある。Microsoftは「大規模推論システムにおいては、生の計算能力よりもデータを効率的に移動させることがボトルネックになりつつある」と説明しており、Maia 300の設計思想が純粋な演算性能の追求からデータフロー最適化へと重心を移していることがうかがえる。オンダイSRAMをソフトウェア管理のスクラッチパッドとして活用する点も、このデータ移動削減の取り組みの一環だ。 背景と今後の見通し Microsoftは2023年以降、独自シリコンの開発を通じて推論コストの削減と外部GPUサプライヤーへの依存低減を図ってきた。Maia 300はその延長線上にあり、エンタープライズ向けAIアプリケーション、複数ステップにまたがるエージェントタスク、医療分野のDragon Copilotといった用途での活用が見込まれている。同社は「フロンティア変革」戦略の一環として、シリコンからシステム、エージェント層までを一体的に最適化する姿勢を示しており、今後の自社AIサービスの価格競争力にも影響を与える可能性がある。Microsoftは2026年11月開催のIgniteで、採用戦略や導入事例についてさらに詳細を公開する予定としている。

概要 Googleは、Cloud Storageのus-central1リージョンで発生した障害についてのインシデントレポート(#mSFVt6PiP557bjRyYsut)を公開した。障害は10月8日04:00(PDT)に始まり、同日16:30(PDT)に解消するまで約12時間30分続いた。影響はus-central1リージョンに限定され、他のリージョンや他のGoogle Cloudサービスへの波及はなかったが、この間、アップロードおよび書き込み操作でHTTP 503 UNAVAILABLEエラーやクライアント側タイムアウトが発生し、レイテンシとエラー率が上昇した。読み取り操作にも軽微な影響があったという。 障害の技術的な原因 根本原因は、特定のバックエンドストレージノードで発生した容量不足への対応だった。Googleはこの容量制約に対処するため、トラフィックをソートして最適化する機能を適用していたが、この最適化処理自体が一部のバックエンドストレージノードで深刻なリソース枯渇を引き起こした。リソースが枯渇したノードでは、オブジェクトデータの取り込み(インジェスト)処理がタイムアウトし始め、アップロード・書き込みの失敗につながった。さらに、基盤となるメタデータベースサービスの問題がこの期間のメタデータ処理エラーに寄与したことも明らかになっており、単一の要因ではなく複数の問題が重なって障害が長期化したことがうかがえる。 復旧までの対応 Googleはまず緊急の容量を動的に割り当てる対応を試みたが、これは奏功しなかった。次に、過負荷状態のノードから選別的にトラフィックを排出(ドレイン)する対応を実施し、同時に問題の原因となったトラフィックソート最適化機能自体を無効化する設定を展開した。加えて、メタデータベースサービスに対して行われていた直近の更新をロールバックした。これらの対応を経て、ドレインされたノードを順次正常なサービスに復帰させることで、最終的に障害は解消された。 今後の対応 Googleは予備報告の段階であり、完全な根本原因分析と予防措置を含む最終報告書を今後提供するとしている。現時点では、容量不足への対処として導入した最適化機能そのものが新たな障害を生んだという経緯が示されており、最終報告でどのような再発防止策が示されるかが注目される。

概要 さくらインターネットは10月8日、GPUサーバを専有利用できる月額定額制のマネージドAIサービス「さくらのAI Engineプライベートエディション」の提供を開始した。従来の「さくらのAI Engine」が従量課金型でトークン消費量に応じて課金されるのに対し、プライベートエディションはGPU単位の月額定額制を採用し、利用量を気にせず安定したコストでAIサービスを運用できる点が最大の特徴だ。独自に開発した大規模言語モデルやファインチューニング済みのモデル、オープンウェイトモデルなど、さまざまなAIモデルを専有環境上でマネージドサービスとして展開できる。 GPU専有とセキュリティ面での特徴 同サービスはGPUサーバを他社と共有せず専有できるため、入力データやモデル資産を外部に出さずに運用することが可能になる。国内データセンターで稼働し、閉域接続にも対応することから、機密情報を扱う社内業務や、顧客データを扱う自社サービスへのAI組み込みなど、セキュリティ要件の厳しい用途を想定したユースケースが想定されている。AI基盤の構築・運用をさくらインターネットに任せることで、利用企業はアプリケーション開発や業務活用そのものに集中できるとしている。なお、記事中では具体的なGPUの機種や個別の対応モデル名は明らかにされておらず、料金の詳細についても個別の問い合わせが必要とされている。 背景と今後の展望 近年、企業における生成AI活用が進む一方で、API利用のトークン量に応じた従量課金はコストの予測が難しく、特に大規模な利用を前提とする企業にとっては予算管理上の課題となっていた。さくらインターネットは専有・定額型のサービスを用意することで、コスト予測のしやすさと、機密情報を外部に出さない安全性の両立を図る狙いがあるとみられる。すでに同社は従量課金型の「さくらのAI Engine」を展開しており、今回のプライベートエディションはその上位・補完的な選択肢として位置づけられる。今後、国内企業のAI活用がさらに広がる中で、セキュリティとコストの両面を重視する企業からの需要が見込まれる。

概要 Cloudflareは、コンテナプラットフォーム「Containers」においてストレージ層の分離が破られ、他テナントのデータを読み取れる脆弱性を公表した。原因はLinuxのdevice mapper thin provisioningでskip_block_zeroing設定が有効になっていたことで、新規割り当てされたディスクブロックがゼロ初期化されないまま再利用されていた。コンテナが未マップ領域に4KiBのブロックを書き込むと、システムは共有プールから64KiBの物理ブロックを割り当てるが、実際に書き込まれるのはそのうちの一部のみで、残り最大60KiBには前のテナントが残したデータがそのまま残存し、生のディスク読み取りを通じて取得できる状態だった。 発見から修正までの経緯 脆弱性はバグバウンティを通じて、セキュリティ研究者のOren Yomtov氏によって9月4日15:26 UTCに報告された。Cloudflareは同日23:15 UTCにはランタイム側の修正デプロイを開始し、9月7日までにロールアウトを完了。さらにディスクの退役、ホストのドレイン、キャッシュのクリアなどを含む全面的な対応を9月19日までに終えたとしている。研究者には9月14日に報奨金が支払われた。報告から初動対応までが数時間という速さだったことがタイムラインから分かる。 漏えいの範囲と実際に取得できたデータ 今回の調査では、グローバル24か所のプロダクション環境のうち18か所で、他テナントに属するディレクトリ構造やデータベースページ、さらには完全なSQLiteデータベースまで復元できたことが確認されている。検証可能だった5,614件のディレクトリブロックはすべて他者由来のものであり、2,700件の異なる外部ディレクトリinodeが識別されたという。これは単なる理論上の脆弱性ではなく、実際に広範囲のテナントデータが影響を受け得る状態にあったことを示している。 影響の限定要因とCloudflareの説明 一方でCloudflareは、攻撃者が特定の被害者や狙ったワークロードのデータを選んで取得することはできず、残存データが実際に存在するかどうかも保証されていなかったと説明している。また、悪用された証拠は確認されていないとしている。ただし、この種の「テナント分離は保証されている」という前提が、ストレージ層での独立した検証なしには成立しないことを今回のインシデントは示した。業界の反応としても、分離を主張するなら各インフラ層で明示的なzero-on-allocateの検証が不可欠であり、アーキテクチャ上の想定だけに依拠すべきではないという教訓が指摘されている。