架電に人は必要ない(Amazon Connect 使用までの道のり)
はじめに
こんにちは
SHIFTのITソリューション部に所属している たかはしです
今回は Amazon Connect を使用して AWS 上のインシデントを自動架電した仕組みを実装しましたが、見事にハマったので私の様な被害者を減らす為にブログにて情報を共有したいと思います
必要な情報のみ欲しい方は目次から飛んで頂ければと思います
使うのに必要な物
会社の登記簿
申請者の在籍証明書
申請者の個人情報(今回は運転免許証のコピー)
Amazon Connect で電話番号を取得する際に AWS へ申請が必要な書類となります
東京リージョンで利用の場合は最低でも上記3点の書類が申請必須でした
※当記事執筆時点
最もネックかつ時間を要する事なので最初に記載しました
申請が受理されてから、内容の確認に約1週間ほどのリードタイムがありました。
その為、Amazon Connect の利用を考えており、日本の電話番号の使用を検討している方は、早めの申請を心掛けると良いと思います
使用可能になるまでのフロー
ざっくり実際に使用可能になるまでのフローを記載します
電話番号取得に関する書類の準備
Amazon Connect Instance の構築( EC2 では無い)
構築した Amazon Connect Instance の ARN から電話番号取得の依頼を AWS に申請(約1週間)
※この際に上記で用意した書類を合わせて送付クォータ引き上げ(Phone numbers per instance)
電話番号が1つだけなら無くても良かったかもしれません・・Amazon Connect のフローの作成
AWS から電話番号が振り分けられる
ここまでが使用可能になるまでの簡単なフローになります
Amazon Connect のコントロールパネルから、実際に払い出された電話番号を選択し、対象の番号(社用携帯)等に電話を架ければ、受電する状態にまでなっています
Amazon Connect Instance の構築やフローの作成手順はたくさんの情報があり、とても簡単なので割愛しております
架電基盤全体イメージ図
全体のざっくりイメージ図は以下の様になります
右側の workload アカウントから SNS 経由で 左側の Connect アカウントにメッセージが飛び、 Lambda を介して Connect から架電通知させる仕組みです
インシデントレベルを決め、 EventBrigde でレベルに応じた SNS Topic を設定し、架電 メール Teamsと通知先を切り分けています
今回は、Amazon Connect の機能を1つのアカウントに集約して運用する事とした為、上記の様な構成になっています
右側のアカウントでは汎用的な作りにし、別アカウントが増えても同じ設定で構築する事で、架電の機構を集約出来る様な仕組みにしています
Lambda のコードサンプル
実際のコードとは全く違いますが、動作確認用のサンプルを記載します
import boto3
def lambda_handler(event, context):
connect = boto3.client('connect')
connect.start_outbound_voice_contact(
DestinationPhoneNumber='+8190xxxxxxxx',
ContactFlowId='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
InstanceId='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx', SourcePhoneNumber='+8150xxxxxxxx' )DestinationPhoneNumber には架電させたい電話番号
ContactFlowId にはAmazon Connect のフロー ARN
InstanceId にはAmazon Connect の InstanceId
SourcePhoneNumber にはAmazon Connect で取得した電話番号
※今回は(050)の番号を取得した為50となっています
上記をそれぞれ読み替えて使用してください ContactFlowId はフローのARNを指定します
以下の様なシンプルなフローで問題ありません
補足として
AWS Connect を1つのアカウントに構築し、架電の仕組みを集約させたので以下の様な情報を確認 / 分析したい事もあるかと思います
システム毎の架電数(インシデント件数)
システム毎の電話番号
日, 週, 月 毎の架電数(インシデント件数)
その場合は DynamoDB 等で架電回数や電話番号を管理し、後続処理として CloudWatch でメトリクスをカスタムダッシュボード化したりすれば分析にも使えるかと思います
電話番号数を必要最低限にする事や、DynamoDB のttlの設定等で、金額も抑えられます
おわりに
現在でもジョブの状態を監視してアラートが鳴ったら担当者に電話を架ける等の運用がたくさんあると思います
しかし、クラウドが身近になり色んなサービスも 増加/拡充 し、出来る限り自動化出来る様になってきました
今回はその一例として架電の自動化にフォーカスした内容をテーマに当記事を執筆しました
当記事を読んで、架電の自動化を検討しようとでも思って頂ければ嬉しいです
執筆者プロフィール：漢字が難しいたかはし
主にAWSインフラ担当です
SHIFTについて（コーポレートサイト）
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
PHOTO：UnsplashのMarkus Spiske