サーバーレス SaaS における運用 監視の負荷軽減のためのアプロー チ

自己紹介 ● 名前：桑名 翔 ● 所属：エムオーテックス株式会社 開発本部 ● 年齢：28 ● 資格： X（旧Twitter）

運用監視の辛かったこと！ アラート多すぎ！！！

運用監視の辛かったこと！ ● プロダクトが大きくなるにつれて、アラートがどんどん増えていく ○ 自分だけじゃ見切れないところもいっぱい ● だけど、どんなアラートも気になる ○ お客様への影響が気になるから・・・

構成について簡単に ● マイクロサービスを構築して運用 ● ほとんどサーバレス構成 ○ 1000個を超えるLambda関数 ○ 数百のDynamoDbテーブルやS3バケット ○ 数十のKinesis ストリームやSQSキュー

運用監視の仕組み ● ログやメトリクスに対してアラーム をセットし、チャットに投稿される 仕組み ● 基本的には通知トリガーで対応する 運用監視システムは自前実装

こんな感じ

なんでアラート多すぎ問題になったのか ● 基本的には全てのリソースにアラームをセット ○ 新規リソースを作成するたびにアラームが増える ○ 要不要をあまり考えず右に倣えでとりあえずセット ● 開発サイクルによる問題 ○ 新機能開発が多くリリース後の見直しが起こりづらい

やっていたこと ● 緊急度に基づいたアラートの振り分け ○ 緊急度：High ■ サービスが停止している可能性があるもの ● 例：処理の大幅な遅延など ○ 緊急度：Low ■ 継続発生していると問題があるもの ● 例：定期処理の失敗など ○ 緊急度：Ignore ■ 完全に対応不要なもの、通知しない ● 例：自動でリトライされるものなど ただし、基本的に振り分けられるのは一度でも発生したことがあるもののみ → 機能リリース後はほとんどが未知のエラーとして緊急度：High として通知される

やっていたこと ● 機能の拡張に伴って、リソース数、アラートが大量増加 ● 毎日１００件以上通知 ○ そのうち９５％以上は対応不要 ○ 当番制で回していたが、当番の日はだいぶ時間を取られる ○ 振り分けるのも手間 機能開発の時間に対する割り込みが無視できないレベルに・・・

Opsチーム導入 ● アラートのトリアージをしてもらう ○ アラートが来ても、確認して対応不要となるものが多かったので、 これだけでもだいぶ楽になった ○ 対応が必要なものはエスカレーション ● 進められていなかった振り分けも実施 ○ 開発チームに確認の上対応不要なものはどんどん ignore に

Opsチーム導入によって ● 開発者の負担はだいぶ減った ○ 当番の日もほとんど対応がいらなくなった ● Opsチームに対応が集まるので、分析のための情報集めも進んだ 次のアクションを考えることができるように

そもそもどうして運用監視をするのか？

そもそもどうして運用監視をするのか？ ● 可用性と信頼性の確保 ● パフォーマンスやコストの最適化 ● セキュリティの確保 など 今の通知システムで 対応したいのはここ

「可用性と信頼性の確保」とは？ ● 可用性と信頼性の確保とは ○ 稼働時間最大 ○ ダウンタイム最小 お客様が問題なくサービスを利用し続けられている ↓言い換えると お客様がサービスを利用できなくなっていることを 検知して対処したい

こんなAPIを考えてみる

こんなAPIを考えてみる ● アラームが重複して発生する ○ Lambdaのエラーログによるアラーム ○ API G/Wの5xxエラーのアラーム ● 対応不要なアラームが発生する ○ マネージドなサービスに対する瞬間的な接続エラー等 ■ それでもエラーは発生するのでアラームになってしまう ■ 慢性的に発生すると、本当は対応が必要だったのにスルーされてしまう

こんなAPIを考えてみる ● 基本的には自動スケール、自動復旧する ○ アプリケーション障害（バグ）以外では ほとんど対応の余地がない では、監視する必要はないのか？

こんなAPIを考えてみる 確かに対処はいらないかもしれないが、原因解明とお客様へ告 知をする義務がある ↓ 告知が必要になる場合にだけ検知できれば十分 ○ 単発のマネージドサービスへの接続エラーや関数のランタイムでのエラ ー等は観測対象外にする

対応効果 ● 現在も取り組み中ですが、通知の数は60 - 70%は減った ○ まず確認する量が減ったので負荷が下がった ○ アラームの役割が明確になったので初動にかかる時間が減った

対応効果 ● それぞれのアラームが発生したら、対応が必要なものになってきたの で、対応へのスピード感も上がった ○ オオカミ少年的アラームがいなくなるだけで危機感が上がった 適切なアラームを設定することで迅速な対応が可能になる そのためにもアラームの意義と役割を明確に

最後に ● Opsチームを導入して、開発業務と運用業務を分けることで、機能開 発の時間の確保と運用に関するナレッジを集約しました。 ○ マイクロサービスにおけるアンチパターンかもしれませんが、まずは時 間とナレッジの確保ができました。 ● これからはシフトレフトで、運用のこともしっかり考えて開発してい けるように取り組んで行こうと思っています。 ○ Opsチームからのナレッジ共有、時間の確保など

ご清聴ありがとうございました！