フィードバックループの短縮:Digmaの無料のDocker拡張機能を使用したJavaアプリの開発

多くのエンジニアリングチームは、Docker イメージを開発するときに同様のプロセスに従います。このプロセスには、開発、テスト、ビルドなどのアクティビティが含まれ、イメージはアプリケーションの後続のバージョンとしてリリースされます。これらの異なる各段階で、大量のデータを収集できるため、コード変更の影響に関する貴重な洞察が得られ、製品機能の安定性と成熟度をより明確に理解できます。

近年、オブザーバビリティは大きな飛躍を遂げており、OpenTelemetry (OTEL) やeBPFなどの高度なテクノロジーにより、アプリケーションのランタイムデータを収集するプロセスが簡素化されています。それでも、そのすべての進歩にもかかわらず、開発者はこの新しいリソースを使用するかどうか、そしてどのように使用するかについてまだ危機に瀕している可能性があります。生データを開発プロセスにとって意味のある有益なものに変換するために必要な労力は、これらのテクノロジーによって提供される利点を上回るように思われるかもしれません。

継続的なフィードバックの実践は、この特定の問題が解決された開発フローを想定しています。コードランタイムデータの評価を継続的に行うことで、開発者はフィードバックループを短縮し、コードベースをより厳密に制御できるというメリットを享受できます。本番システムで問題が発生したり、テストで表面化したりするのを待つ代わりに、さまざまな開発者ツールがコードの可観測性データを監視し、回帰、コードの臭い、または問題に対する早期警告と厳格なリンティングを提供できます。

同時に、テスト環境や運用環境など、複数の配置環境からコードに情報を収集することで、開発者は特定の関数、クエリ、またはイベントが現実世界でどのように実行されているかを一目で理解できます。

ランタイムデータの最初のリンターであるDigmaに会う

Digma は、DevOpsループの継続的なフィードバックギャップを埋めるために作成された無料の開発者ツールです。これは、コードが吐き出している膨大な数のメトリック、トレース、ログを理解することを目的としているため、開発者はそうする必要はありません。そして、これは継続的かつ自動的に行われます。

ツールをさらに実用的にするために、Digmaは可観測性データを処理し、それを使用してIDEでソースコード自体をリントします。開発者の視点から見ると、これはコードに関するまったく新しいレベルの情報が明らかになることを意味し、実際のフィードバックに基づいてより良いコード設計を可能にし、回帰を修正したり、一般的な落とし穴やアンチパターンを回避したりするための迅速なターンアラウンドを可能にします。

ディグマの展開方法

Digma は自己完結型の Docker 拡張機能としてパッケージ化されているため、開発者は外部サービスに登録したり、企業ポリシーで許可されていないデータを共有したりすることなく、コードを簡単に評価できます (図 1)。そのため、Digmaは、特に開発とテストにおいて、コードの実行を監視するための独自のインテリジェントエージェントとして機能します。バックエンドコンポーネントは、時間の経過に伴う実行を追跡し、対処する必要がある動作、パフォーマンス、またはエラーパターンに対する不注意な変更を強調表示できます。

コードに関するデータを収集するために、舞台裏でDigmaは、最新の可観測性のために広く使用されているオープンスタンダードであるOpenTelemetryを活用しています。簡単に始めるために、Digmaが構成作業を処理するため、開発者の観点からは、継続的なフィードバックから始めることは、スイッチを切り替えることと同じです。

フィードバックプロバイダーと可観測性ソースを示すdigmaプロセスの図。 — **図1:** ディグマの概要。

OTELを使用して情報が収集されると、Digmaはリバースパイプラインと表現できるものを介して情報を実行し、データを集約して分析し、APIを介してIDEプラグイン、 Jaeger、およびこの例で説明するDocker拡張機能ダッシュボードを含む複数のアウトレットに提供します。

手記： 現在、DigmaはIntelliJ IDEA上で動作するJavaアプリケーションをサポートしています。ただし、追加の言語とプラットフォームのサポートは、今後数か月以内に展開される予定です。

ディグマのインストール

前提条件: Docker Desktop 4.8 以降。

手記： Docker 拡張機能が有効になっていることを確認する必要があります (図 2)。

青いチェックマークで選択された「Docker拡張機能を有効にする」を示すDockerデスクトップのスクリーンショット。 — **図2:** ドッカー拡張機能の有効化。

ステップ1.ディグマドッカー拡張機能のインストール

拡張機能マーケットプレースで、Digma を検索し、[ インストール ] を選択します (図 3)。

digma の検索結果を示す拡張機能マーケットプレイスのスクリーンショット。 — **図3:** ディグマをインストールします。

ステップ2.コードに関するフィードバックの収集

マーケットプレースから Digma 拡張機能をインストールすると、コードに関するフィードバックを収集するための次の手順を案内するクイックスタートページが表示されます。 Digmaは、2つの異なるソースから情報を収集できます。

IDE 内のテスト/デバッグセッション
Dockerデスクトップで実行されている可能性のあるDockerコンテナ

IDE でのコードのデバッグ/実行中にフィードバックを取得する

DigmaのIDE拡張機能を使用すると、IDEでコードに関するデータを収集するプロセスが簡単になります。セットアップ全体がトグルボタンを1回クリックするだけで済みます(図4)。舞台裏では、Digmaはランタイム構成に変数を追加して、可観測性のためにOpenTelemetryを使用するようにします。事前の知識や可観測性は必要なく、これを機能させるためにコードを変更する必要もありません。

可観測性の切り替えを有効にすると、コードをローカルで実行するとき、またはテストを実行するときでも、すぐにフィードバックが得られるようになります。 Digmaはリグレッションを監視し、コードの臭いや問題を自動的に見つけます。

可観測性切り替えスイッチが有効になっている digma ダイアログボックスのスクリーンショット (青色)。 — **図4:** 可観測性トグルスイッチ。

実行中のコンテナーからのフィードバックの取得

IDE に加えて、Java コードを実行しているマシンで実行中の任意のコンテナからデータを収集することもできます。これを行うプロセスは非常に簡単で、Digma拡張機能の「はじめに」ページにも記載されています。 Dockerfile やコードの変更は含まれません。基本的には、OTEL エージェントをダウンロードし、コンテナ上のボリュームにマウントし、Java プロセスがそれを使用するように指示する環境変数を設定します。

curl --create-dirs -O -L --output-dir ./otel
https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/latest/download/opentelemetry-javaagent.jar

curl --create-dirs -O -L --output-dir ./otel
https://github.com/digma-ai/otel-java-instrumentation/releases/latest/download/digma-otel-agent-extension.jar

export JAVA_TOOL_OPTIONS="-javaagent:/otel/javaagent.jar -Dotel.exporter.otlp.endpoint=http://localhost:5050 -Dotel.javaagent.extensions=/otel/digma-otel-agent-extension.jar"
export OTEL_SERVICE_NAME={--ENTER YOUR SERVICE NAME HERE--}
export DEPLOYMENT_ENV=LOCAL_DOCKER

docker run -d -v "/$(pwd)/otel:/otel" --env JAVA_TOOL_OPTIONS --env OTEL_SERVICE_NAME --env DEPLOYMENT_ENV {-- APPEND PARAMS AND REPO/IMAGE --}

実行時にコードがどのように動作するかを明らかにする

実行中のコンテナからデータを収集する場合でも、IDEでデータを収集する場合でも、Digmaはコードの動作を継続的に分析し、分析結果をIDEのコード注釈とDigma拡張機能自体のダッシュボードの両方として利用できるようにします。実際の例を示すために、Java Spring Boot PetClinic アプリに基づくサンプルアプリケーションを作成しました。

このシナリオでは、リポジトリを複製して IDE からコードを実行し、いくつかのアクションをトリガーして、コードについて何を明らかにするかを確認します。便宜上、一般的な API 呼び出しをシミュレートし、興味深いデータを作成するための実行構成を作成しました。

ここの IntelliJ IDE で PetClinic プロジェクトを開きます。
ペットクリニックサービス構成を実行します。
API にアクセスして http://localhost:9753/ で試してみるか、ワークスペースに含まれている ClientTested 実行構成を実行するだけです。

ほぼ即座に、動的リンティング分析の結果がIDEのコードに表示され始めます(図5)。

分析後の digma インサイトを示すスクリーンショット。 — **図5:** ディグマ分析の結果。

同時に、Digma 拡張機能自体には、コードの場所、API エンドポイント、データベースクエリなど、識別されたすべての資産をカタログ化したダッシュボードが表示されます (図 6)。各アセットについて、そのパフォーマンスに関する基本的な統計と、実行時の動作について追跡する必要がある可能性のある懸念事項のより詳細なリストにアクセスできます。

識別された資産を一覧表示する digma ダッシュボードのスクリーンショット。 — 図6:ディグマダッシュボード。

可観測性データの使用

Digmaが解決しようとしている主な問題の1つは、可観測性データを収集する方法ではなく、それを開発プロセスをスピードアップし、コードを改善できる便利で実用的な資産に変える方法です。 Digmaの洞察は、既存のデータに基づいて設計時に直接適用できるだけでなく、開発/テスト/本番環境で実行されている変更を検証し、開発プロセスへの早期フィードバックと短いループを取得できます。

デザイン時計画コード分析情報の例:

変更された関数の実行時の使用状況を確認し、変更の影響を受けるユーザーを理解する
計画する同時実行性、ボトルネック、重要度
新しいコンポーネントで処理する必要がある既存のエラーと例外
変更したコードを使用した制御フローの完全な視覚化を確認

短いフィードバックループのためのランタイムコード検証の例:

キャッチコードとクエリモデリングの匂い(N + 1 Selectsなど )が検出され、強調表示されます
変更の結果としての新しいパフォーマンスのボトルネックと回帰を特定する
スケーリングの問題を早期に発見し、開発サイクルの一部として対処する

Digmaが進化するにつれて、開発者にとって重要な特定の領域を追跡して明確に可視化し続け、各コードが実際のシナリオでどのように動作しているかを完全に明確にし、プロセスのはるかに早い段階で問題や回帰をキャッチします。

誰がディグマを使うべきですか?

他の多くの可観測性ソリューションとは異なり、Digmaはコードファーストであり、開発者ファーストです。 Digmaは開発者にとって完全に無料で、コードの変更やデータの共有を必要とせず、コードに関するゼロから影響力のあるデータまで数分以内に取得できます。 Javaコードで作業していて、JetBrains IDEを使用していて、実際の実行データを使用してコードを改善したい場合は、マーケットプレイスからDigma拡張機能を取得することから始めることができます。

Slack チャンネルでフィードバックを提供し、Digma が開発サイクルを改善した場所を教えてください。

Docker Desktop, Docker Extensions, Java, Observability