Amazon Web Services（AWS）が 2006 年に登場してから、システムを構築、自動化、およびスケーリングするために企業によってサービスとしてのインフラストラクチャ（IaaS）が積極的に採用されるようになりました。AWS は長年にわたり、基本的なコンピューティングリソース（EC2 や S3 など）以外にも、CloudWatch のような AWS を監視するツールや、Amazon RDS のようなデータベースを管理するためのマネージドインフラストラクチャサービスを展開してきました。また、AWS はサービスも拡張し、ユーザーが AWS Lambda の形で、サーバーレスコンピューティングのような新しいテクノロジパラダイムを利用できるようにしています。AWS のエコシステムは拡大を続けており、開発者と運用チームはインフラストラクチャをクラウドに迅速に展開して拡張できますが、一方で、これらのサービスのリアルタイムヘルスとパフォーマンスを追跡することがこれまで以上に困難になっています。
AWS 環境全体のメトリクスを 1 か所に集約することで、システムの規模が拡大したり進化したりする場合でも、動的なサービスを完全に可視化し、潜在的な問題を効率的に調査できます。このブログ記事では、Amazon EC2、EBS、ELB、RDS、ElastiCache など、広く使用されているサービスを他のインフラストラクチャやアプリケーションとの詳細な関係性を考慮しながら監視するのに役立ついくつかの重要なメトリクスについて説明します。また、Amazon Lambda と、アプリケーションサーバーにシステムレベルのデータがない場合に集中的に確認する必要があるメトリクスについても簡単に説明します。各セクションには［参考情報］セクションがあります。このセクションから、この記事で取り上げる各 AWS サービスについて、より包括的な監視戦略を参照できます。
Amazon EC2
Amazon EC2 とは？
Amazon Elastic Compute Cloud（EC2）を使用すると、インフラストラクチャーをオンデマンドで効率的にプロビジョニングおよびスケーリングできます。EC2 インスタンスは仮想サーバーであり、さまざまなレベルの CPU、メモリ、ストレージ、およびネットワークキャパシティを提供するさまざまなインスタンスのタイプを利用できます。EC2 インスタンスは、Auto Scaling や Elastic Load Balancing などの他の AWS サービスとシームレスに統合されます。コンテナの利用が広がるにつれて、EC2 は、Amazon の Elastic Container Service（ECS）および Elastic Container Service for Kubernetes（EKS）を介して、アプリケーションのオーケストレーションに対するニーズに応えることができるように進化してきました。
監視するメトリクス
お客様のアプリケーションのサポートをするために EC2 インスタンスを展開してスケーリングする場合、インフラストラクチャーが正しく機能していることを確認するために、EC2 インスタンスを継続的にモニターする必要があります。次のメトリクスは、インスタンスのパフォーマンスと可用性を把握するための基盤になります。
CPUUtilization
CPUUtilization は、EC2 インスタンスによって現在使用されているコンピュートユニットの割合を計測します。アプリケーションのパフォーマンスが低下しており、さらに CPU の使用率が高い状態が続いている場合（ネットワーク、ディスク I / O、またはメモリの急増は発生していない）、CPU がリソースのボトルネックになっている恐れがあります。EC2 インスタンス全体の CPU 使用率をトラックすると、インスタンスがワークロードに対して過大または過小であるかどうかを判断するのにも役立ちます。
DiskReadBytes と DiskWriteBytes
このメトリクスの組み合わせは、EC2 インスタンスに接続されているインスタンスストア（「エフェメラル」）のボリュームに対して読み書きされるバイト数を計測します。これらのメトリクスには、C5 および M5 インスタンスタイプに接続されているすべての EBS ボリュームの I / O データも含まれます。他のインスタンスタイプの場合は、EBS から直接ディスク I / O メトリクスにアクセスする必要があります。このメトリクスを監視すると、アプリケーションレベルの問題を特定できるようになります。たとえば、大量のデータが常にディスクから読み取られていることがわかった場合、キャッシュレイヤーを追加してアプリケーションのパフォーマンスを向上できます。
StatusCheck Failed
CloudWatch は、1 分間に 2 回ステータスの合否チェックを実行します。1 回目のチェックでは各 EC2 インスタンスの可用性をクエリし、2 回目のチェックではインスタンスをホスティングしているシステムに関する情報を報告します。これらのチェックにより、EC2 のヘルスが可視化され、問題の原因がインスタンス自体にあるのかインスタンスをサポートするバックエンドのインフラストラクチャーにあるのかを判断できます。
参考資料
ここで説明しているメトリクスの監視は、EC2 インスタンスのヘルスとパフォーマンスを追跡するときの優れた開始点になります。ただし、ニーズを満たすために動的な AWS インフラストラクチャーを拡大および縮小する場合、EC2 インスタンスとこれらのインスタンスを利用するアプリケーションやサービスについての詳細なインサイトを取得するためには、これらのメトリクスを自動的に収集・視覚化して、アラートを通知する必要があります。
Datadog を使用して EC2 の監視を開始するために必要なすべての手順を網羅した、AWS EC2 の監視の詳細については、次の 3 部構成のガイドを参照してください。
- EC2 を監視するための重要なメトリクス
- EC2 メトリクスの収集方法
- Datadog を使用して EC2 インスタンスを監視する方法
Amazon EBS
Amazon EBS とは？
Amazon Elastic Block Store（EBS）は、EC2 インスタンスにブロックレベルの永続的なストレージを提供します。EBS ボリュームには、ソリッドステートドライブ（SSD）とハードディスクドライブ（HDD）の 2 種類があります。EBS ボリュームは、EC2 インスタンスに高信頼性で長期的なストレージソリューションを提供しているため、多くの AWS 環境において重要なレイヤーになっています。EBS を使用すると、ボリュームのスナップショットを S3 バケットに保存でき、アプリケーションインフラストラクチャをスケールアウトする必要があるときにはいつでも AWS リージョン間でレプリカをコピーおよび転送できます。
監視するメトリクス
AWS EBS を監視する場合、以下の重要なメトリクスがボリュームの使用状況とパフォーマンスをトラックするのに役立ちます。
VolumeReadBytes と VolumeWriteBytes
このメトリクスの組み合わせは、一定の時間内にボリューム間で転送されたバイト数を測定します。さまざまな集計方法を通じてこのメトリクスを送信できます。たとえば、これらのメトリクスの合計を読み込んで、特定の期間に読み取りおよび書き込みされた合計バイト数をトラックしたり、各 I / O 操作の平均サイズをクエリできます。これらの情報は EBS ワークロードをプロファイリングする上で重要な基本情報になります。C5 および M5 インスタンスに接続されているボリュームの場合、操作ごとではなく、要求された期間に読み取りおよび書き込みされた平均バイト数のみをクエリできます。
VolumeTotalReadTime および VolumeTotalWriteTime
これらのメトリクスは、クエリ対象の期間にわたるすべての読み取りおよび書き込み操作を完了するのに要した合計時間を秒単位で報告します。レイテンシーの増加が見られる場合は、これらのメトリクスをスループットメトリクスと相関させて、EBS ボリュームが IOPS の制限に達しているかどうかを判断できます。
VolumeQueueLength
ボリュームキューの長さ、つまり実行を待機しているキューに入れられた操作の数によって、EBS ボリュームのワークロードに対するインサイトを取得できます。SSD ボリュームでは使用可能な 500 IOPS ごとに 1 つ、または HDD ボリュームでは 1MiB のシーケンシャル操作を処理する場合は少なくとも 4 つのキュー長を目標とすることを AWS は推奨しています。ただし、長時間にわたってボリュームのキュー長が長くなると、レイテンシーが増大する恐れがあります。ボリュームのキュー長を IOPS やボリュームの読み取り/書き込み時間などの他のメトリクスと相関させて、ボリュームに十分な IOPS がプロビジョニングされており、ワークロードを管理できるかどうかを確認できます。
VolumeIdleTime
VolumeIdleTime は、ボリュームが非アクティブになっている時間を秒単位で計測します。このメトリクスを監視して、プロビジョニングされたリソースを確実に使用できます。アイドル時間が急増し、I / O レベルが低下した場合は、アプリケーションで問題が発生しており、ボリュームにリクエストを送信できなくなっている恐れがあります。
VolumeStatus
AWS は、5 分ごとにステータスをチェックすることで、EBS ボリュームのヘルスを追跡します。VolumeStatus は、すべてのチェックにパスした場合は「OK」を、チェックが失敗した場合は「障害が発生」したことを表示し、完了しなかったチェックがある場合には「データ不足」を表示します。プロビジョニングされた IOPS ボリュームは、予測されるよりもパフォーマンスが低い場合、警告ステータスを送信することもあります。AWS は、ボリュームのデータに矛盾がある可能性があることを検出した場合、そのボリュームに対する I / O 操作を自動的に無効にし、次のステータスチェックはデフォルトで失敗します。AutoEnableIO ボリューム属性を構成することで、これらのボリュームの I / O を手動で再度有効にできます。再度有効にすると、次のステータスチェックにはパスできますが、AWS は問題を検出したことを示すイベントを引き続き記録します。
参考資料
Amazon CloudWatch から入手可能な上記のメトリクスによって、EBS ボリュームの使用状況とパフォーマンスをトラックできますが、これらの情報は全体像の一部にすぎません。たとえば、ディスク使用量などのシステムレベルのメトリクスは CloudWatch からは入手できないため、別の方法で収集しなければなりません。EBS ボリュームに関するインサイトを提供できる他のメトリクスと収集方法については、Datadog の監視ガイドを参照してください。
Amazon ELB
Amazon ELB とは？
Amazon Elastic Load Balancing（ELB）は、アプリケーションのトラフィックを複数の EC2 インスタンスまたはアベイラビリティゾーンに分散します。ELB は、EC2 インスタンスのヘルスを継続的にチェックし、異常なインスタンスから自動的にリクエストをルーティングすることによって、アプリケーションのフォールトトレランスとヘルスを向上します。ELB と Auto Scaling を組み合わせることで、インフラストラクチャーはワークロードの変化やピーク時のトラフィックニーズにも確実に対応できます。
WS Elastic Load Balancing（ELB）は、さまざまなユースケースに対応するためにいくつかのタイプのロードバランサー（例：クラシックロードバランサー、アプリケーションロードバランサー、ネットワークロードバランサー）を提供しています。このブログでは、特にクラシック ELB ロードバランサーを監視するときに重要なメトリクスを中心に説明します。
監視するメトリクス
ELB はアプリケーションユーザーにとって最初のコンタクトポイントとなるため、重要な ELB パフォーマンスメトリクスに注意を向けることは、エンドユーザーエクスペリエンスを向上させる上で重要です。以下のメトリクスを使用して、全体的な ELB のパフォーマンスとヘルスをトラックできます。
RequestCount
このメトリクスは、クエリ期間中に ELB によって処理されたリクエストの数を測定します。このメトリクスが大幅に変動する場合、AWS または DNS の潜在的な問題の兆候である恐れがあります。Auto Scaling を使用していない場合は、EC2 フリートを拡張または縮小する必要があるかを判断するのにも役立ちます。
SurgeQueueLength
SurgeQueueLength は、利用可能なコンピュートリソースに配布されるのを待機しているリクエストの数を測定します。キューに入れられるリクエスト数が多いと、待ち時間が長くなる恐れがあります。この制限値に達すると、それ以降に着信するリクエストはすべてドロップされるため、キューの容量（1,024 件のリクエスト）に達しないように、このメトリクスの最大値は重点的に監視する必要があります。
HTTPCode_ELB_5XX
このメトリクスは、フロントエンド接続とバックエンド接続の両方に HTTP / HTTPS プロトコルを使用して ELB リスナーを構成している場合にのみ使用できます。クエリ期間中にロードバランサーによって返されたサーバーエラーの数を追跡します。Bad Gateway（502）、Service Unavailable（503）、Gateway Timeout（504）などの HTTP 5XX サーバーエラーは調査が必要です。たとえば、Gateway Timeout（504）のエラーが応答のレイテンシーの問題と一緒に増加している場合は、バックエンドをスケールアップしたり、アイドルタイムアウトを増加したりして、より長い時間接続を開いたままにしておくことができます。
Latency
このメトリクスは、ロードバランサー自体からのレイテンシーではなく、バックエンドインスタンスからのレイテンシーを測定します。HTTP リスナーを使用している場合、このメトリクスは、バックエンドインスタンスがロードバランサーによって送信されたリクエストへの応答を開始するのにかかる合計時間（秒単位）を計測します。TCP リスナーの場合、このメトリクスはロードバランサーが登録済みインスタンスに接続するのにかかる秒数を測定します。いずれのリスナーを使用している場合でも、このメトリクスを使用して要求の処理時間の増加をトラブルシューティングできます。レイテンシーが長い場合は、ネットワーク接続、バックエンドホスト、または Web サーバーの依存関係に問題があり、アプリケーションのパフォーマンスに悪影響を及ぼす恐れがあります。
HealthyHostCount/UnHealthyHostCount
ELB はこれらのヘルスチェックを使用して、どのバックエンドインスタンスのヘルスが適正であり、要求を処理できるかを判断します。インスタンスが連続して特定の数のヘルスチェックに失敗する場合（ヘルスチェック構成で不正なヘルスのしきい値で指定）、ELB は自動的にそのインスタンスからトラフィックを切り離し、利用可能な正常なインスタンスにルーティングします。HealthyHostCount を SurgeQueueLength や Latency などの他のメトリクスと相関させて、各アベイラビリティゾーンでトラフィックを処理できる十分で適切なインスタンスを確保し、サービスの停止を回避できます。
参考資料
これらの AWS ELB メトリクスを監視すると、アプリケーションのパフォーマンスとアップタイムを向上できます。ただし、ドロップしたリクエストの数を測定する SpilloverCount などの他の多くのメトリクスも、ユーザーリクエストに対して迅速に応答時間を確保するために活用できます。ELB の監視を包括的に捉えることができる Datadog の次のブログを参照してください。
AWS インフラストラクチャーの拡張
Amazon EC2、EBS、および ELB はインフラストラクチャーの中核となる構成要素を提供していますが、企業の IT チームが複雑化するクラウド環境を管理および自動化するための新しい方法を提供するように AWS エコシステムは進化を続けています。Amazon Relational Database Service（RDS）と Amazon ElastiCache は、データベースやキャッシュエンジンなど、これまで手動で管理していたインフラストラクチャーをユーザーが簡単に移行/展開できるようにするサービスの例です。次の 2 つのセクションでは、これらのサービスを使用する場合に、AWS 環境を監視するための基本的なメトリクスについて説明します。
Amazon RDS
Amazon RDS とは？
Amazon Relational Database Service（RDS）を使用すると、ユーザーはクラウドでリレーショナルデータベース管理システム（RDBMS）をすばやくプロビジョニングして運用できます。Amazon RDS は、いくつかのデータベースインスタンスタイプの他に、広く使用されているデータベースエンジン（MySQL、Oracle、Microsoft SQL Server、PostgreSQL、および MariaDB）に展開できます。また、RDS 向けに特別に構築されたデータベースで MySQL と PostgreSQL と互換性のある Amazon Aurora を利用することもできます。
監視するメトリクス
RDS は、非常にスケーラブルで耐性の高いリレーショナルデータベースのプロビジョニングと管理の作業の多くを自動化しますが、AWS を監視するときの課題も同時に発生します。RDS の環境を拡張する場合、次に示す主要なメトリクスを確認して、そのヘルスとパフォーマンスを監視できます。以下で説明しているメトリクスの一部は、使用されているデータベースエンジンには適用できない場合があります。詳細については、 RDS のドキュメントを参照してください。
FreeStorageSpace
このメトリクスは、各データベースインスタンスで使用可能で割り当て済みストレージの容量を測定します。このメトリクスを監視すると、データベースインスタンスのストレージ容量が不足しているかどうかを検出できます。ストレージが不足すると、データが失われ、アプリケーションに重大な問題が生じる恐れがあります。このメトリクスを注視すると、インスタンスが STORAGE_FULL の状態（この時点でインスタンスに接続できなくなります）になる前にインスタンスのストレージパラメータを増加できます。
DatabaseConnections
DatabaseConnections は、指定された収集期間に開いたデータベース接続の数をトラックします。このメトリクスを使用して、現在のデータベースアクティビティを測定し、データベースエンジンおよびインスタンスタイプに応じて、max_connections パラメータで決定された接続数の上限に達することを回避できます。接続数の上限に達すると、RDS インスタンスは新しい接続を拒否し、クライアントにエラーを返します。
ReadLatency と WriteLatency
このメトリクスの組み合わせは、各ディスクの I / O リクエストが完了するのにかかる平均秒数を測定します。ディスクの待ち時間を測定することにより、データベースのパフォーマンスに影響を与えるリソースの制限を特定および調査するのに役立ちます。
DiskQueueDepth
DiskQueueDepth は、ディスクアクセスを待機しているキューに入れられた I / O リクエストの数を計測します。アプリケーションのパフォーマンスを低下させる可能性があるストレージレイヤーでのボトルネックを検出するために、このメトリクスをレイテンシーと一緒に監視する必要があります。
参考資料
Amazon RDS データベースのパフォーマンスのインサイトを取得するには、AWS の監視に繊細なアプローチが必要です。RDS メトリクスを確認し、データベースエンジンから直接クエリされたメトリクスでそれらを補完する必要があります。以下のブログでは、MySQL、PostgreSQL、および Amazon Aurora で RDS を監視するためのベストプラクティスについて詳しく説明します。
Amazon ElastiCache
Amazon ElastiCache とは？
Amazon ElastiCache は、ホスト型および管理型のインメモリキャッシュサービスです。ElastiCache は、バックエンドにクエリすることなく、アプリケーションがキャッシュから頻繁に要求されるファイルにすばやくアクセスできるようにすることで、読み取り集中型ワークロードのスループットとレイテンシーを大幅に改善します。ElastiCache を使用すると、ユーザーはお好きなキャッシュエンジン（Redis または Memcached）を柔軟に選択できます。
監視するメトリクス
ElastiCache がアプリケーションのスピードアップとユーザーエクスペリエンスの向上を実現するためには、CloudWatch のパフォーマンスメトリクスを継続的にトラックする必要があります。そして、キャシュエンジンから直接クエリするよりも高い粒度のメトリクスで補完する必要があります（下記の「参考情報」セクションに記載されているブログで説明しています）。次のセクションでは、ElastiCache が Redis を実行しているか Memcached を実行しているかにかかわらず、ElastiCache に適用されるいくつかの重要なメトリクスについて説明します。
Current connections
Current connections は、現在キャッシュに接続しているクライアントの数を計測します。このメトリクスが急激に低下する場合、さらに調査が必要なインフラストラクチャーの障害を示唆している恐れがあります。このメトリクスを監視して、接続数の上限と比較します。そして上限に達する前に必要に応じてスケールアップする必要があります（この時点を過ぎると、新しい接続は拒否されます）。Redis または Memcached のどちらを使用しているかにかかわらず、CurrConnections メトリクスを使用して CloudWatch から、またはキャッシュエンジンから直接このデータを収集できます。
処理された Set および Get コマンドの数
このメトリクスの組み合わせは、キャッシュエンジンによって処理された Set および Get コマンドの数を測定します。これらのスループットメトリクスをキャッシュ使用率の重要な指標として使用し、レイテンシーに関する問題の診断に役立てる必要があります。
CloudWatch は、Redis 用の SetTypeCmds / GetTypeCmds メトリクス、および Memcached 用の CmdSet / CmdGet メトリクスを通じてこれらのメトリクスを提供します。Memcached からは直接 Get および Set コマンドの数をトラックするメトリクスをクエリすることもできますが、Redis からは取得できません。
キャッシュのヒットとミス
このメトリクスの組み合わせは、ヒット率、つまり成功したルックアップの割合を算出するのに役立ちます。これは、キャッシュ効率の基本的な指標です。ヒット率が低い場合は、ワークロードに必要なデータを保持するキャッシュのサイズが小さすぎること、およびキャッシュサイズを増やす必要があることを示している可能性があります。
これらのメトリクスは、Redis の CacheHits / CacheMisses メトリクス、および Memcached の GetHits / GetMisses メトリクスを使用して CloudWatch から収集できます。Redis または Memcached のどちらを使用している場合でも、キャッシュエンジンから直接収集できます。
Evictions
このメトリクスは、新しい書き込み用にスペースを空けるため、キャッシュから削除されたアイテムの数をトラックします。Eviction の数が増えている場合は、より大きなノードタイプに移行するか、ノードを追加することでキャッシュをスケールアップする必要があります（Memcached を使用している場合）。
Redis と Memcached のどちらも場合も、Evictions メトリクスを使用して、CloudWatch からこのメトリクスを収集できます。どちらのキャッシュエンジンからも、このメトリクスに直接アクセスできます。
SwapUsage
SwapUsageは、メモリ内にあるべきデータを保持するために使用されるディスクの量を測定します。スワップの使用量が多いとインメモリキャッシュの目的が損なわれ、アプリケーションのパフォーマンスが大幅に低下する可能性があるため、このメトリクスは注意してトラックする必要があります。
Redis と Memcached のどちらも場合も、SwapUsage メトリクスを使用して、CloudWatch からこのメトリクスを収集できます。
参考資料
これらのパフォーマンスとリソース使用率のメトリクスを理解することで、キャッシュが正しく機能していることを確認できますが、キャッシュエンジンから直接クエリされたデータによって、CloudWatch のメトリクスを補完する必要があります。以下のブログでは、ElastiCache とキャッシュエンジンのネイティブメトリクスを包括的に監視する方法を説明しています。
AWS 監視の新しい考え方
長年にわたり、AWS は基本的なクラウドコンピューティングサービスの普及やマネージドインフラストラクチャーサービスの拡大と利便性の向上において主導的な役割を果たしてきました。サーバーレスコンピューティングのような新しいテクノロジーパラダイムは、クラウドコンピューティングリソースの構成と管理の複雑さを取り除き、開発者はバックエンドインフラストラクチャーを管理することなく、コードの実行に集中できます。
2014年に、Amazon はサーバーレスコンピューティングのためのサービスとして Functions-as-a-Service（FaaS）である AWS Lambda をリリースしました。このアプローチでアプリケーションを展開するには、AWS サービスを監視する方法を刷新しなければなりません。従来の手法はシステムレベルのメトリクスの追跡が中心でしたが、サーバーレス監視では機能よりもパフォーマンスと使用状況のデータが重要となります。次のセクションでは、AWS 監視のあり方を変えるために欠かせない、重要な概念とメトリクスについて説明します。
AWS Lambda
AWS Lambda とは？
AWS Lambda は、バックエンドのサーバーリソースをプロビジョニングおよび管理することなく、コードを実行できるようにするイベントベースのコンピュートサービスです。AWS イベントまたは AWS API Gateway を介した API コールに応答して実行するように Lambda 関数を設定できます。また AWS ユーザーインターフェースから Lambda 関数を手動で呼び出して実行することもできます。また、Lambda 関数は、定期的に実行するようにスケジュールすることもできます。Lambda は、従来の AWS インフラストラクチャーに代わるソリューションとして提供されていますが、ELB、SES、S3 などの広く利用されている AWS サービスとも統合されています。
監視するメトリクス
AWS Lambda を利用する主な利点の 1 つは、非常に可用性に優れるコンピュートリソースでコードを実行できることです。これにより、さまざまなワークロードのリクエストを満たすためにインフラストラクチャのプロビジョニングと拡張に時間を費やす必要がなくなります。これにより、システムレベルのデータにアクセスできなくなりますが、Lambda の使用状況とパフォーマンスを監視するために使用できる標準的なメトリクスがいくつかあります。
Duration
このメトリクスは、関数の実行にかかる時間をミリ秒単位で測定します。このメトリクスは呼び出しから終了までの操作全体を測定するので、これを使用して、従来のアプリケーションのレイテンシーメトリクスと同様にパフォーマンスを測定できます。
Errors
このメトリクスは、エラーになった Lambda の実行数をトラックします。エラー率が上昇した場合は、Lambda ログを確認して調べることができます。これらのログから、問題の正確な原因（メモリ不足の例外、タイムアウト、アクセス許可エラーなど）を特定できる場合があります。
Invocations
Invocations は、イベントまたは API 呼び出しリクエストに応答して、失敗したか成功したかにかかわらず、関数が実行された回数を測定します。このメトリクスは、Lambda の使用状況を測定し、予測コストを算出するのに役立ちます。
Concurrent executions
このメトリクスは、アカウント内のすべての関数の同時実行の合計数を示します。関数レベルの同時実行の上限数を設定している場合は、それらの個々の関数について、このメトリクスをクエリできます。デフォルトでは、同時実行の上限はリージョンごとに 1,000 で設定されています。このメトリクスを監視することで、個々の Lambda 関数の同時実行の上限を適切に設定して、1 つの関数の呼び出し数が急増しても、他の関数がワークロードの処理に必要なリソースにアクセスできなくなることを防止できます。このメトリクスは期間によって集計され、平均値がクエリされ、関数の規模と関連コストが決定されます。
Throttles
このメトリクスは、同時実行の上限を超えたためにスロットル（抑制）された呼び出し試行の数を示します。このメトリクスを追跡することで、Lambda のワークロードに合わせて同時実行の上限を調整できます。たとえばスロットル回数が多い場合は、失敗する試行回数を減らすために、同時実行の上限を増やす必要があることを示唆している場合があります。
参考資料
上記で説明したパフォーマンスと使用状況のメトリクスに加えて、Lambda 関数のワークロードとパフォーマンスについて具体的なインサイトを提供する詳細な Lambda メトリクスも収集する必要があります。Lambda 関数の設定、サーバーレスコンピューティング用のアプリケーションの計測、および Datadog を使用した AWS Lambda の監視についての詳細は、以下の記事をご覧ください。
AWS 監視への動的なアプローチ
このブログでは、AWS インフラストラクチャーの進化の軌跡と、さまざまな AWS サービスを実行している場合に、アプリケーションのパフォーマンスを最高の状態で維持するために監視するべき主要なメトリクスについて説明しました。AWS の監視戦略を自動化してスケーラブルにすることで、ホストやサービスが動的かつリアルタイムで拡張および更新されても、インフラストラクチャーの状況を適切に把握できます。[AWS サービス][aws-integration]のすべての製品を含む、 700以上のテクノロジーに対応する Datadog のインテグレーションにより、お使いの環境が拡張または進化しても完全に視覚化できます。
Datadog アカウントをお持ちではない場合は、14 日間の無料トライアルにサインアップいただき、今すぐにお使いのクラウドインフラストラクチャーとアプリケーションの監視を開始いただけます。
