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
Flutter向けPDFビューア、pdfrxのpdfium WASM対応について
espresso3389
0
110
asken AI勉強会(Android)
tadashi_sato
0
150
生成AI時代の開発組織・技術・プロセス 〜 ログラスの挑戦と考察 〜
itohiro73
1
390
GitHub Copilot の概要
tomokusaba
1
150
Beyond Kaniko: Navigating Unprivileged Container Image Creation
f30
0
120
FrankenPHPでLaravelを動かしてみよう
yousaku
0
100
GeminiとNotebookLMによる金融実務の業務革新
abenben
0
250
一体いつからSRE NEXTがSREだけのカンファレンスだと錯覚していた? / When did you ever get the idea that SRE NEXT was a conference just for SREs?
vtryo
1
140
LangChain Interrupt & LangChain Ambassadors meetingレポート
os1ma
2
250
Should Our Project Join the CNCF? (Japanese Recap)
whywaita
PRO
0
310
fukabori.fm 出張版: 売上高617億円と高稼働率を陰で支えた社内ツール開発のあれこれ話 / 20250704 Yoshimasa Iwase & Tomoo Morikawa
shift_evolve
PRO
2
4k
How Community Opened Global Doors
hiroramos4
PRO
1
130
Featured
See All Featured
Designing for humans not robots
tammielis
253
25k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
What's in a price? How to price your products and services
michaelherold
246
12k
Side Projects
sachag
455
42k
Code Reviewing Like a Champion
maltzj
524
40k
A better future with KSS
kneath
239
17k
The Straight Up "How To Draw Better" Workshop
denniskardys
234
140k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Typedesign – Prime Four
hannesfritz
42
2.7k
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チームからのナレッジ共有、時間の確保など
ご清聴ありがとうございました!