Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
イオン店舗一覧ページのパフォーマンスチューニング事例 / Performance tuning...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
AEON
August 26, 2025
Technology
2
790
イオン店舗一覧ページのパフォーマンスチューニング事例 / Performance tuning example for AEON store list page
2025年8月26日開催「イオン×ZOZO×『Web配信の技術』著者が語るパフォーマンスチューニング:60分で掴む劇的改善術 | AEON TECH HUB #18」の登壇資料です
AEON
August 26, 2025
Tweet
Share
More Decks by AEON
See All by AEON
SaaSからAIへの過渡期の中で現在、組織内で起こっている変化 / SaaS to AI Paradigm Shift
aeonpeople
0
140
GitHub Issue Templates + Coding Agentで簡単みんなでIaC/Easy IaC for Everyone with GitHub Issue Templates + Coding Agent
aeonpeople
1
1.4k
SREじゃなかった僕らがenablingを通じて「SRE実践者」になるまでのリアル / SRE Kaigi 2026
aeonpeople
6
4.9k
Azure SRE Agent x PagerDutyによる近未来インシデント対応への期待 / The Future of Incident Response: Azure SRE Agent x PagerDuty
aeonpeople
1
490
「もしもデータ基盤開発で『強くてニューゲーム』ができたなら今の僕はどんなデータ基盤を作っただろう」
aeonpeople
0
410
It's Automatic〜7回目のベルでアラートを取った君へ〜/ignite-aks-automate
aeonpeople
0
700
"AKSのアップグレードに失敗しない漢"への道/failure-of-upgrade-is-not-an-option
aeonpeople
0
1.5k
Terraformのdrift(差分)を全部AIに任せた!...かった
aeonpeople
0
220
Azureコストと向き合った、4年半のリアル / Four and a half years of dealing with Azure costs
aeonpeople
1
480
Other Decks in Technology
See All in Technology
OSC仙台プレ勉強会 AlmaLinuxとは
koedoyoshida
0
180
AWS DevOps Agent vs SRE俺 / AWS DevOps Agent vs me, the SRE
sms_tech
3
880
頼れる Agentic AI を支える Datadog のオブザーバビリティ / Powering Reliable Agentic AI with Datadog Observability
aoto
PRO
0
180
AWS CDK「読めるけど書けない」を脱却するファーストステップ
smt7174
3
150
Scrumは歪む — 組織設計の原理原則
dashi
0
200
会社紹介資料 / Sansan Company Profile
sansan33
PRO
16
410k
Tebiki Engineering Team Deck
tebiki
0
27k
It’s “Time” to use Temporal
sajikix
3
200
VPCエンドポイント意外とお金かかるなぁ。せや、共有したろ!
tommy0124
1
660
OpenClaw を Amazon Lightsail で動かす理由
uechishingo
0
140
内製AIチャットボットで学んだDatadog LLM Observability活用術
mkdev10
0
120
詳解 強化学習 / In-depth Guide to Reinforcement Learning
prinlab
0
190
Featured
See All Featured
Reality Check: Gamification 10 Years Later
codingconduct
0
2k
A Soul's Torment
seathinner
5
2.5k
Chasing Engaging Ingredients in Design
codingconduct
0
140
The Pragmatic Product Professional
lauravandoore
37
7.2k
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
140
We Are The Robots
honzajavorek
0
200
Typedesign – Prime Four
hannesfritz
42
3k
Fireside Chat
paigeccino
42
3.8k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.6k
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
0
240
Amusing Abliteration
ianozsvald
0
130
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
860
Transcript
イオン店舗一覧ページの パフォーマンスチューニング事例 イオンスマートテクノロジー株式会社 CTO室 TechLeadチーム 石川晴貴 2025年8月26日
自己紹介 各種紹介 石川 晴貴(X:@h0r4k) イオンスマートテクノロジー株式会社 CTO室テックリードチーム(2024.06ジョイン) 趣味:プログラミング、ギター 最近やっていること ・Claude Codeと仲良くなること
・社内MCPサーバを作りNewRelicのNRQLを叩かせ Claude Codeからメトリクスの分析をやってもらったり、 社内のAPI群をMCP化させてホクホクしたりしています
各種紹介
None
本題にはいります
• アプリケーション寄りのパフォーマンスチューニングの話(PHP寄りかも) • かなり基礎的かつ古典的な話がメインになるので耳タコではあると思いますが、この機会に改めて。 ※のでカリカリチューニング的な話は出てきません • 既にAEON TECH HUBでも記事にしていますが、チームを代表して改めて本LTでご紹介させていただきます! 今回お話すること
はじめに https://engineer-recruiting.aeon.info/aeon-tech-hub/interview_store-page
• 店舗一覧サイト • 所在地検索、業態・ブランド検索、 キーワード検索 • 店舗情報の閲覧・検索のみでDB更新系の 操作なし • 店舗一覧用CMS
• CMSから店舗一覧上の店舗情報を更新可 能 • DB更新系の操作有り そもそもイオンの店舗一覧とは? 背景
• まずちゃんと遅い • レスポンスの平均が1,200msと激遅 • 急なアクセス増に耐えられない • 台風などの災害時に店舗はやっているのか?の確認でアクセスが増える • DBのCPUが100%に張り付いてしまいページが閲覧できなくなる
• 暫定的な対応として、 • DBのスペックを常時2段階あげた(コストは4倍に) • 具体的にはvCPU→4倍、メモリ→4倍 • リードレプリカの追加 どんな課題があったのか? 課題
• しかし、 • この状態は健全ではなくコストもかかる • なので • 調査と改修を行って高速化しつつDBのスケールダウンを目指す • すでにNewRelicは導入済みだったため、
NewRelicのAPMの情報からパフォーマンス劣化の原因を探り対応を行うことに 課題に対する取り組み 課題
では実際にNewRelicをみていく
• 問題 • 本番環境のcomposer installでオプションの最適化がなされていなかった • 対応 • composer installに--optimize-autoloaderのオプションを追加
改善① フレームワークの本番プラクティスに準拠する 改善
• 補足して • しっかり公式Documentを読む、書いてある 改善① フレームワークの本番プラクティスに準拠する 改善
• 問題 • 1トランザクションの平均DB Callが4万件弱となるようなリクエストがあった (ここに限らず複数の箇所でN+1問題が発生) • 対応 • ループ内で呼び出されてしまっているN+1クエリをEloquentのEagerLoadingを利用し
て不要クエリを削減 改善② N+1問題 改善
• 問題 • CMS上での記事検索が遅く、CMS内で検索を行うたびにスロークエリが発生 • 対応 • スロークエリの実行計画を確認し最適化 • Indexの貼られていないカラムにはIndexを貼る
など 改善③ スロークエリ対策 改善
• 問題 • ORMにてSELECT * でカラムを絞り込まずにデータ取得を行った場合に時間を要する • 対応 • 必要なカラムのみに絞り込んでデータを取得
改善④ ORMでのSELECT * 対応 改善
• 問題 • CMSでDB負荷の高い操作を行うと店舗一覧サイトへ影響が出てしまう状態になって いた • CMS側には高負荷な参照クエリが多く、すべてのクエリの高速化対応をすぐに行う ことは当時難しかった • 対応
• CMS上で発行されるクエリについてはマスターDBへ、店舗一覧サイトなどの参照系 の操作についてはリードレプリカDBに実行するよう分離 • CMS/店舗一覧サイトいずれもLaravelでmiddlewareを作成しそれぞれの middlewareGroupsに設定を追記 改善⑤ マスター/リードレプリカ 改善
• コスト • DB費用が1/4に減少 • vCPU→1/4、メモリ→1/4に削減 • レスポンス • 1,200
ms-> 300ms 以下へ改善 改善の結果 改善の結果 アラートもかなり減りました…
• パフォーマンスチューニングの効果について • 古典的かつ基礎的なパフォーマンスチューニング(と本番最適化)は結局重要 • インフラに対するコスト意識に関して • インフラコストの削減はアプリケーション側の意識も重要 • パフォーマンスチューニングの取り掛かり方について
• 今回はまずNewRelicから問題を炙り出しを行った • 定量的に問題を分析して効果の高い順(かつ実装の容易な順)から潰していった • コスト削減とパフォーマンス改善のバランスについて • 今回はコストを削減しつつパフォーマンス改善も行えた • が、場合によってはCDNなどコストをかけながらパフォーマンス改善を行うという やり方もあるためケースバイケースで検討が必要 まとめ さいごに
• パフォーマンスチューニングの効果について • 古典的かつ基礎的なパフォーマンスチューニング(と本番最適化)は結局重要 • インフラに対するコスト意識に関して • インフラコストの削減はアプリケーション側の意識も重要 • パフォーマンスチューニングの取り掛かり方について
• 今回はまずNewRelicから問題を炙り出しを行った • 定量的に問題を分析して効果の高い順(かつ実装の容易な順)から潰していった • コスト削減とパフォーマンス改善のバランスについて • 今回はコストを削減しつつパフォーマンス改善も行えた • が、場合によってはCDNなどコストをかけながらパフォーマンス改善を行うという やり方もあるためケースバイケースで検討が必要 まとめ さいごに 皆さんも是非機会があれば、パフォーマンスチューニングに チャレンジしてみてください!
ご清聴ありがとうございました