TrainyがAmazon RDS PostgresからClickHouse Managed Postgresに移行した理由

Y Combinator出身の企業 Trainy を創業する前、Roanak BaviskarとAndrew Aikawaは同じチームのMLエンジニアでした。2人は100台を超えるGPUマシンのプールを他の約20名のエンジニアと共有しており、その割り当ては「基本的にホワイトボードに書いて先着順で確保する」というやり方でした。エンジニア一人ひとりに独自の締め切りと計算リソースの必要性があります。Roanakいわく、「会社が本当に必要としていることと、計算リソースの割り当て方をすり合わせるのが本当に難しくなっていった」のです。

RoanakとAndrewは、この問題を解決するためにTrainyを立ち上げました。2つある中核製品の1つ目がKonduktorです。これは、エンジニアが自分たちのマシン群でAIワークロードをスケジューリングするためのCLIです。GPUの健全性、ネットワークの健全性、ロギング、デバッグといった要素を扱ってくれるため、MLエンジニアはRoanakの言葉を借りれば「DevOpsではなく、純粋にMLエンジニアリングに集中できる」ようになります。

今回はRoanakとAndrewに話を聞き、Trainyの最新製品であるPlutoについて、そしてAmazon RDSから ClickHouse Managed Postgres への移行によって、製品をより高速かつ低コストで運用できるようになりながら、同時に統一された一つの基盤にまとめられた経緯をうかがいました。

Pluto: オープンソースの実験トラッカー #

MLエンジニアの仕事は基本的に2つに分かれます。1つはモデルを訓練し、そのための計算環境を整えること。これがKonduktorが扱う領域です。もう1つは結果の分析、つまり実行結果、メトリクス、比較を追いかけながら、次に何を変えるべきかを見極める作業です。

長年、この後者の作業に最適なツールはNeptune AIでした。しかし2025年後半、NeptuneはOpenAIに買収され、製品は終了となりました。その結果、Trainyの多くの顧客は、それまでワークフローの中核を担っていた実験トラッカーを失うことになりました。代表的な代替であるWeights & Biasesも試したものの、規模面で同等のパフォーマンスは得られませんでした。

そこでTrainyは、オープンソースの実験トラッカーである Pluto を開発しました。オープンソースであることは、顧客にとって非常に重要な要素です。「本質的に、Neptuneのようなことが二度と起こらないようにするためです」とRoanakは言います。「たとえ我々が買収されたとしても、顧客からこの製品を取り上げることはできません」。

パフォーマンスも極めて重要です。MLエンジニアは同時に数十本の訓練実行を眺め、それぞれが数千のメトリクスを抱えており、その中からモデルを動かすアーキテクチャやハイパーパラメータの変化を探しています。「一日中、たくさんの違うダッシュボードを見ています」とRoanakは説明します。「そのダッシュボードは非常に高速にロードされ、非常に素早く更新されることが期待されており、非常に大量のデータを非常に速く取り込めることも期待されているのです」。

Konduktorも併用しているチームでは、2つの製品が一つのシステムとして連携し、Trainyはさらにその上で統合機能を構築しています。ある顧客はMCP層を介してPlutoをLinearに接続し、Konduktor経由でGPUジョブを起動し、Claude Codeから実験結果を要約する運用を実現しました。Web UIを一度も開くことなくです。

実験トラッキング用途にClickHouse Cloudを選んだ理由 #

Plutoの中核機能の1つは、多数の実行と多数のステップにまたがるサマリービューを提供することです。この要件だけを取っても、OLAPデータベースが必要になるのは明らかだったとAndrewは語ります。ネットワーク経由でつながっている多くのオブザーバビリティ企業のリーダーたちが、既にClickHouseに頼っていることは知っていました。「それには絶対に理由があるはずだと考えました」とRoanakは言います。

彼らはまずAWS上の ClickHouse Cloud から始めました。「オンボーディングは本当に簡単でした」とAndrew。数時間のうちにコンソールからインスタンスを立ち上げ、データベースの接続文字列を取得して、EKSデプロイメントに環境変数として組み込みました。

最初に実感したメリットの1つは、スケーリング管理の容易さ でした。これは特に初期段階で、トラフィックが断続的に来て、その合間はサービスがアイドル状態になるようなときに役立ちました。「立ち上げ時のコスト最適化という意味で、これは非常に有難かったですね」とAndrewは言います。「ClickHouseインスタンスのスケーリングを自分たちで考える必要はなく、そのまま最初から手に入るのです」。

事業が成長するにつれ、Query Insights も重要な機能となりました。Andrewが説明するには、パフォーマンスのボトルネックを見つけ、その原因が自分たちのサービスなのか、最適化されていないクエリなのかを見極めることは、アプリを構築する上で最も難しい部分の1つです。「コンソール上のQuery Insightsのおかげで、クエリを遅くしている原因を突き止めるうえで80〜90%は済んでしまいます。自分たちでそのツールを作るよりもはるかに速く反復できます」。

初日から、データ取り込みは100%の信頼性で動作しており、これは実験トラッカーにとって「非常に重要」だとRoanakは指摘します。「最初の顧客がログを取り始めて以来、データポイントを一度も落としたことがありません」と彼は言います。「これを可能にしたのは間違いなくClickHouseです」。

Plutoを使うMLエンジニアにとって、最終的にはすべてパフォーマンスに帰着します。「これが実験トラッキングのアプリである以上、クエリ速度がすべてです」とRoanakは言います。顧客の実行は数十万ステップにわたることも多く、Plutoの可視化を支えるクエリはP50で通常50〜100ミリ秒で返ってきます。この速度は「アプリケーションにとって成否を分ける」ものであり、ClickHouse Cloudがそれを顧客に届けることを可能にしているとRoanakは強調します。

RDS Postgresからの移行 #

Plutoのデータすべてがオルタナティブなストアに属するわけではありません。Andrewが説明するように、メトリクスはオブザーバビリティデータのように振る舞い、時系列に沿って平均やmin/max演算を扱いたいものです。これらはClickHouseに置かれます。それ以外のリレーショナルなデータはPostgresに置かれ、実行の作成時刻から、開始時のハイパーパラメータ、ユーザーが追跡したいその他のメタデータまでを含みます。

Trainyは当初、そのPostgres層をAmazon RDS上に構築しましたが、2つの面で問題になりました。1つはコストです。「RDSで最初に使い始めたデフォルト設定は、我々の見ていた規模に対しては高すぎました」とAndrewは言います。もう1つの問題は速度でした。「ロード時間が遅くなっているのに気づきました。ユーザーが最初にページをロードした際、アプリが実験に関するメタデータをRDSからリクエストする必要があったからです」。

彼らは既にClickHouse Cloudに満足していたユーザーだったため、ClickHouseがマネージドPostgresサービスを発表した 時、すぐに魅力を感じました。「既にClickHouse Cloudにいたので、同じアカウント内で試すのはとても簡単でした」とRoanakは言います。

大きな魅力の1つはストレージでした。ClickHouse Managed Postgresは、多くのマネージドPostgresサービスが利用しているネットワーク接続型ストレージではなく、ローカルNVMe上で動作します。ストレージがネットワーク越しではなくコンピュートのすぐ隣にあるため、ディスクアクセスが高速になります。「NVMeストレージは非常に大きな恩恵で、我々のWebアプリケーションの実際のユーザーにとっても大きな恩恵になりました」とAndrewは言います。

Plutoの分析処理は既にClickHouse Cloud上で動いていたので、メタデータ層もそこに移すことで、両方のデータベースが1つのアカウント、1つのベンダーの下にまとまりました。このメタデータは決して小さくなく、移行時点でおよそ40〜50 GBあり、プラットフォームが拡大するにつれてさらに成長すると見込まれています。

ClickHouse Managed Postgresでページロードが最大3倍高速に #

移行前後のセッションデータを比較すると、ClickHouseがマネージするPostgresでの初期ページロードは、Amazon RDS上のものと比べて2〜3倍高速になっています。これらのページロードは実行メタデータの取得に依存するため、ストアが速ければアプリもユーザーにとって速くなります。「全体として、レスポンスが大幅に良くなりました」とAndrewは言います。「そのミリ秒は顧客体験にとって本当に重要です。ユーザーは1日に300回もダッシュボードを更新しているので、積み重なると大きいのです」とRoanakは付け加えます。

移行後にAndrewがClickHouseチームに送ったSlackメッセージ。

Trainyはページロードのパフォーマンスをテレメトリで追跡し、リリースごとに改善を進めています。ClickHouseがマネージするPostgresに移行して以来、ユーザーもその違いに気づいています。あるユーザーは「今までで一番速い見た目だ」と評しました。

別のユーザーは、どの実行が完了し、どれがクラッシュしたかを特定するために複雑なクエリを利用しています。以前はこの実行に10〜15分かかっていましたが、今ではわずか5秒で結果が返ってきます。

パフォーマンスを追求してレイテンシを下げることは、Plutoにおける顧客体験を改善するうえで最も重要な要素です。だから、ClickHouseがマネージするPostgresで得られた結果を見た瞬間に、迷いはありませんでした。

— Roanak Baviskar、共同創業者兼CEO

TrainyとClickHouseの今後 #

Trainyの次の優先事項の1つは、ClickHouseとPostgresの両方にまたがるPluto内のデータに対するエージェント的アクセスを深化させることです。既に着手しているMCP連携を基盤に、エンジニアは実験を自動化し、エージェントにモデルを最適化させることができるようになります。これは、Andrej Karpathyが autoresearch プロジェクトで示した例と似たものです。

もう1つはファイナンシャルオペレーションです。あるMLエンジニアリング担当ディレクターは、各プロジェクトの先月あるいは先四半期のコストを知りたいと考えています。それには、ClickHouseにあるGPU時間とシステムレベルのメトリクスと、Postgresにある実行操作を結合する必要があります。現在これらは別々のストアに存在していますが、クエリを統一できれば、どの研究者がどのプロジェクトで何GPU時間費やしたかを一目で把握でき、Andrewの言葉を借りれば「GPU支出の優先順位をどこに置くべきかについてのインサイトを人々に提供する」ことができます。

どちらの優先事項も、ClickHouse Cloudがネイティブで提供している機能に紐づいています。ClickHouseのリモートMCPサーバー は、エージェントに対してガバナンスと権限スコープの効いた形でClickHouseのデータへのアクセスを提供します。一方、プラットフォームのマネージド取り込みサービスである ClickPipes は、CDCを通じてPostgresのデータをClickHouseにレプリケートできるため、メトリクスとメタデータをまとめてクエリできるようになります。

混沌として整合の取れない計算リソース配分の問題を解決するために3年前にTrainyを立ち上げた2人、RoanakとAndrewは、ClickHouse Cloudを表現する言葉について完全に一致しています。それは「信頼性が高く、簡単で、速い」というものです。