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
Hiroki Ohtake
November 19, 2025
0
58
クラウド食堂 #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
Toranomon Tech Hub 第6回 - AWS Systems Manager Patch Managerの コンプライアンスレポートをBacklogWikiにしてみた
otake0609x
0
88
Auroraリードレプリカが Auto Scalingしてくれなかった話
otake0609x
3
130
Featured
See All Featured
AI: The stuff that nobody shows you
jnunemaker
PRO
3
350
Visualization
eitanlees
150
17k
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
260
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
620
How to build a perfect <img>
jonoalderson
1
5.2k
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
0
240
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
1
1.4k
So, you think you're a good person
axbom
PRO
2
1.9k
Embracing the Ebb and Flow
colly
88
5k
WENDY [Excerpt]
tessaabrams
9
36k
A Modern Web Designer's Workflow
chriscoyier
698
190k
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
310
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 • エラーログだけ分けて出力しましょう • 除外文字列の条件は少なく • 保持期間はしっかりと • ただの文字列ファイルじゃない
ご清聴ありがとうございました