機械学習ワークロードを GKE に移行している話
はじめに
こちらはキャディ株式会社のアドベントカレンダーに寄稿しています。
こんにちは、キャディの Analysis Platform Group でバックエンドエンジニアをしています、廣岡です。普段は機械学習推論のためのインフラやバックエンド構築・運用を主に担当しています。
私たちのチームでは Google Cloud のマネージドサービスを使って機械学習システムを構築してきました。しかしここ最近で、運用の複雑化とワークロードの増加により基盤の見直しを検討しました。
ここではキャディ内の機械学習ワークロードを既存のマネージドサービスから Google Kubernetes Engine (GKE) に寄せるにあたっての経緯や、期待・懸念についてご紹介します。近い状況の組織や開発環境の方の参考になれば幸いです。
移行前の構成と課題
機械学習システムの主な役割は、根本的には「適した仕様やパフォーマンスで機械学習の予測結果を提供する」ことと言えます。社内の機械学習システムは、大きく分けて同期推論と非同期推論の２種類があり、Google Cloud の下記サービスを使って構築していました。
- 同期推論：Vertex AI Prediction
- 非同期推論：Compute Engine のマネージドインスタンスグループ
- その他関連するサービスに Cloud Run
これらのサービスは比較的シンプルな機能で使いやすいものの、成長を続けるキャディのサービスを支えていく上でいくつかの限界を感じていました。
運用負荷の増大
デプロイ先が複数のマネージドサービスに分散していることで、CI/CD やロールバック、ログ・トレース収集などの設定方法もサービスごとに異なるため、非機能要件の維持コストが徐々に増大していました。
また、GPU を利用するワークロードについてはそれぞれでキャパシティを管理する必要があり、リソース計画の複雑さも課題となっていました。その他パフォーマンスに課題があった際や障害対応の際もサービスごとの特性を理解したうえでトラブルシュートを行う必要があり、運用負荷が高くなっていました。
キャッチアップコスト
Vertex AI や Compute Engine のマネージドインスタンスグループは便利なサービスですが、Google Cloud 特有のサービスです。これらのマネージドサービスは仕様理解に一定の学習コストがかかり、メンバー間でキャッチアップ速度に差が生じやすい状況でした。
新しく参画するメンバーにとっても、サービスごとに異なる概念を覚える必要があり、立ち上がりに時間を要していました。
今後の開発生産性への懸念
キャディではスケーラブルにサービスを展開していくため、プロダクト全体としてマルチテナント SaaS アーキテクチャを念頭にした構成を目指しています。これに向けて社内の開発スタンダードやプラットフォーム機能は GKE ベースで整備されていますが、Vertex AI などのフルマネージドサービスや Compute Engine を直接使う構成では、こうした社内スタンダードやプラットフォーム機能に準拠しづらいという課題がありました。
GKE 移行への期待と懸念
GKE への移行を検討するにあたってはいくつかの懸念と期待がありました。ここではその背景を整理します。
懸念１： GKE のキャッチアップと運用負荷
そもそも当初 GKE ではなく他のマネージドサービスを選択していた理由として、チーム内で Kubernetes の知識や開発経験が十分に備わっていなかったことがあります。
以前は機械学習のバックエンドやインフラ構成を行うチーム規模も小さく、Kubernetes 特有の学習コストや運用負荷を抱えることが too much に感じられていました。そのような状況では Vertex AI のようなフルマネージドサービスは有望な選択肢でした。
一方で、私は以前キャディの SRE チームに所属していた時があり、多くのワークロードが既に GKE 上に構築されているのを見ていました。これをきっかけに、機械学習ワークロードを本格的に GKE 上に構築するのも有望かつ現実的かもしれないと考えました。
期待１：メンバーのキャッチアップコスト削減
クラウド特有のマネージドサービスに比べて Kubernetes は一般的な利用者やナレッジが多く、新しく合流したメンバーでもキャッチアップしやすいと考えています。社外でも多くのユーザーやプラクティスがあるため生成 AI によるサポートも受けやすく、学習効率の面でもメリットがあります。
同時に社内でも多くのサービスがすでに GKE 上で稼働しており、運用実績がありました。既存の設定や実装を参考にできる点や、困った際に社内の他チームやメンバーに相談できることも、移行時のキャッチアップを後押しする要因となりました。
期待２：エコシステムとしての成熟度
Kubernetes は OSS として成熟しており、多くの基本的な機能やプラクティスが確立されています。そのためクラウド特有のマネージドサービスよりもトラブルシューティングや機能拡張が行いやすく、運用効率の向上が期待できます。
また、社内の GKE クラスタではすでに ArgoCD やサービスメッシュ、KEDA などのエコシステムが導入・運用されており、これらを自然に活用できる点も大きな魅力でした。Google Cloud のドキュメントでも、GKE 上での機械学習ワークロード向けプラクティスが数多く公開されており、参考資料の豊富さという観点でも恩恵があります。
期待３：プロダクトとしての運用の標準化と一貫性確立
社内では既に多くのサービスが GKE 上にデプロイされており、トラブルシューティングの流れや運用プラクティスが蓄積されています。GKE に移行することで、これらのナレッジも参考にして運用標準を整えることができます。
また、デプロイ戦略やオブザーバビリティ、マルチテナント SaaS のための要件など、プロダクト運用上重要な非機能要件を Kubernetes 上で統一的に扱える点も大きな強みです。特に私たちが目指すマルチテナント SaaS アーキテクチャにおいては、共通要件を満たすための社内プラットフォームが GKE 上で整備されています。これらを取り入れやすいことも移行判断を後押ししました。
既存のクラスタか、新しいクラスタか
GKE へ移行するにあたり、どのクラスタを基盤として採用するかについても検討が必要でした。結果的には運用負荷や運用実績の面から既存のクラスタへ移行することを決めましたが、整理すると次のようなメリットや懸念を考えました。
| メリット | 懸念 | |
|---|---|---|
| 既存クラスタ | SRE チームによるクラスタ運用がすでに確立されているため、追加の管理コストをほとんど発生させずにワークロードを展開できる。既存の ArgoCD や KEDA などのツールもすぐに利用可能 | ML ワークロードは GPU や大量の I/O が必要になるケースが多く、既存ワークロードとの混在による影響を避けるための設計が必要 |
| 新規クラスタ | 既存ワークロードとはインフラレベルで完全に分離できるため、コストの可視性や制御性が高まる | クラスタ自体の管理や、ArgoCD などのツール群を新たに導入・運用する必要があり、運用負荷は大きくなる |
補足として、最近では Cloud Run でも GPU が利用できるようになっており、ML ワークロードの実行環境として魅力的と言えます。一方で現時点では日本リージョンで GPU が利用できないことがネックでした。将来的には日本でも GPU 付き Cloud Run が利用できると考えられますが、すぐに十分な台数を確保できるかどうかは不透明であり、キャパシティリスクが大きいと判断しました。
実際に移行に取り組んでみて
これらの検討内容を踏まえて、期待できる内容が今後の ML 開発に十分有益だと判断し、GKE 移行を決断しました。移行は現在進行中ですが、既に次のような洞察が得られています。
懸念に対して
K8s のキャッチアップについては、チーム全員が既存の社内実装やドキュメントを参考にしながら問題なく開発に参加できており、スムーズに進んでいます。確かに K8s エコシステムは多機能で広範ですが、基本的なアプリケーションのデプロイに必要な設定はシンプルで枯れており、基本的な構築で迷う場面は多くありませんでした。
また、この半年ほどで私のいるチームの人数は倍になりました。新しいメンバーの中には Google Cloud の経験がないメンバーもいますが、Kubernetes ベースの構築であればベンダー特有の依存や仕様が少なく、今のところ学習コストを抑えながら開発を進められています。
加えて、社内の既存クラスタではすでにサービスメッシュや CI/CD などの基盤が整備されています。これらを活用することでスムーズに運用体制を構築できている点も、移行を加速する大きな要因となっています。
GKE 移行の恩恵
ML ワークロードの移行はまだ進行中ですが、事前に期待していたポイントの多くでメリットを感じられています。
たとえば既にクラスタにインストールされている ArgoCD やサービスメッシュのおかげで、CI/CD やロールバックなどデプロイに伴うオペレーション、アクセスログなどの構築が非常に容易になっています。
また社内スタンダードへの追従についても恩恵が得られています。社内の Production Readiness Checklist（サービスのプロダクション運用に向けて非機能要件や設定をカバーするためのチェックリスト）や、プラットフォームサービスも K8s 上のサービスを念頭に置いているため、今回の移行によって自然に追従できるようになっています。
今後の展望
GKE に移行することで、機械学習ワークロードについて今後スケーラブルに改善や拡張していくための土台が整ってきています。一方でまだ既存の ML ワークロード全てが移行できているわけではありません。負荷に応じたスケーリングや、これまで通りのパフォーマンスを維持するための検証も引き続き実施していきます。
また将来的には、新しく作った機械学習モデルを簡単にデプロイしたり、本番に近い状態で適切に評価するための仕組みづくりもやっていきたいと考えています。
まとめ
本記事では GKE による ML 推論基盤統一の背景と取り組みを紹介しました。GKE 上での ML 開発は必ずしも全ての組織に適しているわけではありませんが、一定以上の規模の組織やプロダクトでは非常に有力な選択肢になると感じています。
最後に、キャディ株式会社では「製造業 AI データプラットフォーム」という構想のもと、ソフトウェア開発に取り組む仲間を募集しています。
モノづくり産業のポテンシャル解放を目指す弊社にとって、データや機械学習は非常に重要な役割を担っています。サービスとしても急拡大する中で多様なユースケースやスケールへの対応が必要とされており、ソフトウェアエンジニアとしてチャレンジングで面白い経験が得られる環境だと感じています。各種ポジション選考やカジュアル面談など募集中ですので、ご興味がある方はお気軽にご連絡ください！
キャディについて
Discussion