techtektでは2度目の投稿となります。
パーソルキャリア データ共通BITAで基盤周りのソフトウェアを内製開発しているKenny Songです。
先日の記事でご紹介したAmazon Connect を利用した自動障害連絡がProduction Readyとなったため、パーソルグループ合同で行われたAWS勉強会に登壇してきました。
本日のお品書き:
- AWSグループ内勉強会について
- Mec（Mizuki emergency call）とは
- でも・・お高いんでしょう？
- 新アーキテクチャ
- Mec はパーソルグループ内限定のOSSに
- Amazon Connect の少し使い辛かったポイント
- まとめ
AWSグループ内勉強会について
2021-04-26 にミイダス株式会社 主催の勉強会がオンラインで初開催！
ゲストにアマゾンウェブサービスさんを迎え、開催元のミイダスにパーソルホールディングス、パーソルイノベーションと我々パーソルキャリアからそれぞれ登壇。
述べ13社、60人程がリスナーとして参加し盛り上がりを見せました。
- 巨大データベースの運用とデータレイク
- グループIT本部として提供するAWSアカウント群の管理と統制
- AWS Codeシリーズをフル活用したCICD基盤
- AWSさんからの最新トピック共有
といった非常に濃いラインナップの中、我々からは前述した無人障害連絡基盤を発表したのですが15分という時間で駆け足な紹介となったため、こちらの記事では新たなアーキテクチャを含め改めてご紹介させていただきます。
Mec（Mizuki emergency call）とは
以前記事でご紹介した、Amazon Connect を利用した自動発信機能を基盤としてのサービスに昇格させるため再開発したアプリケーションです。
Acronym でそのまま メック と発音します。
PoCとして構築したモデルを継承しながらAPI化し、障害情報をアプリケーション側からPOSTするだけですぐに電話が掛かってきます。
Mec からの電話に出れなかったら？
Amazon Connect はデフォルトで最大60秒間コールしてくれますが深夜だったり離席していたり、必ずしも電話に応答できるとは限りません。
Mec では誰かが電話に出るまで繰り返し電話をかけたり、指定した最大回数に達するまで電話をかけたりと柔軟に指定することができます。
これは障害情報の連携元ごとに挙動の規定値をセットできるほか、障害度合いに応じ規定を上書きしたり通話間のインターバルを伸ばしたりといったカスタマイズが可能になりました。
また、電話に気づいたが出れなかった際に任意で架電シークエンスをキャンセルし電話を止めることも可能です。
同時刻に複数の障害連携が発生したら？
Mec はAPIキックされた数だけ並列で電話を掛けます。
時間帯や障害規模によって電話する or しない といったこともアプリケーション側で自由に制御可能です。
他のシステムと同時にAPIキックされた場合もそれぞれに電話が掛かります。
それで Mizuki ってだれ？
Amazon Connect でプロンプトを読み上げてくれる音声さんの名称です！
同僚には Takumi さんもいます。
2人とも Amazon Polly というDeepLearningなTEXT読み上げサービスからお手伝いに来ています。
よって、Alexaと同様にSSMLを理解するため人間らしい自然な発声が実現できます。
でも・・お高いんでしょう？
現在の Mec にはデータ共通で管理するいくつかのホストが登録されており、2021年4月は20件程度の架電がありましたが・・
1ドルにも満たない料金で運用できています。
Amazon Connect は秒単位で課金されるOndemandサービスなため、「障害連絡」としては要点のみを読み上げるので通話時間が短い + 本数が潜在的に少ない とダブルパンチが効き低価格運用が可能です！
新アーキテクチャ
小さくなってしまいましたが、PoCとして以前ご紹介した構成をベースにAPI化しています。
主要リソースは、
- Amazon Connect
- ECS（on EC2）
- ALB（Internal）
- RDS
- Lambda
となっており、全てのロジックはPythonの FastAPI を使用し実装しています。
宗教上の理由でAWSに依存したコードを抑えたため、マネージド部分は少し減っています。
SQSの代わりに ElasticMQ というSQS互換のOSSを利用しており、これに対しショートポーリングを繰り返す Poll コンテナを用意しました。
Amazon Connect からInvokeするLambdaは基本的にFastAPIコンテナに対し、応答結果をPOSTし引き渡すだけです。
Mec はパーソルグループ内限定のOSSに
社内にオープンな取り組みとして基盤サービスを開発し提供することができれば今後面白い動きになるのではないかと思い、作成した全てのソースコードはパーソルグループ限定のOSSとして内部へ開示することにしました。
部署や所属組織を問わずグループのネットワーク内であれば Mec 自体を利用することもできますし、リポジトリからcloneして独自に使うこともできます。
APIをWrapしたライブラリもPython, Java, CSharpといった主要言語で用意し、こちらもパッケージレジストリだけでなくソースコードを開示しています。
Amazon Connect の少し使い辛かったポイント
さて、ここまでAmazon Connectを前提に記述してきましたが実際にOutboundコール主体で運用し見えてきた痒いのに手が届かない部分をご紹介します。
尚、これらの情報は勉強会を通じてAWSの方にも伝わっており、改善要望としてお持ち帰りいただけたので今後変わっていく可能性があります。
ポイント1: Outbound callに関するAPIが壊滅的に少ない
Amazon Connect 自体はInbound callに特化したコールセンターシステムのサービスです。
これは米国本土でGAした際もまずはInboundのみで始まり、約半年遅れでOutboundがGAしたことからも伺えます。
- Agent が電話に応答したかどうか
- キュー の途中で顧客が通話を切ったかどうか
- 顧客とAgent、どちらから通話を切ったのか
このような通話ステータスを取得するAPIは用意されているものの、Inbound callに基づくログとして取り扱われておりOutboundでは取得できませんでした。
障害連絡のユースケースでは電話に応答しなかった場合、次のメンバーに架電するような応答結果に応じて動的に通話を組み立てる必要があります。
これらは残念ながら Amazon Connect 単体では実現できないのでAPコンテナやLambda側で独自に実装する必要がありました。
通話ごとのIDとそれに基づく結果などが詳細に取得できるAPIがOutboundでも用意されれば、アーキテクチャを更に簡略できる可能性があるため今後の動向に期待です。
ポイント2: コンタクトフローが削除できない
Amazon Connect では電話が始まってから終了するまでの一連の流れをコンタクトフローとして定義します。
このように Amazon Connect の専用のGUIから構築することができますが、一度作成すると物理削除ができないトラップがあります。
これに対して Amazon 公式の見解はこちらです:
You can't delete a contact flow. To get obsolete contact flows out of your way, we recommend appending zzTrash_ to their name. This will also make them easy to find should you want to reuse them in the future.
つまりコンタクトフローの一覧画面ではフロー名で昇順ソート固定（変更不可！）で表示されており、 zzTrash とPrefixをつけることで前に出てこない
これで論理削除相当というトンデモ理論が公式ドキュメント上で提唱されています・・。
上記に加え100件以上のコンタクトフローを作成できないサービスクォータがあるため安易にポンポン作ると後で困ってしまいます（緩和申請可）
コレじゃない感がすごいので改善して欲しいところです。
ポイント3: IaCとの相性があまり良くない
データ共通は基本的にデータを取り扱う基盤部門であるため、インフラストラクチャーをコードで管理するIaCについても積極的に導入・切替を進めています。
例に漏れず Mec を構成するAWSサービス群もGitHubActionsやGitLabCI、Terraformを使用して管理しているのですが Amazon Connect に関してはCFnにすらテンプレートがありません。
GAから既に4年以上経過していますが現状はAWSコンソールから作成する必要があります。
Amazon Connect 単体でできることは割と少ないので基本的にはコンタクトフローからLambdaを呼び出して処理を委任する必要があるのですが、事前に紐付けしたLambda以外は呼び出すことができません。
この紐付けは上記キャプチャのようにAWSコンソール上からのみ操作可能です。
ARN入力ができず、ソートもされていない（できない）、検索もできないというリストから目当てのLambda関数を探し当てる必要があります。
存在しているLambda関数が多いアカウントだとかなり厳しい戦いに・・。
コンタクトフローそのものを作成する点については元々は他同様にAWSコンソールからしか作業できなかったのですが2020年8月にAPIが公開されました。
ただし座標マップを含むJSONライクなデータを使用しているため、0から作成するのは難易度が高いです。
初回はGUIベースで作成し、エクスポート機能を使用しCICDで操作する文字列の元ネタにするのがオススメです。
まだまだ洗練されている状態ではないですが、出来るとできないは雲泥の差。
今後もどんどん改善されていくと思うので楽しみです。
まとめ
私自身、AWSを使用した開発はパーソルキャリアに入社してから初めて経験しました。
それまではAzureを使用していたのですがネットワークレイヤ一つとっても考えかたと設計に違いがあり、困惑する事柄も多かったのですが Amazon Connect をはじめ他のクラウドベンダには存在しないサービスも多いです。
今回の勉強会ではグループ会社内でも千差万別なアプローチの仕方があると知れてとても興味深い話が様々な視点から聞ける会となりました！
Kenny Songさんのプロフィール
インフラ基盤統括部 データ共通BITA部 データ基盤グループ リードエンジニア
※2021年5月現在の情報です。
