はじめに
最近では 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
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用に構成することもできないかも考えてみたい。（無理か）