はじめに
こんにちは。アプリケーションサービス部の柳田です。
Amazon Connect 関連の構築をご支援していると、通話終了後に何かしらの処理をしたいという要望をお聞きします。 例えば、通話終了をトリガーとして別の処理を開始したい、通話ログをCRM等に連携したい等です。
そのような通話終了後処理を実装する際の選択肢として Kinesis Data Streams + Lambda をまず検討していました。 しかし、最近 Amazon EventBridge を使って Amazon Connect で発生したイベントを通知できるようになりました。こちらでも通話終了後処理は実装できそうです。
Amazon EventBridge で Amazon Connect のイベント通知を行う機能については以下記事を参照ください。
本記事では、通話終了後処理を実装する際の選択肢として Kinesis Data Streams と EventBridge について比較し、どのように使い分けをするのが良さそうか考えていきます。
Kinesis Data Streams と EventBridge の比較
構成図
通話終了後処理を Lambda を利用して実装する想定での構成図は以下になります。
構成図の見た目は、ほぼ変わらないですね。
Kinesis Data Streams 利用Ver
EventBridge 利用Ver
比較表
比較ポイントごとの整理結果を以下表にまとめてみました。
太字にしている箇所は、差別化できる点だと個人的に考える箇所です。
| No | 比較ポイント | Kinesis Data Streams | EventBridge |
|---|---|---|---|
| 1 | イベントトリガー | 通話終了 | ・INITIATED：Amazon Connect着信時や転送受付時 ・QUEUED：オペレーター対応待ち時 ・CONNECTED_TO_AGENT：オペレーター対応開始時 ・DISCONNECTED：通話終了時 特定イベントのみをトリガーとするようフィルタリング設定可能 各イベントの詳細はこちらを参照 |
| 2 | データモデル（呼び出し先に渡されるデータ形式） | CTRデータ(※1) | Contacts Event 特有のデータ |
| 3 | データに問い合わせ属性(※2)が含まれるか | 含まれる | 含まれない ・API（GetContactAttributes）でインスタンスIDとコンタクトIDを元に問い合わせ属性を取得可能 ・ただし、スロットリングの制限あり。2021/6 時点で「1 秒 2 リクエスト (RateLimit) と、1 秒あたり 5 リクエスト (BurstLimit) 」 |
| 4 | データ連携タイミング | 通話終了後数分 | 即時 |
| 5 | エラー時の未処理イベント送信先 | SQS または SNS | SQS（標準キューのみ） |
- ※1 CTR
- CTR = Contact Trace Record。通話に紐づく詳細データを含むレコードのこと。
- ※2 問い合わせ属性
- Amazon Connect の問い合わせフローで保存した値のことを問い合わせ属性と言います
- https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/set-contact-attributes.html
ユースケース
比較表でまとめた内容をもとに Kinesis Data Streams と EventBridge の使い分けについて考えてみました。
Kinesis Data Streams のユースケース
- 問い合わせ属性を通話後処理で参照する必要があるケース
- EventBridge の場合も API を使えば問い合わせ属性の参照が可能ですが、コール数の多い環境の場合は API スロットリングの制限に引っかかる可能性が高くなります。そのため、Kinesis Data Streams を利用するのがベターと考えます。
- 1つの Amazon Connect インスタンス内で複数種類の業務を行っている場合、電話番号や問い合わせ属性からどの業務か判断する必要があると思います。EventBridge から渡されるデータにはそれを判断できる情報（問い合わせ属性や電話番号）は含まれないため、Kinesis Data Streams を利用する必要があります。
EventBridge のユースケース
- 通話終了後処理を即時に行う必要があるケース
- 動作確認した感じだと、イベント発生後すぐに EventBridge から後続処理が実行されていました。
- Kinesis Data Streams の場合は、CTR が書き込まれて、後続処理されるまでに数分ほど必要です。
- 「DISCONNECTED：通話終了」以外のイベントを処理のトリガーとしたいケース
- 本記事で取り上げた通話終了後処理とは少し話がズレますが、待ちキューに入ったことをトリガーに後続処理を行いたい場合などに有用かと思います。
- 今までは待ちキューに入ったことをトリガーに後続処理を行おうとすると、問合せフロー内で Lambda を呼び出す必要がありましたが、EventBridge を使えば不要になります。
おわりに
比較する前は正直違いがよく分からなかったのですが、比較整理すると色々見えてきますね。
通話終了後処理の実装を検討している方の参考になれば嬉しいです。
