IronPDF for JavaをAWSに設定する方法

目次

• 必要な前提条件は何ですか？
• Zipデプロイメントの代わりにDockerを使用するべき理由
• Mavenの依存関係をどのように設定しますか？
• Lambdaハンドラをどのように記述しますか？
• SAMテンプレートをどのように設定しますか？
• Dockerfileをどのように構築しますか？
• Lambda関数をどのように構築してデプロイしますか？
• 次のステップは何ですか？

必要な前提条件は何ですか？ {#prerequisites}

開始する前に、以下のツールが開発機にインストールされていることを確認してください。各ツールは、ビルドおよび展開パイプラインにおいて特定の役割を果たします。

• IntelliJ IDEA — このガイドで使用するIDEです。jetbrains.com/ideaからダウンロード。
• AWS Toolkit for JetBrains — IntelliJ内にSAMプロジェクトウィザードとLambdaラン構成を提供します。 設定方法はAWS Toolkit for JetBrains ドキュメントページにあります。
• AWS SAM CLI — Dockerイメージをビルドし、Lambda関数をデプロイするコマンドラインツール。 インストールはSAM CLIインストールガイドに従ってください。
• Docker Desktop — Lambda関数がZipアーカイブではなくコンテナイメージとしてパッケージされるために必要です。Docker Community Editionをダウンロード。

AWSにデプロイする前にローカルで呼び出しテストを行うには、次もインストールしてください：

• Java 8 JDK — Oracle JDK 8ダウンロードページから入手可能。
• Apache Maven — Mavenインストールガイドに従ってください。

すべてのツールが揃ったら、IntelliJ IDEAを開き、File → New → Projectを通じて新しいプロジェクトを作成します。 プロジェクトウィザードでAWS Lambdaテンプレートを選択し、次のオプションを選びます：

• パッケージタイプ: Image
• ランタイム: java8 または java11
• SAMテンプレート: Maven

Zipデプロイメントの代わりにDockerを使用するべき理由 {#why-docker}

AWS Lambdaは、Zipアーカイブとコンテナイメージの2つのデプロイメントパッケージタイプをサポートしています。 Zipデプロイメントは、AWSが実行環境全体を管理する軽量Java関数には適しています。 ただし、IronPDFはネイティブバイナリ—ChromeベースのPDFレンダリングエンジン—を提供し、実行時に抽出して実行しなければなりません。ZIPデプロイメントの場合、Lambda実行環境はファイルシステムへの書き込みを/tmpに制限しており、ZIPパッケージレイヤーの制限により、大きなネイティブバイナリの抽出は制限されます。

コンテナイメージデプロイメントを使用すると、これらの制約を取り除けます。 独自のDockerイメージを定義するとき、基本のオペレーティングシステム、インストールされたシステムパッケージ、およびディレクトリレイアウトを制御できます。 IronPDFのレンダリングエンジンは、起動時に/tmpに抽出され、必要なシステムライブラリはあらかじめ画像にインストールされており、コンテナサイズ制限（10GB）はエンジン全体を収容できる十分な大きさです。

その実際の結果はシンプルです：PackageType: Imageを設定し、Docker対応のベースイメージを使ってビルドします。 SAM CLIが残りの処理を行います。

Mavenの依存関係をどのように設定しますか？ {#Maven-dependencies}

pom.xmlファイルには、標準のLambda SDKを超える追加の依存関係が3つのカテゴリで必要です：IronPDF Javaライブラリ、IronPDF Linux x64レンダリングエンジン、およびIronPDFエンジン内部で使用されるgRPCトランスポートです。

<dependencies>内に追加します。

//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf</artifactId>
    <version>2024.9.1</version>
</dependency>
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf-engine-linux-x64</artifactId>
    <version>2024.9.1</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-simple</artifactId>
    <version>2.0.3</version>
</dependency>
<dependency>
    <groupId>io.perfmark</groupId>
    <artifactId>perfmark-api</artifactId>
    <version>0.26.0</version>
</dependency>
<dependency>
    <groupId>io.grpc</groupId>
    <artifactId>grpc-okhttp</artifactId>
    <version>1.50.2</version>
</dependency>
<dependency>
    <groupId>io.grpc</groupId>
    <artifactId>grpc-netty-shaded</artifactId>
    <version>1.50.2</version>
</dependency>

//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf</artifactId>
    <version>2024.9.1</version>
</dependency>
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf-engine-linux-x64</artifactId>
    <version>2024.9.1</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-simple</artifactId>
    <version>2.0.3</version>
</dependency>
<dependency>
    <groupId>io.perfmark</groupId>
    <artifactId>perfmark-api</artifactId>
    <version>0.26.0</version>
</dependency>
<dependency>
    <groupId>io.grpc</groupId>
    <artifactId>grpc-okhttp</artifactId>
    <version>1.50.2</version>
</dependency>
<dependency>
    <groupId>io.grpc</groupId>
    <artifactId>grpc-netty-shaded</artifactId>
    <version>1.50.2</version>
</dependency>

ironpdf-engine-linux-x64アーティファクトは、64ビットLinux用の事前コンパイル済みのChromiumベースのレンダリングエンジンをバンドルしています。 これにより、IronPDFはLambdaコンテナ内でHTMLをPDFにレンダリングできます。 これがなければ、レンダリング呼び出しはバイナリ不足エラーで失敗します。 gRPCの依存関係（perfmark-api）が必要なのは、IronPDFがそのレンダリングエンジンとローカルgRPCチャンネルを介して通信するためです。 slf4j-simple依存関係は、IronPDFの内部ログがCloudWatch上で見えるように最低限のログ実装を提供します。

ironpdf-engine-linux-x64バージョン番号を常に合わせること—バージョンのミックスは起動失敗を引き起こします。 Maven CentralにおけるIronPDF for Javaで最新のバージョン文字列を確認してください。

Lambdaハンドラをどのように記述しますか？ {#lambda-handler}

LambdaハンドラークラスはAPIGatewayProxyResponseEventを返します。 最初のレンダリング操作の前に、2つのIronPDF構成呼び出しが必要です：作業ディレクトリを/tmpに設定し、必要に応じてデバッグログを有効にすることです。

App.javaの内容を以下に置き換えます：

//:path=App.java
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyResponseEvent;
import com.ironsoftware.ironpdf.PdfDocument;
import com.ironsoftware.ironpdf.Settings;

import java.nio.file.Paths;
import java.util.HashMap;
import java.util.Map;

public class App {
    public APIGatewayProxyResponseEvent handleRequest(
            final APIGatewayProxyRequestEvent input,
            final Context context) {

        APIGatewayProxyResponseEvent response = new APIGatewayProxyResponseEvent();

        // IronPDF must write its engine binaries and temporary files to /tmp.
        // This is the only writable path available in the Lambda execution environment.
        Settings.setIronPdfEngineWorkingDirectory(Paths.get("/tmp/"));

        // Enable debug logging to CloudWatch during initial testing.
        Settings.setDebug(true);

        try {
            context.getLogger().log("Starting PDF render");

            // Render a PDF from a live URL. Replace with your own HTML or URL as needed.
            PdfDocument pdf = PdfDocument.renderUrlAsPdf("https://www.google.com");

            context.getLogger().log("PDF render complete");

            // Save the rendered PDF to /tmp. Files in /tmp persist for the lifetime
            // of the Lambda execution environment (warm instance).
            pdf.saveAs("/tmp/output.pdf");

            Map<String, String> headers = new HashMap<>();
            headers.put("Content-Type", "application/json");

            return response
                    .withStatusCode(200)
                    .withHeaders(headers)
                    .withBody("PDF generated successfully.");

        } catch (Exception e) {
            context.getLogger().log("PDF render failed: " + e.getMessage());
            return response
                    .withStatusCode(500)
                    .withBody("{\"error\": \"" + e.getMessage() + "\"}");
        }
    }
}

//:path=App.java
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyResponseEvent;
import com.ironsoftware.ironpdf.PdfDocument;
import com.ironsoftware.ironpdf.Settings;

import java.nio.file.Paths;
import java.util.HashMap;
import java.util.Map;

public class App {
    public APIGatewayProxyResponseEvent handleRequest(
            final APIGatewayProxyRequestEvent input,
            final Context context) {

        APIGatewayProxyResponseEvent response = new APIGatewayProxyResponseEvent();

        // IronPDF must write its engine binaries and temporary files to /tmp.
        // This is the only writable path available in the Lambda execution environment.
        Settings.setIronPdfEngineWorkingDirectory(Paths.get("/tmp/"));

        // Enable debug logging to CloudWatch during initial testing.
        Settings.setDebug(true);

        try {
            context.getLogger().log("Starting PDF render");

            // Render a PDF from a live URL. Replace with your own HTML or URL as needed.
            PdfDocument pdf = PdfDocument.renderUrlAsPdf("https://www.google.com");

            context.getLogger().log("PDF render complete");

            // Save the rendered PDF to /tmp. Files in /tmp persist for the lifetime
            // of the Lambda execution environment (warm instance).
            pdf.saveAs("/tmp/output.pdf");

            Map<String, String> headers = new HashMap<>();
            headers.put("Content-Type", "application/json");

            return response
                    .withStatusCode(200)
                    .withHeaders(headers)
                    .withBody("PDF generated successfully.");

        } catch (Exception e) {
            context.getLogger().log("PDF render failed: " + e.getMessage());
            return response
                    .withStatusCode(500)
                    .withBody("{\"error\": \"" + e.getMessage() + "\"}");
        }
    }
}

Settings.setIronPdfEngineWorkingDirectory(Paths.get("/tmp/"))の呼び出しは必須です。 AWS Lambdaの実行環境は、関数コードを読み取り専用ディレクトリにマウントします。 IronPDFエンジンは、起動時にサポートファイルを抽出しソケットを作成しなければならず、これらには書き込みアクセスが必要です。 /tmpディレクトリは、ファイル書き込みのためにLambdaが許可する唯一の場所であるため、IronPDFはレンダリング開始前にそこを指示する必要があります。 この設定を省略するとエンジンが起動せず、すべてのレンダリング呼び出しが例外を投げます。

/tmpファイルシステムにレンダリングされたファイルを保存します。 Lambda関数がPDFをバイナリ応答として返すか、S3にアップロードする必要がある場合、代わりにディスクに書き込まずにpdf.getBinaryData()を使用してバイトを取得します。 大規模なワークロードのためには、Amazon S3にアップロードし、署名付きURLを返すのが推奨されるパターンです。

SAMテンプレートをどのように設定しますか？ {#sam-template}

template.yamlファイルは、Lambda関数のリソース割り当てを制御します。 IronPDFが正常に動作するかどうかに直接影響を与える設定は3つあります：EphemeralStorage.Size。

Globalsセクションを以下のように更新します：

//:path=template.yaml
Globals:
  Function:
    Timeout: 400
    MemorySize: 2048
    EphemeralStorage:
      Size: 1024

//:path=template.yaml
Globals:
  Function:
    Timeout: 400
    MemorySize: 2048
    EphemeralStorage:
      Size: 1024

Timeoutは400秒に設定されています。 コールドスタート時に、IronPDFはレンダリングエンジンを/tmpに抽出し、ローカルのChromiumプロセスを起動する必要があります。 この抽出は初回の呼び出しで30～60秒かかる可能性があります。 330秒未満のタイムアウトは、コールドスタートの呼び出しがタスクタイムアウトエラーで失敗する原因となります。 ウォーム呼び出しははるかに速く、通常単純なHTMLからPDFへの変換では5秒未満です。

MemorySizeは2048 MBに設定されています。 Chromiumレンダラーはメモリを大量に消費します。IronPDFのAWS Lambdaでの最低実行可能メモリは1024 MBですが、2048 MBに設定することで、複雑なページに対するメモリ不足のリスクを軽減し、レンダリング速度を大幅に向上させます。また、Lambdaはメモリに比例してCPU割り当てもスケールします。

EphemeralStorage.Sizeは1024 MBに設定されています。 デフォルトのLambda /tmp割り当ては512MBです。 IronPDFは、レンダリングエンジンバイナリ、フォントキャッシュ、テンポラリレンダリングファイルを/tmpに書き込みます。 これらのアセットはコールドスタートで512 MBを超えることがあり、その結果エンジンの抽出が失敗します。 エフェメラルストレージを少なくとも1024 MBに設定することで、この失敗モードを防ぐことができます。

Dockerfileをどのように構築しますか？ {#dockerfile}

Dockerfileはこのデプロイメントの心臓部です。 それはマルチステージビルドを行います：最初のステージではMavenビルドイメージを使用してJavaプロジェクトをコンパイルします； 2番目のステージでは、Amazon Linux 2を基にした最終Lambdaランタイムイメージを作成し、IronPDFのChromiumエンジンが必要とするシステムパッケージをインストールし、コンパイル済みの成果物をコピーします。

プロジェクトのDockerfileを開き、その内容を次のもので置き換えます：

//:path=Dockerfile
# Stage 1: Build the Maven project
FROM public.ecr.aws/sam/build-java8.al2:latest AS build-image
WORKDIR /task
COPY src/src/
COPY pom.xml ./
RUN mvn -q clean install
RUN mvn dependency:copy-dependencies -DincludeScope=compile

# Stage 2: Create the Lambda runtime image
FROM public.ecr.aws/lambda/java:8.al2

# Update the package index and install system libraries required by Chromium.
# These packages provide font rendering, graphics, audio, GTK3, and input
# method support — all needed by the headless browser inside IronPDF.
RUN yum update -y && \
    yum install -y \
        pango.x86_64 \
        libXcomposite.x86_64 \
        libXcursor.x86_64 \
        libXdamage.x86_64 \
        libXext.x86_64 \
        libXi.x86_64 \
        libXtst.x86_64 \
        cups-libs.x86_64 \
        libXScrnSaver.x86_64 \
        libXrandr.x86_64 \
        GConf2.x86_64 \
        alsa-lib.x86_64 \
        atk.x86_64 \
        gtk3.x86_64 \
        ipa-gothic-fonts \
        xorg-x11-fonts-100dpi \
        xorg-x11-fonts-75dpi \
        xorg-x11-utils \
        xorg-x11-fonts-cyrillic \
        xorg-x11-fonts-Type1 \
        xorg-x11-fonts-misc \
        glibc-devel.x86_64 \
        at-spi2-atk.x86_64 \
        mesa-libgbm.x86_64 \
        libxkbcommon \
        amazon-linux-extras && \
    amazon-linux-extras install epel -y && \
    yum install -y libgdiplus

# Ensure /tmp is writable by the Lambda execution user.
RUN chmod 777 /tmp/

# Copy the compiled classes and dependencies from the build stage.
COPY --from=build-image /task/target/classes /var/task/
COPY --from=build-image /task/target/dependency /var/task/lib

# Entry point: package.ClassName::methodName
CMD ["helloworld.App::handleRequest"]

両方のステージのベースイメージはプレーンjava8.al2タグを使用します。 .al2サフィックスは、IronPDFに必要なAmazon Linux 2を示します。 古いjava8イメージは、オリジナルのAmazon Linux 1上で動作し、yumリポジトリを使用しますが、これらは更新されず、IronPDFが依存するいくつかのパッケージを欠いています。 Java 8でIronPDFをデプロイする際は、常に.al2イメージを使用してください。

yum installブロックは、ページのレンダリングにChromiumが必要とするX11、GTK3、Pango、およびフォント関連のライブラリをインストールします。 これらのパッケージのいずれかを省略すると、不完全なPDF出力があったり、レンダリングエンジンが共有ライブラリ不足エラーでクラッシュする可能性があります。 libgdiplusパッケージは、IronPDFの一部の描画操作で使用されるGDI+互換性に必要です。

helloworld.Appと異なる場合に一致させます。

Lambda関数をどのように構築してデプロイしますか？ {#build-deploy}

Dockerfile、App.javaがすべて設定されると、プロジェクトルートから次の2つのSAM CLIコマンドを実行します。

ステップ1 — コンテナイメージをビルドします：

//:path=build.sh
sam build -u

//:path=build.sh
sam build -u

-uフラグは、Docker（"コンテナを使用する"モード）を使用するようSAMに指示します。 SAMはマルチステージのDockerfileを実行し、Mavenプロジェクトをコンパイルして最終Lambdaイメージを生成します。 Dockerがベースイメージをプルする初回の実行では、このステップに数分かかる可能性があります。

ステップ2 — AWSにデプロイします：

//:path=deploy.sh
sam deploy --guided

//:path=deploy.sh
sam deploy --guided

--guidedフラグは、スタック名、AWS リージョン、アーティファクト用のS3バケット、およびデプロイ前に変更セットを確認するかどうかを尋ねるインタラクティブなプロンプトを起動します。 プロンプトに答えると、SAM はコンテナイメージをAmazon ECRにプッシュし、template.yamlで定義されたLambda関数、API Gateway、およびIAMロールを作成します。

デプロイメントが完了すると、SAM CLIはAPIエンドポイントURLを出力します。 AWS Lambdaコンソールを開いて、デプロイされた関数を表示し、テスト呼び出しを実行し、IronPDFデバッグ出力のためにCloudWatchログを確認します。

最初の呼び出し（コールドスタート）では、Lambda実行環境が起動し、IronPDFがレンダリングエンジンを/tmpに抽出するので、応答時間は60〜120秒を想定します。 同じウォームインスタンスでの後続の呼び出しは数秒以内に戻ります。 本番ワークロードでコールドスタートの遅延が問題になる場合は、Lambda Provisioned Concurrencyを使用してインスタンスを温めた状態に保つことを検討してください。

開発マシンでDockerが実行されている場合、テストイベントペイロードを使用して sam local invoke を実行することで、デプロイ前に関数をローカルでテストすることもできます。

次のステップは何ですか? {#next-steps}

Lambda関数は現在デプロイされており、PDFのレンダリングを行っています。 以下のガイドは、IronPDFの導入が成功した後の一般的な次のステップをカバーしています。

• IronPDF for Java - スタートガイド - HTMLからPDF、URLからPDF、PDFへのスタンプを含むIronPDF Java API全体の概要。
• JavaでHTMLからPDFを生成する方法 - HTML文字列、ファイル、およびテンプレートをPDFにレンダリングします。
• JavaでPDFにヘッダーとフッターを適用する方法 - ページ番号、ロゴ、およびテキストヘッダーをLambdaで生成されたPDFに追加します。
• JavaでPDFに透かしを追加する方法 - PDF出力にテキストまたは画像の透かしをスタンプし、呼び出し元に戻す前に。
• IronPDFライセンス - 本番環境でのLambda展開のライセンスオプション、展開件数ライセンスなど。

IronPDF for Javaの無料トライアルを開始して、評価中に制限なくLambda関数でPDFを生成および編集します。 本番環境への展開の準備が整ったら、IronPDFライセンスオプションを表示し、サーバーレスワークロードに適したプランを見つけてください。