Amazon Connectで障害発生時のオートコールをやってみた

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 Seconds120
CPU0
Load Percent100
Install DependenciesTrue

Amazon Connectに作成したエージェントでログインし、問い合わせコントロールパネルを開いて、Available状態にした後、Run Commandを実行し、1分ほど待って電話がかかってきたことを確認できました。

おわりに

Amazon Connectを使って想像よりも簡単にオートコールの仕組みができて感動しました。しかし、アラームの内容通知や電話が繋がらなかった際のリトライなど、まだまだ改善の余地があると感じます。より良いものが作れるようにAmazon Connectの学習を進めていきたいです!

この記事が少しでも参考になれば幸いです。

この記事をシェアする
著者:hijikuro
AWS歴2年目になりました!Amazon Connect勉強中です!