今まではURLパラメータによる「動的な画像リサイズ＋圧縮」をLambda@Edgeで行っていたが、それをimgixという画像処理に特化したSaaSの画像向けCDNに移行した背景と所感についてまとめてみる。
TL;DR
- Lambda@Edgeはレスポンスサイズの上限が1MBなので、大容量画像に不向き
- imgixの方が、初回（キャッシュなし）時のレスポンスタイムが速い（およそ1000ms → 200ms）
- imgixは導入も手軽で、料金はLambda@Edgeとほとんど変わらない
- imgixはwebp対応ブラウザ（Chromeなど）に自動でwebpで返すことができる
Lambda@Edgeの残念な点
レスポンスサイズの上限が1MBまで
Lambda@Edgeはレスポンスサイズの上限が1MBまでという割と大きな欠点がある。例えば横2000pxにリサイズしたけど1MBを超えてしまうという場合に、リサイズせずにそのままオリジンの画像を返す必要がある。
webp対応かの判定をする場合は遅くなる
imgixは?auto=formatと付けると、Chromeなどのwebp対応ブラウザにはwebp形式で自動で返してくれる。
これの同等の機能をLambda@Edgeで実装する場合、キャッシュの有無にかかわらずUserAgentによる判定のLambdaを1つ挟まなければならず、そのLambdaの起動によってキャッシュありの場合でもレスポンスが遅くなってしまう。下画像でいえばViewer requestにあたる。（画像の処理を行うLambdaはOrigin response）
レスポンス速度が遅い
あとはLambda@Edgeはレスポンスが遅い。キャッシュがない画像をリクエストした際はLambdaが走るのだが、おおよそ1~1.5秒ぐらい掛かる。しかしimgixはwebpの判定とロスレス圧縮を加えても200ms～300msで返ってくる。画像処理がかなり速いのだ。
Lambda@Edgeはレスポンスが遅いため、画像のリリース時にわざわざCloudFrontのドメインを叩いてキャッシュを生成していたが、imgixにしてからはそれが必要なくなった。
imgixは導入簡単で値段も安い
imgixのセットアップ自体もかなり手軽にできる。自分の場合はオリジンの画像をAmazon S3に保存しているが、バケット名とアクセス用IAMのキーを渡すだけでOK。ダッシュボードも見やすいしレンダリングに掛かった時間などもチェックできる。
値段もお手頃で、オリジン画像の取得1000回で3\$、転送量1GBで0.01\$しか掛からない。ほぼLambda@Edgeと変わらない値段だが、最低10ドルからという制限があるので注意が必要。
imgixの代替案
imgixの他にも画像処理CDNを提供するSaaSはある。例えばメルカリやpixivが利用している「ImageFlux」もある。ただImageFluxは料金をサイトで公開しておらず、小規模サービスに導入するには一定のハードルがある。
他にもFastlyは「Image Optimization」を提供している。Fastlyの場合は画像に加えてJSやCSSなどの静的アセットも扱うことができるが、ImageOptimizerの値段は少し高く、契約もFastlyのサポートとコンタクトを取る必要がある。FastlyはVCLも扱えるのでCDNサービスとしては自由度が高く優秀だが、小規模サービスではimgixで十分すぎる。
結論
Lambda@Edgeのメリットを挙げるなら、AWSの証明書と組み合わせて無料でカスタムドメインが使えること、そして法人ならAWSに請求書をまとめられる事ぐらいになる。画像だけなら別にカスタムドメインじゃなくてもいいし、何よりセットアップが手軽で低料金なのがimgixの良いところだと思う。
一休.comもimgix導入で画像最適化とサイトスピードを改善した話という導入事例があり、実際に自分も業務レベルで十分に扱える印象を受けている。サービスの画像周りで課題を抱えているなら、ぜひ検討して欲しい。