1. ホーム
  2. 記事一覧
  3. AWSの監視戦略 主要サービスのメトリクスとアラート設定を理解する

2024.05.29

AWSの監視戦略 主要サービスのメトリクスとアラート設定を理解する

はじめに

AWSクラウド環境を最大限に活用するためには、リソースの監視とアラート設定が不可欠です。この記事を通じて、システムの健全性を維持し、問題が発生する前に迅速に対処する方法を学びましょう。具体的には、EC2、RDS、S3、ELBの監視すべき主要メトリクスと、それぞれのアラート設定の理由について詳しく解説します。

AWS CloudWatchのベストプラクティスでは、メトリクスの適切なしきい値設定と通知の自動化が推奨されています。これにより、問題の早期発見と迅速な対応が可能となります。 AWS CloudWatch アラートのベストプラクティス

リソースの監視はなぜ必要?

リソースの監視は、システムが正常に動いているかどうかをチェックするために大切です。たとえば、コンピューターの処理能力やデータの読み書きの速さ、ネットワークの利用状況などを監視することで、問題が起こる前に気づくことができます。これにより、トラブルを未然に防いだり、問題が起きてもすぐに対応できたりします。また、リソースの使用状況を把握することで、必要なときに追加のリソースを簡単に手配できるため、効率的な運用が可能になります。特にクラウドサービスでは、リソースを無駄なく使うために、監視は欠かせない作業です。

EC2の監視とアラート

EC2インスタンスの監視とアラート設定は、クラウド環境でのパフォーマンス管理と問題の早期検出に不可欠です。CPU使用率、ディスクI/O、ネットワークトラフィック、インスタンスのステータスなど、主要なメトリクスを監視することで、リソースの適切な配分とシステムの健全性を維持することができます。

主要メトリクス

日本語実際のメトリクス参考値 
CPU使用率CPUUtilization80%超
ディスクI/ODiskReadOps, DiskWriteOps高I/O操作数
ネットワークトラフィックNetworkIn, NetworkOut異常な増加
インスタンスのステータスStatusCheckFailed, StatusCheckFailed_Instance, StatusCheckFailed_Systemステータスチェック失敗

アラートの設定理由

CPU使用率

CPU使用率が高いとインスタンスが過負荷になるため、リソースの追加やインスタンスサイズの変更が必要です。例えば、CPU使用率が80%を超えた場合にアラートを設定すると、適切な対策を講じることができます。

ディスクI/O

ディスクI/Oの監視はストレージのパフォーマンス問題を早期に発見するのに役立ちます。例えば、特定のディスクI/O操作が継続的に高い場合にアラートを設定します。

ネットワークトラフィック

ネットワークトラフィックの異常な増加は潜在的なセキュリティリスクを示すことがあります。例えば、NetworkInやNetworkOutの異常な増加を検知した際にアラートを設定します。

インスタンスのステータス

インスタンスのステータスチェックが失敗した場合、ハードウェアやソフトウェアの問題が疑われます。例えば、StatusCheckFailedが検出された際にアラートを設定します。

詳細はEC2の監視ベストプラクティスをご参照ください。

RDSの監視とアラート

RDS(リレーショナルデータベースサービス)の監視とアラート設定は、データベースのパフォーマンスと信頼性を維持するために重要です。CPU使用率、ディスクI/O、データベース接続数、使用可能ストレージ容量、レプリケーションラグなどの主要メトリクスを監視することで、データベースの健全性を確保し、潜在的な問題を早期に検出することができます。

主要メトリクス

日本語実際のメトリクス参考値 
CPU使用率CPUUtilization70%超
ディスクI/OReadIOPS, WriteIOPS高I/O操作数
データベース接続数DatabaseConnections増加
使用可能ストレージ容量FreeStorageSpace10%未満
レプリケーションラグReplicaLag30秒超

アラートの設定理由

CPU使用率

クエリの最適化やインスタンスのスケーリングが必要です。例えば、CPU使用率が70%を超えた場合にアラートを設定します。

ディスクI/O

データベースのパフォーマンス問題を早期に特定するのに役立ちます。例えば、ReadIOPSやWriteIOPSが高い場合にアラートを設定します。

データベース接続数

アプリケーションのスケーリングやリソースの追加を示唆します。例えば、DatabaseConnectionsが急増した場合にアラートを設定します。

使用可能ストレージ容量

ストレージ容量不足を防ぐために重要です。例えば、FreeStorageSpaceが10%未満になった場合にアラートを設定します。

レプリケーションラグ

レプリカのパフォーマンスやネットワークの問題を示すことがあります。例えば、ReplicaLagが30秒を超えた場合にアラートを設定します。

S3の監視とアラート

S3バケットの監視とアラート設定は、データの保管とアクセス管理において重要です。バケットサイズ、オブジェクト数、リクエスト数などの主要メトリクスを監視することで、データ管理の効率化と潜在的な問題の早期検出が可能になります。このアラートにより、コストの最適化やセキュリティ対策が強化されます。

主要メトリクス

日本語実際のメトリクス参考値 
バケットサイズBucketSizeBytes急増
オブジェクト数NumberOfObjects増加
リクエスト数GetRequests, PutRequests異常な増加

アラートの設定理由

バケットサイズ

不正なデータアップロードやアプリケーションの問題を示すことがあります。例えば、BucketSizeBytesが急増した場合にアラートを設定します。

オブジェクト数

データ管理とコスト管理が容易になります。例えば、NumberOfObjectsが急増した場合にアラートを設定します。

リクエスト数

DDoS攻撃やアプリケーションの不具合を示すことがあります。例えば、GetRequestsやPutRequestsが異常に増加した場合にアラートを設定します。

ELBの監視とアラート

Elastic Load Balancing (ELB) の監視とアラート設定は、アプリケーションの可用性とパフォーマンスを維持するために重要です。ELBはトラフィックを複数のターゲットに分散させるため、その健全性を監視することで、潜在的な問題を早期に発見し、迅速に対処することが可能になります。

主要メトリクス

日本語実際のメトリクス参考値 
リクエスト数RequestCount増減
エラーレートHTTPCode_ELB_4XX_Count, HTTPCode_ELB_5XX_Count増加
待機時間Latency長さ

アラートの設定理由

リクエスト数

トラフィックの増減を把握し、キャパシティプランニングが可能です。例えば、RequestCountの異常な変動を検知した際にアラートを設定します。

エラーレート

バックエンドの問題や設定ミスを示します。例えば、HTTPCode_ELB_4XX_CountやHTTPCode_ELB_5XX_Countが増加した場合にアラートを設定します。

待機時間

ユーザーエクスペリエンスに直結し、パフォーマンスの問題を示すことがあります。例えば、Latencyが長くなった場合にアラートを設定します。

ECSの監視とアラート

ECS(Elastic Container Service)の監視とアラート設定は、コンテナ化されたアプリケーションのパフォーマンスと可用性を維持するために重要です。ECSの主要メトリクスを監視することで、リソースの最適化や潜在的な問題の早期検出が可能になります。このアラートにより、システムの健全性を保ち、迅速な対応が可能となります。

主要メトリクス

日本語実際のメトリクス参考値 
CPU使用率CPUUtilization80%超
メモリ使用率MemoryUtilization80%超
タスク数RunningTasksCount増減

アラートの設定理由

CPU使用率とメモリ使用率

コンテナのパフォーマンス問題を特定し、リソースの調整が可能です。例えば、CPUUtilizationやMemoryUtilizationが80%を超えた場合にアラートを設定します。

タスク数

スケーリングの要件やアプリケーションの負荷を把握するのに役立ちます。例えば、RunningTasksCountが急増または急減した場合にアラートを設定します。

アラートの設定方法

アラートを設定することで、リソースの異常を早期に検知し、迅速に対応することができます。ここでは、AWS CLIを使ったアラート設定の手順を説明します。

  1. メトリクスの選択 監視したいメトリクスを選びます。たとえば、EC2インスタンスのCPU使用率などが対象です。

  2. しきい値の設定 アラートを発生させるしきい値を設定します。たとえば、CPU使用率が80%を超えた場合です。

  3. 通知方法の設定 しきい値に達したときに通知する方法を設定します。EメールやSNSトピックを使用します。

  4. AWS CLIでアラームの作成 以下のコマンドを使用して、アラームを作成します。

    aws cloudwatch put-metric-alarm \
        --alarm-name "HighCPUUtilization" \
        --alarm-description "Alarm when CPU exceeds 80%" \
        --metric-name CPUUtilization \
        --namespace AWS/EC2 \
        --statistic Average \
        --period 300 \
        --threshold 80 \
        --comparison-operator GreaterThanOrEqualToThreshold \
        --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
        --evaluation-periods 1 \
        --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:MyTopic \
        --unit Percent

    このコマンドは、CPU使用率が80%を超えたときにSNSトピックMyTopicに通知を送るアラームを作成します。

AWS CLIを使ったアラーム設定の例

  1. SNSトピックの作成 まず、通知を送るSNSトピックを作成します。

    aws sns create-topic --name MyTopic

    このコマンドでSNSトピックMyTopicが作成されます。

  2. SNSトピックへのサブスクリプション 次に、SNSトピックに通知を受け取るEメールアドレスを登録します。

    aws sns subscribe --topic-arn arn:aws:sns:ap-northeast-1:123456789012:MyTopic --protocol email --notification-endpoint example@example.com

    これで、example@example.comに通知が送られるようになります。

  3. CloudWatchアラームの作成 最後に、CloudWatchアラームを作成します。

    aws cloudwatch put-metric-alarm \
        --alarm-name "HighCPUUtilization" \
        --alarm-description "Alarm when CPU exceeds 80%" \
        --metric-name CPUUtilization \
        --namespace AWS/EC2 \
        --statistic Average \
        --period 300 \
        --threshold 80 \
        --comparison-operator GreaterThanOrEqualToThreshold \
        --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
        --evaluation-periods 1 \
        --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:MyTopic \
        --unit Percent

これで、CPU使用率が80%を超えた場合に指定したEメールアドレスに通知が送られるアラームが設定されました。

まとめ

この記事では、AWSリソースの監視とアラート設定の重要性について学びました。適切なメトリクスを選び、しきい値を設定することで、システムの健全性を維持し、パフォーマンスの最適化を図る方法を理解しました。これにより、問題を早期に発見し、迅速に対処することが可能になります。定期的にアラート設定を見直し、ベストプラクティスを守ることで、システムの信頼性を向上させることができます。

皆さんもこの記事を参考にして、AWSリソースの監視とアラート設定を実践し、システムの健全性を保ち続けてください。

参考資料

【番外編】USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話

IT未経験者必見 USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話

プログラミング塾に半年通えば、一人前になれると思っているあなた。それ、勘違いですよ。「なぜ間違いなの?」「正しい勉強法とは何なの?」ITを学び始める全ての人に知って欲しい。そう思って書きました。是非読んでみてください。

「フリーランスエンジニア」

近年やっと世間に浸透した言葉だ。ひと昔まえ、終身雇用は当たり前で、大企業に就職することは一種のステータスだった。しかし、そんな時代も終わり「優秀な人材は転職する」ことが当たり前の時代となる。フリーランスエンジニアに高価値が付く現在、ネットを見ると「未経験でも年収400万以上」などと書いてある。これに釣られて、多くの人がフリーランスになろうとITの世界に入ってきている。私もその中の1人だ。数年前、USBも知らない状態からITの世界に没入し、そこから約2年間、毎日勉学を行なった。他人の何十倍も努力した。そして、企業研修やIT塾で数多くの受講生の指導経験も得た。そこで私は、伸びるエンジニアとそうでないエンジニアをたくさん見てきた。そして、稼げるエンジニア、稼げないエンジニアを見てきた。

「成功する人とそうでない人の違いは何か?」

私が出した答えは、「量産型エンジニアか否か」である。今のエンジニア市場には、量産型エンジニアが溢れている!!ここでの量産型エンジニアの定義は以下の通りである。

比較的簡単に学習可能なWebフレームワーク(WordPress, Rails)やPython等の知識はあるが、ITの基本概念を理解していないため、単調な作業しかこなすことができないエンジニアのこと。

多くの人がフリーランスエンジニアを目指す時代に中途半端な知識や技術力でこの世界に飛び込むと返って過酷な労働条件で働くことになる。そこで、エンジニアを目指すあなたがどう学習していくべきかを私の経験を交えて書こうと思った。続きはこちらから、、、、

note記事3000いいね超えの殿堂記事 今すぐ読む

エンベーダー編集部

エンベーダーは、ITスクールRareTECHのインフラ学習教材として誕生しました。 「遊びながらインフラエンジニアへ」をコンセプトに、インフラへの学習ハードルを下げるツールとして運営されています。

RareTECH 無料体験授業開催中! オンラインにて実施中! Top10%のエンジニアになる秘訣を伝授します! RareTECH講師への質疑応答可

関連記事