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
AEON
August 26, 2025
Technology
2
430
イオン店舗一覧ページのパフォーマンスチューニング事例 / 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
プラットフォーム転換期におけるGitHub Copilot活用〜Coding agentがそれを加速するか〜 / Leveraging GitHub Copilot During Platform Transition Periods
aeonpeople
1
57
JTCにおける内製×スクラム開発への挑戦〜内製化率95%達成の舞台裏/JTC's challenge of in-house development with Scrum
aeonpeople
0
230
2025年にHCP Vaultを学び直して見えた景色 / Lessons and New Perspectives from Relearning HCP Vault in 2025
aeonpeople
0
250
会社もクラウドも違うけど 通じたコスト削減テクニック/Cost optimization strategies effective regardless of company or cloud provider
aeonpeople
2
620
SREがコストセンターではないことを大きな声と実例で伝えたい/SRE Is Not a Cost Center: Real-World Stories That Prove True Value
aeonpeople
1
900
SREチームの越境と対話〜どのようにしてイオンスマートテクノロジーは横軸運用チームの廃止に至ったか〜/the-Cross-border-and-dialogue-of-SRE
aeonpeople
13
7.5k
PagerDuty×ポストモーテムで築く障害対応文化/Building a culture of incident response with PagerDuty and postmortems
aeonpeople
3
830
【内製開発Summit 2025】イオンスマートテクノロジーの内製化組織の作り方/In-house-development-summit-AST
aeonpeople
2
2.8k
【ITmedia DX Summit 23/基調講演】イオンが構築する超大規模データ基盤と、その活用戦略
aeonpeople
2
1k
Other Decks in Technology
See All in Technology
S3アクセス制御の設計ポイント
tommy0124
3
200
複数サービスを支えるマルチテナント型Batch MLプラットフォーム
lycorptech_jp
PRO
1
390
エラーとアクセシビリティ
schktjm
1
1.3k
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
8.7k
大「個人開発サービス」時代に僕たちはどう生きるか
sotarok
20
10k
DDD集約とサービスコンテキスト境界との関係性
pandayumi
3
280
「全員プロダクトマネージャー」を実現する、Cursorによる仕様検討の自動運転
applism118
21
11k
スマートファクトリーの第一歩 〜AWSマネージドサービスで 実現する予知保全と生成AI活用まで
ganota
2
220
【NoMapsTECH 2025】AI Edge Computing Workshop
akit37
0
200
開発者を支える Internal Developer Portal のイマとコレカラ / To-day and To-morrow of Internal Developer Portals: Supporting Developers
aoto
PRO
1
460
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
260
TS-S205_昨年対比2倍以上の機能追加を実現するデータ基盤プロジェクトでのAI活用について
kaz3284
1
170
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Facilitating Awesome Meetings
lara
55
6.5k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.7k
GraphQLの誤解/rethinking-graphql
sonatard
72
11k
Scaling GitHub
holman
463
140k
Six Lessons from altMBA
skipperchong
28
4k
Optimizing for Happiness
mojombo
379
70k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
Designing Experiences People Love
moore
142
24k
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などコストをかけながらパフォーマンス改善を行うという やり方もあるためケースバイケースで検討が必要 まとめ さいごに 皆さんも是非機会があれば、パフォーマンスチューニングに チャレンジしてみてください!
ご清聴ありがとうございました