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
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
當我們開始不讀 Code - AI Agent 時代,Code Review 與 Clean Code 還剩下什麼?
jame2408
1
260
HTML-in-Canvasで作る未来のWeb UI表現
clockmaker
5
5.2k
Apple Intelligence を用いた個人情報誤送信防止、及びユーザーリクエスト体験の改善について
yukiny
0
350
現場と育てるRailsモデリング 〜Spreadsheetから始めたモデル設計〜
siroemk
2
630
dotNET_vulnclicker_intro.pdf
deka_morita
0
140
Simple Storage Service(S3) is not simple
iwatsukayura
0
290
golang-bob.pdf
iwatsukayura
0
130
AmebaブログはKMPから卒業します
kmars0605
0
200
S3 TablesのIcebergデータに、AIエージェントからアクセスしてみた / 20261016developersio2026joetsu-accessing-iceberg-in-s3tables-via-agent
kasacchiful
PRO
0
170
Rでドレミ/Do-Re-Mi_with_R
florets1
0
130
UPDATE をやめる — EF Core でマスタをバージョン管理する
panda728
PRO
0
1.2k
Domain-Driven Transformation
hschwentner
2
2.3k
Featured
See All Featured
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
3.1k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.4k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Abbi's Birthday
coloredviolet
4
10k
What does AI have to do with Human Rights?
axbom
PRO
1
2.5k
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
310
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.5k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
Everyday Curiosity
cassininazir
0
360
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
50
10k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.7k
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%は減った ◦ まず確認する量が減ったので負荷が下がった ◦ アラームの役割が明確になったので初動にかかる時間が減った
対応効果 • それぞれのアラームが発生したら、対応が必要なものに なってきたので、対応へのスピード感も上がった ◦ オオカミ少年的アラームがいなくなるだけで危機感が上がった
簡単まとめ 適切なアラームを設定することで迅速な対応が可能になります そのためにもアラームの意義と役割を明確にしましょう
ご清聴ありがとうございました!