TrueFoundryのビジョン

全体的なビジョン：すべてのベストプラクティスに従い、サービスの作成と管理を容易にし、システム、データ、コスト、影響の監視を含むインフラストラクチャの全体像を完全に把握できるようにする開発者プラットフォーム。初期段階では機械学習に注力します！

TrueFoundryのビジョン（5～10年後）

TrueFoundryは、その核として、マイクロサービスの実行と管理において開発者エクスペリエンスをシームレスにすることを目指しています。適切な抽象化レベルによって、開発者が非常に高いイテレーション速度でビジネスロジックの記述に集中できるような環境を提供します。

コードを記述した後、ジーニーを呼び出し、サービスの種類（サーバーレス、CronJob、データベース、APIサービスなど）やCPU、メモリなどのリソース要件を伝えると、ジーニーはGitOps、Infrastructure as Code (IAC) などのベストプラクティスに従ってサービスを作成し、作成されたすべてのメトリクスを含むダッシュボードを表示してくれる、という流れを想像してみてください。

ServiceFoundryで以下のことを達成したいと考えています。

IACを使用した一元的なインフラストラクチャプロビジョニング

ServiceFoundryは、ユーザーのクラウド上に最も一般的に使用されるオープンソースのインフラストラクチャコンポーネントをプロビジョニングし、ホストします。その例をいくつか挙げます。

1. セキュリティのベストプラクティスが構成されたKubernetesクラスターの起動。
2. Kafka、Spark、Redis、Prometheus、Grafanaなど、一元化されたインフラストラクチャコンポーネントのインストール（またはマネージドサービスの使用）。
3. AWS Elastic Searchのような一部のサービスには、クラウドマネージドサービスを利用できます。
4. データベース、ストレージレイヤーの起動。（当面はマネージドバージョンを使用）
5. Airflow、Argoなどのパイプラインオーケストレーションシステム。
6. CI / CD (Github Actions, Gitlab, AWS Code pipelines)
7. ログ集約 (ELK, EFK)
8. 監視 (標準およびカスタムメトリクス)
9. アラート

サービスの作成

1. 設定可能なテンプレートに基づいてサービスを構築し、デプロイします。ServiceFoundryは、以下の自動化を目的とした独自の原則に基づいています。

• 依存関係管理とパッケージング (Docker、Zip)
• テスト
• 設定管理 (静的および動的に変化する設定)
• インフラストラクチャプロビジョニング (以前にプロビジョニングされた集中型インフラストラクチャ上に)
• オートスケーリング設定
• CI/CD
• ログ集約
• 標準メトリクスによるダッシュボード生成 (ユーザーはカスタムメトリクスを追加可能)
• アラート

上記と同様に、MLモデルやデータベースについても同様に行いたいと考えています。

ServiceFoundryは、標準的な種類のサービスのデプロイと監視を効率化することを目指します。

1. ロードバランシングされたAPIサービス (異なるパラメータに基づくオートスケーリング付き)
2. ジョブサービス (Cronジョブ、イベントによってトリガーされるジョブ)
3. サーバーレス
4. ステートフルサービス
5. 静的ウェブサイト

サービスカタログとグラフ

ServiceFoundryを使用して作成されたすべてのサービスは、完全なメタデータとともに一箇所で確認できます。このカタログには、開発、ステージング、本番などの各アプリケーションのすべての環境も表示されます。これにより、開発者やビジネスリーダーが組織内で実行されているサービスを確認できる開発者プラットフォームポータルが実現します。各サービスに関連付けられている主要なメタデータの一部は次のとおりです。

1. GitHubリポジトリへのリンク
2. 設定
3. モニタリングリンク
4. チームとオーナー
5. 異なるアクセス権限を持つメンバーを追加できる機能。
6. コスト

TrueFoundry MLOps（MLファーストプラットフォーム）

TrueFoundryの当初の焦点は、モデル構築後のパイプラインに特化し、データサイエンティストがモデルのデプロイ、監視、再トレーニングを非常に容易に行えるようにする、シームレスなMLOpsプラットフォームを提供することです。

機械学習パイプラインは、以下の一元化されたインフラストラクチャで構成されています。

関連する各ステップの簡単な説明は以下の通りです。

1. データパイプラインと特徴量ストア： これは本質的にビッグデータの問題であり、データレイクからモデルで使用する特徴量を計算し、トレーニングと本番環境の両方で必要とされる時間制約内で、不整合なく利用できるようにする必要があります。通常、Airflow、Argo、Kubeflow Pipelinesのようなワークフローオーケストレーションエンジンが使用されます。
2. モデルトレーニング： モデルトレーニングは、本質的に複数のマシンで実行できる計算負荷の高い分散ジョブです。また、チェックポイントの保存と復元を通じて、組み込みの回復力も提供する必要があります。
3. モデルサービング： これは基本的に、モデル予測を行うためのリクエストを受け取り、GPU、高い計算能力、メモリ要件など、様々な要件を持つマイクロサービスです。各モデルは通常、単一のマイクロサービスとしてホストされます。そのため、チームが数十のモデルにスケールアップすると、数十のマイクロサービスを管理する問題となり、それ自体が大きな課題となります。
4. モデルモニタリング： これには、システムメトリクス監視と、モデルのパフォーマンスや劣化に関連する機械学習固有の監視の両方が含まれます。また、ログデータを保存し、それに対して集計を実行し、最終的にメトリクスを計算するシステムも必要とします。
5. モデル管理： これは、モデルとその異なるバージョンや実験に関連するすべてのデータを追跡します。後で問題をデバッグしたり、ロールバックしたりするのに非常に役立ちます。

非常に多くの可動部分と異なる技術が関与しているため、通常、データエンジニア、データサイエンティスト、MLエンジニア、DevOps、プロダクトマネージャーなど、複数の人々がMLプロジェクトに関与します。成功するプロジェクトには、これらすべての異なる役割の人々の間の調整が必要であり、これが多くの遅延を引き起こし、データサイエンティストの作業速度を妨げます。

企業における機械学習パイプラインの一般的なワークフローは次のようになります。

MLプラットフォームの主な目的

MLパイプラインにおいて自動化可能な部分を自動化し、データサイエンティストが本番環境でモデルをテストし、他チームへの依存を最小限に抑えながら迅速に反復できるようにすることを目指しています。この動機は、トップテック企業のプラットフォームチームが開発した製品に由来しており、それらの製品は、すべてのチームがより迅速に動き、自律的にデプロイおよび反復することを可能にしています。

現在、データ関連の問題は扱っていません。そのセクションについては後ほどご紹介します。

主要なMLプラットフォームは、以下のサービスで構成されます（中央インフラストラクチャを除く）。

1. トレーニング（異なるトリガーを持つスケジュールされたジョブ）
2. モデルサービス（ロードバランスされたAPIサービス）
3. ストレージ（アーティファクト、データセット、モデル推論データ）
4. MLモニタリングサービス（データからメトリクスを計算するサービス）
5. 特徴量エンジニアリングサービス

これらのサービスを簡単にデプロイし、異なるステージ間でバージョン管理を維持し、それぞれのモニタリングを生成できれば、ML Opsの問題ははるかに単純なものになるでしょう。

このブログはMediumで最初に公開されました https://abhishekch09.medium.com/d8e159743a4b