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
クラウド食堂 #5 ~運用にまつわるLT会~ ログ設計をしっかりしないと、運用が大変なことになります
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Hiroki Ohtake
November 19, 2025
0
64
クラウド食堂 #5 ~運用にまつわるLT会~ ログ設計をしっかりしないと、運用が大変なことになります
クラウド食堂 #5での登壇資料です
https://cloud-shokudo.connpass.com/event/365949/
Hiroki Ohtake
November 19, 2025
Tweet
Share
More Decks by Hiroki Ohtake
See All by Hiroki Ohtake
【JAWS DAYS 2026】Kiro CLIで変わるAWS運用とコスト管理
otake0609x
1
120
Toranomon Tech Hub 第6回 - AWS Systems Manager Patch Managerの コンプライアンスレポートをBacklogWikiにしてみた
otake0609x
0
90
Auroraリードレプリカが Auto Scalingしてくれなかった話
otake0609x
3
130
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
GitHub's CSS Performance
jonrohan
1032
470k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
118
110k
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
110
[RailsConf 2023] Rails as a piece of cake
palkan
59
6.4k
SEO for Brand Visibility & Recognition
aleyda
0
4.4k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.1k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
130
The World Runs on Bad Software
bkeepers
PRO
72
12k
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
64
53k
Transcript
大嵩 洋喜 アイレット株式会社 ログ設計をしっかりしないと、 運用が大変なことになります クラウド食堂 #5 ~運用にまつわる LT会~
01 アジェンダ 自己紹介 02 タイトル回収 03 じゃあどうすればいいの? 04 まとめ
大嵩 洋喜 2023年 4月 新卒入社 2023年 7月~ クラウドインテグレーション事業部配属 ~現在 多数の案件で、AWSインフラ構築&運用保守や監視構築を担当
アイレット株式会社 お お た け ひ ろ き 経歴 クラウドインテグレーション事業部 インフラエンジニア Profile 2025 Japan All AWS Certifications Engineers 資格 音楽(メタル)、ドラム、ゲーム(FPS)、映画 先月のLOUDPARK 25が忘れられない 趣味 @rockyx0609
ANGEL Dojo 2025 頂上決戦に登壇しました! 4
ブログ書いてます! 5
タイトル回収
こうなります 7 お疲れ様です。 ログアラート大量発生により、 監視システムがダウン寸前です。。。
こうなります 8 お疲れ様です。 現在、全社的にNew Relicのコスト最適化を進めております。 調査しましたところ、ログデータが非常に多くなっておりました。
こうなります 9 お疲れ様です。 現在、全社的にNew Relicのコスト最適化を進めております。 調査しましたところ、ログデータが非常に多くなっておりました。 ログデータ量: 運用コストに直結する莫大な情報量 影響: 無視できない割合
10 こうなります • 1つのファイルに正常ログも、エラーログも入っている • Aの文字列が監視対象だけど AかつBの文字列は監視側で除外みたいなものが多 い ◦ 5パターン以上も。。。
◦ 条件が多いため、ログ転送時に安易にフィルターがかけられない • Lambda関数の数が多い(数個ではない) • 非常に大規模なサービスのため、アクセスが多い • 結果、全部のログを転送しなくちゃいけない。。。
じゃあどうすればいいの?
じゃあどうすればいいの? 12 • エラーログだけ、別ファイル(ログストリーム)に • Aの文字列だけど AかつBの文字列は除外みたいな条件をなくす ◦ もしくは条件を簡単にして、転送時にフィルターをかける •
保持期間をしっかりと定義する( CloudWatch は料金が。。) • アクセス数が多くて見れないなら、そもそもログ監視をしない
まとめ
まとめ 14 • エラーログだけ分けて出力しましょう • 除外文字列の条件は少なく • 保持期間はしっかりと • ただの文字列ファイルじゃない
ご清聴ありがとうございました