3人で1000GPU超を統合運用する？マルチクラウド＆オンプレを跨ぐ、構築と運用のリアル！
概要
Turingでは、完全自動運転AIの開発を支えるため、計1000GPU以上に及ぶ計算基盤をわずか3人で運用しています。その内訳は、オンプレミスの自社GPU基盤「Gaggle Cluster」、国内GPUクラウドの「GMO GPUクラウド」、そしてGCP / AWS上のGPUクラスタと多岐にわたります。 クラウド環境では、Terraform / Terragruntによるプロビジョニング、Packerによるイメージ作成、startup script、Ansible playbookを組み合わせて再現性を担保しています。しかし、GMO GPUクラウドやオンプレミス環境に同じ抽象化をそのまま適用することはできません。また、AWSとGCPの間でも、利用可能なサービス、GPUの調達状況、リージョン特性、ノード交換の発生条件は大きく異なります。 本セッションでは、「全部を同じ仕組みに揃える」という理想を追い求めるのではなく、「環境ごとの違いを受け入れながら、同じ思想で統合運用する」ためのInternal Platform設計を紹介します。クラウドではインスタンスの再作成を前提とした復元性を重視する一方、オンプレミスではクラウドで培ったAnsible roleや監視パターンを移植し、クラスタ間の差分を現実的なアプローチで減らしていく泥臭い工夫を語ります。 さらに、少人数での運用を成立させるための省力化の仕組みとして、Datadog / New RelicによるObservability、Slackから起動できるRead-onlyなSRE調査AI Agent（主にDevin）、Rundeck / PagerDuty AutomationによるRunbook Automationの整備状況についても触れます。異常検知からAI Agentによる一次調査、承認付きの復旧操作、IaCによる恒久対応を一つの運用ループとして設計し、各クラスタの制約に合わせて最適化していく過程を、実際の失敗談やトレードオフを交えて共有します。
platform engineeringGPU clusterSlurmIaCTerraformTerragruntPackerAnsibleDatadogAI agent
スピーカー
完全自動運転AIの開発を支えるGPU学習基盤およびマルチクラウド運用基盤の設計・運用を担当。MLOpsチームも兼任し、学習高速化や学習基盤のObservability向上にも取り組む。これまで、ディープテック企業やクラウドプロバイダーをはじめ、国内外のさまざまな企業で、サービス開発（フルスタック）、SRE、ML Platform、クラウド／オンプレミスインフラの設計・実装・運用・提案に幅広く携わる。最近は釣りにハマっている。