マイクロサービス

このサービスは、以下のステートレスなマイクロサービスで構成されています

• Analytics: アシスタントと顧客の間で交わされた会話をログに記録します。 それらのユーザー会話ログは、製品の「分析 (Analytics)」ページ、および /logs API エンドポイントで使用できます。 これは、1.5.0 リリースで導入されました。 Analytics 機能は、Red Hat OpenShift 4.5 以降でのみサポートされるマイクロサービスに依存しています。

• CLU: 言語理解パイプラインへのエントリー・ポイントになる Conversational Language Understanding (自然言語理解 (NLU) とも呼ばれる) インターフェース。ここで、テキストが分析されてインテントおよびエンティティー言及が検出されます。 Store マイクロサービスは、LiteLinks プロトコルを使用してこのマイクロサービスを呼び出し、機械学習トレーニングを開始します。 NLU マイクロサービスは、機械学習モデルのライフサイクルを制御します。 これは、Store マイクロサービスで使用されるワークスペース ID を、パイプラインの内部 ID を理解する機械言語にマッピングします。 NLU マイクロサービスは、機械学習モデルのトレーニング・データを MinIO オブジェクト・ストレージにアップロードします。 言語モデルをトレーニングする必要がある場合 (インテントが編集された後など)、NLU マイクロサービスは Master マイクロサービスを呼び出します。 更新されたモデルが使用可能になると、NLU は TAS マイクロサービスを呼び出して、顧客が入力したユーザー入力を分析します。 ワークスペース ID は UUID フォーマットです。 言語理解パイプライン内のモデルの内部IDは、通常、 vn-[0-9a-f]*-[0-9a-f]* という正規表現パターンに従います。

• CLU Embedding: 言語理解パイプライン内の他のマイクロサービスのための単語埋め込みを提供します。 TAS、 ED-MM、およびトレーニング・ポッドは、gRPC プロトコルを使用して CLU Embedding マイクロサービスを呼び出します。

• Dialog: ユーザー入力に対する応答を生成するためにダイアログ・スキルに定義されている、ダイアログ・ツリーを処理します。 このサービスは、コンテキスト (前に行われた会話ターンから渡された変数) と、ユーザー入力で認識されたインテントとエンティティーに基づき、スキル内のダイアログ・ツリーに従って適切な応答を検出します。 Dialog には、他のサービスまたはプログラムへの、プログラマチック・コールアウトを実行する役割もあります。 このマイクロサービス (Dialog ランタイムと呼ばれることもある) は、Store マイクロサービスによって呼び出される LiteLinks サーバーです。 ダイアログスキル用のインメモリキャッシュがあり、 Redis をダイアログスキルのキャッシュとして使用します。

• ED-MM: ユーザー入力に含まれるコンテキスト・エンティティーを認識します。 このマイクロサービスは言語理解パイプラインの一部となります。 ED-MM とは、Entities Distro model mesh の略です。 ED-MMマイクロサービスのサービス実装は、モデルメッシュパターンに基づいています。 (詳しくは、モデル・メッシュを参照してください。) 処理中のダイアログ・スキルに、そのトレーニング・データ内のコンテキスト・エンティティーが含まれる場合に限り、ユーザー入力を評価するために ED-MM マイクロサービスが TAS マイクロサービスによって呼び出されます。 コンテキスト・エンティティーはコンテキストに結び付けられています。 ED-MM マイクロサービスは、 MinIO からモデルをロードします。 実行時に、エンティティーを検索してコンテキストを検証するためにそれらのモデルが使用されます。 ED-MM マイクロサービスは、単語埋め込みを行うために CLU Embedding にもアクセスします。

• ゲートウェイ： IBM Cloud Pak for Data APIとやりとりし、公開されている IBM Cloud の動作を模倣する適応レイヤー。 そのポッドの名前は ${release-name}-addon-assistant-gw-deployment です。

  ${release-name} は watson-assistant です。

  以下の機能を提供します。

  • サービスのインストールを IBM Cloud Pak for Dataに登録します。
  • API 要求に対して、Store マイクロサービスによって要求された認証データを追加します。
  • サービス・インスタンスが作成または削除されたときに、Store マイクロサービスに通知します。
  • ユーザーが Web UI からインスタンスの詳細を要求したときに、UI マイクロサービスが情報を返すことができるように、IBM Cloud インターフェースのように動作します。

  API 要求が届くと、その要求はまず IBM Cloud Pak for Data ingress nginx サーバーによって処理されます。 nginx サーバーは、要求の許可を検査して認証データを取得するために Gateway マイクロサービスを呼び出すように構成されています。 nginx サーバーは、元の要求にヘッダーを追加してから、Store マイクロサービスを呼び出します。 ただし、初期段階のステップではログが生成されません。 着信した API 要求の最初のログを参照するには、Store マイクロサービスのログを確認してください。

• Integrations: Web チャットやプレビュー・リンクなどの組み込みの統合をサポートするサービス。 これは、1.5.0 リリースで導入されました。

• Master: 基礎となるインテントおよびエンティティー・モデルのライフサイクルを制御します。 このマイクロサービスは言語理解パイプラインの一部となります。 NLU マイクロサービスは、新しいモデルのトレーニングを実行するために、LiteLinks を使用して Master マイクロサービスに要求を送信します。 このタイプの要求は、ダイアログ・スキルが作成されるか、または既存のダイアログ・スキルが更新されると発行されます。 モデルのトレーニングが正常に実行されると、モデルをロードするために TAS マイクロサービスが呼び出されます。

• 数値システムエンティティ ：システムエンティティ（ @sys-date や @sys-number など）で使用される数値の認識を管理します。 これは、1.5.0 リリースで導入されました。

• Recommends: Watson からの推奨 (辞書ベースのエンティティーの同義語やインテントの競合など) をサポートします。 Web UI からのオーサリング時にのみ使用されます。 例えば、ユーザーがエンティティーの同義語の推奨情報を要求すると、UI マイクロサービスは Store マイクロサービスを呼び出します。 Store マイクロサービスは、その要求を Recommends マイクロサービスに転送します。 Recommends マイクロサービスは、MongoDB に保管されている埋め込みを使用して現在の単語の同義語を検索し、それらを Redis キャッシュに保管します。 このマイクロサービスは、同義語のリストを含んだ応答を、Store マイクロサービスに送信します。 ダイアログ・スキル内のインテントの競合を識別する際にも同様のワークフローが使用されます。

• Skill-search: 同じクラスター内で有効にされている Discovery サービス・インスタンスへの API 呼び出しを管理します。 v2 /message API 呼び出しが Store マイクロサービスに到達すると、Store は Redis からセッション状態情報を取得し、スキルの処理を開始します。 処理中のアシスタントに検索スキルがある場合、Store マイクロサービスは HTTPS REST によってこのマイクロサービスを呼び出します。 このマイクロサービスは、 Discovery インスタンスに問い合わせを行い、 Discovery から返された出力を v2 /message APIスキーマに変換します。

• Spellchecker: /message 要求で送信されるユーザー入力のスペルの誤りを訂正します。 この自動修正機能は、英語のダイアログ・スキルに対して自動的に有効になっており、フランス語のスキルに対してもオンにできます。 このマイクロサービスは、語彙単語の編集距離や汎用言語のモデルなどの修正手法を使用して、基本的なスペルチェック機能を提供します。 有効になっている場合、TAS マイクロサービスは、ユーザー入力の意図とエンティティの認識を行う前に、 gRPC を使用してスペルチェッカーを呼び出します。 スペルチェッカーはデータストアに依存せず、他のマイクロサービスを呼び出すこともありません。

• Store: すべてのアシスタント API 呼び出しを処理します。 このマイクロサービスは、リクエスト自体を処理するか、リクエストの処理に必要な他のマイクロサービスを呼び出します。 例えば、顧客が v1 /message APIコールでユーザー入力を送信した場合、そのリクエストはストアに送信され、そこで処理されます。 ステートフル v2 /message API 呼び出しの場合、Store はまず Redis からセッション状態情報を取得します。 次に、NLU マイクロサービスを呼び出して、ユーザー入力を分析し、入力内にあるインテントおよびエンティティーの参照を識別します。 Store は Dialog マイクロサービスを呼び出して、顧客に返す適切な応答を生成します。 Store マイクロサービスは、アシスタント、スキル、およびワークスペース定義を PostgreSQL データベースに保管します。 Store マイクロサービスはセッションの状態 (v2 API から) を Redis データ・ストアに保存します。

• TAS: モデルの推論を実行します。つまり、ユーザー入力内の最も一致するインテントおよびエンティティーを識別します。 TAS は、Train and Serve の略ですが、たいてい既存のモデルを提供します。 TAS マイクロサービスは、MinIO ストレージからメモリーにモデルをロードし、そのモデルを実行してインテントを検出します。 TAS マイクロサービスは、LiteLinks を使用して NLU マイクロサービスから呼び出されます。 TAS マイクロサービスと ED-MM マイクロサービスは、モデル・メッシュ・パターンに基づいています。 (詳しくは、モデル・メッシュを参照してください。) 必要に応じて、TAS は、言語理解パイプラインに属する他のマイクロサービスの呼び出しもそこで行われます。 具体的には、トークン化のための SireG、コンテキスト・エンティティー用の ED-MM (gRPC を使用)、ミススペルを修正するための Spellcheck を呼び出します。 意図認識のため、TASマイクロサービスはワードエンベッディングデータが必要であり、これはCLUエンベッディングマイクロサービスによって提供されます。

• TF-MM: テンソル・フロー・モデル・メッシュ・マイクロサービスは、Universal Sentence Encoder モデルおよび自動エンコーダー・モデルを管理し、本題から外れた話題および無関係のインテントの認識を改善します。 これは、1.5.0 リリースで導入されました。

• UI: スキルとアシスタントを作成するために仮想アシスタント・ビルダーが使用する Web アプリケーション。

データ・ソース

マイクロサービスは以下のリソースを使用します

• Elastic: Elastic データ・ストアには、顧客のメッセージが保管されます。 これらのユーザー会話ログは、アナリティクスのページから確認したり、 /logs API エンドポイントから検索したりすることができます。 これは、1.5.0 リリースで導入されました。

• Etcd: よく使用される、分散型のキー値ストレージ・ソリューション。 Etcd は、サービス・ディスカバリーのために Litelinks のクライアントおよびサーバー (Store、Dialog、NLU、Master、TAS、ED-MM) によって使用されます。 メタデータの保管のために、言語理解パイプラインに属するマイクロサービス (NLU、Master、TAS、ED-MM) によって使用されます。 詳しくは、Etcd ストアを参照してください。

• Kafka: 着信した顧客からのメッセージを入れるためのキューイング・システム。 これは、1.5.0 リリースで導入されました。

• PostgreSQL: よく使用されるリレーショナル・データベース。 このデータベースは、Store マイクロサービスによってのみ使用されます。ワークスペース、スキル、およびアシスタントのための 1 次ストアです。 PostgreSQL に関連したデプロイメント名とポッド名には、${release-name}-store-postgres が接頭部として付けられます。 詳しくは、PostgreSQL データ・ストアを参照してください。

• マルチクラウド・オブジェクト・ゲートウェイ: Multicloud Object Gateway は、 Amazon S3 API を実装するオブジェクト・ストレージ・サービスです。 これは、言語理解パイプラインのマイクロサービス（clu-controller、clu-serving、clu-training、tf-mm、ed-mm、dragonfly）によって使用され、インテントおよびエンティティ分類のトレーニング済みモデルの保存と読み込みに使用されます。 これは、スキルのバージョン管理されたデータを保管するためにオーサリングおよびランタイム・サービス (ストア) によって使用され、オーサリング・エクスペリエンスの非同期アップロードの一時ストレージとしても使用されます。 Watson Assistantでは、Multicloud Object Gateway は多くの場合、 Cloud Object Storageと呼ばれます。 詳しくは、 Multicloud Object Gateway を参照してください。

• Redis: メモリー内データ・ストア。セッション状態のキャッシングまたは共有のためによく使用されます。 Redis は、アシスタントの現在の会話状態を格納するために、Store マイクロサービスによって使用されます。 UI マイクロサービスは、セッション状態を Redis に格納します。 Recommends マイクロサービスと Dialog マイクロサービスは、Redis インスタンスをキャッシュとして使用します。

1.5.0: 1.5.0 リリース以降、以下のデータ・ソースは使用されなくなりました。

• MongoDB: ドキュメント指向のデータベース。 Mongo は、同義語の推奨情報のために Recommends マイクロサービスによって使用される埋め込みなどのデータを保管するために、読み取り専用モードで使用されます。

  MongoDB は、ドキュメント・ベースの分散データベースです。 MongoDB データベースには 3 つのポッドがあります。 replicaSet モードで実行されるため、ポッドの 1 つは読み取り/書き込みモードのコーディネーターの役割で実行され、残りのポッドは読み取り専用のセカンダリーの役割で実行されます。 コーディネーター・ポッドでの変更内容は、セカンダリー・ポッドに複製されます。 サービスのインストール時に、Kubernetes ジョブによってデータが Mongo データベース内にロードされます。 サービスがインストールされた後は、Mongo データベースにデータは書き込まれません。 Mongo からデータを読み取るのは、Recommends マイクロサービスのみです。 Recommends ポッドは作成時に、Mongo が稼働しているかどうかを検査し、必要なデータが Mongo データベースにロードされるまで待機します。

  インストールの一環として行われる、Mongo データベースへの Recommends 用のデータのロードのプロセスには、30 分 (またはそれ以上) かかる場合があります。

  • mongoDB ポッドの名前は、${release-name}-ibm-mongodb-server-[0-9]* という規則に従って付けられます。 リリース名が長い場合、その名前は ${release-name prefix}-[a-f0-9]{4}-336f-server-* に短縮されます。
  • サービスのインストール中に実行される Kubernetes ジョブの名前は、 ${release-name}-recommends-load-mongo です。

  ${release-name} は watson-assistant です。

4.7.0: 4.7.0 リリースより、以下のデータソースは使用されなくなりました

• MinIO: MinIO は、Amazon S3 API を実装するオブジェクト・ストレージ・サービスです。 インテントおよびエンティティーの分類のために、トレーニングされたモデルを保管およびロードする言語理解パイプラインのマイクロサービス (NLU、Master、TAS、ED-MM、トレーニング・ポッド) によって使用されます。 データは nlclassifier-icp バケットに保管されます。 Watson Assistant では、MinIO は COS と呼ばれることがよくありますが、これは Cloud Object Storage の略です。 詳しくは、MinIO を参照してください。

トレーニング・コンポーネント

新しいモデルのトレーニングは、一度限りの、短時間でリソースを多く必要とする活動です。 モデルは、オンデマンドで作成されるポッドでトレーニングされます。 それらのポッドは、トレーニングが完了した後に削除されます。 その一時的な性質のため、トレーニングの要素は標準的なマイクロサービスの一つとは見なされていません。 コンポーネントであるトレーニングポッドは、モデルのトレーニングが必要な場合にのみ使用されます。 ダイアログ・スキル内でインテントのユーザー例が追加または変更されるたびに、トレーニングが開始します。

新規機械学習モデルのトレーニングが必要になると、CLU マイクロサービスが Master マイクロサービスにそのことを通知します。 Master マイクロサービスは、トレーニング・ポッドを動的に作成します。 トレーニング・ポッドの削除と、トレーニングの実行が失敗した場合のリトレーニングを実施します。 また、モデルが削除された場合は、 MinIO からそのモデルを削除する役割も担っています。 システムは、トレーニングの実行が正常に完了したかどうかの判別を、MinIO ストレージに保管されているフラグに基づいて行います。 Master マイクロサービスは、トレーニング・イメージが保管されている Docker レジストリーに対する API アクセスを必要とします。 そのレジストリーから取得するイメージ・メタデータを使用することで、トレーニング・ポッドが正しく開始します。

このコンポーネントによって開始されたトレーニング・ポッドは、SLAD ポッドと呼ばれることがあります。 SLAD は Statistical Learning and Discovery の略です。これは、ポッドで使用される言語分類器を開発したリサーチ・グループの名前です。 トレーニング・ポッドの名前は、先頭が tr[12]? で、その後に vn-… という内部 ID が付きます。 トレーニング・イメージの名前は、チャートのバージョンに応じて nlclassifier-training または clu-training となります。 ${release-name}-master-config 構成マップには、トレーニング・ポッドの JSON テンプレートが含まれます。

${release-name} は watson-assistant です。

データ・ストアの詳細

以下のセクションでは、サービスでデータストアがどのように使用されるかについて、さらに詳しく説明します。 この情報は、インストール時、またはデータ・センターでサービスがデプロイされて稼働するようになってから発生する問題をトラブルシューティングするときに役立てるためのものです。

モデル・メッシュ

TAS マイクロサービスと ED-MM マイクロサービスでは、モデル・メッシュ・パターンを使用します。 モデル・メッシュでは、ロードされた NLP モデルのセットが各ポッドに入っています。 モデルがロードされる場所の管理は、モデル・メッシュ・ライブラリーによって扱われます。 通常運用時には、モデルは 1 つのポッドにのみロードされます。 モデルへのトラフィックを単一のポッドで処理できない場合は、モデルが他のポッドにもロードされます。 モデルがロードされる場所に関するメタデータは、Etcd に保管されます。

TAS と ED-MM は、別々のモデル・メッシュ・グループに属しています。 それぞれのグループには、ポッドおよびロードされたモデルからなる独立したセットがあります。

モデル・メッシュは、ED-MM マイクロサービスのポッド・グループで次のように機能します。 ED-MM マイクロサービスの場合、A と B の 2 つのポッドがあるとします。 コンテキスト・エンティティー認識に関する gRPS 要求は、 Kubernetes DNS を介して受信されます。 要求はポッド A に送られますが、必要なコンテキスト・エンティティー・モデルがポッド B にロードされます。 ポッド A のモデル・メッシュは、 LiteLinksを使用してポッド B に要求を転送します。 ポッド B は、適切なモデルを使用して入力内のコンテキスト・エンティティーを識別し、応答をポッド A に送信します。 ポッド A は、最初の gRPC 要求を送信したサービスに応答で情報を送信します。

TAS マイクロサービスの場合も、モデル・メッシュは同様に機能します。 違いは、TAS への着信要求が、gRPC ではなく LiteLinks を使用して送信される点です。 そのため、NLU マイクロサービスと Master マイクロサービスには、どのモデルがどの TAS ポッドにロードされたかを認識する手段がありません。