SREcon25 Europe/Middle East/Africa 参加レポート – ZOZO TECH BLOG

はじめに

こんにちは、計測プラットフォーム開発本部SREブロックの纐纈です。

2025年10月6日〜9日にダブリンで開催されたSREcon25に参加してきました。本記事では、現地の様子と気になったセッションについて報告いたします。

目次

SREconとは

SREconは、USENIXが主催するSite Reliability Engineering（SRE）に関する国際カンファレンスです。世界中からSREエンジニアやシステム運用に携わるエンジニアが集まり、最新のプラクティスや知見を共有します。

今回の特徴としては、AI/MLシステムの運用に関するセッションが増えており、SREの役割が従来のインフラ運用からAIシステムの品質保証やリスク管理にまで拡大していることがうかがえました。また、クラウドネイティブなアーキテクチャの普及に伴い、Kubernetesやマイクロサービスの運用に関する具体的な事例も多く紹介されました。

現地の様子

今回の会場はDublin Convention Centreで、3つのセッションルームと展示エリアがありました。

比較的小さな規模のカンファレンスですが、その分、参加者同士の交流が活発な印象を受けました。また、ヨーロッパやアメリカからの参加者が多く、後から参加者リストを確認したところ、日本からの参加者は私1人だけのようでした。SREconは年に数回開催されており、次回は2026年3月にアメリカのシアトルで開催される予定です。

セッション紹介

ここからは、今回参加したセッションの中から特に印象に残ったものをいくつか紹介します。

SRE for AI and AI for SRE

まず、AnthropicのNiall Murphy氏によるセッションでは、2024年8月に発生したClaude AIの品質劣化インシデントについて詳細な事後分析が共有されました。このインシデントは、モデル自体の問題ではなく、サービング基盤のシステムの問題がモデルの品質低下を引き起こしたという、非常に興味深い事例でした。

インシデントの概要

8月上旬から、XやRedditで「Claudeが以前より性能が落ちた」という報告が急増しました。しかし、調査を進めても以下のような状況でした。

• モデルの変更は行っていない
• 標準的な品質評価（SWE-bench等）では問題なし
• モニタリングアラートは一切発報していない
• 再現が非常に困難（リクエストのパターンやトラフィック状況によって動的に変化）

最終的に、3つの独立したバグが複合的に影響していたことが判明しました。

1. コンテキストウィンドウルーティングエラー：100万トークン対応のリリース準備時に、短いコンテキストのリクエストを長いコンテキスト用インフラにルーティングした際、正しく動作しなかった。
2. 出力破損バグ：トークン生成処理の最適化により、特定の状況下で確率分布が誤った値となった。極めて低い確率のトークンが選択される（中国語や英語のクエリに対してタイ語のトークンが返される等）。
3. Top-K XLAコンパイラバグ：混合精度の演算とコンパイラバグの組み合わせで、修正を試みた結果さらに悪化するという状況も発生。

学んだこと

このセッションから得られた最も重要な点は、品質がML/AIシステムにとって適切なSLOであるということです。モデルが正しく動作しなければ、可用性やレイテンシーは意味を持ちません。また、システムの問題が品質に影響を与えることを前提に、SREチームも品質のモニタリングが必要だと強く認識しました。

さらに、プライバシーポリシーとデバッグのトレードオフについても考えさせられました。Anthropicはユーザーのプロンプトと応答を保存しないポリシーを持っているため、「英語のクエリに対してタイ語のトークンが返される」といった明らかな異常を自動検出できませんでした。

弊チームでも、サイズ推奨システムをはじめとしたMLシステムを運用しています。パイプラインの変更がモデルの品質へ影響を与える可能性を常に意識し、品質メトリクスを重要なSLOとして扱うべきだと感じました。

Why Risk Management Requires Taking Risks: A Practical Guide to Getting SRE Teams AI-Ready

NVIDIAのGeForce NOWプラットフォームのSREチームによる、AIを活用してインシデント対応時間を劇的に短縮した事例の紹介でした。グローバルで35拠点、25,000台以上の物理サーバー、100,000個以上のGPUを26人のチームで運用している中で、AIをどのように活用しているかが具体的に語られました。

AI活用の段階的アプローチ

GeForce NOWチームは、AIの採用を4つのレベルで段階的に進めていました。

レベル1：要約（Summarization）

• プレイブックやドキュメントの要約
• 最も簡単に始められるが、ドキュメントの品質に大きく依存
• 80％正しい回答では信頼を失うため、実は最も難しい
  • 例：プレイブックに「サービスAを再起動」と書かれているのに、「サービスBを再起動」と要約された場合、障害が悪化してしまう
  • 一度でも誤った情報を提供すると、チーム全体がAIの回答を信頼しなくなり、AI導入の意味が薄くなる

レベル2：情報の統合（Synthesis）

• リアルタイムでメトリクス、SLO、システム状態を集約
• 「ブルガリアで何が起きているか？」といった質問に対し、1分以内で全情報を提示
• 20分かかっていたコンテキスト収集が1分未満に短縮

レベル3：評価（Evaluation）

• システムの状態を評価し、問題の可能性がある箇所を提案
• ベイジアンネットワークを活用した根本原因の分析
  • コンポーネント間の依存関係を確率とともにマッピング
  • 与えられた障害から最も可能性の高い根本原因を推定
  • 観測可能性のギャップも可視化される

レベル4：アクション実行（Action-Taking）

• AIが実際にシステムに対して修復アクションを実行
• サービス再起動などの安全な操作から開始
• 人間の承認ステップを組み込んで安全性を担保

具体的な成果

週次サービスレビューの準備時間が2〜3時間から5分へ短縮されました。また、エグゼクティブからの問い合わせにSREチームを経由せずAIが回答できるようになりました。

弊チームへの適用

弊チームでは、そこまで多くのサーバーを運用していないため、GeForce NOWのような大規模なAI導入は現時点ではコストに見合わないと考えています。しかし、レベル1の要約やレベル2の情報統合は、ドキュメントの整備と合わせてすぐにでも試してみたいと感じました。特にインシデント対応時の初動で、過去の類似インシデントやプレイブックを素早く参照できることは大きな価値があると思います。

Performance Consistency in the Cloud

AWSによる、クラウド環境でのレイテンシー変動の原因と対策についてのセッションでした。ほとんどのアプリケーションではレイテンシーの変動は許容範囲ですが、高頻度取引やゲーム、ベンチマークなど、マイクロ秒単位の一貫性が重要なサービスにとっては致命的な問題となります。

パフォーマンス変動の主な原因

1. マルチテナンシー（最大の要因）

クラウドプロバイダーは公平性を保つため、リソースへ制限を実装しており、これが変動の最大の原因となっています。AWS Nitroは専用ハードウェアに制御をオフロードすることで、カスタマーのCPUサイクルを消費せずに管理しています。

2. 共有リソース

複数のテナントが同じCPUソケットを共有する場合、L3キャッシュやメモリバスが共有されます。CPUサーマルとパワー管理の制限も共有されるため、一方の負荷が高まると全体の周波数が低下し、他のテナントのパフォーマンスも影響を受けます。AWS Nitroハイパーバイザーは、この影響を1％未満のオーバーヘッドに抑えています。

3. ストレージ

マネージドブロックストレージは、ローカルに見えても実際にはネットワーク経由でアクセスされます。パスの長さやネットワークの輻輳によって変動が発生します。AWS SRD（Scalable Reliable Datagram）では、複数のパスを使用することで輻輳を回避し、レイテンシーを改善しています。

4. ネットワーク

データセンター内の配置によって異なるネットワークパスが選択されます。デフォルトの配置は暗黙的であるため、Placement Groupsを使用して同じネットワークスパインに配置することで改善できます。

緩和策

• バースト可能なインスタンスを避ける
• より大きなインスタンスを選択してリミットを上げる
• 専用ホストを使うことでCPUソケット全体を占有
• ARM64 CPUは固定周波数で予測可能性が高い
• ローカルNVMe SSDの使用：ただしエフェメラル（揮発性）の制約あり

学んだこと

現状弊チームでは、このようなレイテンシーの変動はあまり問題になっていません。しかし、将来的にリアルタイム性が重要なサービスを運用する場合、今回の知見を活かしたインスタンス選定やアーキテクチャ設計をしたいと感じました。

CPU Utilization: The Hidden Cost of Running Hot

GitHubのスピーカーによる、高いCPU使用率で運用することによる隠れたコストについてのセッションでした。従来の「CPU使用率を80％以下に保つ」という経験則は必ずしも正しくないことが示されました。ワークロードによって最適な使用率は異なります。

なお、このセッションはこちらのブログ記事を元にされています。

github.blog

高CPU使用率の隠れたコスト

1. レイテンシーの劣化

キューイング理論により、使用率の上昇に伴いレイテンシーは非線形に増加します。CPU使用率90％以上では、わずかなトラフィック増加でも大きなレイテンシースパイクを引き起こします。特にP99/P999のテールレイテンシーが最初に影響を受けます。

2. 障害時のバッファの欠如

障害が発生したインスタンスからのトラフィックを吸収する余裕がなく、カスケード障害が発生しやすくなります。また、オートスケーリングの遅延が致命的になります。

3. デプロイメントリスク

ローリングデプロイメントは一時的な容量損失を引き起こすため、高使用率での運用はデプロイメント起因の障害リスクを高めます。

4. 運用オーバーヘッド

常に容量の問題へ対処する必要があり、アラート疲れが発生します。また、パフォーマンス調査の余裕がなくなります。

最適化の戦略

• サービスのレイテンシー/使用率カーブを理解する
• レイテンシーSLOに基づいて目標使用率を設定する
• リクエストシェディング/ロードシェディングを実装
• 平均だけでなくP99や分布を監視する

所感として、GitHubのような大規模サービスでは、コスト削減のために高いCPU使用率で運用することが多いと思いますが、その場合でもレイテンシーや障害リスクを十分に考慮する必要があると感じました。弊チームではまだそこまで高い使用率で運用していませんが、将来的にスケールする際には今回の知見を活かして適切なバランスを取っていきたいと思います。

MLOps 2025: A Journey into the Past and the Future

最後にZalandoのAlejandro Saucedo氏によるセッションでは、MLOpsの過去10年間の進化を振り返り、現在の課題と今後の展望について語られました。特に印象的だったのは、MLOpsの基本原則は変わらないものの、LLMやエッジMLといった新しい技術トレンドに対応するための進化が求められているという点でした。

MLOpsの進化：過去から現在へ

初期のMLOps（2015-2020）

• Jupyter Notebookがそのまま本番環境で動いていた
• モデルのデプロイは手動で、再現性の確保が困難
• モニタリングは限定的で、モデルの劣化を検知できない
• データのバージョン管理も不十分

現代のMLOps（2020-2025）

• 標準化されたパイプライン（MLflow、Kubeflowなど）
• モデルレジストリによるバージョン管理
• 自動再トレーニングの仕組み
• Feature Storeによる特徴量の一元管理
• ML特化のモニタリング（データドリフト検知など）

教訓

1. ソフトウェアエンジニアリングの原則が適用できる

モデルやデータにもバージョン管理が必要であり、MLパイプラインにもCI/CDが適用できます。また、モデルのコードにもコードレビューやテストが必要です。

2. モニタリングは極めて重要

データドリフト（入力データの分布変化）、モデルパフォーマンスの劣化、特徴量の分布シフト、予測品質の経時的変化など、ML特有の監視項目があります。

3. データの問題は永遠に続く

データ品質の問題、ラベリングの課題、データのバージョニング、プライバシーとコンプライアンスなど、データに関する課題は尽きません。

4. モデルのデプロイ後も運用が続く

本番環境でのモニタリング、A/Bテストのフレームワーク、段階的なロールアウト、ロールバック機能など、デプロイ後の運用が重要です。

現在の課題

スケール

• 大規模データセットでのトレーニング：数TB〜数PB規模のデータを効率的に処理する必要がある
• 高スループット・低レイテンシーでのサービング：数千〜数万リクエスト/秒を数ミリ秒以内で処理
• コスト管理：GPU利用料金の高騰により、学習コストとサービングコストの最適化が重要
• リソースの最適化：限られたGPU/TPUリソースを複数チームで効率的に共有

複雑性

• 複数モデルを組み合わせたシステム：推奨システムでは複数のモデルを連携させる必要があり、依存関係の管理が複雑
• モデルアンサンブル：精度向上のために複数モデルの予測を組み合わせるが、レイテンシーとのトレードオフ
• オンライン学習：リアルタイムでモデルを更新する仕組みでは、データの一貫性やモデルの安定性が課題
• リアルタイム特徴量：ストリーミングデータから特徴量を計算し、推論へ即座に利用する必要がある

ガバナンス

• モデルの説明可能性：金融や医療などの分野では、予測結果の根拠説明が法的要件となる場合がある
• バイアスの検出と緩和：トレーニングデータの偏りがモデルに反映され、不公平な予測を生む可能性
• 規制対応：GDPR、AI規制法など、地域によって異なる法規制への対応
• 監査証跡：誰が、いつ、どのデータで、どのモデルを学習・デプロイしたかの完全な記録

未来のトレンド

1. LLMOps

LLMの台頭により、ファインチューニングのワークフロー、プロンプトエンジニアリングのパイプライン、RAGシステム、モデルの組み合わせなど、新しいMLOps領域が生まれています。

2. Edge ML

デバイス上での推論、Federated Learning、モデルの圧縮、プライバシー保護MLなど、エッジでのML実行が重要になっています。

3. AutoMLの進化

Neural Architecture Search、自動特徴量エンジニアリング、メタ学習、Few-shot学習など、より高度な自動化が進んでいます。

4. MLOpsプラットフォーム

エンドツーエンドのソリューション、クラウドに依存しないツール、オープンソースエコシステム、ベンダーの統合が進んでいます。

2025年のベストプラクティス

インフラ

• モデルをファーストクラスの成果物として扱う：コードと同様に、モデルもバージョン管理され、CI/CDパイプラインでテストされるべき
• 自動化を徹底する：手動デプロイや手動モニタリングは人的ミスの原因となるため、可能な限り自動化
• 再現性を確保する設計：同じコード、同じデータ、同じ環境で学習すれば、常に同じモデルが生成されることを保証
• 最初からスケールを考慮した設計：小規模プロトタイプで成功しても、本番スケールで動かなければ意味がない

プロセス

• クロスファンクショナルチーム（ML + SRE + Product）：ML研究者だけでなく、SREとプロダクトマネージャーが協働することで、実用的なシステムを構築
• 実験トラッキングの規律：すべての実験（ハイパーパラメータ、データセット、結果）を記録し、後から再現・比較可能にする
• 明確なプロモーション基準：どの指標が改善されれば本番にデプロイするかを事前に定義し、恣意的な判断を避ける
• MLシステム向けのインシデント対応：従来のシステム障害とは異なり、モデルの品質劣化やデータドリフトに対応するランブックが必要

文化

• モデル障害に対するブレームレスポストモーテム：モデルの品質劣化が発生した際、個人を責めるのではなく、システムの改善に焦点を当てる
• 継続的な学習マインドセット：MLの技術は急速に進化しているため、チーム全体で最新の知見をキャッチアップし続ける
• チーム間での知識共有：成功事例だけでなく、失敗事例も共有することで、組織全体の学習速度を上げる
• 不確実性を受け入れる：MLモデルが100％正確ではなく、常に誤差を含むことを前提とした設計とコミュニケーション

学んだこと

このセッションを通して、MLOpsの基本原則は変わらないものの、新しい技術トレンドに対応するための進化が求められていることを再認識しました。特に、最初からスケールを考慮した設計については、弊チームでもプロトタイプから本番環境への移行で苦労も多いため、今後のプロジェクトで意識していきたいと思います。また、MLシステム開発に普段関わっていないSREやバックエンドチームでも、最近MLOpsの知識を求められる場面が増えてきているため、今回の内容は非常に参考になりました。

最後に

今回SREcon25に参加して、世界中のSREエンジニアが抱える課題や、それに対する様々なアプローチを知ることができました。

他のカンファレンスとの比較になりますが、SREconは技術的な深掘りだけでなく、文化的な側面にも焦点を当てている点が非常に印象的でした。また、AI/MLシステムの運用に関するセッションが増えており、SREの役割が従来のインフラ運用からAIシステムの品質保証やリスク管理にまで拡大していることを強く感じました。

ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。

corp.zozo.com