CloudWatchから始めるAWS監視

SRE Lounge Hiroshima #2

Transcript

1. CloudWatchから始めるAWS監視 SRE Lounge Hiroshima #2 butadora 1
2. 自己紹介 荒木 雅斗 / butadora SWE, SRE @KG Motors(東広島) 超小型モビリティロボット「mibot」 普段はリモート or 東京オフィス勤務 たまに東広島でmibot乗り回してます ex-サーバーエンジニア→SRE 出身は福岡 2
3. (PR)mibotとは？ 一人乗り超小型EV エアコン付きで航続距離100km 最高時速60km/h、原付ミニカー扱い 自動車普通免許で運転可 任意保険は原付バイク用 or ファミリーバイク特約 SDV(Software Defined Vehicle) スマホアプリ、マイページによる各種操作 3
4. 参加のきっかけ 4
5. 参加のきっかけ 5
6. 参加のきっかけ ということでお邪魔しております！ 広島のスタートアップ所属ということで、仲良くしてください 現在、KG Motorsでは監視を含めたAWS環境をゼロから構築中 初期フェーズの選択肢としてAWSに寄せて構築する方針を検討 今日はその1案としてのアウトプットをさせてください！ n番煎じ、釈迦に説法かもですがあしからず 6
7. AWSの監視ツール、最初からSaaSに全振りする？ オールインワンなSaaSの魅力 DatadogやNewRelic等, オールインワンで監視をはじめられる 導入のハードル 初期フェーズでは「学習コスト」と「費用」が大きな壁になりがち AWS公式の強み 省力ですぐに始められる、CloudWatchシリーズから足場を固める のもよさそう 7
8. 何を見るか？（メトリクスとログ） STEP 1 リソースの把握 → CloudWatch Metrics EC2やRDSなどの標準メトリクスはもちろん、アプリケーション独自のカスタムメトリ クスを可視化し、システム全体の健全性を直感的に把握する。 STEP 2 原因の特定 → CloudWatch Logs / Logs Insights コンテナやアプリケーションのエラーログを一元的に集約。 Logs Insightsの強力なクエリエンジンを用いて、障害時の高速な原因検索を実現する。 今月からALBのログやIntelligent-Tiering対応で、より気軽になった。 8
9. 何を見るか？（外形監視と通知） STEP 3 システムの生存確認 → CloudWatch Synthetics Canary関数を活用し、ユーザー目線での定期的なAPIレスポンスチェックやシナリオテ ストを自動化。ダウンタイムを素早く検知する。 STEP 4 異常の検知と初動 → CloudWatch Alarms + SNS (+ Notification) あらかじめ設定したしきい値超過時に、即座にSlack等へアラートを通知。また、状況 に応じたオートスケーリング連携で初動を自動化する。 9
10. もう一歩進めるなら（AWSの高度な監視） 「オールインワン」な監視領域も、今のAWSならカバー可能 APM（分散トレーシング） → Application Signals / X-Ray パフォーマンス監視やボトルネック特定。マイクロサービス間の通信状況を可視 化する クライアントサイド監視 → CloudWatch RUM ブラウザやモバイル等, 実ユーザー環境のエラーやパフォーマンスを収集しUXまで 統合監視 運用自動化・AIサポート → AWS DevOps Agent 生成AIを活用したインシデント調査の自動化。根本原因の特定から復旧提案まで サポート 10
11. おまけ：外形監視は「AWSの外」からやるのもアリ AWS自体の障害検知のためには、監視元がAWS外にしたい そんな時、さくらのクラウド シンプル監視という選択肢 月額22円（1エンドポイント）という圧倒的な高コスパで導入可能 シンプルな分、他の外形監視と比べてもアラートが届くまでのラグが少ない （個人の感想です） FYI: さくらのクラウド シンプル監視はいいぞ - トラストバンクテックブログ 11
12. まとめ 監視の事始めはAWS標準機能からでもOK インフラや監視のベストプラクティスについて、ぜひ懇親会で情報交換させてくだ さい！ mibot開発に興味がでた方、気軽にカジュアル面談しましょう 採用ページ: https://kg-m.jp/recruit 12