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

2022/12/08 JAWS-UG朝会 #40

Transcript

1. 朝寒すぎて起きれない...
2. 皆起きてる？？
3. 【再学習】 リアルガチでCloudWatchを 有効活用してますか？ JAWS-UG 朝会 #40 2022/12/08
4. まずあんた誰？
5. 自己紹介 本間 崇平 アイレット株式会社 所属 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
6. 1. 事件が起きた 2. CloudWatchの有効活用 3. 結論 お品書き
7. はじめに
8. CloudWatchを正しく使わないと 運用保守が大変になる
9. リアルガチで
10. 何はともかく サーバーレス構成で実稼働が始まった
11. 構成図
12. 実際に稼働してから数カ月後 きましたよアラート...
13. 1. 事件が起きた
14. 何が起きた? 一旦稼働してからってことで必要なCloudWatchメトリクスアラームは設定してた Lambda(Duration,Incations)とAPI Gateway(5XXError, Count)など ただ、アクセス数が増えだして5XXエラーが多発し始めた 運用保守に追われる日々..😇
16. 誰が非機能やったんだよ..
18. 非機能開発はちゃんとしてた (はずだった)
19. いざ、保守対応しだして気づいた 非機能がちゃんとできてねぇ！！
20. あの時、後悔したこと • メトリクス理解不足(設定が足りてない) • ダッシュボードを使ったメトリクス視覚化ができてない • インサイトを使う前提で、ログ出力設計ができてない • どのAWSリソースでエラーが発生してるかも確認できてない • 定期的にモニタリングができてない etc
21. ここから再学習も兼ねて
22. 2. CloudWatchを有効活用しよう
23. Metricsについて
24. そもそもCloudWatch Metricsとは • システムのパフォーマンスに関するデータ • 検索、グラフ表示、アラームに備えて全メトリクスをロード可能 • 基本モニタリング(無料)と詳細モニタリング(一部有料)がある • メトリクスデータは15ヶ月間保持される
25. Metricsでの考慮不足 各リソースのメトリクス閾値を理解せずに曖昧な状態で設定 →結果、アラートが飛ばずに顧客から連絡が...
26. • お前が設定したメトリク スは正しいのか？ • 各リソースのメトリクス のドキュメント確認した のか？ • アラートの閾値が正し い値なのか？ →負荷・性能試験やっ た？ Metricsで意識すること
27. • 閾値レベルに応じたア ラートを作成する • 最初は異常時に気づかな くなる、最初はキツめに閾 値を設定 ログレベルの例 INFO: 興味深い事象 WARN: 異常とは言い切れない自称 CRITICAL: 致命的な状態 アラートの閾値を最初どうするか
28. Logs
29. Logsとは • EC2 インスタンス, Lambda, CloudTrail, Route53などのログ ファイルをモニタリング、保存、アクセスできる • 特定のエラーコードやパターンを検索可能 • ダッシュボードでのログデータ可視化も
30. 実装時にログ出力はできるだけ多くだしておこうと出力してた →結果、余計なログが出力されてアラートの原因調査に時間がか かる →費用が高くついた →どれが致命的なログなのかわからない Logsでの考慮不足
31. Logsで意識すること • 実装時に出力するログを必要最低限だけ出力しているか？ ◦ リクエストログ ◦ レスポンスログ • ログの出力設計はできているか？ ◦ Insightの検索も考慮できているか（後述説明） • CloudWatch Logsの保持期間は短く設定できているか？ ◦ 長期バックアップはできているか？ • コスト面: IncomingBytesメトリクスの利用 ◦ CloudWatch のロググループに取り込まれているデータ量を、ほぼリアルタイ ム示す
32. 長期バックアップもする CloudWatch Logsのサブスクリプションフィルターを使用する https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/SubscriptionFilters.html
33. Logs Insights
34. • CloudWatch Logsのログデータを検索し分析することができ る • クエリを実行することで運用問題を効率的に対応可能 • 1つのリクエストで最大20個のロググループをクエリ可能 Logs Insightsとは
35. Insightのクエリ実行に欲しいログ情報がでなかった →クエリ検索で必要な項目をログ出力できてない(設計不足) →クエリ構文でどれ検索すればいいか咄嗟にできない →再度似た事象発生の時にクエリのテンプレを保存をしてない Logs Insightsでの考慮不足
36. Logs Insightsで意識すること • ログ出力設計は入 念にやる • 頻繁に扱うクエリ は保存 • ログレベルに応じ たクエリ文も用意し て保存
37. ServiceLens(X-Ray)
38. • ServiceLensはCloudWatchをAWS X-Rayと統合 • トレース、メトリクス、ログ、アラームの情報を1ヶ所に統合され 監視性を強化 ServiceLensとは
39. ServiceLensでの考慮不足 どこのリソースで処理時間がかかったか どの時間帯でAWSリソースがエラーが発生したか →瞬時にどこのリソースが問題原因してるか追えなかった
40. ServiceLensで意識すること • どこのリソースで 時間が経過して いるか確認可能 • トレースの分析で X-Rayを使った分 析が可能 • どの時にステータ スがエラーだった かもわかる
41. Dashboard
42. • コンソールにあるカスタマイズ可能なホームページ • 異なるリージョンにまたがったリソースでも、1つのビューでモ ニタリング可能 • メトリクスとアラームをカスタマイズした状態で表示もできる Dashboradとは
43. Dashboradでの考慮不足 • ダッシュボードを使わず、特定のメトリクスだけ確認しており、 木を見て森を見ず状態となっていた → Logsだけで原因調査をするはめに... →時間の無駄
44. Dashboardで意識すること
45. Synthetics Canary
46. • エンドポイントとAPIをモニタリングできる • スケジュールに沿って実行可能なスクリプト ◦ Node.js ◦ Python • アプリからのトラフィックがない場合でも、継続的に検証ができ る • CanaryのプロトコルはHTTPとHTTPSをサポート Synthetics Canaryとは
47. Synthetics Canaryでの考慮不足 疑似モニタリングができてない API Gatewayの定期的な正常性確認ができてない →エンドユーザーより後に、システム問題の特定に遅れる
48. Synthetics Canaryで意識すること 正常性確認用のAPIを実装しCanaryで1分間隔でリクエストをしておく
49. ということで
50. 3. 結論
51. 結論 AWSの責はほぼない 設計・実装したお前の責である
52. リアルガチで
53. AWSの責はほぼない、設計・実装したお前の責である CloudWatchの多くの機能を使って、効率な運用保守をする 稼働してからだと遅すぎるので、非機能は入念に設計・試験しよう CloudWatchは今回紹介できてない機能もまだまだあるので使えるなら使う 結論
54. ドキュメントを見るのが一番正確で最強である https://docs.aws.amazon.com/cloudwatch/index.html
55. 紹介してきた機能を活用することで 運用保守が楽になる
56. おわり