長時間実行タスクに Cloud Pub/Sub を使用するためのアーキテクチャ

この記事では、Cloud Pub/Sub を長時間実行タスクのキューシステムとして使用する方法について、そのアーキテクチャとワークフローを説明します。ここでは、音声ファイルの自動文字起こしを例にとって説明します。

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

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

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

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

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

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

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

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

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

ストレージ

メディアは簡単にアクセス、処理、配信できるように保管する必要があります。可用性が高く、レイテンシが低いストレージが必要です。テラバイトやペタバイトのデータを処理でき、どこからでもアクセス可能でなければなりません。

Cloud Storage では、同等の可用性と耐久性を備えた 3 つのオブジェクト ストレージ ソリューションを提供しています。

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

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

通知

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

メッセージ キュー

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

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 を使用してメッセージを処理する方法を示しています。

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

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

コンピューティング

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

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

スケーリング

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

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

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

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

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

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

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

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

音声処理

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

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

データ ストレージ

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

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

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

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

次のステップ

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

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