マイクロサービスアーキテクチャ
古いアプリケーションの問題
多くの古いクラウド アプリケーションには、一体式のアーキテクチャが使用されています。 これらのレガシー アプリは複数のテナントにサービスを提供できるものの、内部依存性の高いコンポーネントの大規模で扱いにくいセットとして構築されています。 1 つのコンポーネントの失敗が別のコンポーネントに破壊的な影響を与え、その結果、多数のまたはすべてのテナントにサービスの停止を招く可能性があります。 これらのシステムを更新するには、それらをオフラインにする必要があり、アップグレード処理中はユーザーのアクセスが制限されます。 ハードウェアの制限がソフトウェア リソースの応答可能性とスケーラビリティをさらに制約する
Genesys Cloudマイクロサービスソリューション
Genesys Cloudは、マイクロサービスを使用してモノリシックアーキテクチャの問題を解決します。 マイクロサービスの使用により、複雑な問題をシンプルなステートレス オブジェクトにて解決します。 当社のマイクロサービス アーキテクチャはまた、地理的に散在している多数のデータセンターにまたがる数千ものサーバー間でほぼ無制限なスケーラビリティを提供しています。
Genesys Cloudは、いくつかの緊密に結合されたコンポーネントを使用する代わりに、その機能をサービスに分割し、各サービスが特定のタイプのリクエストを処理します。 PureCloud の各サービスは、イラスティック ロードバランサー (ELB) を使用して負荷を分散させ、各グループに複数のサーバーを含めて負荷に基づきダイナミックにスケールします。 我々 は継続的にサービス レベルのトラフィックを監視し、使用率レベルと要求の種類に基づいて microservices を最適化します。
この図は、Genesys Cloudの主要サービスを示しています。
オンデマンドのスケーリング
ほとんどのGenesys Cloudサービスは、自動スケーリンググループ(ASG)を持つELBを使用します。 Genesys Cloudは、サービス固有のポリシー(コンピューティング集約型サービス用CPU、クエリサービスの平均応答時間など)に従ってロードを分散し、グループを監視します。 しきい値ポリシーを超えると、グループは必要に応じて追加のリソースを自動的に追加または削除します。 たとえば、ある組織が突然何百万ものファックスを送信する必要がある場合、他の機能や他のテナントに影響を与えることなく、関連するマイクロサービスが自動的に需要を満たすようにスケールアウトします。
フェイルセーフ処理
マイクロサービスは独立して機能するため、1 つのマイクロサービスの問題が他のマイクロサービスに影響を与えることはなく、潜在的な問題が制限されることになります。 たとえば、3 つの独立した microservices はボイス メールを取得、送信 fax および顧客の着信通話のルーティングを処理します。 ボイス メール検索 microservice が失敗した場合、受信したカスタマーの呼び出し microservice は中断することがなく機能し続けます。
回復による信頼性
個々のサーバーに障害が発生すると、適切なELB / ASGがヘルスチェックの失敗またはタイムアウトを検出し、異常なコンポーネントをロードバランサーから切り離します。 エラーが一時的でない場合、追加のロジックによって自己ヒーリング動作がトリガーされ、エラーのあるノードが停止し、完全に新しいサーバーが作成されてその役目を取って代わります。 トラフィックは、余分な作業をシームレスに収容グループ内の他のサーバーと、衰えることがなく続けてください。 Genesys Cloudは、ユーザーがサービスギャップに気付く前に回復します。 この復元処理により、リソースの急激な上昇が生じますが、Amazon Web Services (AWS) を介して十分なオンデマンドの帯域幅にアクセスできます。
Genesys Cloudは、国際的なクラウドベースのデプロイメントにおいて誰もが認めるリーダーであるAWSの上に構築されています。 私たちはアマゾンと緊密に協力し、彼らのモニタリングとELBシステムをテストし、改良しています。
AWSリージョン
Genesys Cloudは、世界中の複数の独立したAWS地域に導入されています。 各領域は、複数の Amazon の「空きゾーン」からなり、それぞれが 1 つ以上の実際のデータ センターから構成されています。 冗長性はこのレベルでもシステムのファブリックに組み込まれており、各アベイラビリティーゾーンは別々の電源、バックボーンネットワーク接続、複製されたデータメモリ、および（場合によっては）構造的な断層プレートにまたがる物理的分離を持ちます。 カスタマー データは、リージョン内のゾーンおよびデータ センター間でレプリケートされます。 1 つのデータ センター全体を失っても一時的に容量が低下するだけで、その状況はデータの損失なく自動的に修復します。 データの耐久性を確保するため、に加えてデータ主権はまたクラウド展開の重要な側面であります。 Genesys Cloudアーキテクチャにより、組織は「記録地域」を定義し、データがインフラストラクチャ内の地域境界を横切ることがないようにすることができます。
Genesys Cloud Voice展開のためのAWS地域
ブラウザとモバイルクライアント
多くの点で、Genesys Cloudクライアントはマイクロサービスによって使用されるステートレスアプローチをミラーリングします。 ブラウザがGenesys Cloudをレンダリングすると、データ更新のイベント通知など、一連のオブジェクトがブラウザメモリに組み込まれます。 新しい情報がブラウザーによって受信される、メモリ内のオブジェクトを更新し、ユーザーのビューを更新します。
ユーザーがビューを変更したり新しいタスクを開始したりするたびに、既存のローカルデータが直ちに表示され、更新の確認が要求されます。 これらのデータ要求は利用可能なサービスに合わせて形、データ帯域幅を削減し、クライアント ビューの速度を向上するように最適化します。
継続的なアップデート
当社は、Genesys Cloudシステムの生産に新しいコードを継続的に導入しています。 マイナーな欠陥が検出されたら、すぐにそれを修正して影響のあるサービスの新しいバージョンをプッシュします。
当社の分散型アーキテクチャにより、メンテナンスのためにシステム全体を停止することなくローリングアップデートをリリースすることができます。 当社では負荷分散や「red-black デプロイ」などの手法を使用して、カスタマーが当社の更新プロセスによって悪影響を受けないようにしています。 (新しい機能や修正が含まれている) microservice の新しいバージョンが入手できる場合は、そのサービスのための完全に新しいサーバー イメージを作成します。 システムにパッチを施すのではなく、このイメージを使用して全く新しいサーバーを作成します。 これらの新しいサーバーがオンラインになって正常性が確認されたら、ロードバランサーに接続され、少量のトラフィックがそれらのサーバーによって処理されるようになります。 新しいサーバーが期待通りに機能すると仮定し、容量を追加して古いサーバー （サービスの旧バージョンを持つ) をロードバランサーから外し、未処理のリクエストを破棄します。 数分以内で、対象マイクロサービスの機能を提供しているサーバー群全体を置き換えることができます。 WAN インターフェイスにパブリック IP は必要ありません。 インプレースアップグレードを避け、本番前環境でテストしたシステムが本番でデプロイされるシステムと機能的に全く同等であることを保証することで、脆弱性を低減します。 それはまた、新バージョンが万一期待通りに機能しない場合には、マイクロサービスの良好なことが知られているバージョンまですばやくロールバックできます。それはまた、新バージョンが万一期待通りに機能しない場合には、マイクロサービスの良好なことが知られているバージョンまですばやくロールバックできます。
マイクロサービスの独立性と当社の広範な自動テストおよびビルドプロモーションプロセスにより、Genesysは誤って他のものを壊すことを恐れずにバグ修正を推進することができます。 さらに、Genesysは既存のサービスに影響を与えずに新機能用のマイクロサービスを作成できます。 更新は数百万のお客様がGenesys Cloudを積極的に利用している間に行われます。
