Amazon Connect 双方向SMSの運用に向けて、Amazon CloudWatchメトリクスの監視項目候補を整理してみた

はじめに

Amazon Connect では、AWS End User Messaging SMS で取得したSMS対応番号を利用して、顧客とエージェントがSMSでやりとりできます。

公式ドキュメントでは、Amazon Connect でSMSメッセージングを設定する流れとして、AWS End User Messaging SMS でSMS対応番号を取得し、番号で双方向SMSを有効化し、メッセージの宛先として Amazon Connect を指定する手順が説明されています。

https://docs.aws.amazon.com/connect/latest/adminguide/setup-sms-messaging.html

今回は、Amazon Connect の双方向SMSを利用し、顧客とオペレーターがSMSでやりとりする構成を想定して、CloudWatch アラームで監視するメトリクス候補を整理しました。

なお、本記事は、筆者が Amazon Connect 双方向SMSの監視設計を検討するうえで個人的に整理した内容です。実際に採用する監視項目やしきい値は、業務要件、SLA、問い合わせ量、オペレーター体制に応じて調整してください。

本記事では以下を前提にします。

• SMSは日本国内から日本国内への利用を想定する
• SMS送信元はショートコードを前提にする
• 顧客とオペレーターがSMSでやりとりする
• 音声通話は利用しない
• CloudWatch 標準メトリクスを中心に監視する
• 必要に応じて CloudWatch アラーム化する

結論

Amazon Connect 双方向SMSを CloudWatch アラームで監視する場合、監視対象は大きく以下の2つに分けて考えると整理しやすいです。

Amazon Connect 側
  ├ キュー滞留
  ├ 顧客待ち時間
  ├ チャット同時数
  ├ チャットクォータ逼迫
  ├ フローエラー
  └ キュー容量超過

AWS End User Messaging SMS 側
  ├ SMS配信率
  ├ Protectによるブロック
  └ SMS費用

利用する主な CloudWatch Namespace は以下です。

今回整理した監視項目候補は以下です。

また、CloudWatch メトリクスで監視する観点として、以下のサービスクォータも意識します。

ポイントは、Amazon Connect 側ではチャット系メトリクスを中心に見て、SMSの送信、配信、費用、Protectブロックは AWS End User Messaging SMS 側の AWS/SMSVoice 名前空間を見ることです。

また、SMS配信状況は NumberOfTextMessagePartsDelivered 単体ではなく、NumberOfTextMessagePartsSent と組み合わせて配信率として見る方が、到達性の低下を判断しやすいです。

Amazon Connect におけるSMSの扱い

Amazon Connect のSMSは、チャットのサブタイプとして扱われます。

Amazon Connect のSMSセットアップ手順でも、SMSコンタクトを判定するために、フロー内で Segment attributes の Subtype を確認し、値 connect:SMS で分岐する例が説明されています。

In Attribute to check section, set Namespace to Segment attributes and key to Subtype.

Attribute to check セクションで、Namespace を Segment attributes、key を Subtype に設定します。

https://docs.aws.amazon.com/connect/latest/adminguide/setup-sms-messaging.html

In the Conditions to check section, set condition to Equals and value to connect:SMS.

Conditions to check セクションで、条件を Equals、値を connect:SMS に設定します。

https://docs.aws.amazon.com/connect/latest/adminguide/setup-sms-messaging.html

そのため、Amazon Connect 側のCloudWatch監視では、SMS専用メトリクスを見るというより、チャット系メトリクスを中心に見ることになります。

CloudWatch標準メトリクスではSMSのみを抽出できない

Amazon Connect のSMSはチャットのサブタイプとして扱われます。

そのため、Amazon Connect 側のCloudWatch監視では、ConcurrentActiveChats や SuccessfulChatsPerInterval など、MetricGroup=Chats のメトリクスを中心に見ることになります。

一方で、CloudWatch 標準メトリクスおよび CloudWatch アラームでは、SMSのみを抽出して監視することはできません。

Amazon Connect の CloudWatch メトリクスでは、チャット系メトリクスのディメンションとして InstanceId や MetricGroup が提供されますが、SMS、Web Chat などのチャットサブタイプで絞り込むためのディメンションはありません。

https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/monitoring-cloudwatch.html

この点は、Amazon Connect の GetMetricDataV2 API と混同しやすいです。

GetMetricDataV2 API では、contact/segmentAttributes/connect:Subtype に connect:SMS を指定して、SMSのメトリクスを絞り込めます。

https://docs.aws.amazon.com/connect/latest/APIReference/API_GetMetricDataV2.html

ただし、GetMetricDataV2 API は Amazon Connect のメトリクス取得APIであり、CloudWatch 標準メトリクスとは別の仕組みです。そのため、GetMetricDataV2 API でSMSを絞り込めるからといって、CloudWatch アラームで同じ条件を直接指定できるわけではありません。

整理すると以下です。

現時点でSMSのみを利用する構成であれば、MetricGroup=Chats のメトリクスをSMS監視として扱いやすいです。

一方で、将来的にWeb Chat、WhatsApp、Apple Messages for Businessなど、SMS以外のチャット系チャネルも利用する場合は、CloudWatch標準メトリクス上で値が混在する可能性があります。

SMSのみを分離してCloudWatchアラーム化したい場合は、Amazon Connect の問い合わせイベントを EventBridge で受け取り、LambdaでSMSコンタクトのみを判定してCloudWatchカスタムメトリクスを発行する構成を検討します。

Amazon Connect の問い合わせイベントには SegmentAttributes が含まれます。公式ドキュメントでは、SegmentAttributes はチャネルサブタイプを示すために使用でき、例として connect:SMS が挙げられています。

https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/contact-events.html

Amazon Connect 側で見るメトリクス

Amazon Connect 側では、主に AWS/Connect 名前空間のメトリクスを見ます。

Amazon Connect の CloudWatch メトリクスのドキュメントでは、ConcurrentActiveChats、ConcurrentActiveChatsPercentage、ChatsBreachingActiveChatQuota、SuccessfulChatsPerInterval などのメトリクスが説明されています。

https://docs.aws.amazon.com/connect/latest/adminguide/monitoring-cloudwatch.html

キュー滞留を見る

SMS問い合わせがオペレーターに割り当てられず、キューに溜まっていないかを見るために、以下を監視候補にします。

QueueSize は、キュー内のコンタクト数を見るためのメトリクスです。SMS問い合わせが急増した場合や、オペレーター数が不足している場合に、キュー内にコンタクトが溜まり続ける可能性があります。

LongestQueueWaitTime は、キューで最も長く待っているコンタクトの待ち時間を見るためのメトリクスです。SMSは電話より非同期なチャネルですが、初回対応が遅いと顧客体験に影響するため、待ち時間も監視対象に含めます。

QueueCapacityExceededError は、キュー容量超過によってコンタクトを受け付けられなかった可能性を確認するためのメトリクスです。発生した場合は、キュー設計、ルーティング設定、オペレーター数、同時対応数を確認します。

アラーム条件の例です。

QueueSize >= 10 が 5分間継続

LongestQueueWaitTime >= 300秒

QueueCapacityExceededError > 0

しきい値は、問い合わせ件数、オペレーター数、業務時間、SLAに応じて調整します。上記はあくまで例です。

チャット同時数とクォータを見る

SMSはチャットのサブタイプとして扱われるため、同時アクティブチャット数のクォータを確認します。

SMSも Concurrent active chats per instance の対象に含まれるため、同時SMS会話数を見積もる際に確認します。

このクォータには、待機中のチャットや、顧客が長時間無反応のまま残っているチャットも含まれます。

This includes SMS, WhatsApp, and Apple Messages for Business. It also includes chats that are waiting.

これには、SMS、WhatsApp、Apple Messages for Business が含まれます。また、待機中のチャットも含まれます。

https://docs.aws.amazon.com/connect/latest/adminguide/amazon-connect-service-limits.html

そのため、SMSの会話が長時間残る運用では、同時アクティブチャット数が想定より増える可能性があります。

この監視項目に関連するサービスクォータは Concurrent active chats per instance です。ConcurrentActiveChatsPercentage や ChatsBreachingActiveChatQuota を使うことで、同時アクティブチャットのクォータ使用率や超過をCloudWatchで監視できます。

アラーム条件の例です。

ConcurrentActiveChatsPercentage >= 80%

ConcurrentActiveChatsPercentage >= 90%

ChatsBreachingActiveChatQuota > 0

ConcurrentActiveChatsPercentage は、クォータ使用率を早めに検知する目的で利用します。例えば80%をWarning、90%をCriticalのように設定すると、上限に近づく前に検知しやすくなります。

ChatsBreachingActiveChatQuota は、同時アクティブチャットの上限を超えたチャット開始リクエスト数を見るメトリクスです。1件でも発生した場合は、新規SMSコンタクトを開始できなかった可能性があるため確認します。

SuccessfulChatsPerInterval は、正常に開始されたチャット数の傾向を見るためのメトリクスです。通常時の流入傾向を把握する目的でダッシュボードに表示しておくと便利ですが、業務時間や曜日による変動が大きい場合があります。そのため、最初から固定しきい値のアラームにするより、通常値を把握してからアラーム条件を検討するのがよさそうです。

フローエラーを見る

SMS受信後に、フローでキュー振り分け、自動応答、属性設定、外部連携などを行う場合は、フローエラーも監視対象にします。

Amazon Connect のドキュメントでは、ContactFlowErrors はフローのエラー分岐が実行された回数、ContactFlowFatalErrors はシステムエラーによりフロー実行に失敗した回数として説明されています。

https://docs.aws.amazon.com/connect/latest/adminguide/monitoring-cloudwatch.html

アラーム条件の例です。

ContactFlowErrors > 0

ContactFlowFatalErrors > 0

SMS受信後に必ず通るフローでこれらが発生すると、顧客からのSMSが正しくルーティングされない可能性があります。発生時は、対象フローの変更履歴、外部連携先の状態、キュー設定などを確認します。

AWS End User Messaging SMS 側で見るメトリクス

SMSの送信数、配信数、費用、Protectによるブロックは、Amazon Connect 側ではなく AWS End User Messaging SMS 側の AWS/SMSVoice 名前空間で確認します。

AWS End User Messaging SMS の CloudWatch メトリクスのドキュメントでは、TextMessageMonthlySpend、NumberOfTextMessagePartsSent、NumberOfTextMessagePartsDelivered、TextMessagesBlockedByProtect などが説明されています。

https://docs.aws.amazon.com/sms-voice/latest/userguide/monitoring-cloudwatch.html

SMS配信率を見る

SMSが実際に配信されているかを見る場合は、NumberOfTextMessagePartsSent と NumberOfTextMessagePartsDelivered を組み合わせます。

NumberOfTextMessagePartsSent は、送信されたSMSメッセージパーツ数を確認するためのメトリクスです。

NumberOfTextMessagePartsDelivered は、受信者に配信されたSMSメッセージパーツ数を確認するためのメトリクスです。

SMSは文字数や文字種によって複数パーツに分割される場合があります。そのため、メッセージ数ではなく、メッセージパーツ数として扱います。

NumberOfTextMessagePartsDelivered 単体では、送信がなかったため配信数が少ないのか、送信したが配信されていないのかを判断しづらいです。また、送信量そのものが日によって変わる場合、配信数の絶対値だけでは到達性の悪化を判断しにくくなります。

そのため、CloudWatch アラームでは、送信されたSMSメッセージパーツ数である NumberOfTextMessagePartsSent と、配信されたSMSメッセージパーツ数である NumberOfTextMessagePartsDelivered を使い、Metric Mathで配信率を見るのがよさそうです。

Metric Mathの例です。

100 * NumberOfTextMessagePartsDelivered / NumberOfTextMessagePartsSent

目的は、送信したSMSが正常に配信されている割合を監視し、SMS到達性の低下を検知することです。

アラーム条件の例です。

配信率 < 95%

配信率 < 90%

SMS配信率には注意点があります。

AWS End User Messaging SMS のドキュメントでは、マルチパートメッセージの場合、キャリアインフラストラクチャから同じメッセージに対して複数の配信確認が返される場合があり、NumberOfTextMessagePartsDelivered が NumberOfTextMessagePartsSent を超えることがあると説明されています。

When a message is split into multiple parts, the carrier infrastructure may return more than one delivery confirmation for the same message.

メッセージが複数パーツに分割される場合、キャリア基盤から同じメッセージに対して複数の配信確認が返されることがあります。

https://docs.aws.amazon.com/sms-voice/latest/userguide/monitoring-cloudwatch.html

そのため、配信率が100%を超えたこと自体は異常扱いせず、低下方向を監視するのがよさそうです。

また、NumberOfTextMessagePartsSent と NumberOfTextMessagePartsDelivered の記録タイミングには差が出る可能性があります。短い評価期間では同じ期間内に両方のメトリクスが揃わず、意図しないアラームになる可能性があります。まずはテスト送信で反映タイミングを確認し、15分や30分など、ある程度長めの評価期間から調整するのがよさそうです。

SMS送信レートを見る場合

AWS End User Messaging SMS の送信レートに関連するサービスクォータは、Number of SMS messages that can be sent each second, sending rate です。

送信レートは、SMSの「通数」ではなく、1秒あたりに送信できるSMSメッセージパーツ数で考えます。SMSは本文の長さや文字種によって複数パーツに分割される場合があるためです。

この「1秒あたりに送信できるSMSメッセージパーツ数」は、MPS、Message Parts per Second と呼ばれます。

日本国内向けにショートコードを利用する場合、AWS公式ドキュメント上では、ショートコードのMPS上限は固定値として公開されていません。専用ショートコードの送信レートは国または地域によって異なるため、実際の上限はショートコード申請時、または払い出し後の設定値として確認します。

https://docs.aws.amazon.com/sms-voice/latest/userguide/sms-limitations-mps.html

CloudWatch 標準メトリクスでは、NumberOfTextMessagePartsSent により実際の送信メッセージパーツ数を確認できます。ただし、これは送信レートクォータの使用率そのものを直接表すメトリクスではありません。

そのため、送信レートについては、実際のMPS上限が分かった後に、評価期間あたりのメッセージパーツ数として近似的に確認する位置づけになります。

例えば、ショートコードの上限が X MPS だった場合、1分あたりの目安は以下です。

X MPS × 60秒 = 1分あたりの最大メッセージパーツ数

80%で検知するなら以下です。

X MPS × 60秒 × 0.8

90%で検知するなら以下です。

X MPS × 60秒 × 0.9

ただし、これは1分平均での近似です。瞬間的な1秒あたりのスパイクまで正確に検知できるわけではありません。

Protectブロックを見る

AWS End User Messaging SMS Protect は、SMS送信に対する不正利用や想定外の送信を抑えるための保護機能です。

Protect configuration では、国ごとのルールを設定できます。たとえば、特定の国への送信をブロックしたり、AIT、Artificially Inflated Traffic のような不正なトラフィックの影響を抑えるためにフィルタリングしたりできます。

https://docs.aws.amazon.com/sms-voice/latest/userguide/protect-configuration.html

https://docs.aws.amazon.com/sms-voice/latest/userguide/filter-and-monitor-messages.html

この Protect 設定によりSMSがブロックされていないかを見るために、以下を監視候補にします。

アラーム条件の例です。

TextMessagesBlockedByProtect > 0

1件でも発生した場合は、Protect設定、送信先国、送信元設定を確認します。

また、Protectブロック率を見たい場合は、ドキュメントに記載されている以下の式を使います。

100 * AVG(TextMessagesBlockedByProtect)

AWS End User Messaging SMS のドキュメントでは、TextMessagesBlockedByProtect は、Protectによりブロックされた場合は1、ブロックされなかった場合は0の値を持ち、ProtectによってブロックされたSMSの割合は 100 * AVG(TextMessagesBlockedByProtect) で求められると説明されています。

The percentage of SMS messages blocked by Protect can be determined by 100 * AVG(TextMessagesBlockedByProtect).

Protect によってブロックされたSMSメッセージの割合は、100 * AVG(TextMessagesBlockedByProtect) で求められます。

https://docs.aws.amazon.com/sms-voice/latest/userguide/monitoring-cloudwatch.html

ここで注意したいのは、以下の式にはしないことです。

100 * TextMessagesBlockedByProtect / NumberOfTextMessagePartsSent

NumberOfTextMessagePartsSent は、Protectやサービス制限によりブロックされたメッセージを含まないと説明されています。そのため、Protectでブロックされた割合を出す分母としては適していません。

SMS費用を見る

SMS費用を見るために、以下を監視候補にします。

TextMessageMonthlySpend は、当月にSMS送信で使用した金額を米ドルで表すメトリクスです。

https://docs.aws.amazon.com/sms-voice/latest/userguide/monitoring-cloudwatch.html

この監視項目に関連するサービスクォータは Spending threshold です。

Spending threshold は、SMS送信に利用できる月間費用上限です。この上限に達すると、SMS送信が停止される可能性があります。そのため、TextMessageMonthlySpend は、単に費用の増加を見るだけでなく、費用上限に近づいてSMS送信に影響が出る前に検知するためにも重要です。

アラーム条件の例です。

月額予算の 80%

月額予算の 100%

SMS費用は、送信数、送信先国、メッセージパーツ数によって増加します。異常送信や問い合わせ急増を費用面からも検知できるように、TextMessageMonthlySpend は監視しておくとよさそうです。

料金や上限値はアカウント、リージョン、利用状況、時期によって変わる可能性があるため、実際の値は Service Quotas、AWS End User Messaging SMS の設定画面、公式料金ページで確認してください。

CloudWatch標準メトリクスだけでは見づらいもの

オペレーターの初回返信時間、平均返信時間、エージェント別の対応状況、一次解決率、SMS本文単位の失敗理由などは、CloudWatch 標準メトリクスだけでは直接アラーム化しにくい項目です。

これらを監視したい場合は、Amazon Connect のリアルタイムメトリクス、履歴メトリクス、リアルタイムメトリクスルール、問い合わせイベント、Contact Trace Record（CTR）、EventBridge、Lambda、CloudWatch カスタムメトリクスなどの利用を検討します。

また、SMS単位の配信イベントや失敗理由を確認したい場合は、AWS End User Messaging SMS のイベント送信先を利用し、CloudWatch Logs、Amazon Data Firehose、Amazon SNS などへイベントを出力する構成も選択肢になります。

監視項目候補のまとめ

今回整理したCloudWatch監視項目候補をまとめると以下です。

優先アラーム に ◯ を付けたものは、まず CloudWatch アラーム化を検討したい項目です。

ConcurrentActiveChats、SuccessfulChatsPerInterval、NumberOfTextMessagePartsSent、NumberOfTextMessagePartsDelivered、Protectブロック率 は、まずダッシュボードで通常時の傾向を把握し、その後必要に応じてアラーム化を検討する位置づけにしています。

まとめ

Amazon Connect 双方向SMSのCloudWatch監視では、Amazon Connect側のキュー、チャット同時数、フローエラーと、AWS End User Messaging SMS側の配信率、Protectブロック、費用を分けて考えると整理しやすいです。

SMS配信状況は、NumberOfTextMessagePartsDelivered 単体ではなく、Metric Mathで配信率として見るのがよさそうです。また、日本国内向けショートコードの送信レートは固定値として公開されていないため、実際の上限を確認したうえで監視条件を検討します。

実際のしきい値やサービスクォータは、業務要件、SMS本文の長さ、ショートコードの送信レート、SMS送信の利用額しきい値 などに応じて調整します。