Cantaloupe IIIFサーバーのキャッシュ最適化で画像配信を最大7.6倍高速化した
はじめに IIIFに対応した画像サーバーであるCantaloupeを、S3をソースとしたDocker環境で運用しています。IIIFビューア（Mirador, OpenSeadragonなど）では、ズームやパンの操作のたびに数十〜数百のタイルリクエストが同時に発生します。 今回、キャッシュ設定の見直しとパラメータチューニングにより、タイル配信速度を最大7.6倍高速化できたので、その手法と効果を共有します。 環境 サーバー: AWS EC2（2 vCPU, 7.6GB RAM） Cantaloupe: islandora/cantaloupe:2.0.10（Cantaloupe 5.0.7ベース） 画像ソース: Amazon S3（S3Source） テスト画像: 25167×12483px のTIFF画像（512×512タイル） リバースプロキシ: Traefik v3.2 構成: Docker Compose 問題：デフォルト設定ではキャッシュが無効 islandora/cantaloupe イメージのデフォルト設定を調査したところ、以下の状態でした。 キャッシュ種別 デフォルト 説明 Derivative Cache（加工済み画像） 無効 同じリクエストでも毎回画像変換が発生 Source Cache（元画像のローカルコピー） 有効（FilesystemCache） S3から取得した元画像をローカルに保持 Info Cache（画像メタデータ） 有効（メモリ内） 画像の寸法・タイル情報を保持 Client Cache（HTTPヘッダ） 有効（max-age 30日） ブラウザ側のキャッシュ制御 最大の問題は Derivative Cache が無効であることです。IIIFビューアが同じタイルを再度リクエストした場合でも、毎回 S3 → ダウンロード → 画像変換 → レスポンス という処理が走ります。 ベンチマーク方法 単純なタイル一括テスト まず基本的な性能測定として、以下の条件で一括タイルベンチマークを行いました。 タイル数: 91タイル（zoom level 4、scaleFactor=4の全タイル） 同時接続数: 10（ブラウザの一般的な同時接続数） ツール: curl + xargs -Pによる並列リクエスト # タイルURLを生成し、10並列で同時リクエスト xargs -a tile_urls.txt -P 10 -I {} \ curl -s -o /dev/null -w "%{time_total}\n" "{}" Miradorシミュレーション 単純なタイル一括テストに加え、IIIFビューア（Mirador）の実際の操作フローを再現したベンチマークも行いました。Miradorでは、ユーザーが画像を開くと以下のリクエストが短時間に発生します。 ...
