Slide 1
Slide 1 text
顧客の画像データをテラバイト単位で配信する
画像サーバを WebP にした際に起こった課題と
その対応策
～継続的な取り組みを添えて～
1
SRE NEXT 2025
Slide 2
Slide 2 text
2
自己紹介
技術部 技術基盤グループ プリンシパルエンジニア
2019年 中途入社
高橋 拓也 takutaka
インフラエンジニア。パブリッククラウドの活用と
クラウドネイティブ関連技術に関する業務が
多い。自宅の Kubernetes はもうすぐ5年目
となり、愛着があるため破壊的な構成変更が
できない。
Slide 3
Slide 3 text
3
アジェンダ
- GMO ペパボとカラーミーショップについて
- カラーミーショップにおける画像配信
- WebP 化への課題と解決するアーキテクチャ
- リリース
- 効果測定
- 新しい WebP 変換手法への取り組み
Slide 4
Slide 4 text
GMOペパボと
カラーミーショップ
4
Slide 5
Slide 5 text
私たちはインターネットやテクノロジーの力で情報発信のハードルを下げ、
あらゆるアウトプットを世界中に増やします。
さまざまなアウトプットが進化や価値を生み出すように、
私たちもプロダクトを生み出し続け、ユーザーと共に進化し拡大していきます。
ミッション
人類のアウトプットを
増やす
5
Slide 6
Slide 6 text
事業セグメントと主力サービス
ペパボは、主に個人の表現活動を支援するためのさまざまなウェブサービスおよびスマートフォンアプリを提供しています。それぞ
れのサービスは、以下のようにセグメント分けされています。
6
ドメイン・レンタルサーバー（ホス
ティング）
事業
EC支援
事業
ハンドメイド
事業
金融支援
事業
その他
Slide 7
Slide 7 text
7
EC支援事業「カラーミーショップ」
商売をするすべての人を支え、
ECの多様性を広げる
これからビジネスを始める方から、すでに成長中のビジネスを
手がける方まで、商材や事業規模に関わらず「成長できる」EC
サイトが構築できるサービスです。多彩な機能と手厚いサポー
トで商売をする人を支援しています。
国内最大級のECサイト構築サービス
利用料金 フリー / レギュラー / ラージ / プレミアム
主なユーザー 個人商店や中小店舗
契約件数 5.0万件
※2024年9月末時点
※料金プラン詳細(4プラン)：フリー 0円~ 、レギュラー4,950円~、ラージ9,595円~、プレミアム39,600円~
Slide 8
Slide 8 text
- ショップオーナー
- カラーミーショップを用いて EC サイトを運営する方
- カラーミーショップに料金を支払ってくれているのはこちら
- エンドユーザー
- ショップに訪れて購買行動を起こす方
- ショップオーナーにとっての「お客様」
8
カラーミーショップ
カラーミーショップには 2種類の「お客様」がいる
Slide 9
Slide 9 text
画像配信サーバ
9
Slide 10
Slide 10 text
10
画像配信サーバ
- ショップオーナーがアップロードした商品画像
カラーミーショップにおける画像配信
Slide 11
Slide 11 text
11
画像配信サーバ
- 画像配信コンポーネントはすべて AWS 上で構築されている
- CloudFront を用いて月に全体で約400TB配信している
カラーミーショップにおける画像配信
Slide 12
Slide 12 text
12
画像配信サーバ
カラーミーショップにおける画像配信
ショップオーナーの作成したデータを配信することになる
→ 必ずしも商品画像として用いることに向いたデータを入稿いただけるとは限らない
Slide 13
Slide 13 text
13
画像配信サーバ
商品画像に向く画像の例
- jpeg to jpeg の動的画像変換サーバで入稿画像の自動変換を実施している
- ショップオーナーの手間なく最適な画像を配信するため
- 配信容量の削減と表示速度の高速化が実現できている
Slide 14
Slide 14 text
14
画像配信サーバ
商品画像に向く画像の例
- jpeg to jpeg の動的画像変換サーバで入稿画像の自動変換を実施している
- ショップオーナーの手間なく最適な画像を配信するため
- 配信容量の削減と表示速度の高速化が実現できている
転送容量削減によるコスト最適化と
顧客体験の向上を目的として
次世代フォーマットへの動的変換を行った
Slide 15
Slide 15 text
画像を WebP にするぞ！
15
Slide 16
Slide 16 text
16
画像配信サーバ
なぜ WebP か？
- 各種ブラウザでの対応が成熟したフォーマットであった
- iOS の Safari で対応が進んだ
- 圧縮率が高いことが実証されていた
Slide 17
Slide 17 text
実ワークロードでの有効性検証
17
Slide 18
Slide 18 text
18
実ワークロードでの有効性検証
期待する圧縮率を確保できるか
- ショップオーナーの実画像データで期待する結果が得られるか
- より多くの画像で期待する結果が得られるか
Slide 19
Slide 19 text
- カラーミーショップで運営されているショップの回遊をシミュレーション
a. とあるショップの「よくアクセスされる URL」トップ100を出す
b. 100のURLからリンクで辿れる2階層までの全画像を収集する
c. 画像の出現回数、画像の容量を集計する
d. 画像を WebP に変換する
e. 変換後の容量 * 出現回数を全画像で計算する
f. 足し合わせて総容量を比較する
19
実ワークロードでの有効性検証
実ショップから傾向を知る
Slide 20
Slide 20 text
- 約6500枚の画像を評価し、全体で55%の容量削減となることが確認された
• CloudFront の転送量が55%削減される
• うれしい!
20
実ワークロードでの有効性検証
実ショップから傾向を知る
Slide 21
Slide 21 text
- 約6500枚の画像を評価し、全体で55%の容量削減となることが確認された
• CloudFront の転送量が55%削減される
• うれしい!
21
実ワークロードでの有効性検証
実ショップから傾向を知る
効果が高いことがわかったので
リリース戦略を考える
Slide 22
Slide 22 text
画像品質の対応
22
Slide 23
Slide 23 text
- パラメータをチューニングすることで品質への影響を最小限とした
- デザイナー、ステークホルダーと品質確認を実施し OK をもらった
- 品質は問題ない...はず！
23
漸進的なリリース戦略
画像品質を高く保ちつつ効果を得たい
Slide 24
Slide 24 text
- 品質の感じ方は人それぞれ異なる
- 「劣化」はしないが「変化」はする
24
漸進的なリリース戦略
品質にほぼ影響はないとはいえ ...
Slide 25
Slide 25 text
- 品質の感じ方は人それぞれ異なる
- 「劣化」はしないが「変化」はする
25
漸進的なリリース戦略
品質にほぼ影響はないとはいえ ...
ショップオーナーに直接確認していただき
フィードバックを得るのが確実である
Slide 26
Slide 26 text
- 「ショップオーナーだけ WebP で表示される」モードを実装 by windyakin
- ショップの管理画面から有効化できる
- 確認の結果、品質が受け入れられないショップに対しオプトアウトを提供
26
漸進的なリリース戦略
WebP お試しモードの実装
Slide 27
Slide 27 text
- 「ショップオーナーだけ WebP で表示される」モードを実装 by windyakin
- ショップの管理画面から有効化できる
- 確認の結果、品質が受け入れられないショップに対しオプトアウトを提供
27
漸進的なリリース戦略
WebP お試しモードの実装
ショップオーナーにご納得いただいたうえで
リリースを迎えることができた
Slide 28
Slide 28 text
リリース戦略
28
Slide 29
Slide 29 text
29
リリース戦略
- WebP に変換する画像は jpeg に限定した
- png, gif は対象外とした
- 可逆圧縮やアニメーションを含みリスクが高いため
- 商品に紐づく画像を対象とした
- https://img.shop-pro.jp/[ショップを表すパス]/product/ に配置されている
変換対象の決定
Slide 30
Slide 30 text
30
リリース戦略
- WebP を閲覧できないエンドユーザーは「存在する」と仮定した
- 古いPCを使い続けているなど
- エンドユーザーの閲覧環境により画像の差し替えを行う必要がある
WebP を閲覧できないエンドユーザーの存在
Slide 31
Slide 31 text
- picture タグを用いる方法は使えない
- ショップのページはテンプレートで SSR している
- テンプレートはショップオーナーの資産であるため変更不可能
31
リリース戦略
画像の差し替え : picture タグ
Slide 32
Slide 32 text
- サーバサイドでクライアントの閲覧可否を判断する
- 閲覧可能なブラウザからのアクセスは WebP を返却
- そうでなければ従来の画像を返却
32
リリース戦略
画像の差し替え : URL を変えずにデータを差し替える
Slide 33
Slide 33 text
33
リリース戦略
WebP 導入前の構成はこんな感じ
リリース前の構成
CloudFront
/cat.jpg
変換サーバー S3
… AWS Managed
… Self Managed (EKS)
Slide 34
Slide 34 text
34
リリース戦略
- ショップオーナーに入稿いただいた画像は S3 に保管
リリース前の構成
CloudFront
/cat.jpg
変換サーバー S3
入稿画像
Slide 35
Slide 35 text
35
リリース戦略
- jpeg to jpeg の変換を行い CDN にキャッシュさせている
リリース前の構成
CloudFront
/cat.jpg
変換サーバー S3
最適な品質で
返却する
Slide 36
Slide 36 text
36
リリース戦略
- CloudFront と変換サーバとの間に url 変換器を設置
最終的な構成
CF
/cat.jpg
変換 S3
url-conv
Slide 37
Slide 37 text
37
リリース戦略
- CloudFront と変換サーバとの間に url 変換器を設置
最終的な構成
CF
/cat.jpg
変換
url-conv
Slide 38
Slide 38 text
38
リリース戦略
- エンドユーザーから受けたリクエストの Accept ヘッダを変換器に渡す
最終的な構成
CF
/cat.jpg
変換
url-conv
/cat.jpg
Accept: image/jpeg
Slide 39
Slide 39 text
39
リリース戦略
- image/jpeg の場合は jpeg しか表示できないため従来通りのレスポンスを返す
最終的な構成
CF
/cat.jpg
変換
url-conv
/cat.jpg
jpeg
Slide 40
Slide 40 text
40
リリース戦略
- Accept ヘッダに image/webp がある場合、クライアントは WebP 対応
最終的な構成
CF
/cat.jpg
変換
url-conv
/cat.jpg
Accept: image/webp
Slide 41
Slide 41 text
41
リリース戦略
- 拡張子に .webp をつけた Location をつけてクライアントに 302 Redirect する
最終的な構成
CF
/cat.jpg
変換
url-conv
/cat.jpg
302
Loc: /cat.jpg.webp
302
Loc: /cat.jpg.webp
Slide 42
Slide 42 text
42
リリース戦略
- .webp 付きリクエストは url-conv を通り画像変換サーバまで到達する
最終的な構成
CF
/cat.jpg.webp
変換
url-conv
/cat.jpg.webp webp
Slide 43
Slide 43 text
43
リリース戦略
- 変換サーバで WebP に変換され、クライアントまでレスポンスされる
最終的な構成
CF 変換
url-conv
WebP WebP WebP
Slide 44
Slide 44 text
リリース後に ...
44
Slide 45
Slide 45 text
画像が表示できない！
45
Slide 46
Slide 46 text
46
画像が表示できない！
- 様々な OS、ブラウザの環境で発生
- すべてのエンドユーザーではない、っぽい
...
- 社内の検証端末や私物端末で再現しない
...
- 画像サーバのメトリクスに異変は見られない
...
画像が表示できない問い合わせが発生
Slide 47
Slide 47 text
47
画像が表示できない！
- cache-control ヘッダによるブラウザキャッシュによるものではと判断
発生していたであろう事象
Slide 48
Slide 48 text
48
画像が表示できない！
- 先程の図で、cache-control ヘッダもやり取りされていた
発生していたであろう事象
CF
/cat.jpg
変換 S3
url-conv
max-age: xxxx
Slide 49
Slide 49 text
49
画像が表示できない！
- jpeg のキャッシュを持つエンドユーザーがリクエストを送る
発生していたであろう事象
CF
/cat.jpg
変換 S3
url-conv
j
WebP キャッシュ
w
jpeg キャッシュ
j
Slide 50
Slide 50 text
50
画像が表示できない！
- このクライアントは cache-control の max-age を持っているためキャッシュを見る
発生していたであろう事象
CF
/cat.jpg
変換 S3
url-conv
j
cache-control: max-age=86400
Slide 51
Slide 51 text
51
画像が表示できない！
- max-age が切れ、再度 CF にリクエストを送る
- この際に if-modified-since ヘッダを付けて送信する
発生していたであろう事象
CF
/cat.jpg
変換 S3
url-conv
j
If-Modified-Since: 3days-ago
Slide 52
Slide 52 text
52
画像が表示できない！
- CF からも url-conv に同様のヘッダが送られる
発生していたであろう事象
CF
/cat.jpg
変換 S3
url-conv
j
If-Modified-Since: 3days-ago
Slide 53
Slide 53 text
53
画像が表示できない！
- url-conv は webp 拡張子への302を返し、CF もそのままクライアントに返す
発生していたであろう事象
CF
/cat.jpg
変換 S3
url-conv
j
302 Location: /cat.jpg.webp
Slide 54
Slide 54 text
54
画像が表示できない！
- クライアントは、If-Modified-Since を再度つけてリクエストしているように見えた
発生していたであろう事象
CF
/cat.jpg.webp
変換 S3
url-conv
j
If-Modified-Since: 3days-ago
Slide 55
Slide 55 text
55
画像が表示できない！
- そのリクエストは変換サーバ、S3 にまで到達する
発生していたであろう事象
CF
/cat.jpg.webp
変換 S3
url-conv
j
If-Modified-Since: 3days-ago
Slide 56
Slide 56 text
56
画像が表示できない！
- S3 へのリクエストで If-Modified-Since と比較されるのは「オブジェクト変更日時」
- 変更日(アップロード日)より確実に未来であるため304が帰る
発生していたであろう事象
CF
/cat.jpg.webp
変換 S3
url-conv
j
If-Modified-Since: 3days-ago
304 Not Modified
Slide 57
Slide 57 text
57
画像が表示できない！
- 変換サーバはレスポンスヘッダをパススルーする仕様
- CF まで304が到達する
発生していたであろう事象
CF
/cat.jpg.webp
変換 S3
url-conv
j
304 Not Modified
Slide 58
Slide 58 text
58
画像が表示できない！
- ユーザーに CF が304を返しているように見えた
- Refresh Hit ではなく？と思ったのだが...
発生していたであろう事象
CF
/cat.jpg.webp
変換 S3
url-conv
j
304 Not Modified
Slide 59
Slide 59 text
59
画像が表示できない！
- jpeg のキャッシュは /cat.jpg のものであり、/cat.jpg.webp では使えない
- キャッシュを持っていないのに304がレスポンスされたことになる
発生していたであろう事象
CF
/cat.jpg.webp
変換 S3
url-conv
j
304 Not Modified
w
Slide 60
Slide 60 text
60
画像が表示できない！
- jpeg のキャッシュは /cat.jpg のものであり、/cat.jpg.webp では使えない
- キャッシュを持っていないのに304がレスポンスされたことになる
発生していたであろう事象
CF
/cat.jpg.webp
変換 S3
url-conv
j
304 Not Modified
w
「画像が表示されない！」
Slide 61
Slide 61 text
実行した対策
61
Slide 62
Slide 62 text
62
対策
Slide 63
Slide 63 text
63
対策
Slide 64
Slide 64 text
64
対策
URL は jpg なのに WebP
Slide 65
Slide 65 text
- 拡張子を変えずに古いjpeg のキャッシュが使えるようにした
- 転送量、ユーザー体験ともに悪化しないため問題ない
- ブラウザでの表示や保存した場合の挙動も問題なし
- ブラウザは Content-Type でフォーマットを判断する仕様
65
実行した対策
302リダイレクトをやめた
Slide 66
Slide 66 text
- 拡張子を変えずに古いjpeg のキャッシュが使えるようにした
- 転送量、ユーザー体験ともに悪化しないため問題ない
- ブラウザでの表示や保存した場合の挙動も問題なし
- ブラウザは Content-Type でフォーマットを判断する仕様
66
実行した対策
302リダイレクトをやめた
紆余曲折あったがリリースが完了！
効果測定を実施した
Slide 67
Slide 67 text
リリース後の効果測定
67
Slide 68
Slide 68 text
68
リリース後の効果測定
- WebP での表示件数の増加
- 画像あたりの容量の減少
- その結果による CDN の総転送量の低下
期待する効果が得られたか？
Slide 69
Slide 69 text
69
リリース後の効果測定
- WebP での表示件数の増加
- 画像あたりの容量の減少
- その結果による CDN の総転送量の低下
期待する効果が得られたか？
S3 に貯まるリクエストログを
Athena で分析することで効果測定を実施した
Slide 70
Slide 70 text
70
リリース後の効果測定
- 見積もりでは 55% の削減効果
- リリース後の確認で、削減効果がおよそ
10%であることがわかった
全体の配信量を見ると ...
削減効果
リリース前 0%
リリース後(予測) 55%
リリース後(実測) 10%
Slide 71
Slide 71 text
効果が出ていない！？
71
Slide 72
Slide 72 text
72
効果が出ていない！？
仮説は以下の2つに分類できるためそれぞれ確認
- WebP 変換後の容量削減効果が薄い
- 見積もりより変換する件数が少ない
なぜ効果が出ていないのか
Slide 73
Slide 73 text
73
効果が出ていない！？
仮説は以下の2つに分類できるためそれぞれ確認
- WebP 変換後の容量削減効果が薄い
- 見積もりより変換する件数が少ない
なぜ効果が出ていないのか
Slide 74
Slide 74 text
74
リリース後の効果測定
WebP に変換された画像に関しては60%以上サイズの削減が達成できた
「WebP 変換後の容量削減効果が薄い」仮説は棄却される
画像あたりのサイズ確認
種別 対jpeg容量比
image/jpeg 100%
image/webp 44.7%
Slide 75
Slide 75 text
75
効果が出ていない！？
仮説は以下の2つに分類できるためそれぞれ確認
- WebP 変換後の容量削減効果が薄い
- 見積もりより変換する件数が少ない
なぜ効果が出ていないのか
Slide 76
Slide 76 text
76
リリース後の効果測定
一日を通して配信容量を確認すると
...
サービス全体の配信容量はどうか？
種別 全体を100%とした割合
image/jpeg 45.93%
image/webp 29.13%
image/png (更新対象外) 24.76%
Slide 77
Slide 77 text
77
リリース後の効果測定
一日を通して配信容量を確認すると
...
サービス全体の配信容量はどうか？
種別 全体を100%とした割合
image/jpeg 45.93%
image/webp 29.13%
image/png (更新対象外) 24.76%
Slide 78
Slide 78 text
半分が jpeg！！
78
Slide 79
Slide 79 text
79
想定通りの効果が出ていない！！
- 想定ではほぼ WebP になる予定だったが、約半分がいまだ jpeg
- その結果配信量の予測が大幅にずれていた
jpeg の割合が想定より減っていない
Slide 80
Slide 80 text
80
想定通りの効果が出ていない！！
- `/product/` のみ変換する仕様なので、集計を絞る
- この範囲では WebP が容量と件数ともに一番多い
変換しているパスのみに集計を絞る
種別 割合(容量) 割合(件数)
image/jpeg 13.20% 6.4%
image/webp 61.08% 88.5%
image/png (更新対
象外)
25.70% 5.0%
この jpeg は
オプトアウトなど
Slide 81
Slide 81 text
81
想定通りの効果が出ていない！！
- `/product/` のみ変換する仕様なので、集計を絞る
- この範囲では WebP が容量と件数ともに一番多い
- `/product/` 以外に大量に画像が配信されている？
変換しているパスのみに集計を絞る
種別 割合(容量) 割合(件数)
image/jpeg 13.20% 6.4%
image/webp 61.08% 88.5%
image/png (更新対
象外)
25.70% 5.0%
Slide 82
Slide 82 text
82
想定通りの効果が出ていない！！
- 変換後の割合で半分以上が変換対象外の画像だった
めちゃめちゃあった
種別 割合(容量)
`/product/` 47.42%
`/product/` 以外 52.58%
Slide 83
Slide 83 text
83
リリース後の効果測定
一日を通して配信容量を確認すると
...
サービス全体の配信容量はどうか？
種別 全体を100%とした割合
image/jpeg 45.93%
image/webp 29.13%
image/png (更新対象外) 24.76%
Slide 84
Slide 84 text
25%がpng!!!
84
Slide 85
Slide 85 text
85
想定通りの効果が出ていない！！
- 見積もりでは総転送量の55%削減とあった
- 後方互換維持やオプトアウトで13%ほど変換できなった jpeg が残っていた
- 変換対象外の png が転送量の25%を占めていた
- 見積もりに含まれていたが変換されていない画像の転送量が
53%を占めていた
見積もりとの差分まとめ
Slide 86
Slide 86 text
86
想定通りの効果が出ていない！！
- 見積もりでは総転送量の55%削減とあった
- 後方互換維持やオプトアウトで13%ほど変換できなった jpeg が残っていた
- 変換対象外の png が転送量の25%を占めていた
- 見積もりに含まれていたが変換されていない画像の転送量が
53%を占めていた
見積もりとの差分まとめ
jpeg を対象として
すべての画像を WebP にする追加リリースを実施した
Slide 87
Slide 87 text
87
全画像へのリリース
- ほぼすべての jpeg を WebP に変換することができた
- 全件数のうち3%ほど jpeg が残り、全容量の9.5%を占める
最終的なフォーマットの割合
画像種別 容量 件数
image/png 49.34% 51.06%
image/webp 38.15% 40.08%
image/jpeg 9.59% 2.87%
Slide 88
Slide 88 text
- 最終的に約30%の転送量の削減が確認された
88
全画像へのリリース
最終的な転送量の削減効果
Slide 89
Slide 89 text
- 最終的に約30%の転送量の削減が確認された
- 当初の見積もり55%削減から、事実に基づき補正をかける
- 当初の見積もりには png が含まれるため25%を割り引く
- 後方互換維持のため変換できなかった jpeg 分9.5%を割り引く
- 補正後の見積もりは 36%削減となり、致命的な見落としはなさそう
89
全画像へのリリース
最終的な転送量の削減効果
リリース前を100とすると
100-25-9.5=65.5
65.5*(1-0.55)=29.475
29.47+25+9.5=63.97
100-63.97=36.03
Slide 90
Slide 90 text
webp変換処理の最適化
90
Slide 91
Slide 91 text
91
自己紹介
技術部 技術基盤グループ ソフトウェアエンジニア
2024年 中途入社
菅原 大和 drumato
Kubernetesとシステムプログラミングが好きな
ソフトウェアエンジニア。サービスに存在する
あらゆる課題にインフラの専門性で貢献す
る、をミッションに活動。休日は趣味プログラミ
ングとゲームで一日が終わる。
Slide 92
Slide 92 text
WebP変換の仕組み
92
Slide 93
Slide 93 text
- オリジン(S3)の画像を取得(src)
- /tmp に一時ファイルを作成
- disintegration/imaging で処理
- cwebp を実行して変換
- 結果をレスポンス
93
従来の仕組み
WebP対応時の実装
Slide 94
Slide 94 text
- 一時ファイルの作成
- cwebpコマンドの実行
94
従来の仕組み
WebP対応時の実装 ~改善点~
Slide 95
Slide 95 text
新しいWebP変換手法
95
Slide 96
Slide 96 text
96
新しいWebP変換手法
minne事例
https://tech.pepabo.com/2024/04/22/arm-libvips-are-awesome/
Slide 97
Slide 97 text
- Lambdaをx86_64 → arm64に置き換え、かつ画像変換ライブラリを
ImageMagickから
libvipsに変換した記事
- パフォーマンスの大幅改善と、それによるクラウドコスト削減を達成
97
新しいWebP変換手法
minne事例
Slide 98
Slide 98 text
- Lambdaをx86_64 → arm64に置き換え、かつ画像変換ライブラリを
ImageMagickから
libvipsに変換した記事
- パフォーマンスの大幅改善と、それによるクラウドコスト削減を達成
98
新しいWebP変換手法
minne事例
→カラーミーショップにも展開
Slide 99
Slide 99 text
99
新しいWebP変換手法
https://github.com/pepabo/oyaki/pull/19
Slide 100
Slide 100 text
100
新しいWebP変換手法
https://github.com/pepabo/oyaki/pull/19
Slide 101
Slide 101 text
新実装の評価
101
Slide 102
Slide 102 text
- Go標準のベンチマーク( *testing.B ) を使い、マイクロベンチマークを実施
- 単純計算で約2倍程度の高速化が見られた
102
新実装の評価
マイクロベンチマークを実施
Slide 103
Slide 103 text
- 実際に画像配信サーバとして動作させ、
Content-Lengthをもとに定量評価
- 本番環境の商品画像 約6500枚を用い、実際に効果が出るかを検証
- Pythonでリクエストを送信し、pandas DataFrameで集計してseabornで可視化
- 以下、AS-IS をcwebpベース, TO-BE をlibvipsベースとして呼称します
103
新実装の評価
定量評価-コンテンツサイズ -
Slide 104
Slide 104 text
104
新実装の評価
定量評価-統計値-
min max mean median std
AS-IS_JPEG_PROXY 18.0 1015444.0 111159.963123 20651.0 142252.035273
AS-IS_WEBP_CONVERSION 18.0 881900.0 88504.311372 15628.0 120473.495223
TO-BE_JPEG_PROXY 18.0 877438.0 102079.783984 18342.0 131056.972249
TO-BE_WEBP_CONVERSION 18.0 1023856.0 72857.659620 13506.0 103922.802539
Slide 105
Slide 105 text
105
新実装の評価
定量評価-CDF-
Slide 106
Slide 106 text
- 統計情報をもとに、クラウドコストを試算
- WebPの転送量を約18%削減可能と結論づけた
106
新実装の評価
定量評価-コスト-
Slide 107
Slide 107 text
リリース方針
107
Slide 108
Slide 108 text
- デザイナーさん、ステークホルダとのすり合わせ
- CloudFrontのキャッシュ戦略に対する漸進的なリリースの検討
108
リリース方針
リリースに必要なことを整理
Slide 109
Slide 109 text
- 画像品質の変化に対し、デザイナーやステークホルダと認識をすり合わせる
- ECサイト制作サービスにおいて、 画像の重要性はきわめて高い
- ショップオーナーにとって
- 商品のイメージ向上
- 購買率の変化によるビジネスインパクト
- エンドユーザーにとって
- 安心して商品を購入するための情報量
- 先ほどの統計レポート、新手法によって変換された画像データ、コストインパクトなどを共有
109
リリース方針
デザイナーとのすり合わせ
Slide 110
Slide 110 text
- CloudFrontでは、更新日時をキーに1年間キャッシュするようになっていた
- 画像配信サーバを更新するだけではリリースできない
- これを考慮しつつ、リリース範囲を徐々に増やす形で漸進的なリリースを行う方針を検討し
た
110
リリース方針
CloudFrontのキャッシュ戦略に対する漸進的なリリースの検討
Slide 111
Slide 111 text
- CloudFrontのアクセスログをAthenaで集計
- コンテンツサイズの分布を計算し、上位
50ショップを算出
- その50ショップに対し、リリース範囲を設定することにした
111
リリース方針
CloudFrontのキャッシュ戦略に対する漸進的なリリースの検討
Slide 112
Slide 112 text
112
リリース方針
CloudFrontのキャッシュ戦略に対する漸進的なリリースの検討
Slide 113
Slide 113 text
- コンテンツサイズ上位41~50ショップ、上位31~40ショップ、... に分割し、CloudFrontの
Cache Invalidateをいれる
113
リリース方針
CloudFrontのキャッシュ戦略に対する漸進的なリリースの検討
Slide 114
Slide 114 text
リリース後
114
Slide 115
Slide 115 text
- 画像配信サーバの前段にいるnginxのアクセスログベースで集計
- 画像配信サーバをホストしている
EKSノードのCPU使用率を確認
115
リリース後
効果測定
Slide 116
Slide 116 text
- リリース前 P95: 100k~140k bytes
- リリース後 P95: 80k~120k bytes
116
リリース後
レスポンスボディのサイズ改善
Slide 117
Slide 117 text
- リリース前 P95: 0.3~0.4 sec
- リリース後 P95: 0.1~0.2 sec
117
リリース後
レスポンスタイムの改善
Slide 118
Slide 118 text
118
リリース後
ノードのCPU使用率
Slide 119
Slide 119 text
- リリース前後で、見積もり通りの
15~20%削減
119
リリース後
CloudFrontの転送量
Slide 120
Slide 120 text
今後の展望
120
Slide 121
Slide 121 text
121
今後の展望
コンピューティングの再選定
- 現在、画像配信サーバはEKSにてホストされている
- これをLambdaやLambda@Edgeなどの、よりマネージドなプラットフォームに移設
- コスト削減、パフォーマンスの最適化、スケーラビリティ向上などがねらい
Slide 122
Slide 122 text
122
今後の展望
リリースフローの整備
- 画像配信サーバの機能リリースを高速に回せるように、
CloudFrontのキャッシュ戦略を考
慮したリリースフローを確立させていく
Slide 123
Slide 123 text
まとめ
123
Slide 124
Slide 124 text
- 月間配信量400TBの画像サーバについて、ユーザーファーストなリリースを通して WebP
の導入を行い、転送量とユーザー体験を最適化
- 未知の障害や想定と異なる結果に対し、データドリブンな評価とアクションの実行により、期
待した水準でのリリースを完遂
124
最後に
本発表のまとめ
Slide 125
Slide 125 text
最後に
125
Slide 126
Slide 126 text
126
まとめ
- ソフトウェアの開発とデリバリ、評価のフィードバックループを回して改善しつづけることを重
視
- 事業横断的な組織の特性を活かし、レバレッジの効いた取り組みを行う 1石N鳥を実践
- 最高の仕組みを最速で作る
GMOペパボでは
Slide 127
Slide 127 text
127
最後に
We’re hiring!
https://open.talentio.com/r/1/c/pepabo/pages/45336
Slide 128
Slide 128 text
ご清聴いただき
ありがとうございました
128