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
83
0
Share
クラウド食堂 #5 ~運用にまつわるLT会~ ログ設計をしっかりしないと、運用が大変なことになります
クラウド食堂 #5での登壇資料です
https://cloud-shokudo.connpass.com/event/365949/
Hiroki Ohtake
November 19, 2025
More Decks by Hiroki Ohtake
See All by Hiroki Ohtake
【JAWS DAYS 2026】Kiro CLIで変わるAWS運用とコスト管理
otake0609x
1
140
Toranomon Tech Hub 第6回 - AWS Systems Manager Patch Managerの コンプライアンスレポートをBacklogWikiにしてみた
otake0609x
0
120
Auroraリードレプリカが Auto Scalingしてくれなかった話
otake0609x
3
150
Featured
See All Featured
Google's AI Overviews - The New Search
badams
0
1k
New Earth Scene 8
popppiees
3
2.3k
Skip the Path - Find Your Career Trail
mkilby
1
130
ラッコキーワード サービス紹介資料
rakko
1
3.4M
How to Think Like a Performance Engineer
csswizardry
28
2.6k
Stop Working from a Prison Cell
hatefulcrawdad
274
21k
Un-Boring Meetings
codingconduct
0
300
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
1
2k
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
0
1.5k
The Mindset for Success: Future Career Progression
greggifford
PRO
0
340
From π to Pie charts
rasagy
0
190
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
240
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 • エラーログだけ分けて出力しましょう • 除外文字列の条件は少なく • 保持期間はしっかりと • ただの文字列ファイルじゃない
ご清聴ありがとうございました