Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
サーバーレスアプリケーションの観測を適正化し、運用負荷を減らしていってる話
Search
Sho
September 10, 2024
Programming
0
62
サーバーレスアプリケーションの観測を適正化し、運用負荷を減らしていってる話
serverless meetup osaka #3 で登壇した内容です。
#serverlessosaka
Sho
September 10, 2024
Tweet
Share
More Decks by Sho
See All by Sho
チームでリファクタリングを進めるために
ririru0325
0
98
AWS歴6年のSaaS企業が直面する低凝集マイクロサービスの課題とその解決アプローチ
ririru0325
0
20
エムオーテックスの現場_-_SaaSプロダクトのアーキテクチャ変革と技術負債解消の道のり
ririru0325
0
43
できたこと・やっていきたいこと
ririru0325
0
49
jq を駆使して aws cli の運用を最適化
ririru0325
1
160
サーバーレス SaaS における運用監視の負荷軽減のためのアプローチ
ririru0325
0
380
Lambdaのこと
ririru0325
0
63
Other Decks in Programming
See All in Programming
【CA.ai #3】Google ADKを活用したAI Agent開発と運用知見
harappa80
0
310
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
110
愛される翻訳の秘訣
kishikawakatsumi
3
330
「コードは上から下へ読むのが一番」と思った時に、思い出してほしい話
panda728
PRO
38
26k
30分でDoctrineの仕組みと使い方を完全にマスターする / phpconkagawa 2025 Doctrine
ttskch
4
870
chocoZAPサービス予約システムをNuxtで内製化した話
rizap_tech
0
120
Integrating WordPress and Symfony
alexandresalome
0
150
AIコーディングエージェント(Manus)
kondai24
0
190
Canon EOS R50 V と R5 Mark II 購入でみえてきた最近のデジイチ VR180 事情、そして VR180 静止画に活路を見出すまで
karad
0
110
Go コードベースの構成と AI コンテキスト定義
andpad
0
130
Rubyで鍛える仕組み化プロヂュース力
muryoimpl
0
130
テストやOSS開発に役立つSetup PHP Action
matsuo_atsushi
0
160
Featured
See All Featured
Designing Experiences People Love
moore
143
24k
Typedesign – Prime Four
hannesfritz
42
2.9k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
54k
The Invisible Side of Design
smashingmag
302
51k
Bootstrapping a Software Product
garrettdimon
PRO
307
120k
[RailsConf 2023] Rails as a piece of cake
palkan
58
6.2k
Building Adaptive Systems
keathley
44
2.9k
Six Lessons from altMBA
skipperchong
29
4.1k
Code Review Best Practice
trishagee
74
19k
Embracing the Ebb and Flow
colly
88
4.9k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
970
The Power of CSS Pseudo Elements
geoffreycrofte
80
6.1k
Transcript
サーバーレスアプリケーションの 観測を適正化し、運用負荷を減ら していってる話
自己紹介 • 名前:桑名 翔 • 会社:エムオーテックス株式会社 • 資格: • 最近やったこと:JVM
Lambda を カスタムランタイム に置き換えてコスト削減と性能UP
今日の話 • 運用 ◦ アプリケーションのデプロイ ◦ パッチ適用 … etc •
運用監視 ◦ ログ・メトリクス監視 ◦ リソース使用率の監視 … etc
今日の話 • 運用 ◦ アプリケーションのデプロイ ◦ パッチ適用 … etc •
運用監視 ◦ ログ・メトリクス監視 ◦ リソース使用率の監視 … etc
構成について簡単に • AWS をメインにほとんどサーバレス構成でアプリケー ションを構築して運用 ◦ 1000個を超えるLambda関数 ◦ 数百のDynamoDbテーブルやS3バケット ◦
数十のKinesis ストリームやSQSキュー • 運用監視システムは自前実装 ◦ ログやメトリクスに対してアラームをセットし、チャットに投稿される 仕組み ◦ 基本的には通知トリガーで対応する
通知の仕組み
こんな感じ
そもそもどうして運用監視をするのか?
そもそもどうして運用監視をするのか? • 可用性と信頼性の確保 • パフォーマンスやコストの最適化 • セキュリティの確保 … etc
そもそもどうして運用監視をするのか? • 可用性と信頼性の確保 • パフォーマンスやコストの最適化 • セキュリティの確保 … etc
観測しすぎによる運用負荷の高まり • 基本的には全てのリソースにアラームをセット ◦ 新規リソースを作成するたびにアラームが増える ◦ 管理コストも増える • 開発サイクルによる問題 ◦
新機能開発が多くリリース後の見直しが起こりづらい
こんなAPIを考えてみる
課題点 • アラームが重複して発生する ◦ Lambdaのエラーログによるアラーム ◦ API G/Wの5xxエラーのアラーム • 対応不要なアラームが発生する
◦ マネージドなサービスに対する瞬間的な接続エラー等 ▪ それでもエラーは発生するのでアラームになってしまう ▪ 慢性的に発生すると、本当は対応が必要だったのにスルーされてしまう
観測しすぎな現状から抜け出すために • やりたいことは可用性と信頼性の確保 つまり、お客様が問題なくサービスを利用し続けら れていること ↓言い換えると お客様がサービスを利用できなくなっていることを 検知したい
さっきのAPIについて考えてみる • 基本的には自動で復旧やスケーリングする構成 ◦ つまるところ、アプリケーション障害以外ではほとんど対応の余地がない
さっきのAPIについて考えてみる
さっきのAPIについて考えてみる 確かに対処はいらないかもしれないが、原因解明とお客 様へ告知をする義務がある ↓ 告知が必要になる場合にだけ検知できれば十分 ◦ 単発のマネージドサービスへの接続エラーや関数のランタイムでのエラ ー等は観測対象外にする
対応効果 • 現在も取り組み中ですが、通知の数は60 - 70%は減った ◦ まず確認する量が減ったので負荷が下がった ◦ アラームの役割が明確になったので初動にかかる時間が減った
対応効果 • それぞれのアラームが発生したら、対応が必要なものに なってきたので、対応へのスピード感も上がった ◦ オオカミ少年的アラームがいなくなるだけで危機感が上がった
簡単まとめ 適切なアラームを設定することで迅速な対応が可能になります そのためにもアラームの意義と役割を明確にしましょう
ご清聴ありがとうございました!