Autopilot: GenAIのためのインフラ管理を自動化する

Autopilotとは

機械学習運用（MLOps）は、時間とリソースを消費する複雑な手作業のプロセスを伴うことがよくあります。TruefoundryのAutopilotは、これらの運用上の負担を解消し、開発者がコード記述に専念し、データサイエンティストがモデルの改良に集中できるようにすることを目指しています。Autopilotは、リソースの最適化と信頼性の修正を自動的に処理し、最小限の人的介入でスムーズなワークフローを保証します。

なぜこれが必要なのか

あらゆるソフトウェア開発ライフサイクルにおける運用課題は、3つの異なる段階に分けられます。

1. Day 0 – 設計と計画: デプロイ前に、アーキテクチャ、プロビジョニング戦略、セキュリティポリシー、スケーリングフレームワークを定義します。
2. Day 1 – デプロイと実装: インフラをセットアップし、アプリケーションをデプロイし、可観測性を設定し、CI/CDパイプラインを確立します。
3. Day 2 – 運用と保守: 継続的に監視し、リソースを自動スケーリングし、セキュリティパッチを適用し、インシデント管理を行います。

これらのプロセスは3つの異なるフェーズで実装されており、責任の分断から自動化による効率化へと進化してきました。

フェーズ1: 開発と運用の分離

これはチームが通常最初に始める段階です。このフェーズでは、運用の3つの段階は通常、以下の内容を含みます。

• Day 0: 開発者はアプリケーション設計に注力し、運用チームはインフラとセキュリティを担当します。
• Day 1: 開発者はアプリケーションをパッケージ化し、デプロイの準備を行い、運用チームはリソースのプロビジョニングと設定に注力します。
• Day 2: 運用チームがスケーリング、監視、セキュリティパッチの管理を行う一方で、開発者は依然として問題のトラブルシューティングを行っています。

この責任の分離は、開発チームと運用チームの間に不必要な摩擦を生み出します。場合によっては共通の語彙が限られているため、コンテキストの共有がより困難になり、問題はさらに深刻化します。

単一のアプリケーションの場合、これは最初のリリースまでに数週間かかることを意味し、その後の運用作業（day 2 operations）には数日かかり、運用チームと開発チームの間で避けられない調整問題が発生します。

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

AI Gateway Evaluation Checklist

A practical guide used by platform & infra teams

フェーズ2：内部プラットフォームの構築

フェーズ2では、組織は内部プラットフォームを導入し、開発チームがほとんどの運用上のレバーを自由に設定・制御できるようにします。運用チームは、プラットフォームをオーケストレーションの層として使用しながら、より強制力のある標準化の役割に移行します。

このフェーズにはいくつかの欠点があります。

• 開発者にとって、このフェーズは、限られたコンテキストや関連する専門知識しかない初期段階で多くの選択をすることを意味します。これは、認知負荷の増加と最適とは言えないリソース計画につながります。
• このアプローチは、運用チームにとって運用領域の爆発的な拡大として現れます。一連の最適とは言えない決定がなされた結果、典型的なチームでは、サービス数とインフラコストが何倍にも増加する可能性があります。

最初は速度が向上するものの、これは開発チームの作業の複雑性が爆発的に増大することで相殺され、その結果、必然的に両チーム間で懸念の衝突が生じます。

フェーズ3：プラットフォームの自動化

第3フェーズでは、プラットフォーム自体がすべての運用上の懸念事項を自動化し始めます。これにより、運用の3つの段階全体で多くの決定を下す必要がなくなります。

これは、開発チームまたは運用チームのいずれからも運用上の選択がほとんど必要なく、「day 0」自体で3つの運用段階が達成できることを意味します。これがAutopilotが目指すものです。

なぜ今なのか

自動化の必要性は以前から明らかでしたが、以下の新しいパラダイムが登場しているため、Autopilotのようなシステムは現在の状況においてさらに不可欠になっています。

マイクロサービス

マイクロサービスアーキテクチャの広範な採用により、組織内のサービス数はカンブリア爆発を経験しました。変更や新しいサービスを本番環境に投入するこの利便性には、監視がより困難になるという裏側があります。Autopilotは、これらのサービスを確実に最適化できるシステムです。

エージェントシステム

エージェントシステムとは、タスクを自律的に実行するシステムです。それらは、必要に応じて動的にスケールアップおよびスケールダウンできる十分な柔軟性を持つバックエンドインフラストラクチャを備えた、堅牢で自己完結型のデプロイ戦略を必要とします。最新のAIエージェントは、最適に機能するために適応性のある効率的なインフラストラクチャに依存しています。これらは、さまざまなレベルの人間による関与を必要とする動的なシステムです。このようなシステムの広範な展開は、すべての運用面が自動化されたシステムでのみ可能であり、そこにAutopilotが関わってきます。

事例紹介

Truefoundryプラットフォームのあるユーザーにとって、開発クラスターのコストは大きな問題でした。約200のサービスがデプロイされており、これは小さな非効率性が複数のサービスで蓄積され、全体として莫大なコスト増加を引き起こす典型的なケースでした。コスト最適化の試みは、個々のサービスレベルで行う必要がありました。この極端な作業要件により、コスト超過は悪化し、優先事項となることはありませんでした。

オートパイロットを有効にしたところ、ある顧客はわずか2つのクラスターで1500ドルのコスト削減を実現できました。さらに、ワークロードがCPU不足に陥っていたり、メモリ逼迫関連の問題を抱えていたりした箇所で、50以上の信頼性関連の修正が適用されました。

‍

オートパイロットで現在できること

‍

CPU、メモリ、ストレージの最適化

オートパイロットは、アプリケーションのCPUとメモリの設定を自動化します。これは、以下の2つの入力ソースを考慮することで実現されます。

• 過去の使用状況: オートパイロットは、アプリケーションの過去の使用状況を分析し、今後の最適な設定を導き出します。
• リアルタイム調整: オートパイロットは、アラートやその他のイベントソースにも反応し、リアルタイムで緩和策を実行することで問題の芽を摘みます。これによりMTTR（平均復旧時間）が改善され、放置すればはるかに大きな問題となる可能性のある多くの問題を事前に防ぎます。

クラスターの健全性

オートパイロットは、Istio、ArgoCD、Carpenterなど、クラスターにインストールされている個々のコンポーネントの健全性とコストも管理します。これらのコンポーネントのいずれかが故障すると、そのクラスターで実行されているワークロードに壊滅的な影響を与える可能性があります。オートパイロットは、リソースの急増を事前に検知し、それらを考慮に入れることで、これらのコンポーネントが機能し続けながらコスト最適に稼働するようにします。

ノード容量

サービスを超えて、オートパイロットは実行中のサービスを支えるインフラストラクチャについても最適化を行います。これは、アプリケーションに最適なノード容量を推奨することを意味します。アプリケーションのメトリクス、環境、その他の要因を考慮して行われます。

オートスケーリング

多くの開発チームは、アプリケーションが直面すると予想される最大負荷に合わせてアプリケーションをスケールします。これにより、これらの余分なレプリカが使用されていないときに多くの追加コストが発生します。明らかな解決策はオートスケーリングの実装ですが、トラフィックパターンが予測できない場合はそれも適用できません。オートパイロットは、各サービスの過去のメトリクスを分析し、アプリケーションの過去の特性に基づいてオートスケーリングを有効または無効にするための推奨事項を生成します。

‍

次のステップ

本番環境でオートパイロットを使用することで、コストと信頼性の面で既に多くの成果が見られますが、以前に掲げた完全な自動化のビジョンを実現するためには、さらに多くのことを行う必要があります。次に自動化すべき運用上の懸念事項の一部は以下の通りです。

• 定期的なオートスケーリング - 過去のトラフィックを考慮して定期的なオートスケーリングを予測し実装することで、スパイク性の高いワークロードに対してもオートスケーリングを有効にできるようになります。
• 自動シャットダウン推奨 - 使用されていないサービスやワークロードを特定し、シャットダウンすることで、大幅なコスト削減につながります。
• 自動ベンチマーク — サービスの必要リソースを推定することはすでに可能ですが、ライブまたはシミュレートされたトラフィックでベンチマークを実行し、影響を受けるビジネス指標を観察することで、より正確な推定が可能です。Autopilotは、ほとんどの開発チームにとって非常に時間のかかるこのプロセスを自動化することを目指しています。
• クラスターインフラ最適化 - 業界全体のクラスターCPU使用率は平均10%です。 リンク 。CPUに関するアプリケーションの設定ミスがその大部分を占めますが、その大部分は、基盤となるインフラストラクチャにおける負荷分散の非効率性にも起因しています。これは、多くのノードが十分に活用されていなかったり、小さすぎるノードがデーモンセットなどでスペースを無駄にしていたりする形で現れます。インフラのプロビジョニング設定を修正し、クラウドレベルでKarpenterのようなツールを活用することで、この側面を大幅に改善できます。

結論

TruefoundryのAutopilotは、MLOpsの進化における革新的なツールであり、ソフトウェア開発ライフサイクル全体にわたる重要な運用課題に対処します。Autopilotは、リソースの最適化、クラスターの健全性管理、オートスケーリングを自動化することで、チームが運用上のオーバーヘッドではなくイノベーションに集中できるようにします。マイクロサービスやエージェントシステムの普及が続くにつれて、このような自動化の必要性はますます高まっています。その現在の機能と意欲的なロードマップにより、Autopilotは組織が運用効率、信頼性、コスト最適化に取り組む方法に革命をもたらすでしょう。

‍