以下は私が個人的にグラフ化している、メトリクスの設定値です。
発生した障害の内容を確認する
- クラウドウォッチアラーム等と組み合わせることで、障害、または障害の前兆を検知し、被害が拡大する前に行動をとることが求められる項目
APIGateway
5XXError
- 指定された期間に取得されたサーバー側エラーの数。
- Sum 統計は、このメトリクス、つまり、指定された期間内の 5XXError エラーの合計数を表します。
- Average 統計は、5XXError のエラー率、つまり、5XXError エラーの合計数をその期間のリクエストの合計数で割ったものです。
- 分母は Count メトリクス (下記) に対応します。
ポイント
- 5XXのエラーは意図的に発生させていない可能性が非常に高い。
CloudWwatchAlarm等を使って全ての原因を調査し、原因の除去を検討する覚悟でいたべき。
Lambda
Errors
- 関数エラーが発生した呼び出しの数。
- 関数エラーには、コードによってスローされた例外と、Lambda ランタイムによってスローされた例外が含まれます。
- ランタイムは、タイムアウトや設定エラーなどの問題に対してエラーを返します。
- エラー率を計算するには、Errors の値を Invocations の値で割ります。
ポイント
- コードにより例外がスローされた場合、及びタイムアウトが発生した場合は
コード上のバグ、システム的なバグ、仕様的なバグを疑う必要がる。
Throttles
- スロットリングされた呼び出しリクエストの数。
- すべての関数インスタンスがリクエストを処理していて、スケールアップできる同時実行がない場合、Lambda は TooManyRequestsException を使用して追加のリクエストを拒否します。
- スロットリングされたリクエストやその他の呼び出しエラーは、Invocations または Errors としてカウントされません。
ポイント
- 事前に
ConcurrentExecutionsを確認しておくことで前兆を検知することが可能な場合がある。 - Lambdaの同時起動数の上限緩和申請という選択肢があるかもしれない。
DynamoDB
ReadThrottleEvents/WriteThrottleEvents
ポイント
- 既に飽和状態であることを示す。
- システム、設定値、内部処理シーケンス等の見直しが必要
ThrottledRequests
ポイント
- 既に飽和状態であることを示す。
- システム、設定値、内部処理シーケンス等の見直しが必要
SystemErrors
ポイント
- DynamoDBの使い方が悪い可能性もないわけではない？
UserErrors
- 指定された期間中に HTTP 400 ステータスコードを生成する、DynamoDB または DynamoDB ストリーム へのリクエスト。
- 通常、HTTP 400 は、パラメータの無効な組み合わせ、存在しないテーブルの更新の試み、不正なリクエスト署名などのクライアント側エラーを示します。
ポイント
- DynamoDBの使い方が悪い可能性が非常に高いです。
RDS
障害の気配を検知する
- クラウドウォッチアラーム等と組み合わせることで、障害、または障害の前兆を検知し、被害が拡大する前に行動をとることが求められる項目
APIGateway
Latency
- API Gateway がクライアントからリクエストを受け取ってから、クライアントにレスポンスを返すまでの時間。レイテンシーには、統合のレイテンシーおよびその他の API Gateway のオーバーヘッドが含まれます。
ポイント
- APIGatewayのタイムアウトは30秒です。内部処理時間が想定以上に長くAPIGatewayでタイムアウトが発生した場合、APIGatewayはクライアントに対し504を返却します。
Latencyを確認することで2XX（正常動作）と504（タイムアウト）の間に存在する5XXエラーの前兆や見落とされた異常動作を検知することができるかもしれません。Max値を確認するのが良いでしょう。
Lambda
ConcurrentExecutions
- イベントを処理している関数インスタンスの数。この数値がリージョンの同時実行クォータ、または関数で設定した予約済み同時実行制限に達すると、追加の呼び出しリクエストがスロットリングされます。
ポイント
- Lambdaの同時起動数の上限は初期設定で
1000です。上限を超えた処理はスロットリング（エラー）されます。 - つまり起動数の上限設定に対し、どの程度の余裕があるかを観察しておく必要があります。
Max値を確認するのが良いでしょう。
Duration
- 関数コードがイベントの処理に費やす時間。
- 関数のインスタンスによって処理された最初のイベントの場合、これには初期化時間が含まれます。
- 呼び出しの請求期間は、最も近い 100 ミリ秒に切り上げられた Duration の値です。
ポイント
- 各Lambdaに設定されているタイムアウト時間との関係を確認することで、障害の可能性を事前に検知することができるかもしれない。
DynamoDB
RDS
CPUUtilization
- CPU 使用率 (%)
ポイント
- CPU使用率が100（％）に張り付いた状態は、DBとして機能しなくなっている可能性が高いです。
- 付加状況の飽和を事前に検知し、対策を打つ必要があります。
BurstBalance
ポイント
- バースト残量 (%)が0(%)になると、各種Read/Write等の応答速度（処理速度）が著しく低下する可能性があります。
- バースト残量の枯渇を事前に検知し、対策を打つ必要があります。
BinLogDiskUsage
- バイナリログのディスク使用状況 (MB)
- プライマリでバイナリログが占有するディスク領域の量。MySQL リードレプリカに適用されます。
FreeableMemory
- 解放可能なメモリ (MB)
- 使用可能な RAM の容量。
- MariaDB、MySQL、Oracle、および PostgreSQL DB インスタンスの場合、このメトリクスは /proc/meminfo の MemAvailable フィールドの値を報告します。
FreeStorageSpace
- 空きストレージ領域 (MB)
- 使用可能なストレージ領域の容量。
パフォーマンスの改善を検討する
異常が発生していないことを確認するへの対応がパフォーマンスの改善を検討するに対しても効果を発揮することは言うまでもないが、その手前にも改善すべきポイントを発見するためのがある。
APIGateway
4XXError
- 指定された期間に取得されたクライアント側エラーの数。
- Sum 統計は、このメトリクス、つまり、指定された期間内の 4XXError エラーの合計数を表します。
- Average 統計は、4XXError のエラー率、つまり、4XXError エラーの合計数をその期間のリクエストの合計数で割ったものです。分母は Count メトリクス (下記) に対応します。
ポイント
- 4XXのエラーはクライアント側に原因があることがほとんどであるが、なぜクライアントが4XXエラーを出しているかを考えることがクライアントに対するユーザビリティー向上につながる可能性がある。
- 改善ポイントを探るためには、個々の4XXエラーの内容に目を向ける必要がある。
- 改善効果を定量的に評価するためには
Average統計が役立つ可能性がある。
Latency
- API Gateway がクライアントからリクエストを受け取ってから、クライアントにレスポンスを返すまでの時間。レイテンシーには、統合のレイテンシーおよびその他の API Gateway のオーバーヘッドが含まれます。
ポイント
- レイテンシーの増加は
内部資源(各種CPU等)の負荷の増加とユーザービリティーの低下の両方を意味することが多い。 - API毎にレイテンシーを可視化することにより、
どのAPIが内部資源へ負荷をより多く与えているかが確認できる。- サーバでの改善が難しい場合は、クライアントでの使い方を含めた改善によるユーザービリティの向上を検討することが可能かもしれない。
Average値を確認することで、平均的に負荷を高めている処理を発見することにができます。Max値を確認することで、例外的に負荷を高めている項目を確認することができます。
Lambda
DynamoDB
SuccessfulRequestLatency
- 指定された期間中に DynamoDB または DynamoDB ストリームに対して成功したリクエスト。
- SuccessfulRequestLatency は、2 種類の情報を提供できます。
ポイント
- レイテンシーの増加は
内部資源(各種CPU等)の負荷の増加とユーザービリティーの低下の両方を意味することが多い。
RDS
ReadLatency/WriteLatency
- 「読み取り/書き込み」レイテンシー (ミリ秒)
- 1 回のディスク I/O 操作にかかる平均時間。
ポイント
- レイテンシーの増加は
内部資源(各種CPU等)の負荷の増加とユーザービリティーの低下の両方を意味することが多い。 indexのつけ方、正規化の程度、場合によってはDBの構成を冗長化することで、アクセスを高速化することを検討しても良い。
ReplicaLag
- レプリカ遅延 (ミリ秒)
- ソース DB インスタンスからリードレプリカ DB インスタンスまでのラグ。
- MySQL、MariaDB、Oracle、PostgreSQL、および SQL Server のリードレプリカに適用されます。
ポイント
- リードレプリカを使用することは多いと思う。
- 実際に遅延がどの程度許容されるかよりも、遅延を前提としたシステムを構築できているかの方が重要な場合もある。
DatabaseConnections
- DB 接続 (数)
- 使用中のデータベース接続の数。
- メトリクス値には、データベースによってまだクリーンアップされていない、切断されたデータベース接続が含まれていない可能性があります。
- したがって、データベースによって記録されるデータベース接続の数は、メトリクス値よりも多い可能性があります。
ReadIOPS/WriteIOPS
- 読み取り IOPS (数/秒)/書き込み IOPS (数/秒)
- 1 秒あたりのディスク「読み取り/書き込み」 I/O 操作の平均回数。
- 単位: カウント/秒
ユーザーの行動を分析する
APIGateway
Count
- 指定された期間内の API リクエストの合計数。
- SampleCount 統計は、このメトリクスを表します。
ポイント
Lambda
Invocations
- 関数コードが実行された回数 (成功した実行や関数エラーが発生した実行を含む)。
- 呼び出しリクエストがスロットリングされた場合、呼び出しは記録されません。それ以外の場合は、呼び出しエラーになります。これは、請求対象リクエストの数に等しくなります。
ポイント
- 時系列のデータを確認することで、時間帯別の起動状況を確認することができる
- APIと直接連携しないバックグラウンドでのLambda処理の回数も確認することができる
DynamoDB
RDS
補足：実装時に確認しておくべきエラー
Lambda
DeadLetterErrors
- 非同期呼び出しの場合、Lambda がイベントをデッドレターキューに送信しようとしたが、失敗した回数。
- デッドレターエラーは、アクセス許可エラー、リソースの設定ミス、またはサイズ制限が原因で発生する可能性があります。
DestinationDeliveryFailures
- 非同期呼び出しの場合、Lambda がイベントを送信先に送信しようとしたが、失敗した回数。
- 配信エラーは、アクセス許可エラー、リソースの設定ミス、またはサイズ制限が原因で発生する可能性があります。
