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
370
サーバーレス SaaS における運用監視の負荷軽減のためのアプローチ
OpsJAWS Meetup31 泥臭いOPSのLT
Sho
October 23, 2024
Tweet
Share
More Decks by Sho
See All by Sho
チームでリファクタリングを進めるために
ririru0325
0
79
AWS歴6年のSaaS企業が直面する低凝集マイクロサービスの課題とその解決アプローチ
ririru0325
0
15
エムオーテックスの現場_-_SaaSプロダクトのアーキテクチャ変革と技術負債解消の道のり
ririru0325
0
38
できたこと・やっていきたいこと
ririru0325
0
46
jq を駆使して aws cli の運用を最適化
ririru0325
1
150
サーバーレスアプリケーションの観測を適正化し、運用負荷を減らしていってる話
ririru0325
0
60
Lambdaのこと
ririru0325
0
57
Other Decks in Technology
See All in Technology
Adminaで実現するISMS/SOC2運用の効率化 〜 アカウント管理編 〜
shonansurvivors
4
430
Where will it converge?
ibknadedeji
0
200
三菱電機・ソニーグループ共同の「Agile Japan企業内サテライト」_2025
sony
0
140
綺麗なデータマートをつくろう_データ整備を前向きに考える会 / Let's create clean data mart
brainpadpr
3
380
OCI Network Firewall 概要
oracle4engineer
PRO
2
7.9k
KMP の Swift export
kokihirokawa
0
350
E2Eテスト設計_自動化のリアル___Playwrightでの実践とMCPの試み__AIによるテスト観点作成_.pdf
findy_eventslides
1
600
Azure Well-Architected Framework入門
tomokusaba
1
350
AI駆動開発を推進するためにサービス開発チームで 取り組んでいること
noayaoshiro
0
250
Simplifying Cloud Native app testing across environments with Dapr and Microcks
salaboy
0
140
Reflections of AI: A Trilogy in Four Parts (GOTO; Copenhagen 2025)
ondfisk
0
110
Developer Advocate / Community Managerなるには?
tsho
0
120
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.7k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Building Better People: How to give real-time feedback that sticks.
wjessup
369
20k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Gamification - CAS2011
davidbonilla
81
5.5k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
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チームからのナレッジ共有、時間の確保など
ご清聴ありがとうございました!