Shazam の導入事例 : クラウド GPU が意味を持つに至った理由

私たち Shazam は 2012 年以来、認識サービスのために GPU に強く依存してきました。最初は NVIDIA TESLA M2090 でしたが、今は K80 を使用しています。かつてはベア メタル サーバーをメインに使ってきましたが、それはクラウドに GPU が用意されていなかったからです。クラウド GPU が初めて登場したときも、とても高価なうえに、私たちが必要とするパフォーマンスは得られませんでした。

Shazam のビジネスでクラウド GPU が意味を持つようになったのは、つい最近のことです。私たちが Google Cloud Platform（GCP）を使用する方向に舵を切ったのは、それが理由です。

一部の限定されたタスクでは、GPU は CPU と比べて低コストで、高いパフォーマンスが得られる選択肢となります。ユーザーが録音した断片的なオーディオ フィンガープリントと、私たちが抱える 4,000 万曲以上の音楽カタログをマッチングするという Shazam の音楽認識ワークロードでは、GPU の効果は抜群です。

私たちは、マッチングのためにすべての曲のオーディオ シグネチャを取得してカスタム データベース形式にコンパイルし、それを GPU メモリにロードしています。ユーザーが曲を Shazam にかけると、私たちのアルゴリズムはそれとマッチするものが見つかるまで、GPU を使ってデータベースを検索します。これが毎日 2,000 万回以上、トラブルもなく行われているのです。

こうした需要を満たすため、私たちはマネージド サービス プロバイダーから GPU 搭載の専用ベア メタル サーバーをリースし、メンテナンスしてきました。新しい物理サーバーのソーシングやプロビジョニングにはかなりの時間がかかるので、ピーク時の需要に合わせてサーバーをプロビジョニングし、そのシステムを年中無休の 24 時間体制で実行します。そして、マッチングのアルゴリズムを改善し、新しい GPU アーキテクチャとそのパフォーマンスを利用して、なんとかコストを管理できる水準に維持してきたのです。

そんな私たちが、Google Compute Engine で動作する GPU を試してみることにしたのは、今から 6 か月ほど前のことです。インスタンスの追加や削除をすばやく行えるため、ピーク時のフルキャパシティではなく、平均的な需要に対応できる程度で GPU インフラストラクチャを動かしています。今までのところ、インフラストラクチャの 3 分の 1 ほどを Google Cloud に移行しました。

膨大な音楽カタログを効率よく検索するために、私たちは社内で「ティア」と呼ばれている複数のレベルの GPU サーバー クラスタを運用しています。第 1 ティアは最も人気の高い曲のオーディオ シグネチャをデータベースで検索し、それに続くティアは少しずつ認知度の低い音楽の少しずつ長いサンプルを検索します。

この仕組みにより、たとえば Ed Sheeran の “Thinking Out Loud” という曲なら短いサンプルを使ってシングルパスでマッチします。しかし、1950 年代に録音されたリトアニアのポルカ グループの場合は、いくつかのパスの検索と長いサンプルを使って音楽をマッチングしなければなりません（もっとも、人気のある曲だけでなく、非常に珍しい曲でもマッチングさせられるところが、お客様にとっての Shazam の魅力です）。

最初のティアでのヒット率を高めるには、新しくて人気の高い曲に対応した形でインデックス ファイルを最新に保つ必要があります。ただし、人気の高い曲の出入りは激しく、最新に保つのは容易ではありません。スーパーボウル、グラミー賞、社名が付いた最初のゲーム番組 “BEAT SHAZAM” などによるトラフィックの急増は予測できるので、あらかじめスケーリングしていますが、その他の場合は予測不能です。

たとえば、大規模な市場を抱える地域のラジオ局が古い R&B のヒット曲をリバイバルさせたり、今まで人気を集めたことがない曲が突然テレビ CM で使われたりしたような場合です。それらは新曲としてはカウントしませんが、レコード会社や、新しい音楽を絶えず探している社内のエキスパートからの申請に基づいて、毎日カタログに追加しています。

言うまでもないことですが、ベア メタル サーバーで実行する場合は、サービスを大規模に提供している会社が必ず経験するサーバー エラーに備えて、予備のキャパシティをプロビジョニングしておく必要があります。これに対して Google の場合は、エラーが起きるのを待っているノードのプールを維持しなくても、わずか数分でエラー ノードをまったく新品のノードに交換できます。

マネージド サービス プロバイダーの場合、それぞれ 2 個のダイを載せたカードを 4 枚挿入したマシンという単位で GPU をプロビジョニングしなければなりませんでした。そのため、ノードがエラーを起こすと、データベースのシャードが 8 個失われるのです。一方、Google の場合は 1 つのシャードに 1 つの VM をプロビジョニングしているので、ノード エラーの影響は 8 個ではなく 1 個のシャードに局所化されます。

また、Google Cloud GPU には予想外のメリットもありました。計算ユニットに非常に大きな負担をかけるオーディオ シグネチャ データベースの再計算と更新の頻度を大幅に増やすことができたのです。専用インフラでは毎日 1 回ずつ人気曲のインデックスを更新していましたが、Google Cloud では 1 時間以内でインデックスを再コンパイルして GPU インスタンスに乗せられるので、インデックス ファイルは常にほぼ最新です。

このような高い柔軟性が得られたことから、私たちは現在、クラスタ構成を動的に変えることを検討しています。Shazam のアルゴリズムの性質上、動的に変えるほうが好都合だからです。

たとえば、比較的静かな車内で Shazam された曲の識別は、話し声や食器の音が入ってオーディオ シグネチャがわかりにくくなるレストランで Shazam された曲よりも簡単です。クラウド ベースの GPU から得られる柔軟性を活用すれば、時間帯によるニーズの違いに合わせてティアの構成を細かく変えられるようになります。朝の通勤時間帯と、仕事から解放されてバーにいる時間帯とでクラスタの構成を変えることもできるわけです。

Google Cloud の GPU を利用することで開かれる可能性にはわくわくさせられます。新しい GPU がラインアップされた Google Cloud とビジネスを共にできることを楽しみにしています。

私たち Shazam における GCP への移行については、こちらで詳しく紹介しています。

* この投稿は米国時間 5 月 4 日、Shazam の Head of Site Reliability である Ben Belchak によって投稿されたもの（投稿はこちら）の抄訳です。

- By Ben Belchak, Head of Site Reliability Engineering, Shazam