Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
サーバーレスアプリケーションの観測を適正化し、運用負荷を減らしていってる話
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Sho
September 10, 2024
Programming
86
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
サーバーレスアプリケーションの観測を適正化し、運用負荷を減らしていってる話
serverless meetup osaka #3 で登壇した内容です。
#serverlessosaka
Sho
September 10, 2024
More Decks by Sho
See All by Sho
Java ランタイムからカスタムランタイムに行き着くまで
ririru0325
1
580
チームでリファクタリングを進めるために
ririru0325
0
160
AWS歴6年のSaaS企業が直面する低凝集マイクロサービスの課題とその解決アプローチ
ririru0325
0
47
エムオーテックスの現場_-_SaaSプロダクトのアーキテクチャ変革と技術負債解消の道のり
ririru0325
0
93
できたこと・やっていきたいこと
ririru0325
0
69
jq を駆使して aws cli の運用を最適化
ririru0325
1
200
サーバーレス SaaS における運用監視の負荷軽減のためのアプローチ
ririru0325
0
450
Lambdaのこと
ririru0325
0
110
Other Decks in Programming
See All in Programming
Optunaを作ったときにやりたかったこと、その後 (2026/10/16, Optuna Meetup #3)
iwiwi
2
1.2k
気持ちぃ〜角丸 Squircle
ryu1013
0
330
[2026-10-09]一枚の布で作らなくてもいい。 信頼性は「パッチワーク」で紡がれる~既存の運用と新しい可能性をつなぎ合わせてきたCREの話~
tosite
0
110
Unity6 URPによる海底をテーマにしたVJシステムの解説 | Unity Shader 完全に理解した 勉強会
gam0022
0
370
AI-Powered Domain-Driven Design
ziobrando
0
240
[Dev Group Paris Octobre 26] Agentforce, SIforce, Claudeforce, Slackbot… on s'y retrouve ?
nabondance
0
120
コーディング自動化の次へ。人の介入をゼロにするファクトリーとサポートAIによる実践
timakin
5
4.3k
個人開発者よ、Honoを使え(おじさんver)
tanahiro2010
2
270
Compiling a real-world CLI tool to native with Static Hermes
tmikov2023
0
130
全ての永続トークンを、生まれる前に消し去りたい!
sylph01
2
1.1k
HTML-in-Canvasで作る未来のWeb UI表現
clockmaker
5
5.2k
AI時代のコードレビューは人に向けるな、仕組みに向けろ
texmeijin
5
3.7k
Featured
See All Featured
The Curious Case for Waylosing
cassininazir
1
570
4 Signs Your Business is Dying
shpigford
187
23k
Unsuck your backbone
ammeep
672
58k
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
1k
Making Projects Easy
brettharned
120
6.8k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.9k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.9k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.7k
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.5k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
310
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
2
2.9k
Transcript
サーバーレスアプリケーションの 観測を適正化し、運用負荷を減ら していってる話
自己紹介 • 名前:桑名 翔 • 会社:エムオーテックス株式会社 • 資格: • 最近やったこと:JVM
Lambda を カスタムランタイム に置き換えてコスト削減と性能UP
今日の話 • 運用 ◦ アプリケーションのデプロイ ◦ パッチ適用 … etc •
運用監視 ◦ ログ・メトリクス監視 ◦ リソース使用率の監視 … etc
今日の話 • 運用 ◦ アプリケーションのデプロイ ◦ パッチ適用 … etc •
運用監視 ◦ ログ・メトリクス監視 ◦ リソース使用率の監視 … etc
構成について簡単に • AWS をメインにほとんどサーバレス構成でアプリケー ションを構築して運用 ◦ 1000個を超えるLambda関数 ◦ 数百のDynamoDbテーブルやS3バケット ◦
数十のKinesis ストリームやSQSキュー • 運用監視システムは自前実装 ◦ ログやメトリクスに対してアラームをセットし、チャットに投稿される 仕組み ◦ 基本的には通知トリガーで対応する
通知の仕組み
こんな感じ
そもそもどうして運用監視をするのか?
そもそもどうして運用監視をするのか? • 可用性と信頼性の確保 • パフォーマンスやコストの最適化 • セキュリティの確保 … etc
そもそもどうして運用監視をするのか? • 可用性と信頼性の確保 • パフォーマンスやコストの最適化 • セキュリティの確保 … etc
観測しすぎによる運用負荷の高まり • 基本的には全てのリソースにアラームをセット ◦ 新規リソースを作成するたびにアラームが増える ◦ 管理コストも増える • 開発サイクルによる問題 ◦
新機能開発が多くリリース後の見直しが起こりづらい
こんなAPIを考えてみる
課題点 • アラームが重複して発生する ◦ Lambdaのエラーログによるアラーム ◦ API G/Wの5xxエラーのアラーム • 対応不要なアラームが発生する
◦ マネージドなサービスに対する瞬間的な接続エラー等 ▪ それでもエラーは発生するのでアラームになってしまう ▪ 慢性的に発生すると、本当は対応が必要だったのにスルーされてしまう
観測しすぎな現状から抜け出すために • やりたいことは可用性と信頼性の確保 つまり、お客様が問題なくサービスを利用し続けら れていること ↓言い換えると お客様がサービスを利用できなくなっていることを 検知したい
さっきのAPIについて考えてみる • 基本的には自動で復旧やスケーリングする構成 ◦ つまるところ、アプリケーション障害以外ではほとんど対応の余地がない
さっきのAPIについて考えてみる
さっきのAPIについて考えてみる 確かに対処はいらないかもしれないが、原因解明とお客 様へ告知をする義務がある ↓ 告知が必要になる場合にだけ検知できれば十分 ◦ 単発のマネージドサービスへの接続エラーや関数のランタイムでのエラ ー等は観測対象外にする
対応効果 • 現在も取り組み中ですが、通知の数は60 - 70%は減った ◦ まず確認する量が減ったので負荷が下がった ◦ アラームの役割が明確になったので初動にかかる時間が減った
対応効果 • それぞれのアラームが発生したら、対応が必要なものに なってきたので、対応へのスピード感も上がった ◦ オオカミ少年的アラームがいなくなるだけで危機感が上がった
簡単まとめ 適切なアラームを設定することで迅速な対応が可能になります そのためにもアラームの意義と役割を明確にしましょう
ご清聴ありがとうございました!