Azure Container Apps 上の Java の概要

Azure Container Apps では、コンテナー化された Java アプリケーションをクラウドで実行しながら、アプリケーションのデプロイ方法に関する柔軟なオプションを提供できます。

コンテナー化された Java アプリケーションに Container Apps を使用すると、次のものが得られます。

• コスト効率の高いスケーリング: 従量課金プランを使用すると、Java アプリをゼロにスケーリングできます。 アプリの需要がほとんどない場合にスケールインすると、プロジェクトのコストが自動的に抑えられます。

• デプロイ オプション: Azure Container Apps は Buildpacks と統合されています。これにより、成果物ファイルを介して、または独自の Dockerfile を使用して、Maven ビルドから直接デプロイできます。

  • JAR デプロイ (プレビュー): JAR ファイルからコンテナー アプリを直接デプロイできます。

  • WAR デプロイ (プレビュー): WAR ファイルからコンテナー アプリを直接デプロイできます。

  • IDE サポート: IntelliJ からコンテナー アプリを直接デプロイできます。

• 自動メモリ調整 (プレビュー): Container Apps は、Java 仮想マシン (JVM) によるメモリの管理方法を最適化し、Java アプリケーションが最大限のメモリを利用できるようにします。

• ビルド環境変数 (プレビュー): ソース コードから Java イメージのビルドを制御するようにカスタム キーと値のペアを構成できます。

この記事では、Azure Container Apps で Java アプリケーションをビルドするときに確認する必要がある情報について詳しく説明します。

デプロイのタイプ

コンテナー化されたアプリケーションを実行すると、通常、アプリケーション用の Dockerfile を作成する必要がありますが、Container Apps で Java アプリケーションを実行するときには、いくつかのオプションがあります。

アプリケーションのタイプ

さまざまな種類のアプリケーションが、個々のコンテナー アプリとして、または Container Apps ジョブとして実装されます。 次の表を使用すると、シナリオに最適なアプリケーションの種類を決定できます。

この表に示す例は、すべてを網羅していませんが、さまざまな種類のアプリケーションの意図を理解できるようにするためのものです。

デバッグ

Container Apps で Java アプリケーションをデバッグするときは、必ず Java インプロセス エージェントでログ ストリームとコンソール デバッグ メッセージを調べてください。

トラブルシューティング

Java アプリケーションを開発するときは、次の点に注意してください。

• 既定のリソース: 既定では、アプリの CPU は半分で、1 GB が使用可能です。

• ステートレス プロセス: コンテナー アプリのスケール インとアウトに合わせて、新しいプロセスが作成され、シャットダウンされます。 データベースやファイル システム共有などの共有ストレージにデータを書き込むには、事前に計画を立てるようにしてください。 コンテナー ファイル システムに直接書き込まれたファイルを他のコンテナーで使用できるとは想定しないでください。

• ゼロへのスケーリングが既定: アプリケーションの 1 つ以上のインスタンスが継続的に実行されるようにする必要がある場合は、ニーズに最適なスケール ルールを定義してください。

• 予期しない動作: コンテナー アプリのビルド、開始、または実行に失敗した場合は、コンテナーで成果物パスが正しく設定されていることを確認します。

• Buildpack のサポートの問題: Buildpack で依存関係または必要な Java のバージョンがサポートされない場合は、独自の Dockerfile を作成してアプリをデプロイします。 参照のためにサンプル Dockerfileを表示できます。

• SIGTERM および SIGINT シグナル: 既定で、JVM では SIGTERM および SIGINT シグナルを処理します。これらのシグナルをインターセプトしてそれに応じてアプリケーションで処理しない限り、アプリケーションに渡されません。 Container Apps では、プロセス制御に SIGTERM と SIGINT の両方が使用されます。 これらのシグナルをキャプチャせず、アプリケーションが予期せず終了した場合、それらのシグナルはストレージに保持されない限り、失われる可能性があります。

• コンテナー イメージへのアクセス: 成果物またはソース コードのデプロイを既定のレジストリと組み合わせて使用する場合、コンテナー イメージに直接アクセスすることはできません。

監視

すべての標準監視ツールが Java アプリケーションで動作します。 Container Apps で実行する Java アプリケーションをビルドするときは、次の項目に注意してください。

• メトリック: Java 仮想マシン (JVM) メトリックは、Java アプリケーションの正常性とパフォーマンスを監視するのに不可欠です。 収集されるデータには、JVM のメモリ使用量、ガベージ コレクション、スレッド数に関する分析情報が含まれます。 メトリックをチェックすると、アプリケーションの正常性と安定性を確保するのに役立ちます。

• ログ: アプリケーションとエラー メッセージを stdout または stderror に送信して、ログ ストリームに表示できるようにします。 一般的なログ サービスを使用する場合と同様に、コンテナーのファイルシステムに直接ログを記録することは避けてください。

• パフォーマンスの監視構成: パフォーマンスの監視サービスを Container Apps 環境内の別のコンテナーとしてデプロイして、アプリケーションに直接アクセスできるようにします。

診断

Azure Container Apps には、Java 開発者専用の組み込み診断ツールが用意されいます。 このサポートにより、Azure Container Apps で実行されている Java アプリケーションのデバッグとトラブルシューティングが合理化され、より簡単かつ効率的に行うことができます。

• 動的ロガー レベル: コードを変更したり、アプリを強制的に再起動したりすることなく、さまざまなレベルのログ詳細にアクセスして確認できます。 動的ロガー レベルの設定に関する記事を参照してください。

スケーリング

フロントエンド アプリケーションからの要求が同じサーバーに到達することを確認する必要があるか、フロントエンド アプリが複数のコンテナー間で分割されている場合は、スティッキー セッションを有効にしてください。

セキュリティ

Container Apps ランタイムでは、Container Apps 環境内で SSL を終了します。

メモリ管理

Java アプリケーションでメモリ管理を最適化できるように、JVM メモリ調整をアプリで有効にします。

メモリは、ギビバイト (Gi) と CPU コアのペアで測定されます。 次の表は、コンテナー アプリで使用できるリソースの範囲を示しています。

コアは 0.25 コア単位で使用でき、メモリは 2:1 の比率で使用できます。 たとえば、1.25 コアが必要な場合は、コンテナー アプリで 2.5 Gi のメモリを使用できます。

Spring コンポーネントのサポート

Azure Container Apps からは、次の Spring Components のサポートがマネージド サービスとして提供されます。

• Eureka Server for Spring: サービスの登録と検出は、呼び出すライブ アプリケーション インスタンスの一覧を維持するための重要な要件です。 アプリケーションでは、この一覧を使用して、受信要求のルーティングと負荷分散を行います。 各クライアントを手動で構成するのは時間がかかり、人為的なエラーが発生する可能性があります。 Eureka Server は、マイクロサービスが自らを登録し、システム内の他のサービスを検出できるサービス レジストリとして機能し、サービス検出の管理を簡単にします。

• Config Server for Spring: Config Server では、分散システムの外部構成を一元的に管理できます。 このコンポーネントは、クラウドネイティブ環境で複数のマイクロサービスにまたがる構成設定を管理するという課題を対処するように設計されています。

• Spring 用管理: Spring 用管理のマネージド コンポーネントは、アクチュエータ エンドポイントを持つ Spring Boot Web アプリケーション用に設計された管理インターフェイスを提供します。 マネージド コンポーネントは、コンテナー アプリを Spring 用管理コンポーネントにバインドできるようにすることで、コンテナアプリの統合と管理を可能にします。

次のステップ