Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
【再学習】リアルガチでCloudWatchを有効活用してますか?
Search
honma
December 08, 2022
Technology
0
1.5k
【再学習】リアルガチでCloudWatchを有効活用してますか?
2022/12/08 JAWS-UG朝会 #40
honma
December 08, 2022
Tweet
Share
More Decks by honma
See All by honma
AWS IoT Coreのポリシー活用を熱く語ろう
honma12345
0
430
AWSを活用した ドローンIoTソリューション
honma12345
0
260
ランニングコストやっべぇぞ!ECS/FargateでECRへのアクセスについて
honma12345
13
4.1k
複数AWSアカウントに リソース構築する時 どうしてますか?
honma12345
1
2.5k
自然言語解析AIサービス Dialogflowの紹介
honma12345
0
140
AWS IoT Coreを利用したドローンの実例
honma12345
0
450
AWS認定資格を8ヶ月で12冠達成した勉強法
honma12345
0
590
Other Decks in Technology
See All in Technology
Snowflake女子会#3 Snowpipeの良さを5分で語るよ
lana2548
0
230
小学3年生夏休みの自由研究「夏休みに Copilot で遊んでみた」
taichinakamura
0
150
podman_update_2024-12
orimanabu
1
270
5分でわかるDuckDB
chanyou0311
10
3.2k
Amazon Kendra GenAI Index 登場でどう変わる? 評価から学ぶ最適なRAG構成
naoki_0531
0
110
日本版とグローバル版のモバイルアプリ統合の開発の裏側と今後の展望
miichan
1
130
10個のフィルタをAXI4-Streamでつなげてみた
marsee101
0
170
複雑性の高いオブジェクト編集に向き合う: プラガブルなReactフォーム設計
righttouch
PRO
0
110
Postman と API セキュリティ / Postman and API Security
yokawasa
0
200
Jetpack Composeで始めるServer Cache State
ogaclejapan
2
170
LINE Developersプロダクト(LIFF/LINE Login)におけるフロントエンド開発
lycorptech_jp
PRO
0
120
2024年にチャレンジしたことを振り返るぞ
mitchan
0
140
Featured
See All Featured
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
2
170
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.3k
Navigating Team Friction
lara
183
15k
Building Adaptive Systems
keathley
38
2.3k
Making the Leap to Tech Lead
cromwellryan
133
9k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
Building an army of robots
kneath
302
44k
A designer walks into a library…
pauljervisheath
204
24k
Unsuck your backbone
ammeep
669
57k
Raft: Consensus for Rubyists
vanstee
137
6.7k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Transcript
朝寒すぎて起きれない...
皆起きてる??
【再学習】 リアルガチでCloudWatchを 有効活用してますか? JAWS-UG 朝会 #40 2022/12/08
まずあんた誰?
自己紹介 本間 崇平 アイレット株式会社 所属 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
1. 事件が起きた 2. CloudWatchの有効活用 3. 結論 お品書き
はじめに
CloudWatchを正しく使わないと 運用保守が大変になる
リアルガチで
何はともかく サーバーレス構成で実稼働が始まった
構成図
実際に稼働してから数カ月後 きましたよアラート...
1. 事件が起きた
何が起きた? 一旦稼働してからってことで必要なCloudWatchメトリクスアラームは設定してた Lambda(Duration,Incations)とAPI Gateway(5XXError, Count)など ただ、アクセス数が増えだして5XXエラーが多発し始めた 運用保守に追われる日々..😇
None
誰が非機能やったんだよ..
None
非機能開発はちゃんとしてた (はずだった)
いざ、保守対応しだして気づいた 非機能がちゃんとできてねぇ!!
あの時、後悔したこと • メトリクス理解不足(設定が足りてない) • ダッシュボードを使ったメトリクス視覚化ができてない • インサイトを使う前提で、ログ出力設計ができてない • どのAWSリソースでエラーが発生してるかも確認できてない •
定期的にモニタリングができてない etc
ここから再学習も兼ねて
2. CloudWatchを有効活用しよう
Metricsについて
そもそもCloudWatch Metricsとは • システムのパフォーマンスに関するデータ • 検索、グラフ表示、アラームに備えて全メトリクスをロード可能 • 基本モニタリング(無料)と詳細モニタリング(一部有料)がある • メトリクスデータは15ヶ月間保持される
Metricsでの考慮不足 各リソースのメトリクス閾値を理解せずに曖昧な状態で設定 →結果、アラートが飛ばずに顧客から連絡が...
• お前が設定したメトリク スは正しいのか? • 各リソースのメトリクス のドキュメント確認した のか? • アラートの閾値が正し い値なのか?
→負荷・性能試験やっ た? Metricsで意識すること
• 閾値レベルに応じたア ラートを作成する • 最初は異常時に気づかな くなる、最初はキツめに閾 値を設定 ログレベルの例 INFO: 興味深い事象
WARN: 異常とは言い切れない自称 CRITICAL: 致命的な状態 アラートの閾値を最初どうするか
Logs
Logsとは • EC2 インスタンス, Lambda, CloudTrail, Route53などのログ ファイルをモニタリング、保存、アクセスできる • 特定のエラーコードやパターンを検索可能
• ダッシュボードでのログデータ可視化も
実装時にログ出力はできるだけ多くだしておこうと出力してた →結果、余計なログが出力されてアラートの原因調査に時間がか かる →費用が高くついた →どれが致命的なログなのかわからない Logsでの考慮不足
Logsで意識すること • 実装時に出力するログを必要最低限だけ出力しているか? ◦ リクエストログ ◦ レスポンスログ • ログの出力設計はできているか? ◦
Insightの検索も考慮できているか(後述説明) • CloudWatch Logsの保持期間は短く設定できているか? ◦ 長期バックアップはできているか? • コスト面: IncomingBytesメトリクスの利用 ◦ CloudWatch のロググループに取り込まれているデータ量を、ほぼリアルタイ ム示す
長期バックアップもする CloudWatch Logsのサブスクリプションフィルターを使用する https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/SubscriptionFilters.html
Logs Insights
• CloudWatch Logsのログデータを検索し分析することができ る • クエリを実行することで運用問題を効率的に対応可能 • 1つのリクエストで最大20個のロググループをクエリ可能 Logs Insightsとは
Insightのクエリ実行に欲しいログ情報がでなかった →クエリ検索で必要な項目をログ出力できてない(設計不足) →クエリ構文でどれ検索すればいいか咄嗟にできない →再度似た事象発生の時にクエリのテンプレを保存をしてない Logs Insightsでの考慮不足
Logs Insightsで意識すること • ログ出力設計は入 念にやる • 頻繁に扱うクエリ は保存 • ログレベルに応じ
たクエリ文も用意し て保存
ServiceLens(X-Ray)
• ServiceLensはCloudWatchをAWS X-Rayと統合 • トレース、メトリクス、ログ、アラームの情報を1ヶ所に統合され 監視性を強化 ServiceLensとは
ServiceLensでの考慮不足 どこのリソースで処理時間がかかったか どの時間帯でAWSリソースがエラーが発生したか →瞬時にどこのリソースが問題原因してるか追えなかった
ServiceLensで意識すること • どこのリソースで 時間が経過して いるか確認可能 • トレースの分析で X-Rayを使った分 析が可能 •
どの時にステータ スがエラーだった かもわかる
Dashboard
• コンソールにあるカスタマイズ可能なホームページ • 異なるリージョンにまたがったリソースでも、1つのビューでモ ニタリング可能 • メトリクスとアラームをカスタマイズした状態で表示もできる Dashboradとは
Dashboradでの考慮不足 • ダッシュボードを使わず、特定のメトリクスだけ確認しており、 木を見て森を見ず状態となっていた → Logsだけで原因調査をするはめに... →時間の無駄
Dashboardで意識すること
Synthetics Canary
• エンドポイントとAPIをモニタリングできる • スケジュールに沿って実行可能なスクリプト ◦ Node.js ◦ Python • アプリからのトラフィックがない場合でも、継続的に検証ができ
る • CanaryのプロトコルはHTTPとHTTPSをサポート Synthetics Canaryとは
Synthetics Canaryでの考慮不足 疑似モニタリングができてない API Gatewayの定期的な正常性確認ができてない →エンドユーザーより後に、システム問題の特定に遅れる
Synthetics Canaryで意識すること 正常性確認用のAPIを実装しCanaryで1分間隔でリクエストをしておく
ということで
3. 結論
結論 AWSの責はほぼない 設計・実装したお前の責である
リアルガチで
AWSの責はほぼない、設計・実装したお前の責である CloudWatchの多くの機能を使って、効率な運用保守をする 稼働してからだと遅すぎるので、非機能は入念に設計・試験しよう CloudWatchは今回紹介できてない機能もまだまだあるので使えるなら使う 結論
ドキュメントを見るのが一番正確で最強である https://docs.aws.amazon.com/cloudwatch/index.html
紹介してきた機能を活用することで 運用保守が楽になる
おわり