サーバーレスアプリケーションの観測を適正化し、運用負荷を減らしていってる話

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介 ● 名前：桑名翔 ● 会社：エムオーテックス株式会社 ● 資格： ● 最近やったこと：JVM Lambda をカスタムランタイムに置き換えてコスト削減と性能UP

Slide 3

Slide 3 text

今日の話 ● 運用 ○ アプリケーションのデプロイ ○ パッチ適用 … etc ● 運用監視 ○ ログ・メトリクス監視 ○ リソース使用率の監視 … etc

Slide 4

Slide 4 text

今日の話 ● 運用 ○ アプリケーションのデプロイ ○ パッチ適用 … etc ● 運用監視 ○ ログ・メトリクス監視 ○ リソース使用率の監視 … etc

Slide 5

Slide 5 text

構成について簡単に ● AWS をメインにほとんどサーバレス構成でアプリケーションを構築して運用 ○ 1000個を超えるLambda関数 ○ 数百のDynamoDbテーブルやS3バケット ○ 数十のKinesis ストリームやSQSキュー ● 運用監視システムは自前実装 ○ ログやメトリクスに対してアラームをセットし、チャットに投稿される仕組み ○ 基本的には通知トリガーで対応する

Slide 6

Slide 6 text

通知の仕組み

Slide 7

Slide 7 text

こんな感じ

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

そもそもどうして運用監視をするのか？ ● 可用性と信頼性の確保 ● パフォーマンスやコストの最適化 ● セキュリティの確保 … etc

Slide 10

Slide 10 text

そもそもどうして運用監視をするのか？ ● 可用性と信頼性の確保 ● パフォーマンスやコストの最適化 ● セキュリティの確保 … etc

Slide 11

Slide 11 text

観測しすぎによる運用負荷の高まり ● 基本的には全てのリソースにアラームをセット ○ 新規リソースを作成するたびにアラームが増える ○ 管理コストも増える ● 開発サイクルによる問題 ○ 新機能開発が多くリリース後の見直しが起こりづらい

Slide 12

Slide 12 text

こんなAPIを考えてみる

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

観測しすぎな現状から抜け出すために ● やりたいことは可用性と信頼性の確保つまり、お客様が問題なくサービスを利用し続けられていること ↓言い換えるとお客様がサービスを利用できなくなっていることを検知したい

Slide 15

Slide 15 text

さっきのAPIについて考えてみる ● 基本的には自動で復旧やスケーリングする構成 ○ つまるところ、アプリケーション障害以外ではほとんど対応の余地がない

Slide 16

Slide 16 text

さっきのAPIについて考えてみる

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

対応効果 ● それぞれのアラームが発生したら、対応が必要なものになってきたので、対応へのスピード感も上がった ○ オオカミ少年的アラームがいなくなるだけで危機感が上がった

Slide 20

Slide 20 text

簡単まとめ適切なアラームを設定することで迅速な対応が可能になりますそのためにもアラームの意義と役割を明確にしましょう

Slide 21

Slide 21 text

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