Amazon Connectで利用するAmazon Lexの運用時、個人的に確認すべきCloudWatchメトリクスまとめ
2025.01.30はじめに
Amazon Connectのフローから呼び出すAmazon Lexを運用する際、個人的に確認すべきと考えるCloudWatchメトリクスをまとめました。
Lexの利用用途や環境によって確認すべきCloudWatchメトリクスは異なるため、本記事は参考程度にご活用ください。
メトリクスは15か月間保存されるため、過去の情報にアクセスしてサービスのパフォーマンスを把握できます。
また、特定のしきい値を監視するアラームを設定し、しきい値に達した際に通知を送信したり、アクションを実行したりすることも可能です。
Lexで利用されるAPI
AWSドキュメントのLexのメトリクスでは、以下の3つのAPIが記載されているため、先に紹介します。
- StartConversation
- RecognizeUtterance
- RecognizeText
StartConversation APIは、アプリケーション（Amazon Connectなど）とLexボット間で双方向のリアルタイム会話を可能にするストリーミング接続を確立するためのAPIです。
このAPIは、音声やテキスト、DTMFなどのユーザー入力をボットにストリーミングし、双方向のリアルタイム会話を実現するストリーミングベースのAPIとして機能します。
一方、RecognizeUtteranceとRecognizeTextは、ユーザーの音声入力（RecognizeUtterance）またはテキスト入力（RecognizeText）をボットに送信するためのAPIです。
ドキュメントには記載されていませんが、ConnectのフローからLexを呼び出す場合は、StartConversation APIが利用されます。
以下のAPIは利用されません。
- RecognizeUtterance
- RecognizeText
利用されているAPIを確認する方法
ConnectのフローからLexを呼び出す場合、どのAPIが使用されているかは、Lexの会話ログ内のoperationNameから確認できます。
{
~中略~
"operationName": "StartConversation",
それでは、確認しておくべきメトリクスを説明します。
確認すべきメトリクス
Amazon BedrockやAmazon Kendraと統合したLexで利用できるメトリクスもありますが、統合が前提となるため、今回は記載しません。
RuntimeInvalidLambdaResponses
RuntimeInvalidLambdaResponsesは、無効なAWS Lambdaレスポンスの数を示します。
事前にLexにLambdaを関連付けていた場合、LexがLambdaを呼び出し、LambdaがLexにレスポンスを返した際に、そのレスポンスが無効だった場合が該当します。
無効なレスポンスが発生した場合は、Lexの会話ログやLambdaの実行ログを確認して原因を特定しましょう。
RuntimeLambdaErrorsとRuntimePollyErrors
RuntimeLambdaErrors と RuntimePollyErrors は、LexがLambdaやAmazon Pollyを呼び出した際にエラーが発生した場合に記録されます。
AWSドキュメントでは、エラーが発生するすべての条件が網羅的に記載されているわけではありませんが、たとえば、LambdaサービスやPollyサービスで一時的な問題が発生し、Lexが呼び出しに失敗した場合や、それぞれのサービスを呼び出すためのIAM権限が不足していた場合に、これらのメトリクスが記録されます。
実際に、LexのIAMロールの権限を意図的に不足させた状態で、Lambda関数やPollyサービスの呼び出しでエラーが発生した際に、RuntimeLambdaErrorsおよびRuntimePollyErrorsのメトリクスが記録されることを確認できました。
また、Lexに関連付けたLambda関数を呼び出すよう設定した後に、そのLambda関数を削除すると、RuntimeLambdaErrorsが記録されることを確認しました。
もしエラーが発生した場合は、Lexの会話ログや権限回りを確認しましょう。
RuntimeSystemErrorsとRuntimeUserErrors
RuntimeSystemErrorsはシステムエラーが発生したことを示し、システムエラーのレスポンスコードは500～599です。
RuntimeUserErrorsはユーザーエラーが発生したことを示し、ユーザーエラーのレスポンスコードは400～499です。
Lexでの一般的なエラーやStartConversation APIでのエラーについては、以下の2つのドキュメントに記載されています。詳細はそちらをご参照ください。
発生した場合、LexやConnect、Lambdaなどのログを確認しましょう。
RuntimeThrottledEvents
RuntimeThrottledEventsは、スロットルされたイベントの数を示します。
Lexは、1秒あたりに受け取るトランザクションの数が制限数を超えると、リクエストをスロットルします。
具体的には、Lexのクォータには「StartConversationの同時音声モード会話数」という項目があり、Connectから同一のLexのエイリアスを同時に呼び出せる最大数が定められています。
Lexが対応できる同時最大数は、エイリアスによって異なります。
- TestBotAlias：2
- 他のエイリアス：200
その他のエイリアスの場合、「StartConversationの同時音声モード会話数」の最大値は200であるため、201件目のリクエストが発生した時点でRuntimeThrottledEventsが1として記録されます。
メトリクスが記録された場合は、制限の引き上げをリクエストを検討しましょう。
RuntimeConcurrency
RuntimeConcurrencyは、同時接続の数を示します。
先ほど、Lexのクォータで「StartConversationの同時音声モード会話数」の最大値が定められていると解説しましたが、このメトリクスは同時接続数をカウントするものです。
基本的に、その他のエイリアスの「StartConversationの同時音声モード会話数」はRuntimeConcurrencyメトリクスと同じと考えて問題ありません。
制限を引き上げていない場合、その他のエイリアスの同時音声モード会話数は最大で200までしかカウントされません。
ただし、厳密にはRuntimeConcurrencyメトリクスはディメンションごとに分かれており、以下の条件を満たすメトリクスを確認する必要があります。
これにより、RuntimeConcurrencyは、「その他のエイリアスのStartConversationの同時音声モード会話数」と同等の値を確認できます。
- BotAliasIdが「TestBotAlias」以外であること
- InputModeが「Speech」であること
- 補足：電話でConnectを利用する場合、Connectから呼び出されるLexのInputModeは「Speech」になりますが、Connectをチャットで利用する場合は「Text」になります。
「その他のエイリアスのStartConversationの同時音声モード会話数」とは、「TestBotAlias」以外のエイリアスにおける同時音声モード会話数を指します。そのため、上記の条件を満たすメトリクスを確認することで、同等の値を把握できます。
もしRuntimeConcurrencyが1秒間で200近くまで記録されている場合は、制限の引き上げをリクエストすることを検討してください。
複数エイリアスを利用する場合
「TestBotAlias」以外の複数のエイリアスを同時に利用している場合、それぞれのエイリアスに対応するメトリクスはBotAliasIdごとに分かれて表示されます。この場合、該当するすべてのメトリクスを合計して監視する必要があります。
会話ログ
ConversationLogsTextDeliveryFailure と ConversationLogsAudioDeliveryFailure は、Lexが指定された送信先にテキストログまたはオーディオログを配信できなかったことを示すメトリクスです。
- ConversationLogsTextDeliveryFailure: CloudWatch Logsへのテキストログ配信に失敗した場合に記録されます。
- ConversationLogsAudioDeliveryFailure: S3バケットへのオーディオログ配信に失敗した場合に記録されます。
エラーの原因として、以下の設定に関連する問題が考えられます。
- IAMアクセス許可の不足
- LexのIAMロールやS3バケットポリシーに必要な権限が不足している場合
- 送信先のリソースが存在しない
- S3バケットやCloudWatch Logsグループが作成されていない場合
- AWS KMSキーへのアクセス権限の不足
- S3バケットやCloudWatch Logsグループで設定されているAWS KMSキーにアクセスできない場合
気にしなくて良い
RuntimeSucessfulRequestLatency
RuntimeSucessfulRequestLatencyは、Lexへのリクエストが成功してからレスポンスが返されるまでのレイテンシー時間を示します。
これは、ユーザーの発話が終了してからLexのレスポンスを待つ「ユーザーの待ち時間」ではありません。詳細は以下の記事をご参照ください。
特に要件がなければ、チェックは不要だと考えます。
RuntimeRequestCount
RuntimeRequestCountは、ランタイムリクエストの数を示します。
RuntimeThrottledEventsやRuntimeConcurrencyがチェックできていればよいので、特に要件がなければ、確認は不要と考えます。
RuntimeRequestLength
RuntimeRequestLengthは、ユーザーの発話やLexの応答を含め、StartConversation APIでの会話の合計の長さが記録されます。
クォータなどの制限もないので、特に要件がなければ、気にしなくて良いと考えます。
最後に
本記事では、Amazon Connectから呼び出すAmazon Lexを運用する際に、個人的に確認しておくべきと考えるメトリクスについて解説しました。
エラーやスロットルに関するメトリクスは、把握しておく必要があります。
なお、Lexの利用用途や環境によって確認すべきメトリクスは異なるため、本記事はあくまでも参考程度にご活用ください。
