retty_image-optimizer_yamagoya2018

Transcript

1. Rettyにおける画像変換について Takumi Suzuki (@jp_taku2)
2. 自己紹介 Retty すずたく @jp_taku2 2014.4 オールアバウト 新卒入社 2016.8 Retty 入社 インフラを主にやっています。
3. 日本最大級の実名グルメサービス「Retty」 実名グルメサービス「 Retty」は、「信頼できる人からお店探しができる」グルメサービスとして、 2011年6月サービス開始以降、 利用者に実際行ったお店のオススメ情報を投稿していただく形で運営しています。 実名制の投稿、オススメの口コミ、周囲への拡散の仕組み など、スマートフォン時代のグルメサービスのスタンダードとしての特徴を兼ね備えたサービスとなっております。 （ご参考）Rettyのサービスコンセプト → https://retty.me/announce/philosophy/
4. スマホ時代の実名グルメサービス「Retty」 月間利用者数3,000万人突破
5. 好みの合う人や達人のオススメ、 近くの人気店から探せるアプリとして支持を拡大
6. agenda 1. Rettyにおける画像利用 a. 従来の画像変換について b. 移行検討になった課題 2. サービス比較 a. Image Optimizer b. ImageFlux c. Image Manager 3. 移行 a. 方法 b. 結果 4. まとめ
7. Rettyにおける画像利用
8. • web ◦ 店舗ページ ◦ エリアページ ◦ まとめページ • app ◦ タイムライン ◦ 店舗ページ ほぼ全てのページで利用 Origin画像数：約1500万枚 Rettyで使用されている画像
9. 従来の画像変換について
10. 従来の画像変換 第１期 ▪ 4つのテンプレートサイズの画像を用意 ▪ 原則全てのページでこれを使用する。
11. 従来の画像変換 第2期 ▪ ImageMagick+Nginxで画像変換を行う ▪ webの一部のみ適用
12. 従来の画像変換 第3期 ▪ 第3期 ✓ webをJavaScriptによる動的画像サイズ指定に変更 ✓ 第2期のものをWeb全展開（サーバー台数：4台→45台） ✓ アプリ全展開 ✓ webp対応
13. 発生した問題① ▪ 想定されていない利用による高負荷 ✓ 全展開して使用したことにより発生 ▪ 変換対象画像の多様化 ✓ JavaScriptにより動的画像サイズ変更により発生 ▪ 画像レスポンス速度の低下 ✓ 多様なサイズ変更・高負荷によりレスポンス速度低下
14. 発生した問題② ▪ コストの爆増 ✓ c4.largeが4台→45台 ▪ 運用コストが増えた ✓ アラートが毎週なるように鳴った。 ✓ なるはいいが対応が暫定対応しかできなくなってきた。 ▪ 改善の余地がなくなった ✓ Nginx + ImageMagickのシンプルな構造のためプログラムで
15. サービス比較
16. 比較したサービス ▪ Image Optimizer ✓ Fastlyによって提供されている画像配信サービス ▪ ImageFlux ✓ さくらインターネット株式会社とピクシブ株式会社が 共同で開発、提供しているクラウド画像変換サービス ▪ Image Manager ✓ アカマイ・テクノロジーズの画像変換サービス
17. 比較項目 ▪ 変換機能の充実度 ✓ 基本：crop / resize ✓ 何かサービスに活かせそうな機能 ▪ 対応URL ✓ Origin 3種 ✓ 提携サイトの画像 ▪ 移行コスト ▪ 運用コスト ✓ アラートの数が増加 ✓ アップデートによる工数増加 ▪ 費用コスト ✓ 現状よりは下げたい
18. 比較表 サービス名 従来の画像 変換 Image Optimizer (Fastly) ImageFlux (Sakura) Image Manager (Akamai) 機能充実度 3 4 5 3 対応URL数 5 5 3 1 フォーマット 3 4 5 3 移行コスト 5 3 1 運用コスト 3 5 5 1 費用コスト 2 3 2 5 Total 3.2 4.3 3.5 2.3 ※1 (悪い） < … < 5(良い）
19. Image Optimizerがmatchした点 ▪ resizeの長編・短編合わせが設定できた ▪ Slackでの相談ができ、サポートが手厚かった ▪ 設定をVCLベースでGit管理にできる ▪ VCLにより、従来のPathを変更することがないため、 開発側の移行工数がテストのみで終わることができた。
20. 移行について
21. 移行方法 1. Custom VCLを使用して、既存のPathと新規に発生するPathを 共存させそのまま使用できるように設定した 2. 画像テスト用のページを作成し、サイト内で使用されているドメイン から、全て正常に返っているかのテストを行った 3. 全チームにテストを行ってもらい、期待通りの返り値が返っているか テストを行った 4. DNS切り替え
22. 移行方法① ▪ Custom VCLを使用して、既存のPathと新規に発生するPathを 共存させそのまま使用できるように設定した
23. 移行方法② ▪ 画像テスト用のページを作成し、サイト内で使用されているドメイン から、全て正常に返っているかのテストを行った
24. 移行方法③ ▪ 開発者にもテストを行ってもらい、期待通りの返り値が返っているか テストを行った
25. 移行方法④ ▪ DNS切り替え ▪ DNSの設定ミスで切り替え失敗。。。 ▪ 深夜にリトライ
26. 移行結果 1. 従来の画像変換サーバーではWebpを使用したい場合、明示的 にパラメータを渡しておく必要があったが、Fastlyを使用する事 により、UAによりAutoでwebpを返せるようになった。 2. 画像変換の変換速度によるボトルネックが消え、投稿後反映に かかる時間が小さくなった 3. 画像容量と一部レスポンス速度が改善した
27. 移行結果① ▪ 従来の画像変換サーバーではWebpを使用したい場合、明示的にパ ラメータを渡しておく必要があったが、Fastlyを使用する事により、 UAによりAutoでwebpを返せるようになった。
28. 移行結果② ▪ 画像変換の変換速度によるボトルネックが消え、投稿後反映にかか る時間が小さくなった ▪ 画像容量とレスポンス速度が安定しました
29. 発生した課題
30. 課題だった所 ▪ 最近、当初の予定よりトラフィックが多かったため、 再見積もりが必要になった。 ▪ Originアクセスが想定より多くなってしまい、 コストが余分に発生してしまった。
31. 解決方法 ▪ 意図しないサイズで画像を使用していた場所を修正 ▪ Fastlyとの契約変更 ✓ 迅速に対応して頂き、当月適用してもらえた。
32. まとめ
33. まとめ ▪ Fastlyの移行までのサポートが手厚かった。 ✓ 開発途中だったAPIを提供して頂けた ▪ 従来よりはコストが下がった。 ✓ ちょっと見積もりが甘かったので手放しで喜ぶほど下がらなかった。 ▪ 画像クオリティ・レスポンス・容量が向上した。 ▪ 運用コストが激減した。 ✓ アラートがならずに安眠ができて最高
34. ご清聴ありがとうございました.