長時間実行タスクでの Cloud Pub/Sub の使用

このソリューションでは、長時間実行タスクのキューシステムとして Google Cloud Pub/Sub を使用する方法について説明します。このソリューションでは、音声ファイルの文字起こしを自動的に行います。

さまざまな種類のメディアに音声が含まれています。話し言葉からテキストに変換する機能があると便利なことも少なくありません。たとえば、字幕から動画を検索したり、コールセンターの通話内容を解析したりする場合に、このような機能は有効です。数時間分の動画が秒単位でアップロードされたり、ヘルプデスクで毎日数時間分の会話が記録されたりしている場合、文字起こしを自動的にバッチ処理できれば、作業時間を大幅に短縮できます。

ここでは、通話が記録された音声ファイルをクラウド上のストレージにアップロードする場合のメディア処理インフラストラクチャについて説明します。これらのファイルの音声を文字に変換し、結果のファイルをデータベースに保管して分析に使用します。ここで説明するアーキテクチャは、処理に数時間かかるサイズの大きい画像や動画にも有効です。

アーキテクチャとワークフロー

次の図は、アーキテクチャとワークフローを表しています。

ファイルのアップロードと処理の概要。手順は次のテキストで説明しています。

この図で、ユーザーがコンテンツをアップロードすると、システムは次のように対応します。

  1. ウォッチャー アプリが、アップロードされた新しいメディアを取得します。
  2. ウォッチャーにリンクされているウェブフックがメディアの詳細情報を含むメッセージをキューに追加します。
  3. キューを参照しているワーカーの 1 つがこのメッセージを取得します。
  4. 同じワーカーが該当するメディアをストレージから取得し、処理します。
  5. 完了後、ワーカーが結果を出力ストレージの場所に保存します。
  6. ワーカーがメッセージを確認し、メッセージがキューから削除されます。

要件とインフラストラクチャ

このアーキテクチャでは、いくつかのコンポーネントが必要になります。

ストレージ

すぐにアクセスし、処理を行って配信できるように、メディアを保存します。可用性が高く、レイテンシが低いストレージが必要です。PB ではなくとも、TB のデータを処理でき、どこからでもアクセス可能でなければなりません。

Google Cloud Storage では、可用性と持続性が同じ 3 つのオブジェクト ストレージ ソリューションを利用できます。

  • Standard。データの処理と保存に便利です。データにはミリ秒単位でアクセスできます。コストのかからないコンテンツ配信ネットワーク(CDN)も利用します。Google の最先端のネットワークを使用して、公開コンテンツを配信します。
  • NearlineNearline Storage は、低コストで耐久性のあるバックアップ オプションを提供します。データの最初のバイトに数ミリ秒でアクセスできるので、迅速に復元できます。
  • ColdlineColdline Storage は低価格のストレージで、年に 1 回程度しかアクセスしないデータの保存に最適なオプションです。Coldline は、長期間保存するデータ、アーカイブ、オンライン バックアップ、障害復旧に適しています。また、データの取得も迅速に行うことができます。

このソリューションでは、Standard ストレージにファイルを保存して処理します。

通知

ファイルはいつでもオブジェクト ストアに保存できます。迅速な対応を行うには、ストレージを監視し、新しいメディア ファイルが追加されたときに自動的にイベントを生成するコンポーネントが必要になります。Cloud Pub/Sub Notifications for Cloud Storage 機能を構成してバケットを監視し、バケット内のコンテンツが変更されたときに Cloud Pub/Sub にイベントを生成できます。

メッセージ キュー

受信するメディア ファイルが多い場合、メディアを迅速に処理するには複数のワーカーが必要になります。処理待ちのファイルが多いほど、必要なワーカーの数が多くなります。コストを削減して予算内に収めるには、処理キューを使用して、同時に実行するワーカーの数を減らす必要があります。

Google Cloud Pub/Sub は可用性の高いメッセージング システムおよびキューイング システムです。1 対他(ファンアウト)、多対 1(ファンイン)、多対多などの通信構成に対応し、HTTP API 経由でアクセスできます。Cloud Pub/Sub は、push と pull の両方のサブスクリプション モデルに対応しています。

このソリューションは、Cloud Pub/Sub を使用して耐久性のある効率的なキューを作成しています。このキューの特徴は次のとおりです。

  • 1 つのパブリッシャー。新しいファイルに対してメッセージを公開します。このメッセージには、ファイルや場所を記述するメタデータが含まれています。

  • 1 つのキュー。すべての公開メッセージが格納されます。

  • 一連のワーカー。メッセージをキューから取得します。pull 型のサブスクリプション モデルでは、現在のメディア ファイルの処理が完了してから次のファイルを取得できます。

  • ワーカーがキューからメッセージを取得するときにメディア ファイルの処理完了を確認できないと、キューシステムはワーカーでエラーが発生したと解釈し、キューにメッセージを返します。

  • ワーカーは、メディアの処理が完了した場合にのみ、メッセージの確認応答をします。この確認応答により、Cloud Pub/Sub はキューからメッセージを削除します。

  • 時間のかかる処理の場合には、承認期限を定期的に延長できます。この処理を行わないと、元のワーカーが作業中にもかかわらず、Cloud Pub/Sub がメッセージをキューに返します。

  • 各メッセージには有効期限があります。メッセージが期限までに処理されないと、キューから削除されます。これにより、キューサイズの急増を防いでいます。

次の図は、このソリューションが Cloud Pub/Sub にメッセージを渡して処理する方法を表しています。

メッセージの処理。手順は次のテキストで説明しています。

前の図では、ワーカーがメッセージを pull した後もキューにメッセージが残っています。これは、要求済みとマークされ、他のワーカーから作業できなくなります。指定した承認期間内に、サブスクリプションでリクエストを行ったワーカーから確認応答を受信しない場合には、再度使用可能になります。

コンピューティング

メッセージ キューに関連するファイルの処理は、いくつかのステップで行われます。

  1. キューを読み取る。
  2. 音声ファイルを読み込む。
  3. 音声から文字を起こす。
  4. 結果を保存する。

スケーリング

すべてのステップをタイムリーに行うには、受信トラフィックの量に応じて自動的にスケーリング可能なワーカーが必要です。スケーリングは手動または自動で実行します。手動スケーリングは、受信ファイルの数とサイズが比較的一定で、処理の負荷に必要なワーカーの数を知っている場合に最適です。自動スケーリングは、受信ファイルの数が急に増加しても対応できます。

前述の要件を基準にすると、メディア ファイルを変換するコンピューティング能力と、水平方向に自動的にスケーリングし、必要に応じてワーカーを追加できる能力が必要になります。

Compute Engine インスタンスはテンプレートに基づいて作成されます。

Google Compute Engine を使用すると、実行するコンピューティング タスクに応じて、仮想マシン インスタンスを増やすことができます。

マネージド インスタンス グループは、手動と自動の両方のスケーリングに対応しています。インスタンス グループ マネージャは、マシンイメージまたはコンテナのインスタンス テンプレートを使用して、同一マシンのグループを作成できます。

手動スケーリングの場合、インスタンス グループ マネージャは、指定された数の仮想マシン インスタンスが常に稼働するように管理します。また、必要に応じてインスタンスを追加したり、レスポンスのないインスタンスを終了したりします。

自動スケーリングを使用すると、インスタンス グループ マネージャは、選択した指標(CPU の平均使用率、HTTP ロードバランサの負荷、インスタンスのカスタム指標、Cloud Pub/Sub キューサイズなど)に基づいてインスタンスを作成または終了します。

マネージド インスタンス グループでは、Cloud Pub/Sub と instance/cpu/utilization の組み合わせに基づく自動スケーリングを使用できます。ワーカーの数はキューのサイズに応じて増減できますが、VM がメディア ファイルを処理している間はインスタンスを終了できません。

音声処理

コンピューティング用のプラットフォームを構成したら、次に検討が必要になるのはメディア ファイルの解析方法です。場合によっては、ジョブをカスタマイズし、コンピューティング能力を増強しなければなりません。このソリューションは、メディア処理ではなくキュー アーキテクチャを重視しているので、Cloud Speech API を使用して一部の音声ファイルを同時に処理します。

これにより、ワーカーのビジー状態が持続され、キューのサイズが大きくなる可能性がありますが、ソリューションが複雑になることはありません。

データ ストレージ

メディア(この場合、音声ファイル)の処理が完了した後で結果を保存しておくと、分析に利用できます。BigQuery が提供する SQL インターフェースは簡単なものですが、ストレージは他の Google ツールでも使用できます。

Google Cloud Platform のインフラストラクチャ

次の図は、Google Cloud Platform を使用してメディア処理ソリューションを作成する方法を表しています。

メディア処理ソリューションのアーキテクチャ

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...