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
100
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
クラウド食堂 #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
Toranomon Tech Hub 第8回 S3のオブジェクトを15万件あの世に送った話
otake0609x
0
42
クラウド食堂_9_AWS環境をTerraform化するClaude_Codeプラグインを作った
otake0609x
0
150
【JAWS DAYS 2026】Kiro CLIで変わるAWS運用とコスト管理
otake0609x
1
150
Toranomon Tech Hub 第6回 - AWS Systems Manager Patch Managerの コンプライアンスレポートをBacklogWikiにしてみた
otake0609x
0
160
Auroraリードレプリカが Auto Scalingしてくれなかった話
otake0609x
3
170
Featured
See All Featured
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
410
Music & Morning Musume
bryan
47
7.3k
Technical Leadership for Architectural Decision Making
baasie
3
540
Google's AI Overviews - The New Search
badams
0
1.6k
YesSQL, Process and Tooling at Scale
rocio
174
15k
Making the Leap to Tech Lead
cromwellryan
135
10k
Rails Girls Zürich Keynote
gr2m
96
14k
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
63
45k
Side Projects
sachag
455
43k
How to Ace a Technical Interview
jacobian
281
24k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
800
The Pragmatic Product Professional
lauravandoore
37
7.4k
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 • エラーログだけ分けて出力しましょう • 除外文字列の条件は少なく • 保持期間はしっかりと • ただの文字列ファイルじゃない
ご清聴ありがとうございました