顧客の画像データをテラバイト単位で配信する 画像サーバを WebP にした際に起こった課題と その対応策 ～継続的な取り組みを添えて～

SRE NEXT 2025 で発表した内容となります。

Transcript

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