powered by TechFeed
表示モード
Deep Dive

SlackのAI推論基盤がマルチクラウド化で「レイテンシ67%削減」— 特定プロバイダーへの依存をどう切り離したか

6月25日、Matt Fosterが「Slack Outlines Four-Phase Journey to a Multi-Cloud AI Serving Platform」と題した記事を公開した。この記事では、SlackのAI推論インフラがAmazon SageMakerからAWSとGoogle Cloudにまたがるマルチクラウド構成へと4段階で進化した経緯について詳しく紹介されている。

6月25日、Matt Fosterが「Slack Outlines Four-Phase Journey to a Multi-Cloud AI Serving Platform」と題した記事を公開した。この記事では、SlackのAI推論インフラがAmazon SageMakerからAWSとGoogle Cloudにまたがるマルチクラウド構成へと4段階で進化した経緯について詳しく紹介されている。


「10倍の需要変動」と「シングルプロバイダー依存」という2つの壁

SlackのAI推論基盤は、当初Amazon SageMaker上に構築されていた。エスクロー(隔離)VPC内でクロスアカウントIAMロールを使う構成で、セキュリティ分離の観点では堅牢だったが、手動でのキャパシティ予測・クラスター拡張のスケジューリング・A100/H100 GPUリソースの事前確保が必要だった。数百万の日次ユーザーを抱える中で、キャパシティ不足は即座にユーザー影響に直結する問題だった。

この運用負荷を下げるために移行したのがAmazon Bedrockだ。Bedrockへの移行によりGPU予約管理が不要になり、Anthropicの新しいモデルへのアクセスも早くなった。移行はコンプライアンスレビュー・負荷テスト・フィーチャーフラグによる段階ロールアウトで進められ、カスタマー影響のあるインシデントはゼロだったという。

ただ、Bedrock移行後も課題が残った。SlackのAIワークロードはピーク時と閑散時で最大10倍のトラフィック変動が発生する。この問題に対しては、BedrockのProvisioned Throughput(PT)とOn-Demandを組み合わせるハイブリッド構成を採用した。対話型トラフィックはレイテンシが低いPTエンドポイントに、バースト的なバックグラウンド処理はOn-Demandにオーバーフローさせる設計だ。

スケーリング問題は解消されたが、シングルプロバイダー依存という根本的なリスクは残ったままだった。


フェーズ4:プロバイダー非依存の抽象化レイヤーを構築

記事の題名にある「4段階の進化」とは、①SageMakerによる初期構築、②Bedrockへの移行、③Provisioned Throughput/On-Demandハイブリッド化、そして④マルチクラウド抽象化レイヤーの導入を指している。本節ではその最終フェーズを掘り下げる。

シングルプロバイダー依存リスクを解消するため、SlackはGoogle Cloud Vertex AIを加えたマルチクラウド構成に移行した。

マルチクラウド化で最も重要なのが、プロバイダー非依存のサービングレイヤーの実装だ。Slackが導入した機能は以下の通りである。

  • シークレットレス認証:認証情報をコードやシークレット管理に持たせず、クラウドネイティブな仕組みを活用する。AWSであればIAMロール、Google CloudであればWorkload Identityといった、各プラットフォームが提供するIDベースの認証機構を利用することで、静的なクレデンシャルを排除する考え方だ
  • API正規化:AWSとGoogle CloudのAPIの差異を吸収する統一インターフェース
  • 統合オブザーバビリティ:プロバイダーをまたいだ一元的な監視
  • インテリジェントルーティング:Time-to-first-token・p90レイテンシ・5xxエラー率をリアルタイムで評価し、劣化したエンドポイントから自動的にトラフィックを切り離す仕組み

この抽象化レイヤーはA/Bテストやコントロールされたモデルロールアウトにも対応している。

最終構成の効果として、Slackは複雑な推論ワークロードの品質が約10%向上し、短いプロンプトに対するレイテンシが約67%削減されたと報告している。また、利用可能なファウンデーションモデルの幅の拡大、地理的フェイルオーバー能力の向上、特定クラウドへの依存度低減も得られたとしている。


同様のアプローチは他でも広がっている

類似の取り組みはSlackだけではない。AIルーティングサービスのPadisoはAnthropicのClaudeトラフィックをBedrock・Vertex AI・Anthropic直接APIの3経路に分散させてレジリエンスを高める構成を紹介している。BentoMLもレイテンシと可用性に基づいてトラフィックをルーティングするマルチクラウド・クロスリージョン推論戦略を提唱している。プロバイダー依存の排除・フェイルオーバー・運用の柔軟性という課題意識は各所で共通している。

AIモデルのエコシステムが急速に変化し続ける中で、Slackの事例はアプリケーションロジックをモデルプロバイダーから切り離す抽象化レイヤーの設計が、推論インフラの現実的な選択肢になりつつあることを示している。


詳細はSlack Outlines Four-Phase Journey to a Multi-Cloud AI Serving Platformを参照していただきたい。