はじめに

最近では AWS Lambda がコンテナに対応したことで、これまで無理だったような「ちょっと重たい処理」も動かせるようになってきました。

今回はその応用として「Excel を PDF に変換する」処理を Lambda + Docker で実現した構成を性能評価して実用可能か検証したいと思います。変換自体は全く同じような過去記事がありますのでそちらを参照していただければと。

関連記事で以前、Lambdaでの x86 と ARM の性能比較も書きました👇
https://qiita.com/hats_yaki/items/9d7e3522b1158f099645

ARMでは動作できないパターンを検証したくて進めてたけど逆に難しくてここに行き着いたというわけです。

システム構成図（概要）

          ┌────────────┐
          │ S3         │
          │(Excel保存) │
          └────┬───────┘
               │
     Event / API Gateway
               │
     ┌────────▼────────────┐
     │ AWS Lambda（Docker）│
     │ ・LibreOffice変換処理│
     └────────┬────────────┘
              │
          ┌───▼────┐
          │ S3     │
          │(PDF保存)│
          └───┬────┘
              │
     Presigned URLで返却

イメージサイズと実行パフォーマンス

Containerイメージサイズ

環境	表示サイズ
Windows ローカル（`docker images`）	約 993MB
ECR にプッシュ後（表示サイズ）	約 383MB

※ ECR 上は圧縮後サイズが表示されるため、実サイズとの差異あり。Lambdaにデプロイ可能な上限（10GB）は問題なし。

メモリサイズごとの実行時間

LibreOfficeの起動・PDF変換を伴うため、初回はウォームアップがやや重め 表からは省いてます。2回目以降は高速になります。2回目以降の所要時間（課金時間）をベースにコストパフォーマンスを計測。

Lambda実行結果とコストパフォーマンス比較

メモリ (MB)	所要時間 (ms)	最大使用メモリ (MB)	コストパフォーマンス（GB-ms）
768	2923.02	389	2192.26
1024	2221.19	390	2221.19
1280	1777.46	389	2221.82
1536	1403.57	389	2105.36
1792	1383.73	389	2421.53

※ 初回起動は省いてます

実装の一部

Dockerfile.app

docker-compose.yml

version: '3.8'

services:
  libreoffice-base:
    build:
      context: .
      dockerfile: Dockerfile.base
    image: libreoffice-base:latest

  app:
    build:
      context: .
      dockerfile: Dockerfile.app
    depends_on:
      - libreoffice-base
    image: pdf-app:latest

Dockerfile.app

FROM debian:bullseye-slim

# 基本システムツールのインストール
RUN apt-get update
RUN apt-get install -y --no-install-recommends apt-utils
RUN apt-get install -y --no-install-recommends software-properties-common

# 必須ライブラリのインストール
RUN apt-get install -y --no-install-recommends libc6 libgcc1 libstdc++6
RUN apt-get install -y --no-install-recommends libx11-6 libxext6 libxrender1
RUN apt-get install -y --no-install-recommends libfontconfig1

# LibreOfficeのインストール（最小構成）
RUN apt-get install -y --no-install-recommends libreoffice-core
RUN apt-get install -y --no-install-recommends libreoffice-calc

# フォントのインストール（日本語対応）
RUN apt-get install -y --no-install-recommends fonts-noto-cjk
RUN fc-cache -fv

なお、この他にも Dockerfile.app app.py entry.sh などアプリケーションを動かすためのファイルがありますが本章のメインではないので割愛します。

まとめ

Lambda × コンテナ × LibreOfficeで「Excel → PDF変換」は十分に実現可能
GUI不要のCLI操作だけで完結する点が便利

LibreOfficeのイメージを作る必要があり、イメージサイズが1GBの時点でパフォーマンスダメかなと思いましたが思いのほか実用的ではないかという結果になっているし、体感は実運用ありありか。
イメージサイズが1GBなら、メモリサイズはそれを少し上回る程度が最もパフォーマンス良いのかなと思いましたが、1,536MBあたりで頭打ちになるようで、このサイズが最もパフォーマンス良かったです。

終わりに

記事を書いていて思ったが、最大使用メモリがイメージサイズに達してないってことはエフェメラルストレージが関係・・・する？追加検証はいつか・・・
元々、ARM構成で動かないパターンを模索する中で行き着いたが、ARM用に構成することもできないかも考えてみたい。（無理か）