Cantaloupe IIIFサーバから serverless-iiif への移行記録
EC2上でDocker稼働させていたCantaloupeを、AWS Lambda + CloudFrontベースの serverless-iiif（Samvera）に移行した際の調査と作業の記録です。
iiifawslambdacloudfrontcantaloupeserverless
台本(フルテキスト)
動画の掛け合いを書き起こしたものです。音声を再生しづらい場合はこちらをお読みください。
オープニング
- Cantaloupe (EC2) から serverless-iiif (Lambda) への移行
- セキュリティ負荷軽減とコスト削減が動機
- うさぎ
- こんにちは。今日はどんなトピックを紹介するの？
- WhiteCUL
- EC2 上の Docker で動かしていた Cantaloupe という IIIF 画像サーバを、Lambda ベースの serverless-iiif に移行した記録です。
- うさぎ
- どうして移行しようと思ったの？
- WhiteCUL
- 主にセキュリティとコスト面です。EC2 を公開していると OS パッチ、Docker イメージの脆弱性、Java の CVE 追従など、継続的な作業が多くありました。サーバレス化すれば OS 管理が AWS の範囲になります。
- うさぎ
- コスト面ではどれくらい違うの？
- WhiteCUL
- t3.large 24 時間稼働で月 60 ドル以上かかっていましたが、過去 30 日のトラフィックから試算すると月 4 ドル程度になる見込みでした。
serverless-iiif の選定と特徴比較
- Samvera の serverless-iiif は SAR から 1 コマンドでデプロイ可能
- Cantaloupe は柔軟・高機能、serverless-iiif は軽量・マネージド
- うさぎ
- serverless-iiif ってどういうものなの？
- WhiteCUL
- Samvera プロジェクトが提供する Node.js + sharp で動く IIIF Image API サーバを Lambda にパッケージしたものです。AWS Serverless Application Repository から 1 コマンドでデプロイできます。
- うさぎ
- Cantaloupe と比べてどう違うの？
- WhiteCUL
- Cantaloupe は 100 以上のパラメータで詳細設定でき、プロセッサも TurboJpeg や Kakadu など選べます。serverless-iiif はパラメータが 10 個程度と少なく、エンジンは sharp 固定です。
- うさぎ
- キャッシュはどうなるの？
- WhiteCUL
- Cantaloupe はアプリ内に 3 層のキャッシュを持てますが、serverless-iiif は Lambda がステートレスなので CloudFront による外付けキャッシュが前提です。
性能比較とリージョン選定
- us-east-1 より Tokyo Lambda の方が応答が速い
- CloudFront の CDN ヒットは両者とも 50ms 前後
- うさぎ
- 速度はどれくらい出るの？
- WhiteCUL
- 東京からの計測で、Cantaloupe の origin は info.json が 550〜580 ミリ秒でしたが、実はこれは CloudFront のキャッシュヒットでした。サーバレス Tokyo の cold は 790〜900 ミリ秒で、実用上ほぼ同等でした。
- うさぎ
- CloudFront のヒット率が高ければ問題ないのね。
- WhiteCUL
- そうです。キャッシュヒット時は両方とも 50 ミリ秒前後で返ります。タイル画像は内容が変わらないので TTL を 1 年に設定できます。
- うさぎ
- us-east-1 と Tokyo でどう違ったの？
- WhiteCUL
- S3 のバケットと Lambda が同じリージョンだと、クロスリージョンのラウンドトリップが省けます。Tokyo Lambda は us-east-1 版より明確に速い結果でした。
セキュリティ強化
- OAC for Lambda Function URL で直接アクセスを遮断
- Reserved concurrency でコスト爆発を物理的に防止
- うさぎ
- セキュリティはどう強化したの？
- WhiteCUL
- CloudFront の Origin Access Control for Lambda を設定して、Lambda Function URL に SigV4 署名付きでリクエストするようにしました。直接 URL を叩くと 403 が返ります。
- うさぎ
- コスト爆発対策はどうしたの？
- WhiteCUL
- Reserved concurrency を 50 に設定しました。同時実行が 50 を超えると 503 で fail-fast になるので、攻撃時でも費用が青天井にはなりません。
- うさぎ
- WAF も使ったの？
- WhiteCUL
- はい。組織内の共有 WAF に rate-based ルールが既にあったため、CloudFront に attach するだけで自動的に適用されました。
カットオーバーの落とし穴
- associate-alias は DNS 検証エラーで通らなかった
- DNS 切替 → alias 追加の順序が正解
- うさぎ
- 本番への切り替えで詰まったことはあった？
- WhiteCUL
- CloudFront の associate-alias API を使おうとしたら DNS 検証エラーで通りませんでした。ドキュメントと挙動が一致しない状況で、最終的に手動の update-distribution に切り替えました。
- うさぎ
- どういう順序で進めたの？
- WhiteCUL
- 旧 CloudFront から alias を削除、DNS を新 CloudFront に切り替え、その後で新 CloudFront に alias を追加という順序です。DNS が新 CF を指した状態でないと alias 追加が CNAMEAlreadyExists で弾かれます。
- うさぎ
- サービス断はどれくらいだったの？
- WhiteCUL
- 概ね 2〜3 分でした。事前に DNS の TTL を 300 秒から 60 秒に下げておいたことで、クライアント側のキャッシュが早く失効して短く済みました。
まとめ
- S3 + Lambda + CloudFront の構成で月 4 ドル程度に削減
- 移行は「DNS 切替 → alias 追加」の順序が重要
- うさぎ
- 今日のポイントをまとめてほしいわ。
- WhiteCUL
- S3 に置いた画像を IIIF で公開するのが主目的で、アクセスが多くない場合は serverless-iiif が運用負荷とコストの両面で有利です。
- WhiteCUL
- OAC for Lambda URL で直接アクセスを遮断、Reserved concurrency でコスト上限を設定するセキュリティ対策が有効でした。
- うさぎ
- カットオーバーには注意が必要ね。
- WhiteCUL
- そうですね。DNS 切替と CloudFront alias 追加の順序、事前の TTL 短縮が大事でした。
- うさぎ
- よく分かったわ。ありがとう！