高可用性のあるコンタクトセンターをAmazon Connectで構築する
📅 2020-04-12
Amazon Connectだけでなく、AWSのサービスは1つのリージョン内で複数のアベイラビリティゾーンにまたがって冗長化を行うことで高可用性を持っているということは、AWSを利用したことのある人は知っているかと思います。
Amazon Connectはマネージドなサービスであるため、内部的にどういったアーキテクチャで高可用性を担保しているのかがわかりません。
昨年2019年12月のre:Inventにて公開された情報を元に内部のアーキテクチャを見ていきましょう。
Amazon Connectの概要
一般的なコンタクトセンター構成
まず一般的なコンタクトセンターの構成要素を見てみましょう。
- 通信キャリアとの接続
- IVR
- 通話のルーティング
- 通話録音
- CTI
- 音声認識
- PBXとの接続
これら全てを持つシステムはあまり存在しないでしょうし、それぞれ別のシステムを導入しているのが一般的かと思います。
Amazon Connectの特徴
主要な特徴です。この中でも重要な要素をピックアップしてみます。
- 100%クラウドベース
- 完全従量課金制
- 面倒な電話通信、キャリアとの接続を気にしなくて良い
- サービス利用者が自分で設定できる
- 動的なコールフローもパーソナライズしたコールフローも作成可能
- その他のAWSサービスやパートナーとの連携が強力
これらの要素があるため、Amazon Connectは先程の一般的なコンタクトセンター構成要素全てをカバーすることができます。（文字が変な感じですが。。）
この図を見ると、お客さんとエージェントの間にはAmazon Connectだけがあるだけです。この中には実際何があるのでしょうか？掘り下げてアーキテクチャベースで見ていきましょう。
Amazon Connectの高可用性
アベイラビリティゾーン（AZ）という概念
AWSにはまずサービスの提供範囲としてリージョンという概念があります。各リージョンは完全に独立しています。
- 東京
- バージニア北部
- シドニー
Amazon Connectがサービス展開されているリージョンの例ですが、要するに東京のAmazon Connectを使用している場合はバージニアやシドニーのリージョンの状態がどうであろうと影響がないということです。リージョンが互いに独立しているためです。
各リージョンの中には、複数のアベイラビリティゾーン（AZ）というデータセンター郡があります。各AZは地理的に離れた場所にありますが、互いに低レイテンシーの冗長化されたネットワークで接続されており、1つのデータセンターではできない高可用性を実現しています。
このAZ郡によって、仮にどれかのAZで停電や災害による停止があった場合にもサービスに影響を与えることなく稼働を続けることができます。
そして、東京には4つのアベイラビリティゾーンがあります。
一般的なAmazon Connectのワークロード
エージェントや管理者のPC、社内のCRMやデータウェアハウスを除いて、全てがAWS上に展開されています。AWS上でも、Kinesis、データウェアハウス、Lambda、Lexといった別サービス連携以外はAmazon Connect内で完結するようにできています。
色々複雑につながっていますが、実際にエージェントや管理者が業務上でアクセスするのは青色の線のみで、Amazon Connectのインターフェース画面とCRMのWebサーバーのみです。
Amazon Connect内部アーキテクチャ
さらにAmazon Connectの内部アーキテクチャを見ていきましょう。
通信キャリアとの接続はAWS Direct Connect（専用回線）で行っています。この専用回線は複数の冗長化された回線で行っています。
接続先では複数のAZにまたがってSBCとEC2がサービスを支えています。先程も書きましたが、これにより高可用性と耐障害性を実現しています。
エージェントのCCP（ブラウザフォン）は各AZのSBCと接続しており、高品質な音声通話を提供します。音声通話のメディアストリームはKinesis Video Streamsへ、ログやメトリクスデータは外部のデータベースに自動で保存されます。保存されたデータは更にS3へ保存することができ、管理者はGUIを通してデータを閲覧することができます。
電話通信、キャリアとの接続の高可用性
Amazon Connectはキャリアとの接続において以下の要件を満たすことで、高可用性を担保しています。
- 各リージョンでは複数の通信キャリアとの接続があります
- 各通信キャリアとは複数の冗長化された接続があります
- フリーダイアル電話番号の通信は複数のキャリアが管理し、キャリア間冗長性を持ちます
- DID番号（直通番号）は1つの通信キャリアで管理され、キャリア間冗長性を持ちません
- DID番号はキャリア冗長性を持ちませんが、複数AZのリンク冗長性を持っているため、リンク障害が起きても別の場所で通話を配信できる機能を提供できます
番号種別の可用性については、アメリカについての記載はありますが東京リージョンではどのようになっているかはわかりません。
AWS は、フリーダイヤル番号を責任ある組織、つまり「RespOrg」として管理します。お客様が番号を要 求したり、Amazon Connect に移植したりすると、その番号を SOMOS に登録します。その番号が登録さ れると、複数のキャリアを選択して、ルートとキャリアの両方の冗長性を提供することができます。これ により、最高レベルの可用性が実現され、キャリアが完全に停止した場合でも、その番号を引き続き利用 できます。フリーダイヤル番号の価格が直通ダイヤルよりも高いため、このレベルのサービスは追加料金 がかかりますが、サービスの信頼性とカスタマーエクスペリエンスにより、これが最も魅力的なオプショ ンとなります。
（中略）
DID 番号は 1 つのキャリアにスレッド化されるため、Amazon Connect では DID 番号のキャリア冗長性を 提供しません。複数のアベイラビリティーゾーンにわたってリンク冗長性を提供しているため、リンク障 害が発生した場合でも、キャリアは別の場所で通話を配信できる機能を利用できます。DID 番号には、1 つの番号で対応できる通話数に関するキャパシティー制限もあり、この番号はリージョンによって異なり ます。プライマリインバウンドチャネルとして DID 番号を使用する場合は、AWS アカウントチームと協力して、適切なタイプの DID 番号で適切に有効化されていることを確認することが重要です。また、1 つ の番号につき 100 を超える同時通話が期待されます。
CCP（ブラウザフォン）の内部アーキテクチャ
一般的なユースケースではコンタクトセンターからインターネット経由でCCPは通信を行います。AWS Direct Connectなどの専用回線やVPNを使用することもできます。
高い音声品質を提供し、エージェントステータスの遅延等が起こらないように、こちらも複数AZにまたがって複数のインスタンスと接続をしています。
その他のコンポーネント
- エージェント管理とコンタクト管理
- ルーティング
- コールフローの実行
- リアルタイムメトリクス
- ヒストリカルメトリクス
Amazon Connectのこれら全てのコンポーネントも複数のAZにまたがって、Active/Active構成で実行されています。
Amazon Connectで高可用性を実現するためのTips
全体構成
- キャリア間冗長化されているフリーダイアル電話番号を活用する（東京リージョンではどうなっているかわかりません。。）
- 別システムとの連携を行う場合には、そのシステムにもAZ冗長性をもたせる
- Amazon DynamoDBやAWS Lambdaといった高可用性を持つAWSサービスを活用する
障害への対策
- AWS LambdaやAmazon Lexは、別のリージョンにも同じものを用意しておくことでコールフロー内でエラーが起きた際にフォールバックすることができます
- 上記のフォールバックは常に設定することも、設定でスイッチすることもできます
- 依存するシステムにエラーが発生した場合に、コールフロー内でフォールバックルーティングを構築することで必要最低限のルーティングを行うことができます
変更と環境の管理
- AWS LmabdaやAmazon Lexのエイリアス機能を利用することで、変更によって起こりうるリスクを最小限にすることができます
- コールフロー内で適切なエイリアスへ向くように即座に変更することができます
- テスト環境と本番環境とでAmazon Connectインスタンスを分け、コールフローのインポート/エクスポート機能で本番環境への適用を行うことができます
- 単一のAmazon Connectインスタンス内でもテストコールフローと本番のコールフローを分けることができ、テストフローがうまくいった場合に本番フローへ移行するということもできます
まとめ
Amazon Connectは99.99%のSLAを掲げています。これは時間でいうと1年のうちに利用不可となる時間が1時間以下ということです。内部のアーキテクチャを見ていかに堅牢なサービスであるかが理解いただけるかと思います。
これを考えると料金はとても安く感じます。
Amazon Connectの料金について
2021年初頭には現在ローカルリージョンである大阪がスタンダードなリージョンへ拡張されることが発表されています。まだ明らかになってはいませんが、大阪リージョンでもAmazon Connectが利用できる場合、リージョン間冗長化を行うことでさらに高可用性、耐障害性を持ったコンタクトセンターを実現できるようになります！
コンタクトセンターの移行や新規での立ち上げの際には第一の選択肢としてぜひ検討してみてください！