音声入力を使用した本番環境対応のライブ音声文字変換のアーキテクチャ

このガイドでは、音声入力Google Kubernetes Engine(GKE)Memorystore などの Google Cloud テクノロジーを使用した、可用性と復元力が高いライブ音声文字変換を提供するアーキテクチャについて説明します。このガイドは、デベロッパーとアーキテクトを対象にしており、Kubernetes と GKE に関する基本的な知識があることを前提としています。概要についての説明が必要な場合は、GKE の概要をご覧ください。

このアーキテクチャを実装するには、関連するチュートリアルをご覧ください。

はじめに

音声のライブ ストリームをテキストに変換するためのユースケースは数多くあります。報道機関は音声をその場で文字に変換し、ライブ配信用の字幕を生成します。電話の通話やミーティングはリアルタイムで文字に変換され、聴覚に障がいのある人も参加できるようになります。会議やイベントでは、主催者がライブ音声を文字変換して、参加者にテキストで表示できます。

現在使用されている音声文字変換ソリューションの多くは、熟練した人間のオペレーターと専用のソフトウェアを組み合わせる必要があります。このプロセスは人間のオペレーターに依存するため、音声文字変換の作業の規模を拡大するのが難しい場合があります。つまり、通常は小規模なライブ配信やイベントに対してのみ音声文字変換を実施することが可能です。

音声入力は音声文字変換をサポートします。音声入力に音声のストリームを渡すと、リアルタイムで音声文字変換されて、テキストのストリームが返されます。音声入力を使用すると、報道機関ではこれまでの音声文字変換処理を自動化して増強し、人間のオペレーターへの依存を減らして音声文字変換作業の範囲を拡大することが可能となります。

音声文字変換を利用するユーザーにとっては、品質、レイテンシ、整合性が重要な要素になります。これは、ライブ配信やイベントに音声文字変換が含まれている場合に特に当てはまります。遅延やドロップが頻繁に発生すると、ユーザー エクスペリエンスが低下し、不満が生じます。そのため、どの音声文字変換ソリューションでも、質の高いテキスト変換を提供する必要があります。ただし、障害や停止によって音声文字変換の中断を最小限にするために、高可用性と復元力を確保する必要もあります。このガイドでは、可用性と復元力の高いライブ音声の文字変換を行うソリューションの主な要件を満たすアプリのアーキテクチャについて説明します。

アーキテクチャ

本番環境に対応した音声文字変換アプリの Google Cloud 上におけるインフラストラクチャのアーキテクチャ

このアーキテクチャには、次の機能が含まれています。

  • 3 つのアプリのマイクロサービス:
    • Ingestor。このサービスはソース音声ストリームを取り込みます。
    • Transcriber。このサービスは音声入力を呼び出し、音声文字変換結果を出力します。
    • Reviewer。このサービスは、レビューのために音声文字変換結果をウェブアプリに表示します。
  • GKE。複数のゾーンにまたがるリージョン GKE クラスタでアプリのマイクロサービスをホストします。アプリのマイクロサービスはゾーンをまたいでデプロイされます。
  • Memorystore for Redis。高速な中間ストレージとして使用されます。これは高可用性構成でデプロイされます。
  • ロードバランサ。以下のことを行うためにアプリ機能をインターネットに公開します。
    • ソース音声ストリームの転送先 IP アドレスを指定します。
    • 審査担当者のウェブアプリを提供します。

要件と推奨事項の概要

このセクションでは、音声文字変換を行うアプリの要件の例と、要件に対処するための推奨事項を示します。特に記載がない限り、推奨事項については後のセクションで詳しく説明します。

要件 推奨
アーキテクチャは柔軟で、疎結合されている必要があります。 アプリを一連の独立したコンテナ化されたマイクロサービスとして設計します。GKE を使用してマイクロサービスの管理とオーケストレートを行います。
アーキテクチャは、単一のリージョン内で高可用性がある必要があります。 リージョン GKE クラスタを使用して、ゾーン間でアプリのマイクロサービスを冗長的にデプロイします。
アプリは取り込み用の固定 IP アドレスを提供する必要があります。 Ingestor サービスを LoadBalancer タイプの Kubernetes Service としてデプロイします。
アプリは、人間のオペレーターが音声文字変換をレビューするためのメカニズムを提供する必要があります。 音声文字変換をリアルタイムに表示するウェブアプリを提供します(この要件については、このドキュメントでは詳しく説明していません)。
音声はリアルタイムで音声文字変換する必要があります。 音声入力のストリーミング音声認識リクエストを使用します。
アプリでは、音声入力へのアクティブな接続を 1 つ維持する必要があります。 リーダー選出を使用して、単一の Transcriber Pod をプライマリとして選択します。
エンドツーエンドの音声文字変換を低レイテンシで実行する必要があります。 Memorystore for Redis を高速のインメモリ中間ストレージとして使用します。
音声文字変換は会話のコンテキスト(たとえば、既知のドメイン語彙)を理解したうえで行う必要があります。 音声適応を使用して、音声入力に単語とフレーズのヒントを提供します。
アプリは、複数の同時入力音声ストリーム(チャネル)を処理できる必要があります。 チャネルごとに個別の Transcriber インスタンスをデプロイします。他のアプリのリソースをチャネル間で共有することを検討してください。
アプリは、音声文字変換の中断を最小限に抑えて、障害から回復する必要があります。 リーダー選出、冗長デプロイ、ロードバランサを使用して復元力を高めます。障害を発生させてアプリの復元力をテストします。

一連のコンテナ化されたマイクロサービスとしてアプリを設計する

アプリを疎結合の一連の独立したコンポーネントまたはサービスとして設計することが、アーキテクチャのベスト プラクティスです。疎結合の設計を採用すると、各サービスのライフサイクルを個別に管理できます。サービスはさまざまなチームで構築、管理できます。各チームは、他のチームの選択に制約されることなく、最適なテクノロジーを選択できます。こうしたメリットが、マイクロサービスのアーキテクチャ パターンで最も重要です。

マイクロサービス アーキテクチャでは、多くの場合、サービスをコンテナとしてパッケージ化します。各コンテナでヘルスチェックを実行し、各サービスを特定のリソースに制限し、互いに独立して開始および停止できるので、コンテナはサービスベースのアプリに最適です。アプリを一連のコンテナとしてビルドすることで、効率性、ポータビリティ、整合性の向上などのメリットも得られます。

アプリをマイクロサービスに分割する方法と場所を決めるのは難しい判断になることもあります。ただし、この音声文字変換アプリについては、次の表に示すように役割を明確にします。

マイクロサービス 説明
Ingestor ソース音声ストリームを消費し、中間ストレージに書き込みます。

音声はサードパーティのソフトウェアおよびドメイン固有のプロトコルを使用して配信され、暗号化されることもあります。そのため、音声文字変換コンポーネントとは別に取り込みコンポーネントを設計してデプロイすることをおすすめします。
Transcriber 取り込まれた音声を使用し、音声入力を呼び出して、音声文字変換結果を中間ストレージに書き込みます。

Transcriber サービスはアプリの中核となるものです。音声入力への接続の管理と維持、および音声文字変換の結果の処理を担当します。
Reviewer 音声文字変換を使用し、レビューのためにウェブアプリに表示します。

通常、報道機関では、音声文字変換で生成されたものを監視するために人間のオペレーターが必要となります。この要件に対応するために、Reviewer ウェブアプリでは、音声文字変換されたものがブロードキャストでダウンストリームに送信する前に修正する機能が提供されることもあります。

GKE を使用してアプリのマイクロサービスをホストする

GKE は、コンテナ化されたアプリのホスティングに適しています。まず、GKE クラスタは Kubernetes を利用しており、次のメリットがあります。

  • Kubernetes は、疎結合のコンテナ化されたアプリを管理、オーケストレーションするためのクラウドネイティブなプラットフォームを提供します。
  • Kubernetes はクラスタを宣言的に管理するので、設定がバージョン管理され、レプリケーションも容易になります。
  • Kubernetes はオープンソースで、ポータビリティを提供します。

次に、GKE はフルマネージド サービスであり、次のような高度なクラスタ管理機能を提供します。

  • クラスタノードのインスタンス数の自動スケーリング
  • クラスタノード ソフトウェアの自動アップグレード
  • ロードバランサ、VPC ネットワーク、データベース、ロギングとモニタリングなど、他の Google Cloud サービスとの緊密な統合。
  • リージョン内のゾーン間で冗長性を提供し、可用性を向上させるリージョン クラスタ。

本番環境で GKE を使用する方法の詳細については、本番環境での GKE 環境の準備ガイドをご覧ください。

可用性を高めるためにアプリ マイクロサービスを冗長的にデプロイする

音声文字変換の抜けや配信が断続的になると、音声文字変換に依存しているユーザーを苛立たせる可能性があります。信頼性の高い音声文字変換配信を実現するには、アプリがサービスの停止やエラーに対応できなければなりません。

可用性とは、システムの稼働時間を表す尺度です。Google Cloud では、高可用性は通常、アプリサービスを複数のゾーンに冗長的にデプロイすることによって実現されます。サービスが複数のゾーンに存在する場合、特定のゾーンで発生するサービス障害への対応力が強化されます。

アプリを複数のリージョンにデプロイすると、単一のリージョンにデプロイするよりも可用性が向上します。ただし、マルチリージョン アプリにはデータ レプリケーションの必要性などの制約があり、慎重な設計と管理が必要になる場合があります。こうした音声文字変換アプリでは、単一リージョン内の複数のゾーンにアプリをデプロイすると、おそらく十分な可用性が提供されます。

リージョン GKE クラスタ構成を使用する

GKE には、クラスタをリージョン内のゾーンに分散する方法に関するオプションが用意されています。オプションは次のとおりです。

  • シングルゾーン クラスタ。すべてのクラスタノードが単一のゾーンにあります。同じゾーンで実行されている単一のコントロール プレーン(Kubernetes マスター)が存在します。ゾーン間でアプリを利用可能にする必要があるため、シングルゾーン クラスタは音声文字変換アプリには適していません。
  • マルチゾーン クラスタ。クラスタノードが、リージョン内の複数のゾーンに分散されます。プライマリ ゾーンで動作する単一の Kubernetes コントロール プレーンが存在します。
  • リージョン クラスタ。クラスタノードが、リージョン内の複数のゾーンに分散されます。リージョン クラスタには、コントロール プレーンの複数のレプリカがあり、リージョン内の複数のゾーンで実行されます。

Transcriber サービスでは、Kubernetes リーダー選出(後述)を使用して、音声入力との通信を管理します。リーダー選出には、Kubernetes コントロール プレーンとのインタラクションが必要です。リーダー選出プロセスを最大限活用するには、コントロール プレーンが複数のゾーンで利用可能であることが重要です。したがって、リージョン クラスタは、音声文字変換アプリにとって賢明な選択です。

アプリのマイクロサービスをゾーン間でデプロイする

リージョン GKE クラスタには、特定のリージョンにある複数のゾーンで動作するコントロール プレーンのコンピューティング ノードとレプリカが含まれます。Kubernetes Deployment オブジェクトを使用すると、マイクロサービスの複数のレプリカを冗長的にデプロイできます。デフォルトでは、Kubernetes は各ゾーンのノード間でレプリカを均等に分散しようとします。

Deployment は、複数の同じ Pod のセットを表します。Deployment は Kubernetes Deployment コントローラによって管理されます。レプリカで障害が発生したり応答しなくなったりすると、コントローラが自動的にレプリカを置き換えます。この方法では、Deployment は、アプリ マイクロサービスの 1 つ以上のインスタンスがリクエストの処理に利用できるようにするために役立ちます。

各マイクロサービス(IngestorTranscriberReviewer)に対して、少なくとも 2 つのレプリカを持つ Deployment を作成できます。これにより、各マイクロサービスが複数のゾーンで冗長的に利用できるようになります。

負荷分散サービスを使用した音声の取り込みに安定した IP アドレスを指定する

ソース音声ストリームは、専用のハードウェアとソフトウェアが含まれる、オンプレミスのインフラストラクチャからのものである場合があります。音声文字変換アプリでは、ソース インフラストラクチャが頻繁に再構成を必要としないようにするため、音声を送信できる安定したターゲット IP アドレスを提供する必要があります。しかし、Deployment 内の Pod が停止して再生成されると、IP アドレスが変わります。安定した IP アドレスを Deployment に割り当てるには、Kubernetes Service を作成する必要があります。

Kubernetes Service オブジェクトを使用すると、一連の Pod を単一のリソースとして公開できます。Service は、クライアントが Pod にアクセスするために使用できる単一の固定 IP アドレスを受け取ります。Service タイプは、内部トラフィックと外部トラフィックに対する Service の公開方法を制御します。たとえば、LoadBalancer タイプの Service を作成すると、GKE によって、関連付けられた Google Cloud ロードバランサがプロジェクトに自動的に作成されます。Service でさまざまなタイプの負荷分散を使用する方法については、GKE のネットワーキングの概要をご覧ください。

アプリは単一のリージョンにデプロイされるため、HTTP 以外のプロトコルを使用して配信される音声ストリームをサポートする必要がある場合があります。したがって、外部リージョンの TCP / UDP ネットワーク ロードバランサは、Ingestor サービスの出発点として適しています。このロードバランサには、インターネットからアクセス可能な安定した外部 IP アドレスがあり、使用可能な Ingestor Pod 間でトラフィックを分散できます。

ストリーミング音声認識を使用して音声をリアルタイムで文字変換する

音声入力では、ストリーミング認識リクエストを使用した音声文字変換をサポートしています。ストリーミング認識では、音声入力を使用して双方向の gRPC ストリームを確立します。リクエスト ストリームで音声を送信し、レスポンス ストリームで音声文字変換の結果を非同期で受信します

次のガイドラインは、音声入力から最適な結果を得るために役立ちます。

  • クライアント ライブラリを使用すると、音声入力の操作が簡単になります。たとえば、クライアント ライブラリは gRPC 通信を抽象化するため、ビジネス ロジックに集中できます。
  • ソース音声をサンプリングしてエンコードする方法の詳細については、ベスト プラクティスの推奨事項と最適化ガイドに従ってください。
  • 中間結果フラグを設定します。これにより、音声入力は、最終結果を待つのではなく、仮の音声文字変換が利用可能になったらそれを返すように伝えます。これは、音声の連続ストリームがある場合に便利です。
  • ユースケースに関連する可能性がある他の構成オプションを試してみてください。たとえば、句読点挿入の自動化単語レベルの信頼度話者ダイアライゼーションなどの機能により、さらに役立つ結果が得られる場合があります(こうした機能のすべてをすべての言語で利用できるわけではありません。ご使用の言語で利用できる機能については、サポートされている機能のページをご覧ください)。

音声入力とのステートフル インタラクションと効率的なフェイルオーバーにリーダー選出を使用する

音声入力を使用して確立された双方向ストリーミング接続はステートフルです。これは、音声入力から返される仮の音声文字変換の結果は、それ以降の音声のチャンクを受け取ると進化する場合があるためです。したがって、音声データは 1 つの長時間接続で送信する必要があります。

ただし、可用性を向上させるため、Transcriber サービスの Pod はリージョン内の複数のゾーンに冗長的にデプロイされます。したがって、いずれかの Pod をプライマリ、つまりリーダーとして指定するための堅牢なメカニズムが必要です。リーダーの Pod のみがキューからの音声データを消費して音声入力に送信します。他の Pod はフェイルオーバーのホット スタンバイとして機能します。このパターンは、リーダー選出パターンと呼ばれます。

Kubernetes Go クライアントを使用してリーダー選出が実装できます。また、その使用方法を示すが用意されています。候補プロセスは、Kubernetes コントロール プレーンによって管理されるロックを取得するために競合します。1 つのプロセスがロックを取得すると、定義された期間リーダーとして選出されます。リーダーは、継続的にハートビートを送信し、リーダーとしての地位を更新します。他の候補は定期的にリーダーになるための新しい試みを行います。リーダーが指定された時間内に地位を更新しない場合、他の候補者の 1 人がリーダーに選出され、ロックが付与されます。

このアプリでリーダー選出を使用することで、障害や停止が発生した場合に、音声文字変換の配信の遅延を最小限に抑えることができます。リーダー選出を使用すると、現在のリーダーが失敗した場合、他の Pod が音声文字変換の再開を待機しているため、Kubernetes が新しい Pod をデプロイするのを待つ必要はありません。

リーダー選出構成では、リーダー以外の Pod は通常アイドル状態であるため、単一 Pod 構成よりも多くのクラスタ リソースが消費されます。ただし、レイテンシの影響を受けやすい音声文字変換アプリでは、この追加コストは理にかなっています。

リーダー選出ロジックは、各 Transcriber Pod 内のサイドカー コンテナとしてデプロイできます。これにより、リーダー選出のロジックとコア音声文字変換のロジックの分離を維持できます。

Kubernetes におけるリーダー選出について詳しくは、Kubernetes ブログの Kubernetes と Docker での簡単なリーダー選出をご覧ください。

高速の中間ストレージとして Memorystore を使用する

アプリを一連の疎結合マイクロサービスとしてデプロイすると、アーキテクチャに柔軟性がもたらされます。ただし、これは、あるレイヤから別のレイヤにデータを渡すメカニズムが必要であることも意味します。

音声文字変換の使用例では、レイテンシと処理の順序が重要な要件になります。音声文字変換はリアルタイムで行われるため、アプリ内ですばやくデータを移動し、音声文字変換のレイテンシが増加する可能性のある操作を最小限に抑えることが重要です。また、音声のチャンクが正しい順序で処理されることも重要です。順序が正しくなければ、音声文字変換が不完全または不正確になる可能性があります。

Memorystore for Redis は、リアルタイムのデータ処理を必要するユースケースに適した高速インメモリ ストアを提供します。Memorystore は、次の理由により、音声文字変換アプリに適しています。

  • 高速: データはディスクではなくメモリに保存されます。メモリとのデータのやり取りは、ディスクよりもはるかに効率的です。
  • 柔軟性: Redis には、データの格納や処理に役立つデータ構造とコマンドが用意されています。また、さまざまな Redis クライアント ライブラリもあります。
  • オープン: Memorystore for Redis はオープンソースの Redis と完全な互換性があります。
  • フルマネージド: Memorystore はフルマネージドであるため、インフラストラクチャの管理ではなくアプリに集中できます。
  • 高可用性: スタンダード ティアの Memorystore for Redis インスタンスはゾーン間で自動的にレプリケートされ、正常性がモニタリングされます。また、高速の自動フェイルオーバーも備えています。詳細については、高可用性のドキュメントをご覧ください。

Memorystore for Redis を信頼性の高いキューとして使用する

Redis のリストは、順序付けされたキューとしてよく使用されます。この音声文字変換アプリは、ソース音声データが順序どおりに受信されることを前提としています。このため、Ingestor サービスが音声データを名前付きキューに書き込むことができ、Transcriber サービスがキューから取り込むことができます。Redis には、データがキューに入ってくるまで Transcriber サービスを効率的にブロックできるようなコマンドが用意されています。

音声入力ではストリーミング結果が非同期で返されるため、障害が発生した場合の音声文字変換の損失を最小限に抑える必要があります。たとえば、2 番目の Redis キューを使用して、音声入力に送信された最後の N 秒間の音声を一時的に複製できます。障害が発生し、新しい Transcriber Pod がリーダーに選出された場合、新しいリーダーは 2 番目のキューを読み取り、メインキューからの処理を開始する前に、処理済みの音声を音声入力に再送信できます。Redis の BRPOPLPUSH コマンドは、1 つのリストからデータを読み取り、別のリストに追加するアトミックな方法を提供します。このような信頼性の高いキューイングのユースケースでよく使用されます。このアプローチでは、音声文字変換のフラグメントが重複することがある点にご注意ください。音声文字変換のダウンストリーム コンシューマは、潜在的な重複を管理する必要があります(潜在的な重複を管理するタスクについては、このドキュメントでは説明しません)。

Memorystore の代替として Pub/Sub を評価する

Pub/Sub は、スケーラビリティと可用性に優れた、耐久性の高いイベント取り込みおよび配信システムです。Pub/Sub は、送信者と受信者を分離する低レイテンシの非同期メッセージングを実現します。Pub/Sub は多くの場合、アプリのある部分から別の部分にイベントとデータを渡すために使用されます。

音声文字変換アプリでは、Memorystore の代わりに Pub/Sub を使用できます。たとえば、取り込まれた音声データを Redis に保存し、Transcriber サービスで読み取る代わりに、Pub/Sub を使用して、Transcriber サービスで使用されるサブスクリプションに音声を公開できます。

Pub/Sub には次の機能があります。

  • グローバルな可用性
  • 非常に高いスケーラビリティ
  • シーク機能による簡単なメッセージ再生。アプリの回復に役立ちます。
  • サーバーレス デプロイ。ご利用いただいた分だけのお支払いです

ただし、Pub/Sub には以下の制約もあります。

  • メッセージ配信の順序は保証されません。
  • Pub/Sub の At-Least-Once 配信機能では、メッセージが複数回配信される可能性があり、重複が発生する可能性があります。
  • Pub/Sub はストレージにメッセージを書き込むため、レイテンシが増加する可能性があります。

ユースケースによっては、上記のリストの制約を無視または回避できる場合があり、Pub/Sub が効率的になる可能性があります。両方のテクノロジーを評価して、どちらがお客様のシナリオに最適かを判断してください。

音声適応を使用して音声文字変換のヒントを音声入力に提供する

このドキュメントに記載されているガイドラインに従うことで、音声入力が正確な結果を提供できるようになります。音声文字変換の精度をさらに高めるために、音声適応を使用して音声入力にさらにコンテキスト情報を追加できます。

音声適応では、音声文字変換リクエストを音声入力に送信するときに、ヒントとして機能する単語とフレーズのリストを含めます。このヒントは、音声入力が音声データから指定したフレーズを認識するために役立ちます。たとえば、ライブ ストリームの音声で誰かが天気について話している場合、天気に関連する一般的な単語を含めると、音声文字変換の精度が向上する可能性があります。

本番環境のユースケースでは、必要に応じて検索できるヒントの辞書を作成できます。たとえば、テレビ放送で天気予報の自動字幕起こしをしている場合、アプリは事前に作成した気象用語の辞書を検索できます。しかし、放送内容がゴルフに関するものに変わると、アプリはゴルフ用語とプレーヤー名の辞書を検索できます。

高度なユースケースでは、辞書をリアルタイムで更新できます。訓練を受けたレビュー担当者は、音声文字変換の出力をモニタリングし、辞書をその場で変更できます。Transcriber サービスでは、辞書への変更のイベント通知をリッスンし、それ以降の音声入力への接続の際に更新された辞書を取得して使用できます。

ソース音声ストリームごとに個別の Transcriber Deployment を作成する

通常、放送局は複数のチャネルを運用しており、複数のチャネルの音声文字変換を同時に生成したいと考えています。各チャネルは個別のソース音声ストリームを表します。各チャネルの音声文字変換を行うには、アプリで音声入力への個別の接続を維持する必要があります。これにはいくつかの方法があります。

1 つの方法は、Transcriber ロジック内で一連のチャネルを直接管理することです。この方法を使用すると、クラスタ内に Transcriber Deployment が 1 つしかないため、GKE クラスタがシンプルになります。ただし、この手法では、アクティブなチャネルと接続のセットを維持管理する必要があるため、音声文字変換のロジックが複雑になります。また、この方法では、すべてのチャネルが 1 つの Deployment で動作するため、チャネルごとに異なる構成(異なるヒント辞書や異なる優先度など)を使用するのも難しくなります。

他の方法として、チャネルごとに別個の Transcriber Deployment を作成することをおすすめします。これにより、各 Transcriber インスタンスが音声入力への単一のストリーミング接続を管理するため、アプリのロジックが簡素化されます。このアプローチには、次のような利点があります。

  • 柔軟性: チャネルごとに異なる構成を持つ Deployment を作成できます。たとえば、プレミアム チャネルは、標準的なチャネルよりも多くのクラスタ リソースを保証される場合があります。
  • 分離: 各音声文字変換チャネルを個別のエンティティとして扱うことができます。
  • リソースの効率性: Kubernetes は、1 つの大規模な Deployment を管理する場合と比較して、クラスタ リソースに複数の小さな Transcriber Deployment を最適に分散できます。

ラベルまたは Namespace を使用してチャンネル別にリソースをグループ化する

Kubernetes には、関連リソースをグループ化するための機能がいくつか用意されています。これらの機能を使用して、次のようにチャネルごとにクラスタ リソースを分離できます。

  • ラベルとは、Pod などの Kubernetes クラスタ内のオブジェクトに関連付けられる Key-Value ペアのことです。ラベルを使用して、オブジェクトのサブセットを整理および選択できます。
  • Namespace は、クラスタ リソースを分割する方法です。Namespaces は、Kubernetes クラスタ内の仮想クラスタと考えることができます。1 つの Kubernetes クラスタ内に複数の Namespaces を持つことができ、それがすべて互いに論理的に分離されます。

ラベルと Namespace を使用して、特定のチャネルに対して構成された個別の Transcriber インスタンスをデプロイできます。ラベルにより、リソースをすばやく簡単にグループ化できます。Namespace は、より正式な分離を提供します。各チャネルによって消費されるクラスタ リソースを制御する場合、または異なるチームがチャネルを管理している場合に適しています。

ソース音声ストリーム間でリソースを共有する

前のセクションで説明したように、ソース音声チャネルごとに別々に Transcriber インスタンスを作成することには利点があります。音声文字変換アプリの要件によっては、チャネルごとに別々の Ingestor Deployment と Reviewer Deployment を作成することもあります。このアプローチは、次の制約のいずれかが適用される場合は理にかなっています。

  • アプリ全体で各チャネルを高度に分離する必要がある。たとえば、各チャネルが別々のチームによって管理される。
  • Ingestor サービスが、複数のストリームを簡単に処理できないサードパーティのソフトウェアを使用している。
  • Reviewer アプリに、各チャネルに対するカスタム動作がある。

ただし、疎結合アーキテクチャを選択するメリットの 1 つは、サービスごとに異なるスケーリングとデプロイ戦略を選択できることです。上記に記載された制約が適用されない場合は、複数のチャネルで Ingestor サービスや Reviewer サービスを共有することの方が効率的である場合があります。たとえば、単一の Deployment で複数のチャネルを処理することには、次のような利点があります。

  • Kubernetes Service は複数のポートを公開でき、チャネルごとに別々のポートをターゲットにできます。これにより、Ingestor サービスと Reviewer サービスでは、チャネル全体で使用される単一のロードバランサと単一の外部 IP アドレスを提供できます。そのため、コストが削減されて、管理オーバーヘッドが少なくなります。
  • 同様に、アプリで公開される外部 IP アドレスの数を最小限に抑えることをおすすめします。
  • 自動スケーリングを使用して、チャネルがオンラインまたはオフラインになるときに、Deployment を拡大または縮小できます。

Memorystore for Redis を共有する

リソースの共有について Memorystore for Redis にも同じ考慮事項が適用されます。チャネルごとに別々に Memorystore インスタンスを作成すると、チャネルが分離されます。ただし、コストが増加し、管理オーバーヘッドが大きくなる可能性があります。

Redis は高スループット向けに設計されているため、各チャネル専用の Memorystore インスタンスを作成しても、リソースを効率的に使用できるとは限りません。チャネルをきれいに分離する必要な場合、Memorystore の代わりに GKE クラスタ内で Redis を実行できます。このアプローチでは、クラスタ内の各チャネルに対して Redis Deployment を作成します。しかし、Redis を自分で管理する必要がでてきます。高可用性構成で Redis を運用するのは難しい場合があります。Kubernetes で Redis を実行する方法の詳細については、例: Redis を使用した PHP ゲストブック アプリケーションのデプロイをご覧ください。

前述のように、Memorystore for Redis は高パフォーマンス向けに設計されており、1 つのインスタンスで複数のチャネルを同時に処理できる必要があります。Memorystore for Redis は、必要に応じて容量を追加または削除してスケーリングできることにも注意してください。このようにして、単一の Memorystore インスタンスをチャネル間で共有し、必要に応じてインスタンスを拡大または縮小できます。チャネル間で Memorystore インスタンスを共有している場合は、そのチャネル ID を Redis キーの接頭辞として使用できます。

失敗を発生させてアプリの復元力をテストする

復元力は、本番環境の音声文字変換アプリの重要な要件です。障害が発生したりサービスが停止したりした場合、アプリは、音声文字変換での損失を最小限に抑えつつ、音声文字変換を速やかに再開する必要があります。

このドキュメントで説明するアーキテクチャには、復元力を高める機能がいくつか含まれています。

  • Transcriber サービスでは、現在のリーダーで障害が発生した場合に、リーダー選出を使用してホット スタンバイ Pod に効率的にフェイルオーバーします。
  • アプリは Redis の信頼性の高いキューイング機能を使用して、障害発生時のデータ損失を最小限に抑えます。
  • このアーキテクチャには、ロードバランサが関連付けられた Kubernetes Services が含まれています。Google Cloud のロードバランサには、基盤となるコンピューティング ノードが正常であることを確認するためのヘルスチェックが含まれています。
  • このアプリケーション サービスはゾーンをまたいで冗長的にデプロイされるため、ゾーンの障害から保護するために役立ちます。
  • 各アプリサービスは、必要な Pod レプリカの数を指定する Kubernetes Deployment です。Pod がクラッシュまたは削除されると、Kubernetes では構成されたレプリカの数を満たすように自動的に再作成されます。
  • スタンダード ティアの Memorystore for Redis インスタンスは、複数のゾーン間で自動的にレプリケートされ、稼働状態がモニタリングされます。また、高速の自動フェイルオーバーも備えています。

発生する可能性のあるすべてのエラーや機能停止をテストすることはできませんが、失敗を発生させて結果を調べることで、アプリについて多くのことを学ぶことができます。復元力と復元をテストするときは、目標と予想を定義することが重要です。特定のユースケースでは、ある程度の音声文字変換の損失が許容されている場合もあります。その他のユースケースでは、音声文字変換の損失を最小限に抑えるための厳しい要件がある場合があります。復元の目標を事前に定義しておくと、その目標に対する進捗状況を測定するために役立ちます。

障害モードの詳細な説明については、このドキュメントでは取り上げません。以下のセクションでは、アプリの復元力を評価するために実行できるいくつかのベースライン テストについて説明します。

Kubernetes Pod を削除する

アプリに障害を発生させる 1 つの方法は、GKE クラスタから Kubernetes Pod を削除することです。これは、カオス エンジニアリングの一種です。簡単な方法は、一定の間隔で Pod をランダムに削除するカスタム スクリプトを作成することです。その代わりに、Kubernetes クラスタでカオステストを実行できるサードパーティ ツールが多数存在します。Pod が削除されたときの各アプリサービスの動作を体系的にテストする必要があります。

Memorystore の手動フェイルオーバーを実行する

Memorystore for Redis のスタンダード ティアのインスタンスは、レプリケーションと自動フェイルオーバーによって高可用性を提供します。ゾーン障害に対応するため、プライマリとレプリカは同じリージョン内の異なるゾーンに配置されます。フェイルオーバーは、プライマリ Redis インスタンスの障害時に発生します。

Memorystore のフェイルオーバーは、次のようにアプリに影響を与えます。

  • プライマリ インスタンスがレプリカにフェイルオーバーすると、Memorystore for Redis への既存の接続が切断されます。ただし再接続時は、同じ接続文字列または IP アドレスを使用しても、アプリは自動的に新しいプライマリ インスタンスにリダイレクトされます。
  • Memorystore for Redis サービスがレプリカをプライマリに昇格させている間、Memorystore for Redis インスタンスは一時的に利用できなくなります。

このような条件下でアプリの動作をテストするには、手動フェイルオーバーを開始します。通常、フェイルオーバーが起きると、ある程度のデータ損失が発生します。損失の程度を測定し、実際のユースケースに最適な処理方法を決定する必要があります。

次のステップ