はじめに
最近、プロジェクトで運用回りの設計を行う機会があったので、その際に学習したことをまとめました。AWSを使っている方で監視に興味があるけど、まだ良く理解できていないという方のためになれば幸いです。ここではAWS監視の基本について解説しています。
監視の目的
以下に代表的な監視の目的を列挙します。
- アプリケーションの正常性をチェックする
- 例：Webシステム 応答時間、HTTP 5XXエラー率
- 例：バッチシステム 処理時間（目標完了時間の超過の有無）
- アプリケーションを元の状態に回復する
- 異常状態への変化を検知して、正常状態に復旧する方法を用意する
- トラブルの原因を調査する
- アプリ/リソースの動作状況をログやメトリクスとして記録して、トラブルが生じた際に活用出来るようにする
- ユーザー行動を分析する
- ユーザーの行動をアクセスログなどで記録して、将来のユーザー行動やトレンドを予測する
- キャパシティを分析する
- リソースに関する状況をメトリクスとして記録して、将来のキャパシティを分析する
監視のアンチパターン
以下によくやりがちな監視のアンチパターンの例を示します。
不適合な監視
- Webアプリの正常性チェックのためにApacheプロセスを監視
Apacheプロセスの起動有無とWebアプリの動作が正常かどうかは異なる
Webアプリの正常性チェックにはユーザリクエストを実際に発生させて応答を確認する
情報不足
- オートスケールの結果インスタンスが消失してログも消失
トラブル調査が必要になった時点では確認するすべがない
トラブル調査に必要な情報は保全方法の事前確認が必要
- 秒単位のリアルタイムシステムの調査用に5分間隔のメトリクス収集
トラブル発生時に相関のある複数のグラフの前後/因果関係が分からない
秒単位のリアルタイム性が必要なシステムの調査には秒単位の粒度でのメトリクス記録する
通知過多
- "ERROR"を含むログが出力されたら全てメール通知する
大量の通知によって運用負荷が増大して、重大な通知の見逃しにつながる
ログ自体は可能な限り収集して、後から振り返って削っていく
通知は対応が必要なものだけに絞り、重要/緊急度を元に通知方法や通知先を設定する
例）
・即時対応が必要な場合 → 電話
・即時対応が不要な場合 → メール
クラウドとオンプレミスの監視の違い
- リソースをオンデマンドに追加・削除出来る
- リソースが一時的にしか存在しないことがある
- マネージドサービスが提供されている
- クラウド特有の仕組み・サービスが用意されている
クラウドの特性を考慮して監視設計する
AWSを活用するメリット
- インフラストラクチャの管理が不要になる
- HWの管理はAWSの役割
- ログ・メトリクスの取得が容易
- 設定するだけでログ・メトリクスを収集出来るサービスが多い
- セキュア・柔軟な保管領域
- ログの保管ストレージを無制限に利用できる
- ローテート期間を柔軟に設定できる
- インテグレーションが豊富
- ログの検索・分析サービスが複数ある
監視のサイクル
監視設計を一度作ってそのままにしておくのは危険です。
下記の4ステップを継続的に回し続け、アプリケーションに適応した監視設計を目指しましょう。
1. 収集
- 監視目的から収集対象・粒度・保存期間を決める
- 収集対象・粒度・保存期間はコストとのトレードオフ
2. 監視
- 収集した状態を適切な方法で把握・確認する
- 目的に応じた監視
- ダッシュボードによる状態の可視化
- リアルタイムのアラート通知
- 通知頻度は運用負荷とのトレードオフ
3. 行動
- 収集・監視した状態を元に適切なアクションをとる
- 目的に応じたアクション（リソースの調整、システムの回復、...）
- システムを回復しやすいように設計しておく
❑Design for Failureの原則
システムの一部のコンポーネントが故障してもアプリケーションは継続動作するように設計する- 回復しやすいアプリケーション設計のポイント
- リトライと冪等性：同じ操作を何度繰り返しても、同じ結果が得られる
- ステートレス：現在の状態を表すデータなどを保持せず、入力の内容によってのみ出力が決定される
4. 分析
- 収集した状態を中長期的に分析する
- 分析結果をもとに将来のビジネス状況や必要キャパシティを予測
- 分析を効率的に実現できるようにデータを保持・加工しておくこと
AWS監視で利用する代表的なサービス
-
収集フェーズ
- CloudWatch Metrics: メトリクスの収集
- CloudWatch Logs, S3: ログの収集
- Kinesis Data Firehose: ログをCloudWatch LogsやS3に転送
- CloudTrail: 全AWSサービスのAPIログを記録
- VPCフローログ: VPCのトラフィックログを記録
-
監視フェーズ
- CloudWatchコンソール: 複数のメトリクスのグラフやログを表示
- CloudWatchダッシュボード: 複数のメトリクスのグラフ、アラームを一括表示（カスタマイズ可能）
- CloudWatch Alarm: アラームの設定
- CloudWatch Synthetics: 外形監視に関するサービス
-
行動フェーズ
- AWS Auto Scaling: メトリクスを元にリソースのキャパシティを自動的に調整
- CloudWatch Events: リソースの状態変化等を契機にLambdaなど各種AWSサービスを実行
- Lambda: Pythonなどで書かれたプログラムをサーバーレス環境で実行（任意の運用作業を実行）
- Systems Manager: 管理対象のサーバー上で任意のコマンドを実行
-
分析フェーズ
- CloudWatch Logs Insights: CloudWatch Logsに蓄積されたログを検索・可視化
- Athena: 複数のS3上のファイルを一括で検索
- ElasticSearch: REST APIでクエリして全文検索（CloudWatch Logs Insightsより柔軟な検索が必要な時に利用）
- ElasticSearch Kibana: ElasticSearchに蓄積されたログを検索・可視化（CloudWatch Logs Insightsよりリッチな可視化を行い時に利用）
- QuickSight: 様々なデータに接続できるBIサービス