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
サーバーレス SaaS における運用監視の負荷軽減のためのアプローチ
Search
Sho
October 23, 2024
Technology
0
350
サーバーレス SaaS における運用監視の負荷軽減のためのアプローチ
OpsJAWS Meetup31 泥臭いOPSのLT
Sho
October 23, 2024
Tweet
Share
More Decks by Sho
See All by Sho
AWS歴6年のSaaS企業が直面する低凝集マイクロサービスの課題とその解決アプローチ
ririru0325
0
9
エムオーテックスの現場_-_SaaSプロダクトのアーキテクチャ変革と技術負債解消の道のり
ririru0325
0
22
できたこと・やっていきたいこと
ririru0325
0
44
jq を駆使して aws cli の運用を最適化
ririru0325
1
130
サーバーレスアプリケーションの観測を適正化し、運用負荷を減らしていってる話
ririru0325
0
55
Lambdaのこと
ririru0325
0
44
Other Decks in Technology
See All in Technology
クラウド開発の舞台裏とSRE文化の醸成 / SRE NEXT 2025 Lunch Session
kazeburo
1
590
Copilot coding agentにベットしたいCTOが開発組織で取り組んだこと / GitHub Copilot coding agent in Team
tnir
0
190
CDK Vibe Coding Fes
tomoki10
1
630
Rethinking Incident Response: Context-Aware AI in Practice
rrreeeyyy
2
940
マルチプロダクト環境におけるSREの役割 / SRE NEXT 2025 lunch session
sugamasao
1
730
united airlines ™®️ USA Contact Numbers: Complete 2025 Support Guide
flyunitedhelp
1
470
全部AI、全員Cursor、ドキュメント駆動開発 〜DevinやGeminiも添えて〜
rinchsan
10
5.1k
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
820
“日本一のM&A企業”を支える、少人数SREの効率化戦略 / SRE NEXT 2025
genda
1
270
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
18k
サービスを止めるな! DDoS攻撃へのスマートな備えと最前線の事例
coconala_engineer
1
180
OpenTelemetryセマンティック規約の恩恵とMackerel APMにおける活用例 / SRE NEXT 2025
mackerelio
3
2k
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
512
110k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Designing for humans not robots
tammielis
253
25k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
The Pragmatic Product Professional
lauravandoore
35
6.7k
What's in a price? How to price your products and services
michaelherold
246
12k
Writing Fast Ruby
sferik
628
62k
Optimizing for Happiness
mojombo
379
70k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
108
19k
How to Think Like a Performance Engineer
csswizardry
25
1.7k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Transcript
サーバーレス SaaS における運用 監視の負荷軽減のためのアプロー チ
自己紹介 • 名前:桑名 翔 • 所属:エムオーテックス株式会社 開発本部 • 年齢:28 •
資格: X(旧Twitter)
運用監視の辛かったこと! アラート多すぎ!!!
運用監視の辛かったこと! • プロダクトが大きくなるにつれて、アラートがどんどん増えていく ◦ 自分だけじゃ見切れないところもいっぱい • だけど、どんなアラートも気になる ◦ お客様への影響が気になるから・・・
構成について簡単に • マイクロサービスを構築して運用 • ほとんどサーバレス構成 ◦ 1000個を超えるLambda関数 ◦ 数百のDynamoDbテーブルやS3バケット ◦
数十のKinesis ストリームやSQSキュー
運用監視の仕組み • ログやメトリクスに対してアラーム をセットし、チャットに投稿される 仕組み • 基本的には通知トリガーで対応する 運用監視システムは自前実装
こんな感じ
なんでアラート多すぎ問題になったのか • 基本的には全てのリソースにアラームをセット ◦ 新規リソースを作成するたびにアラームが増える ◦ 要不要をあまり考えず右に倣えでとりあえずセット • 開発サイクルによる問題 ◦
新機能開発が多くリリース後の見直しが起こりづらい
やっていたこと • 緊急度に基づいたアラートの振り分け ◦ 緊急度:High ▪ サービスが停止している可能性があるもの • 例:処理の大幅な遅延など ◦
緊急度:Low ▪ 継続発生していると問題があるもの • 例:定期処理の失敗など ◦ 緊急度:Ignore ▪ 完全に対応不要なもの、通知しない • 例:自動でリトライされるものなど ただし、基本的に振り分けられるのは一度でも発生したことがあるもののみ → 機能リリース後はほとんどが未知のエラーとして緊急度:High として通知される
やっていたこと • 機能の拡張に伴って、リソース数、アラートが大量増加 • 毎日100件以上通知 ◦ そのうち95%以上は対応不要 ◦ 当番制で回していたが、当番の日はだいぶ時間を取られる ◦
振り分けるのも手間 機能開発の時間に対する割り込みが無視できないレベルに・・・
Opsチーム導入 • アラートのトリアージをしてもらう ◦ アラートが来ても、確認して対応不要となるものが多かったので、 これだけでもだいぶ楽になった ◦ 対応が必要なものはエスカレーション • 進められていなかった振り分けも実施
◦ 開発チームに確認の上対応不要なものはどんどん ignore に
Opsチーム導入によって • 開発者の負担はだいぶ減った ◦ 当番の日もほとんど対応がいらなくなった • Opsチームに対応が集まるので、分析のための情報集めも進んだ 次のアクションを考えることができるように
そもそもどうして運用監視をするのか?
そもそもどうして運用監視をするのか? • 可用性と信頼性の確保 • パフォーマンスやコストの最適化 • セキュリティの確保 など 今の通知システムで 対応したいのはここ
「可用性と信頼性の確保」とは? • 可用性と信頼性の確保とは ◦ 稼働時間最大 ◦ ダウンタイム最小 お客様が問題なくサービスを利用し続けられている ↓言い換えると お客様がサービスを利用できなくなっていることを
検知して対処したい
こんなAPIを考えてみる
こんなAPIを考えてみる • アラームが重複して発生する ◦ Lambdaのエラーログによるアラーム ◦ API G/Wの5xxエラーのアラーム • 対応不要なアラームが発生する
◦ マネージドなサービスに対する瞬間的な接続エラー等 ▪ それでもエラーは発生するのでアラームになってしまう ▪ 慢性的に発生すると、本当は対応が必要だったのにスルーされてしまう
こんなAPIを考えてみる • 基本的には自動スケール、自動復旧する ◦ アプリケーション障害(バグ)以外では ほとんど対応の余地がない では、監視する必要はないのか?
こんなAPIを考えてみる 確かに対処はいらないかもしれないが、原因解明とお客様へ告 知をする義務がある ↓ 告知が必要になる場合にだけ検知できれば十分 ◦ 単発のマネージドサービスへの接続エラーや関数のランタイムでのエラ ー等は観測対象外にする
対応効果 • 現在も取り組み中ですが、通知の数は60 - 70%は減った ◦ まず確認する量が減ったので負荷が下がった ◦ アラームの役割が明確になったので初動にかかる時間が減った
対応効果 • それぞれのアラームが発生したら、対応が必要なものになってきたの で、対応へのスピード感も上がった ◦ オオカミ少年的アラームがいなくなるだけで危機感が上がった 適切なアラームを設定することで迅速な対応が可能になる そのためにもアラームの意義と役割を明確に
最後に • Opsチームを導入して、開発業務と運用業務を分けることで、機能開 発の時間の確保と運用に関するナレッジを集約しました。 ◦ マイクロサービスにおけるアンチパターンかもしれませんが、まずは時 間とナレッジの確保ができました。 • これからはシフトレフトで、運用のこともしっかり考えて開発してい けるように取り組んで行こうと思っています。
◦ Opsチームからのナレッジ共有、時間の確保など
ご清聴ありがとうございました!