Anthropicは9月14日、エンジニアリングブログに記事を公開した。筆者のSachin Malhotra氏が書いたのは、社内のあるサービスが負荷に押しつぶされ、作り直された経緯だ。このサービスは「テスト影響分析」と呼ばれ、役割は単純明快で、あるコード変更が入ってきたときに、どのテストを実行すべきで、どれを省略できるかを判断する。裏方のコンポーネントに見えるが、それが持ちこたえられなくなった理由には代表性がある。
まず倍率を見る
ブログが示す最初の数字群は出力側のものだ。Anthropicのエンジニアが四半期あたりに提出するコード量は、2021~2025年の水準の8倍に達しており、そのうち80%はClaudeが書いたコードだ。ClaudeはPRのレビューと承認でも大きな比重を占めている。
2つ目の数字群は負荷側のものだ。コードベース内のテスト総数は10倍に増え、半年間でCIジョブ数は25倍になった。
3つ目の数字群が最も事態の進行速度を物語る。チームは負荷に耐えるため応急措置を3回実施したが、それぞれが稼いだ時間は70日、29日、1日未満と先細りだった。3回目の対策はリリース当日に飲み込まれた。
旧サービスはどこで詰まったか
従来のアーキテクチャには、各テスト結果を順番にストレージへ書き込む単一プロセスのリスナーが存在した。単一の書き込み口では横方向にスケールできず、PRが処理能力を超える速度で流入すると、キューが積み上がり始める。ブログの原文表現では、このリスナーは「starts to increasingly fall behind the PR queue(PRキューへの遅れがどんどん大きくなっていく)」状態になる。
遅延の影響は複合的だった。記事が挙げる例では、20分の遅れが数万件分のテスト結果更新の未反映に相当したという。テスト選択はまさに過去の結果を根拠に判断するため、履歴が不正確だと選ばれるテスト集合の信頼性も崩れる。さらに悪いことに、このプロセスにはメモリリークもあり、毎日午後になると上限に張り付いていた。
何に作り替えたのか
作り直しの発想は、状態をプロセスの外に追い出すことだった。新しいアーキテクチャはインメモリのデータストアを導入し、どのリスナーワーカーもあらゆる結果を処理できるようにした。ワーカー自身は状態を保持せずログへの追記だけを担うため、必要に応じてマシンを増やせる。これとは別に、数秒おきにログを畳み込んでテストごとの履歴に整理する独立した消費プロセスがあり、セレクターが判断を下す際はこの履歴を直接参照する。
代償はコストの増加だ。ブログはこれを率直に認めており、引き換えに得たのはスケーラビリティと可観測性だとしている。どの段階が遅いのか、どこで遅いのかを個別に測定できるようになった。この再設計全体は、エンジニア1人が3週間で完成させた。
25倍という曲線
半年で25倍という数字は、月次の複利成長率に換算するとおよそ1.71倍(25の6乗根)に相当する。この傾きをさらに半年先まで延長すると625倍になる。記事末尾の「always plan for the exponential(常に指数関数的な増加を想定せよ)」という一文はレトリックではなく、すでに実測されたこの曲線に対応している。
もっとも、この曲線の外挿は当然当てにならない。社内のポリシーや割り当て、エンジニアリングの習慣の変化で増加率は曲がりうるし、AnthropicはCI費用の絶対額も、新サービスがテストを何%ふるい落としたのかも、作り直し後の遅延がどの水準まで下がったのかも公表していない。どれだけコストを削減できたのかは、公開情報からは導き出せない。
ただ、負荷がどの工程からどの工程へ伝わっているかという手がかりははっきりしている。今年4月、GitHubはCopilotの個人向け3プランで新規登録を停止し、理由としてエージェントによる長時間タスクの計算コストがプラン設計を超えたことを挙げた。さらに以前には、AIによるコミットの急増がGitHubの障害につながり、Microsoftが一時AWSからキャパシティを借りて凌いだこともあった。3つの出来事は形こそ違うが、示しているのは同じことだ。コード生成の工程が先に加速し、次にレビューが加速し、その先にある「人間がコードを書く速度」を前提に容量設計されたシステムが、順番に押し寄せる波を受けることになる。テスト影響分析は、今回の波で早めに警報を鳴らした部類にすぎない。
参考資料:CocoLoop、Anthropicエンジニアリングブログ。コード量の倍率、テストおよびCIジョブの増加率、3回の応急措置の有効期間は、いずれも同記事の公表値に基づく。