;

Ichizokuは日本唯一のSentry公認販売業者です。
日本語のドキュメント、動画、サポート窓口で日本のお客様のSentry活用を支援します。

【Anthropic】600人以上のエンジニア&1つのツール。Anthropic の Sentry ストーリー

 

世界でも Anthropic が日々取り組んでいる課題ほど技術的に複雑な挑戦に取り組むチームはそう多くありません。

AIとAI安全性研究の最前線で働くAnthropic の日々の業務には、想像を絶する規模のデータセット、大規模な分散ジョブ、そして高度に専門化されたハードウェアが関わっています。同社のエンジニアは GPU メモリの制約から最下層レベルでの計算最適化まで、あらゆる課題に取り組みながら、ほんの少し前までは考えられなかった種類のコードを継続的にリリースしています。

システムの複雑さが増すにつれて、問題が発生した際の修正も一層複雑になります。

Anthropic の既存のインフラストラクチャーモニタリングツールが追いつかない状況になったとき、彼らはSentryを導入して、より迅速に問題を見つけて修正することにしました。バグやクラッシュを早く取り除くことができれば、本当に重要な研究に注力する時間が増えます。

「Sentry は Sonnet の開発を進める上で重要な役割を果たしました。」と、Anthropic のシステムリードを務める Nova DasSarma が、同社の最も先進的なAIモデルの1つに言及しながら語っています。

 

 

課題:圧倒的なログ量

AI研究では、時間は単なるコストではなく「前進」そのものです。業界の最前線で取り組むなら、バグの特定と修正に何日もかけている余裕はありません。

「1つのノード障害が、数百、あるいは数千台のサーバーに影響することがあります… Sentry 導入前は(多くはハードウェア故障が原因で)クラッシュループに陥ることがよくありましたが、不良ハードウェアを排除するためのノードレベルのテレメトリがありませんでした。」ー Nova(システムリード)

インフラが拡大するに伴い、問題も増加しました。

  • 既存のモニタリングツールが処理しきれない圧倒的なログ量
  • ノードレベルのハードウェア問題の可視性がない
  • 分散システム間でエラーを関連付けるのが難しい
  • エラーが発生したときに最初に誰が知るべきか、エラーの所有権を追跡する能力が限られている

 

トレーニングしていたモデルが大規模化するにつれて、これらの問題は深刻化しました。数千の GPU が同時に稼働する中で、デバッグに費やす1分1秒がリソースの浪費と研究の停滞につながります。

「私たちは、デバッグに数日かかる障害にぶつかっていました。何千台ものサーバーが関わる中で、それをSentryで“数時間”に短縮できたことは、大規模トレーニングジョブを効率よく回し続けるうえで決定的でした」ー Nova(システムリード)

小規模なジョブでは問題なかった既存のセットアップは、この規模には適していませんでした。

「以前のツールは厳しいスロットル制限があり、生成されるログの量が多すぎて処理しきれませんでした。」ー Nova(システムリード)

彼らが求めていたのは、このスケールに対応でき、失敗を手作業でつなぎ合わせなくてもよいリアルタイムのデバッグソリューションでした。

 

 

解決策:スケールした状態での即時可視化

Anthropic の機械学習インフラは、小さな障害がすぐに大きな混乱へと発展する規模で動いています。Claude 1 のトレーニング時点でも、既存のインフラ監視は追いつけなくなっていました。

「これは、それまでで最大のジョブでした。以前はほとんどのジョブが数ノードで完結していました。でも大規模モデルを学習させると、1つのノード障害が数千台のサーバーに影響します。」ー Nova(システムリード)

以前の会社で Sentry を使ったことのあるメンバーもいました。そのため、GPU クラスターで連鎖的障害が起き、デバッグがほぼ不可能になったとき、Sentry が助けになると分かっていました。

時間を無駄にできない中で、まずは1つのジョブに Sentry を組み込み、効果を検証しました。

「ジョブに Sentry SDK をとりあえず入れて、再デプロイしました。」ー Nova(システムリード)

効果はすぐに現れました。

  • 例外がリアルタイムに可視化され、手作業でログを探す必要がなくなった
  • ノードレベルでの相関により、故障ハードウェアの特定が容易になった
  • 問題のあるノードを数日ではなく数時間で排除できるようになった

 

「数日間クラッシュループから抜け出せなかった状態から、数時間で不良ノードを引き抜いて、ジョブを再稼働できるようになりました。」ー Nova(システムリード)

個人のクレジットカードで支払った「実験」として始まった取り組みは、最終的に全社規模のソリューションへと発展し、大規模AIトレーニングのデバッグのやり方そのものを変えていきました。

 

 

より賢いデバッグシステムの構築

Sentry は導入直後から十分に機能しましたが、スケールに伴い、Anthropic は Sentry の柔軟性を活かして、大規模 MLトレーニングの要件に合わせた監視へと拡張しました。

GPU 関連エラー向けのカスタム例外処理、Kubernetes のプリエンプションを追うための合成イベント、失敗を特定の実験に結び付けるジョブ単位のエラートラッキングを開発しました。

さらに、ハードウェア種別、データソース、サービス依存関係、ジョブのオーナーといった重要メタデータを捉える詳細なタグ設計を実装し、デバッグに必要なコンテキストを深めました。

「私たちの Sentry の使い方は、リリース指向というよりジョブ指向です。エラーはジョブに基づいてタグ付けされるので、Anthropic内の適切な開発者に自動で割り当てられます。」ー Nova(システムリード)

「カスタムアラート、タグ、ダッシュボード、そして Sentry のオープン API のおかげで、チーム全体にとっての使いやすさを保ちながら、必要に応じて Sentry を拡張できる柔軟性があります。」ー Nova(システムリード)

「たとえば私たちは Slack 中心の会社なので、アラートの転送をたくさん行っています。」ー Nova(システムリード)

「API を通じて、Sentry データと自社のログシステムを組み合わせたカスタムダッシュボードも作りました。Sentry API に対してクエリできることは、私たちにとって非常に価値があります。」ー Nova(システムリード)

従来のソフトウェアリリースではなく、個々の ML ジョブを軸にエラーモニタリングを組み立てたことで、デバッグはより効率化し、ダウンタイムが減り、実験を計画通りに進められるようになりました。

 

 

ワークフローにおけるSentryの役割を拡大

Anthropic は例外の追跡、エラーの割り当て、障害のリアルタイム分析のために Sentry を活用しています。対象は研究チームの主要言語である Python、Rust、C++ を含む全言語です。

デバッグに必要なコンテキストが1か所に集約されたことで、問題解決は大きく改善しました。

「Sentry は開発者にとって、問題をデバッグするために必要な情報がすべて揃う“1つの場所”を提供してくれます。」ー Nova(システムリード)

 

 

Sentryが「より速く」解決に導く主要な課題

1. データ処理の問題

何千台ものサーバーで走る研究ワークロードでは、データ検証が重要です。不良データは実験全体を壊し得ます。Sentry により、広範囲に影響が出る前に、問題のあるシーケンスを特定・隔離できます。

「locals を Sentry に送ると、毒データがあるのか、削除すべきシーケンスがあるのかがすぐ分かります。」と Nova は言います。「どのファイルに手を入れる必要があるかが正確に見えるので、追跡はかなり簡単です。」

 

2. サービス依存関係

複数の環境と相互接続された下流サービスがあると、失敗の追跡は難しくなります。「モデルが学習している環境がいくつかある状況を想像してください。」と Nova は説明します。

Sentry のクエリ機能を使うことで、原因を素早く特定し、関連エラーを切り分けられます。「Discover を使えば、特定のジョブに関連するエラーをすべて切り分け、特定のサービスに結び付けられます。」と Nova は述べています。

「直近90日間のすべてのエラーを即座にクエリできるのは、非常に有用です。」とNovaは説明します。「破損バグがあると考えたとき、例外を creator タグでグルーピングして、どのジョブが影響を受けたかをすぐ確認できます。」

 

3. GPU関連の障害

ハードウェア障害は、特に台数が多いほど特有の難しさがあります。あるハードウェアが悪い結果を返し始めると、問題は波及し、連鎖して増幅します。Anthropic は Sentry を使って、問題のあるハードウェアをより速く特定し、オフライン化しています。

「GPU は非常に信頼性の高いハードウェアで、CPU より千倍も多くの仕事をこなす現代の奇跡です。」と Nova は言います。「ただし不安定になることもあり、ときどき間違った計算結果を返します。Sentry が提供するカスタムタグとエラーコンテキストによって、特定のホストに切り分けられるので、フリートから外せます。」

 

 

Sentry が Anthropic のエンジニアを支える仕組み

研究とエンジニアリングにまたがる多数の開発者がいる中で、Sentry は Web、モバイル、そして研究チームが使う大規模な Python モノリス全体にわたるエラーの「単一の信頼できる情報源」を提供しています。

以前:デバッグに数日かかり、研究が遅れ、高価なGPU時間を消費していました。
現在:数時間で修正し、実験を計画通りに進め、コストも抑えられています。

「Sentryは、複雑な分散システムを可視化し、壊れたジョブをクローズするまでのループを完結させてくれます。開発者がデバッグに必要とするものを、1か所にすべて揃えてくれます。」ー Nova(システムリード)

 

なぜ Sentry が適しているのか
  • エラーを1箇所で管理 → 複数のツールを行き来してログを追いかける必要なし
  • デバッグが迅速に → インシデントを数時間で解決し、日数はかからない
  • 生産性が10-15%向上 → 開発に専念でき、デバッグの時間が減少
  • インシデント解決が20-30%迅速化 → ダウンタイムの減少、作業中断が減少

 

「Sentry なしではスケールアップできなかったでしょう。ほとんどのインシデントはハードウェアに関するもので、すべて Sentry 内でデバッグしています。」ー Nova(システムリード)

 

 

未来を見据えて

AIのトレーニングがますます複雑化する中で、Anthropic は Sentry の Autofix の利用を模索しています。これは Sonnet を基盤としたもので、デバッグ時間をさらに短縮することを目指しています。AI研究の分野では、計算時間が高コストであるため、適切なツールは単に問題を解決するだけでなく、その勢いを維持する鍵となります。

 

 

Original Page: 600+ Engineers, 1 Tool: Anthropic’s Sentry Story

 

 




IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

 

シェアする

Recent Posts