前章ではCantaloupeを用いた自前のイメージサーバ構築を解説しました。本章では、サーバの管理が不要な サーバーレスアーキテクチャ を使ったIIIF画像配信について、AWSの serverless-iiif プロジェクトを中心に解説します。

サーバーレスアーキテクチャのメリット

従来型のイメージサーバ（Cantaloupe等）では、EC2インスタンスの起動・停止管理、OSのセキュリティパッチ適用、Java/ミドルウェアのアップデートなど、継続的な運用コストが発生します。サーバーレスアーキテクチャでは、これらの負担が大幅に軽減されます。

観点従来型（Cantaloupe等）サーバーレス
サーバ管理OS・ミドルウェアの管理が必要不要
スケーラビリティインスタンスサイズの調整が必要自動スケール
コスト常時起動で固定費が発生リクエスト数に応じた従量課金
初期構築比較的手間がかかるCloudFormation/SAMで自動構築
カスタマイズ性Delegate Script等で柔軟Lambda関数の範囲内

特に、アクセス頻度が少ないデジタルアーカイブでは、常時サーバを起動させておくコストが課題になりがちです。サーバーレス構成では、リクエストが発生したときだけ処理が実行されるため、コスト効率に優れます。

serverless-iiifの概要

serverless-iiif は、Samveraコミュニティが開発しているオープンソースプロジェクトで、AWSの各種サービスを組み合わせてIIIF Image APIサーバを構築します。

構成要素は以下のとおりです。

  • AWS Lambda: IIIF Image APIのリクエスト処理を行う関数
  • Amazon S3: ソース画像（ピラミッドTIFF等）の格納先
  • Amazon CloudFront: CDNによるキャッシュと配信の高速化
  • AWS SAM / CloudFormation: インフラの自動構築

IIIF Image API 2.x および 3.0 に対応しており、公式リポジトリでは「コスト効率が高く、無限にスケーラブルなIIIF Image Server」と紹介されています。

デプロイ手順

serverless-iiifのデプロイは、AWSマネジメントコンソールのGUIから行う方法と、AWS SAM CLIを使う方法があります。ここでは、より簡便なGUIベースの手順を解説します。

1. S3バケットの準備

まず、ソース画像を格納するS3バケットを作成します。バケット名は任意ですが、後の設定で使用するため控えておきます。

例:my-iiif-images

2. ソース画像のアップロード

S3バケットにピラミッドTIFF形式の画像をアップロードします。画像の作成方法は次章「画像の前処理 – ピラミッドTIFFの作成」で詳述しますが、簡易的には以下のコマンドで変換できます。

vips tiffsave source.jpg output.tif \
  --tile --pyramid --compression jpeg \
  --tile-width 256 --tile-height 256

AWS CLIでアップロードします。

aws s3 cp output.tif s3://my-iiif-images/output.tif

サブディレクトリに格納する場合、IIIF URLではパス区切りの / を %2F にエンコードしてアクセスする点に注意してください。たとえば ezu/1286201.tif は、拡張子を除いた ezu%2F1286201 として指定します。

3. Lambda関数のデプロイ

AWSマネジメントコンソールから、serverless-iiifのサーバーレスアプリケーションをデプロイします。以下のURLにアクセスします。

https://console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-1:625046682746:applications/serverless-iiif

設定画面で以下の項目を入力します。

項目説明
アプリケーション名ユニークな名前を指定（重複するとエラーになる場合があります）
SourceBucket先ほど作成したS3バケット名
ForceHostカスタムドメインを使用する場合にドメイン名を指定（後述）

「このアプリがカスタム IAM ロールを作成することを承認します。」にチェックを入れ、「デプロイ」ボタンを押します。

デプロイ完了後、「デプロイ」タブの「CloudFormation スタック」リンクからCloudFormationの画面に遷移し、「出力」タブでエンドポイントURLを確認します。Image API v2 と v3 の両方のエンドポイントが表示されます。

4. 動作確認

エンドポイントURLを使って info.json を取得します。

https://<endpoint-url>/iiif/3/<画像名（拡張子なし）>/info.json

JSONが正しく返却されれば、デプロイ成功です。

CloudFrontによるCDN配信とカスタムドメイン

serverless-iiifのデフォルトではLambdaのFunction URLまたはAPI Gatewayが直接公開されますが、本番運用ではCloudFrontを前段に配置し、カスタムドメインで提供する構成を推奨します。

CloudFrontディストリビューションの作成

  1. CloudFrontコンソールで新しいディストリビューションを作成
  2. Origin domain にLambdaエンドポイントのドメイン部分を入力
  3. 代替ドメイン名（CNAME） にカスタムドメインを入力（例: iiif.example.com）
  4. Custom SSL certificate でACM証明書を選択

Route 53でのDNS設定

Route 53のホストゾーンで、カスタムドメインのAレコード（エイリアス）をCloudFrontディストリビューションに向けて設定します。

ForceHostの設定

serverless-iiifのデプロイ時に ForceHost パラメータにカスタムドメインを指定しておくと、info.json 内の id フィールドに正しいドメイン名が反映されます。これを設定しないと、Lambda側のドメインが id に使われてしまい、一部のビューアでエラーが発生する場合があります。

デプロイ後にForceHostを変更する場合は、Lambda関数の環境変数を直接編集するか、CloudFormationスタックを更新します。

設定変更後は、CloudFrontのキャッシュ無効化（Invalidation）を実行して、古いレスポンスをクリアしてください。

画像サイズの制限と対策

serverless-iiifでは、AWS Lambdaの制約（メモリ、実行時間）に起因する画像サイズの上限があります。

制約事項

  • Lambdaのデフォルトメモリは限られており、大きな画像の処理に時間がかかる場合があります
  • 初回アクセス（コールドスタート）時は、Lambda関数の起動時間が加算されるため、レスポンスが遅くなります
  • 2回目以降のアクセスでは、CloudFrontのキャッシュにより高速にレスポンスが返されます

対策

  • Lambda関数のメモリ・タイムアウト設定: Lambda関数の「設定」画面から、メモリサイズを1024MB以上に、タイムアウトを60秒以上に設定することを推奨します
  • ピラミッドTIFFの最適化: ソース画像をlibvipsで変換する際に、JPEG圧縮（Q=75程度）を使用してファイルサイズを抑えます。ImageMagickで変換した場合はファイルサイズが大きくなりがちです（検証では同一画像でvips: 35.6MB、ImageMagick: 107.4MBという差が確認されています）
  • CloudFrontの活用: 一度配信されたタイル画像はCloudFrontにキャッシュされるため、同じタイルへの2回目以降のアクセスはLambdaを経由しません

コスト最適化のポイント

サーバーレス構成のコストは主に以下の要素から構成されます。

サービス課金要素
Lambdaリクエスト数 + 実行時間 x メモリ
S3ストレージ容量 + リクエスト数
CloudFrontデータ転送量 + リクエスト数

コストを最適化するためのポイントは以下のとおりです。

  1. CloudFrontのキャッシュ戦略: TTL（Time To Live）を長めに設定し、Lambda呼び出しを最小限に抑えます。画像が更新されることは稀なため、長いTTLが適しています
  2. ソース画像の圧縮: ピラミッドTIFFのJPEG品質をQ=75程度にすることで、S3ストレージコストとLambdaのメモリ消費を抑制できます
  3. リージョンの選択: us-east-1（バージニア北部）はLambda、S3ともに料金が比較的安価です
  4. アクセスパターンの把握: CloudWatchでLambdaの呼び出し回数とCloudFrontのキャッシュヒット率を監視し、不要なコストが発生していないか確認しましょう

アクセス頻度が低い場合（月間数千リクエスト程度）、S3のストレージ料金が主なコストとなり、月額数ドル程度で運用できます。

Cantaloupeとの使い分け

serverless-iiifとCantaloupeは、それぞれ異なるユースケースに適しています。

比較項目serverless-iiifCantaloupe
運用コスト従量課金（低頻度アクセスに有利）固定費（常時起動が前提）
初回応答速度コールドスタートで遅い場合あり常時高速
カスタマイズ性Lambda関数の範囲内Delegate Scriptで高い自由度
アクセス制御IAM / CloudFrontレベルDelegate Scriptで画像単位の制御
対応ストレージS3のみS3, Azure, ファイルシステム等
画像形式ピラミッドTIFF（JPEG2000非対応）多数の形式に対応

serverless-iiifが向いているケース:

  • アクセス頻度が低〜中程度のデジタルアーカイブ
  • サーバ管理のリソースや知見が限られている場合
  • AWSを既に利用しており、運用をAWSに統一したい場合

Cantaloupeが向いているケース:

  • 高頻度のアクセスが見込まれる場合
  • IIIF Authentication API など高度なアクセス制御が必要な場合
  • Azure Blob Storageやオンプレミスのストレージを使いたい場合
  • JPEG2000をソース画像として使いたい場合

両者を併用する構成も有効です。たとえば、メインのコレクションはCantaloupeで配信し、アクセス頻度が低い補助的な画像はserverless-iiifで提供するといった使い分けが考えられます。

AWS Lambdaでの自動変換パイプライン

serverless-iiifと組み合わせることで、画像のアップロードからIIIF配信までを自動化するパイプラインを構築できます。詳細は次章で解説しますが、概要は以下のとおりです。

  1. 元画像をS3の入力バケットにアップロード
  2. S3イベント通知によりLambda関数が起動
  3. Lambda関数内でpyvipsを使ってピラミッドTIFFに変換
  4. 変換済みファイルを出力バケット（= serverless-iiifのSourceBucket）にアップロード
  5. serverless-iiif経由で自動的にIIIF Image APIで配信

この構成では、利用者はS3にJPEGやPNG画像をアップロードするだけで、自動的にIIIF対応の画像配信が開始されます。

まとめ

serverless-iiifは、AWSのマネージドサービスを活用して、運用負荷の少ないIIIF画像配信基盤を構築できる優れたソリューションです。特にデジタルアーカイブのような、高い可用性を求めつつもアクセス頻度が安定しないケースで真価を発揮します。

ただし、コールドスタートの問題やカスタマイズ性の制限もあるため、要件に応じてCantaloupeとの使い分けを検討することが重要です。次章では、IIIFイメージサーバに供給するソース画像の前処理として、ピラミッドTIFFの作成方法を詳しく解説します。