MLOpsプラットフォーム（機械学習のライフサイクル全体を管理する基盤）を、クラウドのマネージドサービスからセルフホストに移すとき、最初に直面するのはコストではなく運用設計の問題です。Google Cloud の Vertex AI は実験管理・学習ジョブ・モデルレジストリ・推論エンドポイントを一括提供しますが、GCP 固有の API に依存するため、他のクラウドやオンプレミスへの移植性が低くなります。ClearML はその代替となるオープンソースの MLOps プラットフォームで、Docker が動く環境であればどこにでも展開できます。
マネージドサービスとセルフホストの運用コスト構造の違い
Vertex AI のような従量課金型サービスは、学習ジョブの実行時間・ストレージ・推論リクエスト数でコストが積み上がります。予測しにくい増加要因があるため、MLパイプライン（一連の学習処理を自動化したワークフロー）を頻繁に回す環境では、月次コストが変動しやすい構造になります。
セルフホストに切り替えると、コストはインフラの固定費に変わります。その代わり、監視・バックアップ・バージョンアップといった運用作業が自組織の責務になります。ClearML サーバーは内部で Elasticsearch（全文検索エンジン）・MongoDB（ドキュメントDB）・Redis（インメモリKVストア）の 3 つを使います。これらはそれぞれ異なる障害パターンを持つため、監視対象も増えます。
たとえば Elasticsearch は起動時に OS レベルの仮想メモリ上限を `vm.max_map_count=524288` 以上に設定しておかないと、コンテナが起動直後にクラッシュします。この値はデフォルトの Ubuntu では 65530 程度なので、設定変更を忘れると原因が分かりにくい障害になります。
コンポーネント別の障害パターンと監視設計
ClearML の構成要素は、Vertex AI の機能と次のように対応しています。
- Vertex AI Experiments → ClearML Experiment Manager（メトリクス・成果物を自動記録）
- Vertex AI Training Job → ClearML Agent + Tasks（キュー経由で任意マシンをワーカーにする）
- Vertex AI Pipelines → ClearML Pipelines（Python ネイティブの DAG で追加コンパイル不要）
- Vertex AI Model Registry → ClearML Model Repository（バージョン管理とリネージ追跡）
- Vertex AI Endpoints → ClearML Serving / Triton（カナリアリリース・A/Bテストに対応）
それぞれのコンポーネントで監視すべき点が異なります。Experiment Manager は MongoDB への書き込みが正常に機能しているかを確認します。ClearML Agent は対象キューをポーリング（定期的に確認する処理）しているため、エージェントプロセスの死活監視が必要です。推論を担う Triton Inference Server はモデルの読み込みに失敗しても起動自体は成功するため、モデルごとのヘルスチェックエンドポイント（`/v2/models/{name}/ready`）を個別に叩く必要があります。
リバースプロキシ（外部からのリクエストを内部コンポーネントに振り分けるサーバー）として Traefik v3 を使う構成では、Let's Encrypt による TLS 証明書の自動更新も Traefik が担います。証明書の取得に失敗すると API・Web UI・ファイルサーバーの 3 つのサブドメインすべてが HTTPS で応答できなくなるため、`acme.json`（証明書のキャッシュファイル）のパーミッションが 600 であることと、DNS の A レコードが正しく引けていることを事前に確認しておく必要があります。
オンプレ・プライベートクラウド移行時のデータ管理の考え方
Vertex AI からの移行で最も見落とされがちなのは、学習データと成果物のストレージ設計です。Vertex AI では Cloud Storage がバックエンドとして透過的に使われますが、ClearML のファイルサーバーはローカルディスクにデータを保存します。
シード記事では `/opt/clearml/data/` 以下に Elasticsearch・MongoDB・Redis・ファイルサーバーのデータをそれぞれ分離して配置する構成を示しています。本番運用では、このディレクトリをブロックストレージ（AWS EBS・GCP Persistent Disk・オンプレの NFS など）にマウントしてホスト OS から切り離し、スナップショットによるバックアップを設定するのが一般的なパターンです。
# Elasticsearch の起動前チェック例
curl -s http://localhost:9200/_cluster/health | python3 -m json.tool
# status が "green" または "yellow" であることを確認
# "red" の場合はシャード割り当て失敗を意味するKubernetes 環境に移行する場合は、ClearML の公式 Helm チャートを使う選択肢もあります。Docker Compose による単一ノード構成は検証や小規模チームには十分ですが、エージェントを多数並列化したい場合や高可用性（HA）が求められる場面では、Kubernetes 上での PersistentVolume 設計が現実的になります。
移行を段階的に進めるなら、まず ClearML をサイドバイサイドで立ち上げ、既存の Vertex AI ワークロードと並行して実験メトリクスを ClearML にも送るところから始めるのが、リスクを抑えた現実的なアプローチです。ClearML のクライアントライブラリはコード変更なしに自動でメトリクスをキャプチャするため、既存の学習スクリプトへの影響を最小化できます。
セルフホストの MLOps プラットフォームは、ベンダーロックインの解消と引き換えに運用責務を引き受ける選択です。その責務の範囲を事前に正確に把握することが、移行判断の出発点になります。