Kubernetesによるアプリケーション開発

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
Kubernetes は、高可用性とオートスケーリングを必要とする大企業や中規模組織のチームにとって理想的なプラットフォームとして広く認識されています。しかし、既存の開発者ワークフローに摩擦を生じさせる側面もあります。この変化は、マイクロサービスパラダイムの採用に向けた広範な動きと、ソフトウェアの実行方法の複雑化の一部として理解できます。本記事では、このパラダイムシフトに伴い、ソフトウェア開発の問題がどのように進化してきたかを考察します。
開発ループ
まず、開発ループの概念と、それが開発ワークフローで果たす役割から始めましょう。どのようなソフトウェアプロジェクトの開発ループも、Git を介して交差する2つの独立したループで構成されています。

これらは次のとおりです。
- インナー開発ループ - 開発者自身のワークステーションでコードを記述、コンパイル、テストするプロセスです。このループは、満足のいくコードがGitに移動されるまで続きます。
- アウター開発ループ - このループは、コードが開発者のワークステーションからGitに移動された後にトリガーされます。テストの実行と最終製品のデプロイが含まれます。理想的には、このプロセスは継続的なループとして設定され、テストに合格したすべてのコードプッシュでデプロイが行われるべきです。
これらのループは互いに連携し、完全なソフトウェア開発ライフサイクルを形成します。
マイクロサービスの台頭
マイクロサービスの登場により、スケーラビリティと信頼性を向上させる、小さく、独立した、疎結合なソフトウェアコンポーネントがもたらされました。その利点は広く知られているため、ここでは詳しく述べませんが、私たちの懸念は、それに伴う運用上の複雑さの増加にあります。

ここで、シンプルな構成を考えてみましょう。そこでは、 フロントエンド が APIを呼び出し、APIはさらに「 identity 」と「 db。このシナリオでは、開発者は api レイヤーで作業します。このレイヤーには、ダウンストリーム(フロントエンド)とアップストリーム(ID、db)の両方の依存関係があります。では、 api サービスの開発プロセスが、2つの異なる開発ループでどのように変化するかを見ていきましょう。-
インナー開発ループ
- アップストリーム依存関係へのアクセス -
apiサービスが正常に動作するためには、IDサービスとdbサービスの両方と通信する必要があります。 - ダウンストリーム依存関係へのアクセス -
apiサービスに加えられた変更がダウンストリーム依存関係と互換性があるかをテストするためには、ダウンストリームからのリクエストをこのサービスにリダイレクトすることも重要です。
アウター開発ループ
- アップストリーム依存関係 -
apiサービスのe2eテストを実行するには、稼働中のidentityとdbサービス - ダウンストリームの依存関係 - また、
フロントエンドがテスト目的でこのサービスにアクセスできるようにする方法も必要です。 - ホストされたエンドポイント - 上記の要件に加えて、この
APIサービスのコピーをホストし、直接テストできるようにする必要があります。
インナーデブループの問題は、 Telepresence ( Ambassador Labs 製)が解決してきた課題です。私たちは、 TrueFoundryプラットフォーム 上で Interceptsによってアウターデブループの問題を解決しようと試みました。
TrueFoundry Interceptsの紹介

TrueFoundry Interceptsのコンセプトは、前述のセクションで概説した3つのアウターデブループの問題を解決することで機能します。これを解決するために、以下の戦略を採用しています。
- プレビューURL - プラットフォーム自体を使用することで、既存のサービスのコピーを特定のコミットSHAで簡単にデプロイできます。これにより、特定のコミットやプルリクエスト専用のプレビューURLを作成できます。
- ヘッダーベースのインターセプト - インターセプトを使用すると、サービスは同じURLを使い続けながら、プレビューコピーにリダイレクトする追加のヘッダーを追加できます。例えば、
apiサービスにインターセプトをアタッチして、渡されるヘッダーに基づいてプレビューコピーにリダイレクトさせることができます。これは、frontendは、テスト中にヘッダーを追加で渡すだけで、同じURLで作業を続けることができます。
💡
TrueFoundryのインターセプトについてさらに詳しく知るには、弊社のドキュメントをご参照ください - https://docs.truefoundry.com/docs/intercepts
まとめ
マイクロサービスの登場によってもたらされた開発フローの変化と、それらにどのように対処しようとしているかについて議論しました。これは未解決の課題であり、今後この分野でさらに革新的なソリューションが生まれることが期待されます。
お話ししましょう
LLMプロジェクトからのリターンを最大化し、AIを適切に活用してビジネスを強化したいとお考えでしたら、ぜひお話しし、意見交換をさせていただければ幸いです。
☕️を飲みながらお話ししませんか
TrueFoundryが5分でLLMをデプロイするお手伝いをする方法をご覧ください:
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.


















.webp)
.webp)


.png)

.png)














