2023年の機械学習デプロイメント

アプリケーションとインフラストラクチャのデプロイは複雑なプロセスであり、インフラチームとアプリケーション開発チーム間の連携が必要です。内部開発者プラットフォームは、両チームがより少ないミスで迅速に作業を進めるのに役立ち、その結果、生産性が向上し、安定性が高まります。

デプロイメントとソフトウェアライフサイクルにおいて考慮すべき主要な事項

1. Docker化 バージョン固定による依存関係のパッケージ化は再現性にとって重要です。不要な依存関係を含むDockerイメージは、Dockerイメージを肥大化させ、起動時間の増加につながる可能性があります。
2. デプロイモードの選択： デプロイには多くの選択肢があります。ウェブサービス、ジョブ、サーバーレスメソッド、静的ウェブサイトなど、それぞれに長所と短所があり、トラフィックパターン、レイテンシ要件、メモリおよびCPU要件に基づいて最適な方法となり得ます。
3. スケーラビリティ スケールは多くの問題を引き起こし、スケーリングポリシーの適切な設定、オートスケーラーの構成、サービスのステートレス化の確保が必要です。同時にコストを最適化しながら。
4. 監視とデバッグ性： 異なるバージョンのソフトウェアを比較するにはどうすればよいでしょうか？ログ、メトリクス、カスタムメトリクスの記録とダッシュボードでの監視は非常に簡単であるべきです。
5. シークレット管理とセキュリティ： 適切なシークレット管理のサポートが必要です。また、認証情報を共有するのではなく、サービスアカウントを使用して他のシステムへのアクセスを提供する必要があります。
6. 自動化とCI/CD： 優れたCI/CDパイプラインを持つことは、迅速な開発とバグの発見にとって非常に重要です。ワンクリックで新しい環境をシームレスに作成できること。開発環境からステージング、本番環境へと自動化された方法で移行できることで、プロセスがはるかにスムーズになります。
7. バージョン管理、イミュータブルデプロイメント、ロールバック： シークレット値とともにデプロイメントを簡単にロールバックできるべきです。現在のすべてのシステムでは、最後の環境変数またはシークレット値のセットでデプロイメントをロールバックすることはほぼ不可能です。
8. 複数の環境： 複数の環境を管理したり、動的な環境を立ち上げ/停止したりできることは、開発者がより隔離された方法でテストするのに役立ち、全体的な進捗をより迅速かつ低コストで実現します。
9. APIセキュリティと認証 — 外部および内部APIの認証 — シンプルなユーザー名とパスワードによる認証、OIDC認証、サービスアカウント、ベアラートークン？
10. レート制限とロードバランサーの設定 — すべてのAPIに組み込むべき一般的なベストプラクティス（ロードバランサーの設定）
11. デプロイの速度と自律性 — 開発者はデプロイから切り離されるのではなく、デプロイを制御していると感じるべきです。彼らを情報共有の輪に入れ、自律的に行動できるようにしつつ、人為的なミスによってコアインフラが破損しないようにすることは、このプラットフォームの主要な目標の一つです。
12. コスト最適化 — 最適なハードウェアと最適なデプロイタイプを選択することが、これを最適化するのに役立ちます。
13. インフラとアプリケーションの変更の調整: ある環境から別の環境へ移行する際、インフラの変更も同時に展開する必要があることがよくあります — これを見落とすと、本番環境でアプリケーションが動作しなくなる原因となります。
14. ABテスト / トラフィックシェーピング

TrueFoundryとは？

企業向けの内部開発者プラットフォームとして機能するデプロイプラットフォームです。その目標は、開発者がインフラに関する詳細な知識がなくてもアプリケーションを簡単にデプロイおよび保守できるようにすること、そしてインフラ/DevOpsチームがエンジニアリングおよびセキュリティのベストプラクティスを強制するためのポリシーを簡単に作成できるようにすることです。

TrueFoundryプラットフォームの主要な設計原則は何ですか？

1. 完全なAPI駆動型アーキテクチャ — — TrueFoundryは、Kubernetesと非常によく似た完全なAPI駆動型アーキテクチャを採用しています。これにより、ユーザーはその上にインターフェース、UI、および自動化を構築できます。
2. Kubernetes上に構築された拡張可能なPaaS — Kubernetesが許可するコア機能に対して、複数のプラグインでカスタマイズ可能です。
3. GitOps駆動型 （GitOps以外のモードもサポート）
4. 導入初日からきめ細やかなアクセス制御
5. Infrastructure as Code (Terraform) — どんなクラウドアカウントでもすぐに立ち上げ可能です。
6. セキュリティ・バイ・デフォルト — TruefoundryはPOLP原則（最小権限の原則）に従い、サービスアカウントの利用、TLS、保存データの暗号化、エアギャップ環境のサポートといったセキュリティのベストプラクティスを採用しています。
7. 設計段階からクラウドネイティブ — 当社は、設計段階からクラウドネイティブであり、すべてのクラウドプロバイダーで利用可能なコンポーネントを意図的に選択しています。

TrueFoundryでサポートされている主な機能

複数のクラウドにわたるさまざまなデプロイ方法：

トラフィックパターン、CPUおよびメモリ消費量に基づいて、ワークロードの種類によって最適なデプロイ方法は異なります。目標は、Kubernetes上のサービス、Kubernetes上のジョブ、AWS Lambda、Kubernetes上のサーバーレス（Knative）、Google Cloud Run、モデルサーバーなど、複数のシステムにわたるデプロイメントのための単一インターフェースを提供することです。TruefoundryはGitリポジトリと統合されており、任意のGitリポジトリから直接デプロイできます。

ジョブ全体のメトリクスとグラフのログ記録および可視化

TrueFoundryを使用すると、開発者は詳細なメトリクス、パラメータ、画像、プロット、アーティファクトをログに記録でき、詳細なダッシュボードを使用してジョブの実行を比較できます。

ソフトウェアカナリア / シャドウテスト

TrueFoundryは、シャドウテストによって、既存の本番環境に影響を与えることなく、ライブデータで新しいバージョンのソフトウェアを簡単にテストできるようにします。また、新しいバージョンにトラフィックを徐々に移行することで、ソフトウェアのカナリアリリースも可能です。

シークレット管理

開発者はシークレットを作成し、アプリケーション内で参照できます。シークレット管理の主な機能の一部：

1. シークレットストレージは、Vault、AWS Secrets Manager、Google Secrets Manager、AWS Parameter Storeなどのシークレットストアによってバックアップされています。実際のシークレット値はプラットフォーム自体には保存されません。
2. プラットフォームは、どのシークレットがどのアプリケーションで使用されているかを追跡します。そのため、シークレットが変更されるたびに、対応するサービスを再デプロイするようユーザーに促すことができます。
3. プラットフォームはシークレットのバージョンを管理し、対応するシークレットバージョンとともにアプリケーションのロールバックを可能にします。

シークレットへのアクセス制御 — 閲覧者はシークレットのキーは確認できますが、シークレットの値は確認できません。この方法により、DevOps/インフラチームはシークレットの値を公開する心配なく、開発者とキーを共有できます。

マルチクラスター管理とデプロイ

Truefoundryは複数のクラスターとの統合と、それら全体でのアクセス制御管理を可能にします。Truefoundryはクラスターの認証情報を一切保存しないため、社内の様々なユーザーにとって安全です。

チームごとのKubernetesアクセス制御

Truefoundryは、Kubernetesの名前空間にアクセス制御を適用し、リソースクォータを設定して異なるチームに割り当てることを容易にします。これにより、開発者はより自律的に作業できるようになり、同時にインフラの安定性、コスト管理、セキュリティが確保されます。

プラットフォーム上で直接閲覧可能な基本的な監視およびログUI

TrueFoundryは、お客様が使用したいログまたはメトリクスプラットフォームについて、特定の意見を持つものではありません。ここでの目的は、いくつかの一般的なログおよび監視ソリューションと統合し、プラットフォーム上で概要を素早く表示できるようにすることです。より詳細でカスタマイズ可能なビューについては、Prometheus、Loki、ELK、Datadog、NewRelicなどの既存の監視ソリューションのご利用をお勧めします。

デプロイされ稼働中の全サービスの統合ビュー（サービスカタログ）

サービスごと、チームごと、エンジニアごとのレベルでのコスト見積もりと最適化。

サービスごとまたはチームごとのレベルでコスト見積もりと最適化を追跡できるようにしたいと考えています。すべてのエンジニアにコストの可視性を公開するだけで、コスト最適化への意識が生まれ、特定のチームへの負担が軽減されます。

あらゆるTerraformモジュールのデプロイ（これにより、あらゆるマネージドデータベース、キュー、またはキャッシングサービスのデプロイが可能になります）

DevOpsチームまたはインフラチームが作成したTerraformモジュールを使用して、クラウドサービスのデプロイを可能にしたいと考えています。例えば、DevOpsチームがデータベース作成用のTerraformモジュールを作成し、開発者はRDS用のTerraformモジュールに基づいてUIからデータベースをプロビジョニングできます。これは、後述のプラグインフレームワークとKubernetes上のTerraformコントローラーに依存します。

TrueFoundryは既存のスタックと連携できますか？

TrueFoundryでは、車輪の再発明を避け、既存のシステムを可能な限り活用したいと考えています。そのため、多くの既存のインフラツールと統合しており、ユーザーは自身のインフラを持ち込んだり、ニーズに合わせてTruefoundryをカスタマイズしたりできます。

1. クラウドアカウント（AWS、GCP、Azure）—これにより、クラスターの自動プロビジョニング、Lambdaの作成、マネージドサービスのデプロイが可能になります。
2. Git統合（Github、Bitbucket、Azure）—これにより、開発者はGitリポジトリから直接アプリケーションをデプロイできます。
3. シークレットストア（AWS Secrets Manager、Google Secrets Manager、Hashicorp Vault）—これにより、シークレットの実際の値はプラットフォーム上ではなく、シークレットストアに保存されます。
4. Dockerレジストリ—Dockerhub、Google GCR、Amazon ECR、Github Dockerレジストリ
5. Terraform連携
6. 監視連携: Prometheus Grafana、Datadog、NewRelic
7. ロギングインフラ連携 — Loki、Datadog、ELKスタック。
8. CI/CD連携 — Truefoundryは、Github Actions、Jenkins、AWS Codebuild、Google Codebuildなどの既存のCI/CDパイプラインと連携できます。

もしリストにない連携をご希望の場合は、喜んで対応し、追加させていただきます。

TrueFoundryはどのようにセキュリティを強化しますか？

POLP原則

当社はPOLP原則に従い、インフラチームがスタック全体でPOLP原則を容易に適用できるようにします。開発者はアクセスが必要なワークスペースに追加でき、その変更はそれらのワークスペースに限定されます。

Truefoundryプラットフォームにはシークレットやパスワードは保存されません

Truefoundryは、Kubernetesの認証情報やシークレットなどの機密情報を一切保存しません。すべてのデータは保存時に暗号化されます。すべてのアクセスはサービスアカウントを通じて提供することをお勧めします。

また、チームがプラットフォーム全体で行われたすべてのアクションを把握するのに役立つ、完全な監査ログを提供する予定です。

TrueFoundryはどのようにオープンでカスタマイズ可能ですか？

Kubernetesクラスターはあなたの管理下にあります

TrueFoundryは、ワークロードをデプロイする生のKubernetesクラスターを公開し、顧客に完全なアクセス（適切な権限を持つkubectlを含む）を提供します。これにより、Truefoundryに加えて、ユーザーはブロックされることなく、ほぼ自由に操作できます。

これとは別に、KubernetesのCRDと同様に、さらにプラグインを簡単に構築できるプラグインフレームワークもサポートしています。

TrueFoundryでのカスタムプラグインの構築

TrueFoundryは、各デプロイメント手法をカスタムプラグインとしてサポートしています。

プラグインを作成するには、ユーザーは3つの部分を記述する必要があります。

1. 入力スキーマの仕様を定義する入力キューファイル
2. 入力仕様を出力仕様に変換する方法を定義するプロセッサ
3. Output specifications sent to Kubernetes.

Currently, input and output specifications are Cue Lang Processors must be in Go. However, in the future, we will enable input/output schemas to be defined using JSON Schema and allow processors to be written in any language.

Automatically generate UI and Python interfaces from input cue files.

How to onboard to TrueFoundry

Infrastructure setup by the Infra/DevOps team:

1. Create a Kubernetes cluster using Terraform. TrueFoundry provides sample Terraform code that allows you to launch a cluster with a single click by committing the Terraform code to a GitHub repository. The DevOps/Infra team can freely customize and reapply the Terraform code.
2. Create service accounts via Terraform to provide access from Kubernetes namespaces to other infrastructure.
3. Add service accounts to workspaces on the TrueFoundry platform and assign workspaces to different teams.
4. TrueFoundry bootstraps the Kubernetes cluster with a default monitoring stack (Kube-prometheus-loki-grafana stack), Istio (ingress), and ArgoCD (infrastructure deployment). TrueFoundry dumps manifest files into a GitHub repository, allowing the infrastructure team to modify them according to their requirements.
5. To deploy managed infrastructure, the infrastructure team can provide Terraform modules for databases, queues, caches, and more. Developers can then provision this infrastructure using the modules provided by the infrastructure team.
6. Onboard developers to the platform.
7. Assign workspaces to teams/applications.
8. Developers can start deploying immediately by following the documentation.

How does TrueFoundry work?

TrueFoundry has two components: a control plane and a workload cluster agent. This enables TrueFoundry to orchestrate workloads across multiple clusters.

Differentiation from other platforms

Architecture

1. Multi-cluster support from day oneTruefoundryは当初からマルチクラスターに対応しており、クラスターは複数のリージョンやVPCにまたがって存在でき、プライベート/パブリックのいずれにも対応可能です。これは、PorterやNorthflankの現在のアーキテクチャでは非常に困難でしょう。Komodorのアーキテクチャはこれを実現できますが、彼らはKubernetesの可視化と監視に重点を置いており、これらは当社のプラットフォームでは標準で提供されます。
2. 当初からのマルチクラウド対応Porter、Northflank、Qoveryの場合、これはKubernetesレイヤーのみに当てはまります。当社のアーキテクチャはオープンであるため、より多くのクラウドネイティブコンポーネントとの統合構築をサポートしています。Argonautは当社と同様に、より広範なレイヤーでこれを実現しています。
3. 完全な透明性とGitOps 当社は完全な透明性モデルを採用しており、ユーザーは自身のアーキテクチャを完全に制御でき、Truefoundryによって一切制限されることはありません。Porter、Northflank、Qoveryの場合、クローズドなアーキテクチャのため、大企業はその機能セットでは物足りなくなるでしょう。また、当社はGitOpsモードと非GitOpsモードの両方を許可しており、これはまだ誰も実現していません。Porter、Northflank、Qoveryは非GitOpsのプッシュベースであるのに対し、CoSphereは完全にGitベースです。

アプリケーションとインフラの統一デプロイ

当社はアプリケーション、ジョブ、MLデプロイメントに深く統合されています。これにより、多くのインフラ知識が開発者用語に変換されます。他の多くのプラットフォームは、抽象化を構築し、インフラの概念を減らすことでこれを実現していますが、当社は物事を隠すのではなく、簡素化することでこれを実現しようとしています。

Argonautはインフラとアプリケーションのデプロイを統合するこのアプローチを採用していますが、これは2〜3年の製品サイクルになるでしょう。彼らはインフラ側から着手しています。

プラグイン

当社のプラグインベースのアーキテクチャは、Kubernetes CRDフレームワークと独自のCueLangフレーバーに基づいています。これにより、CLI、UI、およびすべての言語でプラグインを非常に迅速に展開する能力が得られます。これはKubevela（オープンソースリポジトリ）の設計に触発されたものであり、このパターンを確立している他のプレイヤーを当社は知りません。これは当社の独自の強みの一つであり、他のプレイヤーよりもはるかに迅速に構築することを可能にします。

透明性

当社は完全なソースコードを公開することで、可能な限り透明性を保つよう努めており、これにより当社からの移行を非常に容易にします。これを保証しているのはPorterとpurple.shだけのようです。その他はすべて非常にクローズドなシステムです。

インサイト

当社はすでに独自のインサイトを提供し、デプロイ時に環境変数を変更しないといったソフトウェアデプロイメントにおける最も一般的なバグを防いでいます。当社のように、シークレット履歴とデプロイ履歴の両方を知っているからこそ、これを実行できる、または実行している他のプラットフォームを知りません。ソース管理から本番環境までのコードのパイプラインを把握しているため、コスト、安定性、開発者の生産性に関する多くのインサイトを生成することもできます。

プラットフォームチームの代替

当社のプラットフォームは、プラットフォームチームが社内で構築するものに近い設計になっています。リソース割り当て、セキュリティ、開発者向けの抽象化といった主要な課題に対処します。Porter、NorthflankはHerokuに似ています。Qovery、Argonautは中小企業向けのDevOpsの代替のようなものです。Humanitec、shipaはプラットフォームチーム向けに設計されていますが、彼らの抽象化は、理解し、論理的に考えるのがかなり難しいと感じました。