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
サーバーレスアプリケーションの観測を適正化し、運用負荷を減らしていってる話
Search
Sho
September 10, 2024
Programming
0
36
サーバーレスアプリケーションの観測を適正化し、運用負荷を減らしていってる話
serverless meetup osaka #3 で登壇した内容です。
#serverlessosaka
Sho
September 10, 2024
Tweet
Share
More Decks by Sho
See All by Sho
jq を駆使して aws cli の運用を最適化
ririru0325
1
39
サーバーレス SaaS における運用監視の負荷軽減のためのアプローチ
ririru0325
0
220
Lambdaのこと
ririru0325
0
19
Other Decks in Programming
See All in Programming
エンジニアとして関わる要件と仕様(公開用)
murabayashi
0
310
Macとオーディオ再生 2024/11/02
yusukeito
0
380
シェーダーで魅せるMapLibreの動的ラスタータイル
satoshi7190
1
480
Duckdb-Wasmでローカルダッシュボードを作ってみた
nkforwork
0
130
イマのCSSでできる インタラクション最前線 + CSS最新情報
clockmaker
4
760
Remix on Hono on Cloudflare Workers
yusukebe
1
300
Functional Event Sourcing using Sekiban
tomohisa
0
100
Make Impossible States Impossibleを 意識してReactのPropsを設計しよう
ikumatadokoro
0
270
Jakarta EE meets AI
ivargrimstad
0
270
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
0
120
CSC509 Lecture 09
javiergs
PRO
0
140
cmp.Or に感動した
otakakot
3
230
Featured
See All Featured
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
Building Applications with DynamoDB
mza
90
6.1k
Being A Developer After 40
akosma
87
590k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
The Pragmatic Product Professional
lauravandoore
31
6.3k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
720
It's Worth the Effort
3n
183
27k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Typedesign – Prime Four
hannesfritz
40
2.4k
Become a Pro
speakerdeck
PRO
25
5k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
47
2.1k
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%は減った ◦ まず確認する量が減ったので負荷が下がった ◦ アラームの役割が明確になったので初動にかかる時間が減った
対応効果 • それぞれのアラームが発生したら、対応が必要なものに なってきたので、対応へのスピード感も上がった ◦ オオカミ少年的アラームがいなくなるだけで危機感が上がった
簡単まとめ 適切なアラームを設定することで迅速な対応が可能になります そのためにもアラームの意義と役割を明確にしましょう
ご清聴ありがとうございました!