AWSの監視ツールについて調べてみた
IT技術
はじめに
AWSでシステムを構築し、アプリケーションが動作し始めたら、次に重要なステップは「監視」です。監視を通じてシステムの健康状態を保ち、パフォーマンスを最大限に引き出すことが可能になります。この記事では、AWSでシステムを構築した後の監視方法について調べていきます!
監視って、具体的に何をするの?
「監視」と一言で言っても、その範囲はとても広いです。
- サーバーの動作状況(CPU使用率やメモリ使用率)
- アプリケーションのレスポンスタイム
- エラー発生状況
- データベースの状態
- 運用コストと使用状況
などなど、その他にも考慮する点は沢山あります。
AWSでは、これらをカバーするために様々なサービスが存在します。
AWSの監視リソースについて
AWSの監視に便利なサービスを紹介します。ここでは大きくシステム情報と運用情報に分けています。
システム情報
- AWS CloudWatch
AWS CloudWatchは、AWSリソースとアプリケーションが発行するメトリクスの監視、ログの収集と分析、アラームの設定を提供します。これにより、システムのパフォーマンスをリアルタイムで監視し、異常が発生した際に迅速に対応できます。
運用情報
- AWS CloudTrail
AWS CloudTrailは、AWSアカウントの活動記録を保持します。どのユーザーがいつどのような設定を行ったか、作業の詳細を記録することが出来ます。これにより、ガバナンス、コンプライアンス、運用監査、リスク監査のための貴重な情報を提供します。
- AWS Budgets
AWS Budgetsを使用すると、コストと使用状況の予算を設定し、予算を超えた場合にアラートを受け取ることができます。例えば、月間のEC2インスタンス使用料が設定した予算を超えそうになった場合、AWS Budgetsからのアラートによって事前に通知を受け、コストの管理を効果的に行うことができます。
- AWS Personal Health Dashboard
AWS Personal Health Dashboardは、AWSリソースと環境に影響を与える可能性のある問題についてアラートと自動修復の指示を提供します。例えば、使用中のEC2インスタンスタイプに関する予定されたメンテナンスがある場合、Personal Health Dashboardを通じて事前に通知を受け取り、計画的な対応を行うことが出来ます。
- AWS Cost Explorer
AWS Cost Explorerを使用すると、過去と現在の使用状況とコストの詳細な分析を行い、将来の支出を予測することができます。例えば、過去12ヶ月間のS3使用料のトレンドを分析し、データの成長に基づいて次の年度の予算を計画することが可能です。
しかし、ただ監視サービスを使えば良いわけではありません。
大切なのは、何を監視するか、そしてどう対応するかです。
例えば、CPU使用率の異常上昇を検知した場合、自動スケーリングをトリガーすることでリソース不足に迅速に対応することができます。他にも、エラーログの増加を検知した場合、即座に開発チームに通知し、問題解決のプロセスを開始することが可能です。
紹介したリソースの監視と対応を、図示すると以下のようになります。
引用:https://www.sunnycloud.jp/column/20210209-01/
CloudWatchについて
今回はシステム情報にフォーカスして、CloudWatchについて紹介していきます。
CloudWatchは、AWSリソースとアプリケーションの監視を簡単に行える強力なサービスです。
主要な機能を紹介します!
メトリクスの収集と分析
CPU使用率やディスクI/O、ネットワーク使用量など、AWSリソースのメトリクス(指標)をリアルタイムで収集してくれます。これらのデータを使って、システムのパフォーマンスを分析したり、ボトルネックを見つけ出したり出来ます。
ログの収集と分析
CloudWatch Logsを使えば、アプリケーションやシステムのログを簡単に収集・閲覧・分析できて、エラーの原因追求がグッと楽になります。
アラームの設定と通知
「このメトリクスがこの値を超えたら教えて!」そんな要望に応えるのがCloudWatch Alarmsです。
設定した閾値をメトリクスが超えると、メールやSMS、Slackなどで通知してくれるので、問題が起きてもすぐに対応できます。
他にも、アラートをトリガーとしてLambdaを実行するなど様々なことが出来ます。
ダッシュボードの作成
CloudWatch Dashboardsを使えば、重要なメトリクスやアラームを一つの画面にまとめて表示できます。カスタマイズも自由自在なので、それぞれの監視ニーズに合わせて作成することが出来て、リアルタイムに視覚的に情報を得ることが出来ます。
なぜCloudWatchが選ばれるのか
CloudWatchは、特に準備不要で即座に監視を開始できる点で、多くの現場で使われています。
また、AWS内のリソースに対してネイティブに統合されているため、別の監視ツールを導入する際の学習コストや設定の手間を省くことができます。
大規模な開発プロジェクトではDatadogやNew Relicなどのサードパーティ監視ツールを併用することもありますが、CloudWatchだけでも、小・中規模のプロジェクトにおけるインフラ監視のニーズを満たすことが可能と思います。
チーム全員がAWSに慣れ親しんでいる場合、CloudWatchを中心にシステム監視を行うことで、効率的に運用を行うことが可能です。
AWSを使用している開発チームにとって、CloudWatchはシステム監視の「基本」となるサービスです。
AWSで監視を設定する
今回は、ECSのCPU使用率のメトリクスを例にCloudWatchで簡単な監視設定をしていこうと思います。CloudWatchでアラートが発生した時にエラー通知がメールで届くようにします。
メトリクスの確認
ECSの構築は省略しますが、メトリクスを取得したい場合は、クラスター>モニタリングの設定からContainer InsightsをONにします。ONにすることで自動的にECSメトリクスが取得されます。
ECSの代表的なメトリクスです。
- CPUReservation - クラスターでタスクを実行することで予約されている CPU ユニットの割合。
- CPUUtilization - クラスターやサービスで使用されている CPU の割合。
- MemoryReservation - クラスターでタスクを実行することで予約されているメモリの割合。
- MemoryUtilization - クラスターやサービスで利用されるメモリの割合。
そのほかにも、クラスター毎のメトリクスやサービス毎のメトリクスなど様々な種類があります。詳細は公式ドキュメントを参照してください。:AWS公式ドキュメント
今回はECSのCPUUtilizationを監視対象とします。
CloudWatch Alarmsの設定
CloudWatch Alarmsを利用して、特定の条件下でアラートを発生させる設定を行います。この例では、過去2分間の平均CPU使用率が70%を超えた場合にアラートがトリガーされるように設定します。
メトリクスと条件の指定
CloudWatchアラームからアラームの作成を選択
メトリクスの選択からECS/ContainerInsights > 監視対象のClusterName・ServiceNameを指定して絞り込んで「CPUUtilization」にチェックをつけて次に進みます。
過去2分間のCPU使用率が70%以上でアラートを発生したいので、下記の条件で設定します。
- 統計:平均値
- 期間:2分間
- 閾値の種類:静的
- アラームの条件:70以上
アクションの設定
アラームが発生した際に、トリガーされるイベントを設定していきます。それぞれのアクションについて簡単に説明します。
- 通知
SNSトピックを紐づけることで、警告メールの送信やSlack通知などを設定できます。 - Lambda アクション
アラートをトリガーとしてLambda関数を実行することができます。 - Auto Scaling アクション
ECSなどで、CPU使用率が特定の閾値(例: 70%)を超えた際にオートスケーリングを設定できます。この設定により、CPU使用率が閾値を超えた際に自動的にタスク数が増加し、スケールアウトが行われます。 - Systems Manager アクション
Systems Managerを使用して、特定のアラートに応じた自動化されたアクション(例: パッチ適用、コマンド実行)をトリガーすることができます。
今回はSNSトピックを作成してエラー内容をメールで送信するようにします。
通知を開いて、新しいトピックを選択をします。トピック名を入力、メールアドレスを入力して作成します。設定したアドレスに確認のメールが来るので承認しておいてください。これで通知設定完了です。
名前と説明を追加
アラーム名と説明を追加しましょう。プレビューして問題なければ作成完了です。
アクションタブで作成したSNSトピックが紐づけられていることを確認しましょう。
Apache JMeter や Locust などの負荷テストツールを使用して、ECSに負荷をかけてメールが届くか確認しましょう。通知の確認だけなら閾値を変更したほうが良いかもしれません。アラートが発生するとメールが確認できました!
一連の流れをterraformで記述するとこうなります。
1resource "aws_cloudwatch_metric_alarm" "ecs_cpu_high" {
2 alarm_name = "ecs-cpu-utilization-high"
3 comparison_operator = "GreaterThanOrEqualToThreshold"
4 evaluation_periods = 2
5 metric_name = "CPUUtilization"
6 namespace = "AWS/ECS"
7 period = 60
8 statistic = "Average"
9 threshold = 70
10
11 dimensions = {
12 ClusterName = var.ecs_cluster_name
13 ServiceName = var.ecs_service_name
14 }
15
16 alarm_actions = [
17 aws_sns_topic.default.arn
18 ]
19}
20
21resource "aws_sns_topic" "default" {
22 name = "ecs-cpu-utilization-alert"
23}
24
25resource "aws_sns_topic_subscription" "email_subscription" {
26 topic_arn = aws_sns_topic.default.arn
27 protocol = "email"
28 endpoint = "your-email@example.com" # ここに通知を受け取るメールアドレスを設定してください。
29}
CloudWatchの料金
CloudWatchの料金は、使用したサービスの量に基づいて計算されます。基本的には、収集したメトリクスの数、ログのデータ量、アラームの数などによって料金が変動します。特定のメトリクスとアラーム数については無料で利用できますが、それを超える使用には料金が発生します。
例えば、CloudWatch Logsでは、収集したログデータの量に応じて料金がかかります。また、ログデータを長期間保存する場合は、追加のストレージ料金が必要になる場合があります。保持期間を適切に設定して必要なログだけ残すようにしましょう。
最新の料金情報については、AWSの公式サイトのCloudWatch料金ページで確認してください。https://aws.amazon.com/jp/cloudwatch/pricing/
まとめ
AWSでの監視機能についてご紹介してきました。監視というと少し専門的で取っつきにくいイメージがあるかもしれませんが、システムを守り、運用をスムーズにするために欠かせない重要なプロセスです。今回取り上げたCloudWatchの設定例は、AWSでの監視を始めるための基本的なガイドラインです。AWSには様々な監視ツールがあり、プロジェクトのニーズに合わせて選択することが可能です。各ツールの特徴を理解し、最適な監視環境を構築してみてください!今後もAWSサービスに関するさまざまな情報をブログで共有していきたいと思います。
ライトコードでは、エンジニアを積極採用中!
ライトコードでは、エンジニアを積極採用しています!社長と一杯しながらお話しする機会もご用意しております。そのほかカジュアル面談等もございますので、くわしくは採用情報をご確認ください。
採用情報へ
あだっちー(エンジニア)
8月から入社しました。安達です。 前職ではメカ設計・生産技術の業務をしておりました。 趣味はスノボとキャンプです! 日々邁進して参りますのでよろしくお願いいたします!
おすすめ記事
移転したライトコード大阪オフィスを調査せよ!
広告メディア事業部
2024.04.03
日常
【GCP】BIG QUERYを触り程度に理解してみる
かねまさ(エンジニア)
2024.04.02
IT技術
【Android】Github ActionsでFirebase Test Labの実行を分散する
笹川(エンジニア)
2024.04.02
IT技術
【Next.js】App Router で使用できるキャッシュまとめ
モーリー(エンジニア)
2024.03.29
IT技術
GitHubActionsのランナーに触れてみた
こやまん(エンジニア)
2024.03.28
IT技術