デベロッパー

Java クライアントライブラリのネイティブイメージサポートを発表 - 短期間のワークロードを最適化

2022年7月26日

https://storage.googleapis.com/gweb-cloudblog-publish/images/native_imagessupport_heroimage.max-2200x2200.png

Google Cloud Japan Team

※この投稿は米国時間 2022 年 7 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

Cloud Java クライアントライブラリに、ネイティブイメージコンパイルのサポートが組み込まれました。

ネイティブイメージテクノロジーを使用すると、Java アプリケーションを事前にコンパイルして、スタンドアロンの実行可能ファイルにすることができます。これにより、コールドスタートアップ時間が短縮され、先行メモリ使用量が少なくなるなど、いくつかのパフォーマンス上の利点が得られます（JVM を必要としないため）。

ただし、ネイティブイメージコンパイルは、一部の形式の Java コード（リソースの読み込み、リフレクション）とは必ずしも互換性があるとは限らないため、追加の構成が必要になります。今回のリリースにより、Cloud クライアントライブラリには、ネイティブイメージのコンパイルに必要な構成が付属しているため、追加の構成を行うことなく、アプリケーションをコンパイルできるようになりました。また、このテクノロジーを使用すると、JVM 実行時に最適化が失われてしまうことから、ネイティブコンパイルは、迅速な起動と応答時間が重要な短期間のワークロードに最適であることにも注意してください。

パフォーマンス上のメリット

ネイティブイメージとしてビルドされたアプリケーションと、標準の Java（17.0.3、Temurin）で実行された同じアプリケーションのパフォーマンスを比較したところ、次の利点がありました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/01_Average_startup_times_in_milliseconds.max-600x600.png

https://storage.googleapis.com/gweb-cloudblog-publish/images/02_Average_startup__first_request_times_in_m.max-600x600.png

上記のパフォーマンスの差は、特に起動時間を比較すると大きくなります。この例では、ネイティブイメージの起動時間の 87.65% が 1 ミリ秒未満でした。これは、コールドスタートのレイテンシを最適化することを目的とした場合に大きな違いをもたらします。

メモリ使用量

ネイティブイメージにコンパイルされたアプリケーションのメモリ使用量も大幅に少なくなります。ps コマンドを使用して、Resident Set Size（タスクが使用した、スワップされていない物理メモリ）を確認したところ、次の結果が得られました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/03_Resident_Set_Size_in_kilobytes.max-600x600.png

スタートガイド

ここでは、ネイティブイメージコンパイルを使用して、Pub/Sub Storage のサンプルを実行する方法について説明します。

ネイティブイメージコンパイルのクライアントライブラリサポートによって解き放たれるパフォーマンス上の利点を示すために、このガイドに基づいて、Pub/Sub および Storage クライアントライブラリを利用するサンプルアプリケーションを作成します。自分のマシンや Cloud Shell でも自由に試してみてください。

前提事項

上記のパフォーマンスデータを収集するために使用したアプリケーションを再現するには、次のものが必要です。

Google Cloud プロジェクト（Pub/Sub および Storage API が有効になっている）
Pub/Sub トピック
Storage バケット

サンプルアプリのビルド

まず、次の Maven の goal を使用して、プロジェクトを生成します。

読み込んでいます...

これにより生成される新しい Maven プロジェクトは、サンプルアプリの妥当な開始点となります。

まず、Maven コンパイラプラグインのリリースバージョンを 17（以降）に設定し、クライアントライブラリを依存関係として追加します。

読み込んでいます...

App.java と同じディレクトリに ListPubSubNotifications というクラスを追加します。

読み込んでいます...

このクラスは、特定の Storage バケットに設定されている Pub/Sub 通知を一覧表示します。

次に、PublishWithErrorHandlerExample という同じパッケージに別のクラスを追加します。

読み込んでいます...

package com.mycompany.app;

import com.google.api.core.ApiFuture;
import com.google.api.core.ApiFutureCallback;
import com.google.api.core.ApiFutures;
import com.google.api.gax.rpc.ApiException;
import com.google.cloud.pubsub.v1.Publisher;
import com.google.common.util.concurrent.MoreExecutors;
import com.google.protobuf.ByteString;
import com.google.pubsub.v1.PubsubMessage;
import com.google.pubsub.v1.TopicName;

import java.io.IOException;

import java.util.Date;
import java.util.concurrent.TimeUnit;

public class PublishWithErrorHandlerExample {

public static void publishWithErrorHandlerExample(String projectId, String topicId)
            throws IOException, InterruptedException {
        TopicName topicName = TopicName.of(projectId, topicId);
        Publisher publisher = null;

try {
            // トピックにバインドされたデフォルト設定でパブリッシャー インスタンスを作成する
            publisher = Publisher.newBuilder(topicName).build();

String message = String.valueOf(new Date().getTime());

ByteString data = ByteString.copyFromUtf8(message);
            PubsubMessage pubsubMessage = PubsubMessage.newBuilder().setData(data).build();

// パブリッシュされると、サーバーによって割り当てられたメッセージ ID（トピック内で一意）を返す
            ApiFuture<String> future = publisher.publish(pubsubMessage);

// 成功 / 失敗を処理するための非同期コールバックを追加する
            ApiFutures.addCallback(
                    future,
                    new ApiFutureCallback<String>() {

@Override
                        public void onFailure(Throwable throwable) {
                            if (throwable instanceof ApiException) {
                                ApiException apiException = ((ApiException) throwable);
                                // API 例外の詳細
                                System.out.println(apiException.getStatusCode().getCode());
                                System.out.println(apiException.isRetryable());
                            }
                            System.out.println("Error publishing message : " + message);
                        }

@Override
                        public void onSuccess(String messageId) {
                            // パブリッシュされると、サーバーによって割り当てられたメッセージ ID（トピック内で一意）を返す
                            System.out.println("Published message ID: " + messageId);
                        }
                    },
                    MoreExecutors.directExecutor());
        } finally {
            if (publisher != null) {
                // パブリッシャーでの作業が終了したら、シャットダウンしてリソースを解放する。
                publisher.shutdown();
                publisher.awaitTermination(1, TimeUnit.MINUTES);
            }
        }
    }
}

このクラスは、特定のトピックにタイムスタンプメッセージをパブリッシュし、失敗した場合の例外を処理します。

最後に、App.java のメイン関数に、両方のクラスの関数を呼び出して起動 / 実行時間を追跡するロジックを追加します。

読み込んでいます...

package com.mycompany.app;

import java.io.IOException;
import java.lang.management.ManagementFactory;
import java.time.Duration;
import java.time.Instant;
import java.util.concurrent.TimeUnit;

public class App 
{
    private static final Instant INITIALIZATION_TIME = Instant.ofEpochMilli(ManagementFactory.getRuntimeMXBean().getStartTime());

private static final String projectId = "YOUR_PROJECT_ID";
    private static final String bucketName = "YOUR_BUCKET_NAME";
    private static final String topicId = "YOUR_TOPIC_ID";

public static void main(String... args) throws IOException, InterruptedException {
        final Duration startupTime = Duration.between(INITIALIZATION_TIME, Instant.now());
        ListPubSubNotifications.listPubSubNotifications(bucketName);
        final Duration timeToFirstRequest = Duration.between(INITIALIZATION_TIME, Instant.now());
        PublishWithErrorHandlerExample.publishWithErrorHandlerExample(projectId, topicId);

System.out.println("Startup time: " + startupTime.toMillis() + " ms, or " + TimeUnit.NANOSECONDS.toMicros(startupTime.toNanos()) + " microseconds");
        System.out.println("Time to finish first request: " + timeToFirstRequest.toMillis() + "ms");
        System.out.println("Shutting down. Total time elapsed: " + Duration.between(INITIALIZATION_TIME, Instant.now()).toMillis() + "ms");
    }
}

サンプルアプリケーションを配置したので、ネイティブイメージビルドを構成する準備が整いました。

ビルド構成

次の「native-image」ビルドプロファイルを pom.xml に追加します。

読み込んでいます...

<profiles>
  <profile>
    <id>native-image</id>
    <build>
      <plugins>
        <plugin>
          <groupId>org.graalvm.buildtools</groupId>
          <artifactId>native-maven-plugin</artifactId>
          <version>0.9.11</version>
          <extensions>true</extensions>
          <executions>
            <execution>
	<id>build-native</id>
	<goals>
                <goal>build</goal>
	</goals>
	<phase>package</phase>
            </execution>
          </executions>
          <configuration>
            <mainClass>com.mycompany.app.App</mainClass>
          </configuration>
        </plugin>
      </plugins>
    </build>
  </profile>
  <profile>
    <id>regular-jar</id>
    <build>
      <plugins>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-assembly-plugin</artifactId>
          <executions>
            <execution>
	<phase>package</phase>
	<goals>
                <goal>single</goal>
	</goals>
	<configuration>
                <archive>
                  <manifest>
                    <mainClass>
                      com.mycompany.app.App
                    </mainClass>
                  </manifest>
                </archive>
                <descriptorRefs>
                  <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
	</configuration>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </build>
  </profile>
</profiles>

このプラグインとプロファイルは、アプリケーションをネイティブイメージにビルドするために必要な構成を native-image ビルダーに提供するプロセスを簡素化します。「mainClass」パラメータがアプリケーションにとって正しいことを確認し、「buildArgs」を使用してオプションをビルダーに渡せることに注意してください。

この時点で、アプリをネイティブイメージに組み込む準備ができています。ただし、native-image の事前ビルドで念頭に置くべきことがいくつかあります。

同等のジャストインタイムビルドよりも時間がかかる（約 5～10 分*）
かなりのメモリを消費する（約 6～10 GB *）

* 値は Cloud Shell の e2-standard-4 マシンタイプでこのサンプルをビルドした結果です

ビルドを実行するには、適切な JDK と native-image ビルダーがあることを確認する必要があります。このプロセスは SDKMAN! を利用することで大幅に簡素化できます。

次のコマンドを使用して、GraalVM などの適切な JDK ディストリビューションをインストールします。

読み込んでいます...

次に、現在のシェルでこのバージョンを使用するように sdkman に通知します。

読み込んでいます...

次に、native-image 拡張機能をインストールします。

読み込んでいます...

最後に「native-image」プロファイルを使用して、native-image-client-libraries-sample プロジェクトのビルドを実行します。

読み込んでいます...

このビルドプロセスには数分かかることがあります。ビルドが完了すると、パフォーマンスの違いを実際に確認するために必要なものがすべて揃います。

生成された実行可能ファイルは「ターゲット」ディレクトリにあります。プログラムを実行して、Cloud Storage バケットから通知を受信することを確認します。

読み込んでいます...

https://storage.googleapis.com/gweb-cloudblog-publish/images/Side-by-side.max-800x800.png

この例では、ネイティブイメージは通常の jar より 159 倍速く起動し、19 倍速く終了しました。ネイティブイメージコンパイルの結果は、ワークロードによって大きく異なる可能性があるため、クラウドリソースを最大限に活用するために、独自のアプリケーションを自由に試してみてください。

まとめ

これは、Cloud Java クライアントライブラリでネイティブイメージコンパイルがサポートされる仕組みの一例にすぎません。サポートされているライブラリと、ネイティブイメージとしてアプリケーションを構築する方法の詳細については、公式ドキュメントをご覧ください。ドキュメントページは、試してみることができるいくつかのサンプルへもリンクしています。

- Java デベロッパーアドボケイト Aaron Wanjala
- プロダクトマネージャー Cameron Balahan

投稿先