【再学習】リアルガチでCloudWatchを有効活用してますか？

by honma

Slide 1

Slide 1 text

朝寒すぎて起きれない...

Slide 2

Slide 2 text

皆起きてる？？

Slide 3

Slide 3 text

【再学習】リアルガチでCloudWatchを有効活用してますか？ JAWS-UG 朝会 #40 2022/12/08

Slide 4

Slide 4 text

まずあんた誰？

Slide 5

Slide 5 text

自己紹介本間崇平アイレット株式会社所属 Shuhei Honma 2018年に入社(平成最後の新卒) AWS歴4年と数ヶ月 AWS使ってなんでもやる開発エンジニア受賞歴・2022 iretスペシャリスト認定制度・2022 Japan AWS Partner Ambassador ・2022 APN AWS Top Engineers (Service) ・2022 APN ALL AWS Certifications Engineers

Slide 6

Slide 6 text

1. 事件が起きた 2. CloudWatchの有効活用 3. 結論お品書き

Slide 7

Slide 7 text

はじめに

Slide 8

Slide 8 text

CloudWatchを正しく使わないと運用保守が大変になる

Slide 9

Slide 9 text

リアルガチで

Slide 10

Slide 10 text

何はともかくサーバーレス構成で実稼働が始まった

Slide 11

Slide 11 text

構成図

Slide 12

Slide 12 text

実際に稼働してから数カ月後きましたよアラート...

Slide 13

Slide 13 text

1. 事件が起きた

Slide 14

Slide 14 text

何が起きた? 一旦稼働してからってことで必要なCloudWatchメトリクスアラームは設定してた Lambda(Duration,Incations)とAPI Gateway(5XXError, Count)などただ、アクセス数が増えだして5XXエラーが多発し始めた運用保守に追われる日々..😇

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

誰が非機能やったんだよ..

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

非機能開発はちゃんとしてた (はずだった)

Slide 19

Slide 19 text

いざ、保守対応しだして気づいた非機能がちゃんとできてねぇ！！

Slide 20

Slide 20 text

あの時、後悔したこと ● メトリクス理解不足(設定が足りてない) ● ダッシュボードを使ったメトリクス視覚化ができてない ● インサイトを使う前提で、ログ出力設計ができてない ● どのAWSリソースでエラーが発生してるかも確認できてない ● 定期的にモニタリングができてない etc

Slide 21

Slide 21 text

ここから再学習も兼ねて

Slide 22

Slide 22 text

2. CloudWatchを有効活用しよう

Slide 23

Slide 23 text

Metricsについて

Slide 24

Slide 24 text

そもそもCloudWatch Metricsとは ● システムのパフォーマンスに関するデータ ● 検索、グラフ表示、アラームに備えて全メトリクスをロード可能 ● 基本モニタリング(無料)と詳細モニタリング(一部有料)がある ● メトリクスデータは15ヶ月間保持される

Slide 25

Slide 25 text

Metricsでの考慮不足各リソースのメトリクス閾値を理解せずに曖昧な状態で設定 →結果、アラートが飛ばずに顧客から連絡が...

Slide 26

Slide 26 text

● お前が設定したメトリクスは正しいのか？ ● 各リソースのメトリクスのドキュメント確認したのか？ ● アラートの閾値が正しい値なのか？ →負荷・性能試験やった？ Metricsで意識すること

Slide 27

Slide 27 text

● 閾値レベルに応じたアラートを作成する ● 最初は異常時に気づかなくなる、最初はキツめに閾値を設定ログレベルの例 INFO: 興味深い事象 WARN: 異常とは言い切れない自称 CRITICAL: 致命的な状態アラートの閾値を最初どうするか

Slide 28

Slide 28 text

Logs

Slide 29

Slide 29 text

Logsとは ● EC2 インスタンス, Lambda, CloudTrail, Route53などのログファイルをモニタリング、保存、アクセスできる ● 特定のエラーコードやパターンを検索可能 ● ダッシュボードでのログデータ可視化も

Slide 30

Slide 30 text

実装時にログ出力はできるだけ多くだしておこうと出力してた →結果、余計なログが出力されてアラートの原因調査に時間がかかる →費用が高くついた →どれが致命的なログなのかわからない Logsでの考慮不足

Slide 31

Slide 31 text

Logsで意識すること ● 実装時に出力するログを必要最低限だけ出力しているか？ ○ リクエストログ ○ レスポンスログ ● ログの出力設計はできているか？ ○ Insightの検索も考慮できているか（後述説明） ● CloudWatch Logsの保持期間は短く設定できているか？ ○ 長期バックアップはできているか？ ● コスト面: IncomingBytesメトリクスの利用 ○ CloudWatch のロググループに取り込まれているデータ量を、ほぼリアルタイム示す

Slide 32

Slide 32 text

長期バックアップもする CloudWatch Logsのサブスクリプションフィルターを使用する https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/SubscriptionFilters.html

Slide 33

Slide 33 text

Logs Insights

Slide 34

Slide 34 text

● CloudWatch Logsのログデータを検索し分析することができる ● クエリを実行することで運用問題を効率的に対応可能 ● 1つのリクエストで最大20個のロググループをクエリ可能 Logs Insightsとは

Slide 35

Slide 35 text

Insightのクエリ実行に欲しいログ情報がでなかった →クエリ検索で必要な項目をログ出力できてない(設計不足) →クエリ構文でどれ検索すればいいか咄嗟にできない →再度似た事象発生の時にクエリのテンプレを保存をしてない Logs Insightsでの考慮不足

Slide 36

Slide 36 text

Logs Insightsで意識すること ● ログ出力設計は入念にやる ● 頻繁に扱うクエリは保存 ● ログレベルに応じたクエリ文も用意して保存

Slide 37

Slide 37 text

ServiceLens(X-Ray)

Slide 38

Slide 38 text

● ServiceLensはCloudWatchをAWS X-Rayと統合 ● トレース、メトリクス、ログ、アラームの情報を1ヶ所に統合され監視性を強化 ServiceLensとは

Slide 39

Slide 39 text

ServiceLensでの考慮不足どこのリソースで処理時間がかかったかどの時間帯でAWSリソースがエラーが発生したか →瞬時にどこのリソースが問題原因してるか追えなかった

Slide 40

Slide 40 text

ServiceLensで意識すること ● どこのリソースで時間が経過しているか確認可能 ● トレースの分析で X-Rayを使った分析が可能 ● どの時にステータスがエラーだったかもわかる

Slide 41

Slide 41 text

Dashboard

Slide 42

Slide 42 text

● コンソールにあるカスタマイズ可能なホームページ ● 異なるリージョンにまたがったリソースでも、1つのビューでモニタリング可能 ● メトリクスとアラームをカスタマイズした状態で表示もできる Dashboradとは

Slide 43

Slide 43 text

Dashboradでの考慮不足 ● ダッシュボードを使わず、特定のメトリクスだけ確認しており、木を見て森を見ず状態となっていた → Logsだけで原因調査をするはめに... →時間の無駄

Slide 44

Slide 44 text

Dashboardで意識すること

Slide 45

Slide 45 text

Synthetics Canary

Slide 46

Slide 46 text

● エンドポイントとAPIをモニタリングできる ● スケジュールに沿って実行可能なスクリプト ○ Node.js ○ Python ● アプリからのトラフィックがない場合でも、継続的に検証ができる ● CanaryのプロトコルはHTTPとHTTPSをサポート Synthetics Canaryとは

Slide 47

Slide 47 text

Synthetics Canaryでの考慮不足疑似モニタリングができてない API Gatewayの定期的な正常性確認ができてない →エンドユーザーより後に、システム問題の特定に遅れる

Slide 48

Slide 48 text

Synthetics Canaryで意識すること正常性確認用のAPIを実装しCanaryで1分間隔でリクエストをしておく

Slide 49

Slide 49 text

ということで

Slide 50

Slide 50 text

3. 結論

Slide 51

Slide 51 text

結論 AWSの責はほぼない設計・実装したお前の責である

Slide 52

Slide 52 text

リアルガチで

Slide 53

Slide 53 text

AWSの責はほぼない、設計・実装したお前の責である CloudWatchの多くの機能を使って、効率な運用保守をする稼働してからだと遅すぎるので、非機能は入念に設計・試験しよう CloudWatchは今回紹介できてない機能もまだまだあるので使えるなら使う結論

Slide 54

Slide 54 text

ドキュメントを見るのが一番正確で最強である https://docs.aws.amazon.com/cloudwatch/index.html