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
280
サーバーレス SaaS における運用監視の負荷軽減のためのアプローチ
OpsJAWS Meetup31 泥臭いOPSのLT
Sho
October 23, 2024
Tweet
Share
More Decks by Sho
See All by Sho
できたこと・やっていきたいこと
ririru0325
0
37
jq を駆使して aws cli の運用を最適化
ririru0325
1
81
サーバーレスアプリケーションの観測を適正化し、運用負荷を減らしていってる話
ririru0325
0
44
Lambdaのこと
ririru0325
0
32
Other Decks in Technology
See All in Technology
(機械学習システムでも) SLO から始める信頼性構築 - ゆる SRE#9 2025/02/21
daigo0927
0
220
クラウドサービス事業者におけるOSS
tagomoris
3
960
2.5Dモデルのすべて
yu4u
2
950
2/18/25: Java meets AI: Build LLM-Powered Apps with LangChain4j
edeandrea
PRO
0
150
Windows の新しい管理者保護モード
murachiakira
0
180
Helm , Kustomize に代わる !? 次世代 k8s パッケージマネージャー Glasskube 入門 / glasskube-entry
parupappa2929
0
270
Goで作って学ぶWebSocket
ryuichi1208
3
2.3k
深層学習と古典的画像アルゴリズムを組み合わせた類似画像検索内製化
shutotakahashi
1
270
なぜ私は自分が使わないサービスを作るのか? / Why would I create a service that I would not use?
aiandrox
0
890
ホワイトボードチャレンジ 説明&実行資料
ichimichi
0
130
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
180
AI エージェント開発を支える MaaS としての Azure AI Foundry
ryohtaka
6
650
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
42
7.2k
Typedesign – Prime Four
hannesfritz
40
2.5k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.5k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Bootstrapping a Software Product
garrettdimon
PRO
306
110k
RailsConf 2023
tenderlove
29
1k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Why Our Code Smells
bkeepers
PRO
336
57k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.2k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
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チームからのナレッジ共有、時間の確保など
ご清聴ありがとうございました!