Amazon Connectで障害発生時のオートコールをやってみた
目次
はじめに
スカイアーチHRソリューションズの肱黒です!
この記事はAmazon Connect Advent Calendar 2023の13日目の記事です。
ギークフィードさん、クラスメソッドさん、スカイアーチHRソリューションズの有志によるカレンダーとなっております。
私が書くのは初心者的な内容ですが、他の記事はre:Invent期間中のアップデート解説など、とてもレベルが高いものばかりですのでぜひ読んでみてください!
この記事では、Amazon Connect DiveDeep Trainingのアウトバウンドコールの自動化セクションを参考に、障害発生時のオートコールを試してみた際の内容を書きます。
概要
まず、Systems Manager Run Commandを使用して、EC2にCPU負荷をかけて障害を発生させます。その後、CPU使用率のCloudWatch Alarmがアラーム状態になり、SNSを通じて、Amazon ConnectのstartOutboundVoiceContact APIを実行するLambdaを呼び出して、ユーザーに電話をかけるという流れになります。
実際には携帯電話にかけたかったのですが、Amazon Connectはデフォルトでは090、080、070番号への発信が許可されていません。AWSサポートへの申請で緩和も可能なようですが、今回はAmazon Connectで番号を2つ取得し、Amazon Connectで電話を受ける形で実施しました。
やってみる
Amazon Connectを設定する
基本的にはDiveDeep Trainingに沿って設定を進めていきました。
Amazon Connectインスタンス作成については、実施済みだったので割愛します。(手順はこちら)
Amazon Connect内のキューの設定などはこちらを実施しました。フローは2-2.アウトバウンドコールの自動化セクションから一部変更して下記のような形で作成しました。
電話を受けたユーザーに対して「障害が発生しました。」というメッセージを伝えたかったので、ウィスパーフローも別途作成しました。
フローの画面から下記画像の箇所を選択して設定しました。
Lambdaを設定する
引き続きアウトバウンドコールの自動化セクションをもとにIAMポリシーの作成と割り当て、パラメータの書き換え、Lambda作成と進めましたが、テスト時にNode.jsのランタイムが原因でエラーが発生しました。
Node.js 18.xでバンドルされるAWS SDK for JavaScriptのバージョンがv2からv3になったようです。(DiveDeep Trainingのコードをそのまま使う場合は、ランタイムNode.js 16.xを使用すれば動作しました。)
Node.js 16が2023/9/11でサポート終了とのことだったので、こちらのリファレンスのサンプルコードを使い、ランタイムはNode.js 20.xにしました。
import { ConnectClient, StartOutboundVoiceContactCommand } from "@aws-sdk/client-connect";
const client = new ConnectClient();
export const handler = async (event, context) => {
const input = {
ContactFlowId: "作成したフローのID",
DestinationPhoneNumber: "フローに紐づけた電話番号",
InstanceId: "使用しているAmazon ConnectインスタンスのID",
QueueId: "フロー内の「作業キューの設定」で設定したキューのID",
SourcePhoneNumber: "もう一つの電話番号"
};
const command = new StartOutboundVoiceContactCommand(input);
const response = await client.send(command);
return response;
};
SNS設定のため、作成したLambdaのARNを控えておきます。
EC2を設定する
詳細は割愛します。個人的なポイントとしては下記です。
- Run Commandを使用したかったため、SSMエージェントがプリインストールされているAmazon Linux2を選択
- SSMの要件でインターネット接続が必要なため、パブリックサブネットに構築
- AmazonSSMManagedInstanceCoreの権限を付与したIAMロールをアタッチ
- 詳細モニタリングを有効化する
SNSを設定する
トピックはスタンダードで作成し、サブスクリプションを下記のように設定しました。
プロトコル | AWS Lambda |
エンドポイント | 作成したLambdaのARN |
CloudWatch Alarmを設定する
アラームは下記のように設定しました。
メトリクス名 | CPUUtilization |
InstanceId | 作成したインスタンスのID |
統計 | 最大 |
期間 | 1分 |
しきい値の種類 | 静的 |
次の時… | 以上 |
…よりも | 90 |
アラームを実行するデータポイント | 1/1 |
欠落データの処理 | 欠落データを見つかりませんとして処理 |
アラーム状態トリガー | アラーム状態 |
次の SNS トピックに通知を送信 | 既存の SNS トピックを選択(作成したトピックを指定) |
Run Commandを実行する
Systems Managerのコンソール画面からRun Commandのページに移動します。
ドキュメント名のプレフィックス : Equals : AWSFIS-Run-CPU-Stressで検索します。
コマンドのパラメータは下記のように設定し、ターゲットに作成したEC2を指定、その他はデフォルトのままにしました。
Duration Seconds | 120 |
CPU | 0 |
Load Percent | 100 |
Install Dependencies | True |
Amazon Connectに作成したエージェントでログインし、問い合わせコントロールパネルを開いて、Available状態にした後、Run Commandを実行し、1分ほど待って電話がかかってきたことを確認できました。
おわりに
Amazon Connectを使って想像よりも簡単にオートコールの仕組みができて感動しました。しかし、アラームの内容通知や電話が繋がらなかった際のリトライなど、まだまだ改善の余地があると感じます。より良いものが作れるようにAmazon Connectの学習を進めていきたいです!
この記事が少しでも参考になれば幸いです。