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
100
サーバーレス SaaS における運用監視の負荷軽減のためのアプローチ
OpsJAWS Meetup31 泥臭いOPSのLT
Sho
October 23, 2024
Tweet
Share
More Decks by Sho
See All by Sho
サーバーレスアプリケーションの観測を適正化し、運用負荷を減らしていってる話
ririru0325
0
26
Lambdaのこと
ririru0325
0
11
Other Decks in Technology
See All in Technology
複数の外部サービスデータの統合と変換を実現する Railsのインポートアーキテクチャ / Rails import architecture for integration and transformation of multiple external service data
aiandrox
0
390
WebRTC と AI の組み合わせ
tnoho
0
390
新入社員 オンボーディング改善プロジェクト - シンプルな仕組みで変革のきっかけを
enpipi
0
520
The road to green code (with Sonar)
bluehats
0
190
AWS CDK を活用した 大量 AWS アカウントへのプロビジョニング例 〜 SaaSus Platform の場合 〜 於 JAWS-UG CDK支部 #17
yaggy
1
180
自然言語処理を役立てるのはなぜ難しいのか
pfn
PRO
17
4.6k
開発健全性の可視化と開発者体験の改善 ~ Compassでエンジニアに活力と生産性を ~
atlassianjapan
0
100
Brakeman を欺く - Kashiwa.rb #4
kozy4324
1
110
エンジニアのドメイン知識獲得コストを低減するアプリケーションデザイン
ryo_nagata_
3
180
外部カンファレンスで登壇しよう! 〜「強い」エンジニアへの一歩を踏み出す〜
logica0419
4
140
VueとViteで作るUIコンポーネントライブラリ ~デザインシステムとプロダクトの理想的な分離を目指して~ / 20241019_cloudsign_VueFesJapan2024_1
bengo4com
8
4.9k
Kubernetes Summit 2024 Keynote:104 在 GitOps 大規模實踐中的甜蜜與苦澀
yaosiang
0
130
Featured
See All Featured
Fashionably flexible responsive web design (full day workshop)
malarkey
404
65k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
31
1.7k
What's in a price? How to price your products and services
michaelherold
243
11k
Writing Fast Ruby
sferik
626
60k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
7.7k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
231
17k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
46
2.1k
Facilitating Awesome Meetings
lara
49
6k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
260
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チームからのナレッジ共有、時間の確保など
ご清聴ありがとうございました!