Kubernetes

10 年以上にわたり、Spring Boot はエンタープライズ Java アプリケーションを構築するための事実上の標準として君臨してきました。 Java は、その豊富なエコシステム、構成より規約のパラ​​ダイム、堅牢な依存関係注入エンジン、および大規模なコミュニティ サポートにより、世界中のバックエンド システムの基盤となっています。 しかし、クラウドネイティブ アーキテクチャ、Kubernetes オーケストレーション、Docker コンテナ化、サーバーレス実行 (AWS Lambda、Knative) への移行により、メモリ効率、インスタント スケーリング、コールドスタート レイテンシといった新しい技術的課題がバックエンド インフラストラクチャに導入されました。 従来の Java フレームワークは、長時間稼働するモノリシック サーバー向けに設計されており、元々は一時的なコンテナ化環境向けに設計されたものではありませんでした。マイクロサービスが Kubernetes 上で 0 から 50 のインスタンスまで水平にスケールしたり、短期間のサーバーレス関数として実行したりする場合、200MB 以上のヒープ メモリを消費しながら、Java 仮想マシン (JVM) プロセスが起動するまで 3 ～ 10 秒待機すると、運用上および財務上のハンディキャップが生じます。 Quarkus は、特に GraalVM および OpenJDK HotSpot 向けに Java を調整するためにゼロから構築された Kubernetes ネイティブ Java フレームワークです。 「Supersonic Subatomic Java」 と呼ばれる Quarkus は、Java コードのコンパイル、起動、実行方法を根本的に再定義します。

最新のクラウドネイティブ システムでは、マイクロサービスはビジネス ロジックを実行する以上のことを行うことが期待されています。ログの処理、SSL/TLS 証明書の管理、メトリクスの収集、再試行メカニズムの実装、および他のサービスとの安全な通信の調整を行う必要があります。 この横断的な機能をすべて各アプリケーションのコードベース内に直接埋め込むと、コードの肥大化、密結合、言語のロックインが発生します。 ここで、サイドカー パターンが登場します。このガイドでは、サイドカー パターンとは何か、それが最新のマイクロサービス アーキテクチャに不可欠である理由、および簡単な例えと Kubernetes 構成例を使用してそれがどのように機能するかを詳しく説明します。 現実世界の例え: オートバイのサイドカー このパターンを理解する最も簡単な方法は、サイドカー付きのオートバイを考えることです。 あなたが高性能のオートバイを持っていると想像してください。この車両は、1 人のライダーを迅速に輸送するという 1 つのことを非常にうまく実行するように設計されています。ここで、乗客の手荷物を運ぶ必要があるか、追加の座席を追加する必要があるとします。 オートバイのフレーム、エンジン、ホイールを完全に再設計して車に変えることができます。しかし、それには多大な労力が必要で、バイクのシンプルさが損なわれ、メンテナンスが難しくなります。 代わりに、サイドカーを接続します。 サイドカーは、オートバイに接続する独立した自己完結型ユニットです。バイクの移動を共有し、バイクの行くところならどこへでも移動し、緊密に連携して動作します。しかし、オートバイの核となるエンジンは手つかずのままです。 ソフトウェア アーキテクチャでは: Motorcycle は、主要なアプリケーション コンテナです (チェックアウトやユーザー認証などのコア ビジネス ロジックを実行します)。 サイドカーは、別個のヘルパー コンテナーです (SSL 終了、監視、ログ配布などのユーティリティ タスクを実行します)。 ジャーニー は、デプロイメント (Kubernetes ポッドなど) のライフサイクルです。 問題: 分野横断的な懸念とコードの肥大化 サイドカーが登場する前は、開発者はアプリケーション コードにヘルパー ライブラリを直接組み込む必要がありました。たとえば、ログを中央サーバーに送信する場合は、ログ ライブラリをインポートします。メトリクスが必要な場合は、メトリクス SDK を追加しました。