IBM Cloud Docs
フェイルオーバー・オプション

フェイルオーバー・オプション

組織の watsonx Assistant の可用性を高めるために使用できるオプションについて説明します。

概要

IBM® watsonx™ Assistant インスタンスは、マルチゾーン・リージョン (MZR) (韓国ソウルを除く) にわたるすべてのデータ・センターにおいてデプロイされ、MZR 内にある個別ゾーンのいずれかが失われても持ちこたえることができます。 ただし、地域的な障害が発生する可能性があり、 IBM は障害を最小限に抑えるために努力していますが、ビジネス上重要なアプリケーションのために別の地域にトラフィックを移動することを検討することをお勧めします。

watsonx Assistant インスタンスのコピーを別の MZR に配置する必要があります (例えば、米国東部と米国南部にアシスタントをデプロイします)。 watsonx Assistantの 2 つ目のサービス・インスタンスを購入する必要があり、必要なアシスタントとスキルの 2 つ目のインスタンスをインスタンス化する必要があります。2 つのリージョン間で変更を同期するには、変更管理コントロールを実装する必要があります。watsonx Assistant サービスおよび Speech サービスには、定義をエクスポートおよびインポートするために使用できる API があります。

2 つのインスタンスがある場合、以下の 2 つのトポロジーを考慮してください。

  • アクティブ/アクティブ: 両方のインスタンスが常にトラフィックにサービスを提供し、2 つの間に負荷が分散されます。
  • アクティブ/パッシブ: 1 つのインスタンスがアクティブで、パッシブ・サイトがトラフィックを受信するのは、フェイルオーバーが発生した場合のみです。

それぞれのアプローチには長所と短所があります。 watsonx Assistant に固有の考慮事項については、以下のセクションで詳しく説明します。

考慮事項

1 つの地域の IBM® watsonx™ Assistant インスタンスは、2 番目の地域のインスタンスを認識しません。これは、 watsonx Assistantの一部の機能に影響する可能性があります。

分析

IBM® watsonx™ Assistant 分析では、ユーザーとの対話数および包含率に関する概要統計が提供されます。 分析では、地域間の統計は累積されません。 アクティブ/パッシブ・トポロジーでは、分析に対するこのアプローチで十分です。 ただし、アクティブ/アクティブ・トポロジーを使用する場合は、 Webhook を使用して対話データを収集し、カスタム・データウェアハウスおよびレポートを作成して合計使用量を把握する必要があります。

Web チャットと v2 api のセッション履歴

セッション履歴を使用すると、ユーザーがページを最新表示したり、同じ Web サイト上の別のページに変更したりしたときに、Web チャットで会話の履歴とコンテキストを維持できます。 この機能はインスタンス間で機能しないため、進行中の会話を再開する必要があります。

課金

IBM は、 IBM Cloud アカウントに基づいて請求書を計算します。 IBM® watsonx™ Assistant は、以下のように特定のサービス・インスタンス内で集約することで、月次平均ユーザー (MAU) メトリックを計算します。

  • 同じ サービス・インスタンス内で 2 つの異なるアシスタント・リソースで使用されている同じ MAU は、1 MAU としてカウントされます。
  • 異なる サービス・インスタンス内で 2 つの異なるアシスタント・リソースで使用される同じ MAU は、2 つの MAU としてカウントされます。

アクティブ/アクティブ ・トポロジーの場合、最悪のシナリオでは、請求期間中に MAU カウントが 2 倍になる可能性があります。

電話統合機能

ある地域の電話統合は、別の地域の電話統合を認識しません。 アシスタントが両方の領域で同じように構成されていることを確認する必要があります。 また、リージョン間のフェイルオーバーを検出して管理するには、アップストリーム SIP トランキング・プロバイダーに依存する必要があります。

Monitoring

SIP トランキング・プロバイダーは、リージョン内の各ゾーンに定期的に SIP OPTIONS メッセージを送信することにより、watsonx Assistant セッション・ボーダー・コントローラー (SBC) をアクティブにヘルス・チェックするように構成できます。 応答の受信の失敗は、手動フェイルオーバーをトリガーする失敗の通知を提供するか、または経路リストからの失敗したゾーンの削除を自動化するために使用できます。

フェイルオーバー

SIP トランキング・プロバイダーは、特に領域間で自動フェイルオーバーが予期される場合に、フェイルオーバーの検出と管理において重要な役割を果たします。 通常、SIP トランキング・プロバイダーは、リージョン内の各ゾーンをアクティブ/アクティブとして扱い、アシスタントがアクティブ/パッシブとして構成されている 2 つのリージョンとして扱うように構成する必要があります。 SIP トランキング・プロバイダーは、常に、単一リージョン内のゾーン間で負荷とフェイルオーバーのバランスを取るように構成する必要があります。

完全な停止

電話統合の失敗には 2 つのタイプがあります。 1 つ目のタイプは、3 つのすべてのリージョン・ゾーンのセッション・ボーダー・コントローラーが到達不能になる完全な停止です。 SIP トランキング・プロバイダーは、通話が失敗したことを SIP タイムアウトによって即時に通知され、自動的にフェイルオーバーするように構成することができます。あるいは、SIP トランキング・プロバイダーで手動でコール・ルーティングを再構成して、障害が発生した領域からパッシブ・バックアップ領域にトラフィックを移動するようにすることができます。 フェイルオーバーが自動化され、リージョン・バックアップが有効になっている場合は、事前構成された数の障害が短期間で発生した場合にのみ、常に別のゾーンを最初に試行し、トラフィックをパッシブ・バックアップ・リージョンにリダイレクトすることをお勧めします。 これにより、短時間の停止のみが発生した場合に、リージョン間の不要なフェイルオーバーが回避されます。

IBM® watsonx™ Assistant は、リージョン内の各ゾーンの IP アドレスを含むラウンドロビン完全修飾ドメイン名 (FQDN) を提供します。 多くの SIP トランキング・プロバイダーは、障害が発生すると、FQDN 内の各 IP を自動的に再試行します。 災害復旧をサポートするために、サービス・プロバイダーは、2 つの別個の SIP トランク (リージョンごとに 1 つずつ) を構成する必要がある場合があります。これは、1 つのリージョン内のすべてのゾーンが失敗した場合にのみ、呼び出しをバックアップ・リージョンに切り替える必要があります。 SIP トランキング・プロバイダーで SIP INVITE 障害タイムアウトを十分に低く設定して、フェイルオーバーの発生時に長い通話セットアップ待ち時間が発生しないようにすることが重要です。

部分的な停止

2 番目のタイプの障害は、地域内の部分的なサービス停止です。 部分的な停止は、1 つの地域内で発生する可能性のあるサービス障害の変動が多いため、検出と管理が非常に難しくなります。 場合によっては、小さな問題が呼び出しのパフォーマンス特性に影響を与えるが、呼び出しの失敗の原因にはならないことがあります。

最終的に通話が失敗する原因となる問題の場合、アシスタントが通話を処理する方法は 2 つあります。 1 つ目は、通話を受け入れて、それを構成済みのデフォルト SIP URI に転送することです。 この設定は電話統合で構成でき、通話中の失敗にも使用されます。 デフォルトの転送ターゲット SIP URI は、電話統合構成の「拡張」タブにある 「通話が失敗した場合の SIP ターゲット」 フィールドで定義されます。

電話統合は、通話をライブ・エージェントに転送する代わりに、通話のセットアップ中に障害が検出された場合に SIP 500 (サービス利用不可) メッセージを使用して SIP INVITE に応答するように構成することもできます。 その後、SIP 500 を使用して、通話を別のゾーンにリダイレクトしたり、多数の SIP 500s を受信した場合は別のリージョンにリダイレクトしたりすることができます。 SIP 500 INVITE エラーを使用することは、アップストリーム SIP トランキング・プロバイダーに障害をシグナル通知するためのより良い方法です。これは、プロバイダーが通話を転送する方法を提供するためです。 通話量が少ないシナリオでは、デフォルトの転送ターゲットのみを使用して通話の失敗を処理することができますが、アシスタントによって処理される通話量が多いと、多数の通話が顧客コンタクト・センターに送信される可能性があります。 特定のインスタンスに対してこの 500 エラー応答機能を有効にするには、 IBMに要求を行う必要があります。

完全なサービス停止と部分的なサービス停止の両方を計画する必要があります。 最初のステップとして、自動化を有効にする前に、領域間の手動フェイルオーバーを計画することをお勧めします。 すべてのカスタム音声モデル・トレーニングを含め、両方の地域に watsonx Assistant の完全なレプリカが必要です。 自動化が有効になっている場合は、完全なリージョン障害が検出されたときにパッシブ・バックアップ・リージョンを検出してフェイルオーバーするための戦略から開始することをお勧めします。 実装後に、電話統合デプロイメントで発生する可能性があるほとんどの障害状態をカバーする部分的な障害に対処するための戦略を策定します。

Web チャット

Monitoring

Web チャットには onError リスニング機能が用意されています。この機能を使用すると、ホスト・ページで特定のタイプの停止エラー (特に INITIAL_CONFIG、OPEN_CONFIG、および MESSAGE_COMMUNICATION エラー) を検出できます。

詳しくは、 エラーの listenを参照してください。

フェイルオーバー

Web チャットのフェイルオーバーの処理は、別の地域で追加の Web チャット統合をセットアップすることを前提とすると、簡単です。 フェイルオーバーを手動でトリガーする必要がある場合は、以下の変更を行います。

  • 統合 ID、リージョン、サービス・インスタンス ID、およびサブスクリプション ID (該当する場合) を含む組み込みスクリプトは、新しい統合とリージョンの ID を使用するように変更または更新する必要があります。
  • ヒューマン・エージェントに接続するために Salesforce または ZenDesk の統合を使用している場合は、それらのシステム内の構成を更新して、正しい統合と通信できるようにします。 これらのシステムをセットアップするには、Web チャット構成の「ライブ・エージェント」タブの指示に従ってください。 この機能は、エージェントの会話履歴を取得するためにのみ必要です。
  • Web チャット・セキュリティーを有効にしていて、暗号化されたペイロードを使用している場合、暗号化に使用される IBM提供の公開鍵は、地域によって異なる可能性があります。 その場合は、正しい鍵を使用するように、JSON Web Token (JWT) を生成するシステムを更新する必要があります。

組み込みスクリプトでさまざまな統合 ID を使用し、ユーザーが Web チャット統合を「スティッキー」にすることで、Web チャットのアクティブ/アクティブ構成をセットアップできます。 そうしないと、ユーザーが別の統合にフェイルオーバーした場合、会話履歴が失われる可能性があります。

API

Monitoring

/message 呼び出しの応答コードをキャプチャーしてモニターします。 ライブ /message トラフィックの応答コードをキャプチャーして集約する必要があります。

理想的には、応答コード統計を外部パーシスタンス・ストアに保存します。 この共有ストアは、アプリケーションのすべてのデプロイ済みインスタンスからの応答コード結果を集約し、フェイルオーバーをトリガーするかどうかを決定する際の最大の精度を提供します。

あるいは、応答コードを集約して、アプリケーションのインスタンスのメモリー内で評価することもできます。 一部のトラフィックのみがフェイルオーバーの決定に寄与しているため、フェイルオーバーの決定が行われる頻度に影響する可能性があります。

どちらの集約アプローチでも、定義されたしきい値を超えるとフェイルオーバーがトリガーされる可能性があります。 フェイルオーバーを決定する一般的な方法には、以下のものがあります。

  • パーセンテージ・ベース: 要求の X% を超えると、non-200 応答コードが返されます。
  • 連続ベース: 行内の X 呼び出しは non-200 応答コードを返します。
  • 制限ベース: X 呼び出しは、時間フレーム内に non-200 応答を返します。

領域間の不要なフェイルオーバーを回避するには、 /message エンドポイントを呼び出すときに、堅固な再試行メカニズムが存在することを確認してください。

v1 および v2 ステートレス API のフェイルオーバー

正常なフェイルオーバーの場合:

  • トレーニング・データの変更は、地域間で同期する必要があります。 更新される領域間で watsonx Assistant によってデプロイされるアルゴリズムの変更のリスクを軽減するために、大きな時間枠 (日数など) で遅延した変更をプッシュしないようにしてください。
  • サービス全体の単一の請求書を維持するには、地域間のサービス・インスタンスに同じ IBM Cloud アカウントを使用する必要があります。
  • クライアント・アプリケーションは以下をサポートする必要があります。
    • IBM® watsonx™ Assistant API ホスト名
    • サービス・インスタンス資格情報
    • v1: workspace_id
    • v2: assistant_id

/message の呼び出しのランタイム・フローには影響しませんが、 IBM Identity and Access Management (IAM) を使用する微細化されたアクセス制御を使用する場合は、地域間で IAM ポリシーが同期されていることを確認してください。  IAM はグローバル・サービスですが、 watsonx Assistant アクセス制御で使用されるカスタム・リソース (アシスタントとスキル) は、特定のリソースを持つ各地域に特定のポリシーが必要であることを意味します。

アクティブ/パッシブ トポロジーの場合、何らかの形式の 回路ブレーク・パターン を使用できます。 エラーが検出されない限り、1 つのリージョン内の 1 つのサービス・インスタンスのみが使用されます。その時点で、システムは、関連するフェイルオーバー・メタデータを更新して、他のリージョンのサービス・インスタンスにトラフィックをルーティングすることで応答できます。 フェイルオーバーが発生した場合は、新しいリージョンをアクティブ・インスタンスとして引き続き使用するか、初期リージョンが安定したときにそのリージョンの使用を再開するかを決定できます。

アクティブ/アクティブ ・トポロジーの場合、何らかの形式のロード・バランシングを使用できます。このロード・バランシングでは、異なる地域にある複数のサービス・インスタンスが常に一定の割合のトラフィックを受信します。 ローテーションから領域をプルするタイミングを決定するには、追加のロジックを確立する必要があります。 このモニター・ロジックでは、アクティブ/パッシブ構成に類似した 回路ブレーク・パターン を使用することも、領域の正常性を判別する別個の専用モニター・フレームワークに依存することもできます。 アクティブ/パッシブと同様に、ローテーションに領域を挿入するタイミングを決定することも考慮する必要があります。

v2 ステートフル API のフェイルオーバー

v2 ステートフル API のフェイルオーバーはステートレスに似ていますが、以下の詳細を考慮する必要があります。

  • 会話の状態は、特定の領域に結合されたデータベース内の watsonx Assistant によって保持されます。 そのため、ステートフル v2 /message のフェイルオーバーは中断を伴う可能性があります。
  • アクティブ/パッシブ トポロジーの場合、進行中のすべての会話が終了したと想定する必要があります。
  • アクティブ/アクティブ ・トポロジーの場合、 v2 ステートフル /message ・アーキテクチャーの領域ロック・パーシスタンス制約を考慮すると、会話 (セッション) のすべてのターン (/message API 呼び出し) が同じ領域内で発生する必要があります。