Google CloudでBigtableの小さなワークロードでも動かせる

Cloud Bigtableは長年、Google Cloud上の大きなペタバイト級の分析やオペレーショナルのワークロードを支える、完全なマネージドNoSQLサービスだった。しかし1ノード1時間あたり0.65ドルという料金と、1クラスターあたり3ノード以上というGoogle Cloudの要求により、それは決してお安いサービスとは言えなかった。しかしながら、今日(米国時間4/7)からそれが変わる。これからはBigtableのプロダクションワークロードを、わずか1ノードでも動かすことができる。

Google Cloud BigtableのプロダクトマネージャーSandy Ghai氏が、今日の発表声明で次のように述べている。「Bigtableを、大小を問わず、さまざまなキー-ヴァリューおよびワイドカラムのユースケースの優れたホームにしたい。それは新人デベロッパーでも、古参のエンタープライズでも同じであり、みなさまが自己管理しておられたHBaseやCassandraなどのクラスターの、ランディングページでありたい」。

これによりGoogle Cloudでは、小さなクラスターのレプリケーションによる高可用性と、ワンノードの開発インスタンスとワンノードのプロダクションインスタンスを必要に応じて切り替えることが可能になる。さらにまた、今ではサービスのSLAが、サイズを問わずすべてのBigtableのインスタンスを対象にしている。

このところGoogle Cloudは大企業エンタープライズ顧客の獲得と問題対応に熱心だったから、今回のようにBigtableに小さなワークロードを歓迎する動きは興味深い。でも、初めに一つのノードだけを必要とした企業が、やがて大量のクラスターを必要とするようになったりするから、Bigtableのこれまでの最小要件は小さな企業にとって障壁だった。しかもデータベースは、企業が小さい時期と大きくなってからとで、安易に切り換えるようなサービスではない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Spotifyの「2019年まとめ」提供、Google Dataflow史上最大のジョブの舞台裏

2019年12月前半に、Spotifyはその年にユーザーが最も多くストリーミング再生した曲を集めた「Wrapped(まとめ)」プレイリストをパーソナライズして提供した。これ自体は以前から提供されているもので特に新しいものではないが、2019年は過去10年間を振り返るプレイリストも提供された。これはかなり大規模のジョブだ。増え続ける無料ユーザーと有料サブスクリプション利用者に向けてどのようにこのプレイリストを生成したのか、Spotifyは舞台裏の一部を明かした。

画像:Frazer Harrison/Getty Images for Spotify / Getty Images

SpotifyがGoogle Cloud Platformの大口利用者であることは、秘密ではない。2016年にSpotifyはGoogle Cloudへの移行を発表し、2018年にはその後の3年間でGoogle Cloudのインフラストラクチャに4億5000万ドル(約500億円)以上を支出する見込みであることを明らかにしている。

同じく2018年、この年のWrappedでSpotifyはGoogle Cloud Platform上で史上最大のGoogle Cloud Dataflowでジョブを実行した。Dataflowは数年前にGoogleが実験を開始したサービスだ。Spotifyのエンジニアリング担当バイスプレジデント、Tyson Singer(タイソン・シンガー)氏は筆者に対し次のように語った。「2015年に我々はビッグデータを処理するApache BeamとGoogle Cloud DataflowのためのScala API『Scio』を開発し、オープンソース化した。我々はDataprocではなくDataflowを選択した。スケールする際に運用のオーバーヘッドが少なくて済むことと、Dataflowが予測されるストリーミング処理のニーズに合っていたことがその理由だ。現在はDataflow用に設計され最適化された優れたオープンソースのツールセットがあり、社内のほとんどのチームで使用しているほか、Spotify以外でも使われている」

Wrapped 2019には、1年間のまとめと10年間のまとめがあった。Spotifyが実行したジョブは2018年の5倍の規模だったが、かかった費用は4分の3で済んだ。このことについてシンガー氏は、チームがプラットフォームを熟知したからだと考えている。「このようなグローバルのスケールでは、複雑になるのが当たり前だ。Google Cloudのエンジニアリングチームや専門家と緊密に協力し、前年までの経験から学んだ結果、我々が実行したDataflowのジョブはこれまでに書かれた中で最も洗練されたもののひとつとなった」

専門知識があっても、データ分析を最適化しユーザーの興味を引くストーリーを伝えるために、データセット全体のイテレーションを回すことはできない。シンガー氏は「これを処理するジョブは大規模で複雑だ。Google Cloud Dataflowに負担をかけすぎないために、複雑さと処理を切り離す必要があった。つまり我々はアイデアから、データ分析、ユーザーごとに固有のストーリーを生み出すに至るまで、もっとクリエイティブになる必要があった。そして時間内にコストを下げてスケールする必要もあった。十分に注意を払わないと、リソースを無駄にし下流のチームの速度を落としてしまう危険があった」と語る。

この作業負荷を処理するために、Spotifyは社内のチームをデータ処理、クライアント向けの設計、バックエンドシステムの3つのグループに分け、さらにデータ処理のジョブを細かく分けた。これはチームにとってきわめて異例のアプローチだった。「2019年、SpotifyはDataflowの『Shuffle』という機能を使った大規模なジョブを実行した。大量のデータがあり、誰が何をしたのかを理解するためにそのデータを整理する必要があったためだ。これはとてもパワフルだが、データ量が多いとコストがかさむ」。

2020年、SpotifyのエンジニアはGoogle CloudのBigtableを中間ストレージレイヤーとして使うことによりShuffleの使用を最小限にとどめた。シンガー氏は「常にデータの再グループ化が必要というよりは、多くのデータをパラレルに処理し格納するために、BigtableをDataflowのジョブ間を修復するツールとして使用した。Dataflowのジョブを小さいコンポーネントに分割し、コアの機能を再利用することで、ジョブのスピードを上げレジリエンスを高めることができた」と説明する。

シンガー氏は、少なくともコスト削減の一部はBigtableを使うこのテクニックによるものと考えている一方で、課題をデータ収集、アグリゲーション、データ変換のジョブに分解してからさらに複数のジョブに分割したことも指摘する。「こうすることで、より多くのデータをパラレルに処理するだけでなく、再実行するジョブを選択してコストを抑えた」

シンガー氏のチームのエンジニアたちが開発したテクニックの多くは、現在、Spotify全体で使われている。同氏は「Wrappedを機能させることで、我々はユーザーを理解するためのツールを作り、ユーザーのために優れた製品を作ることができる。Scio、Dataflow、ビッグデータ処理に関する我々の専門技術と専門知識は、Spotifyの製品ポートフォリオを強化するために広く使われている」と述べた。

[原文へ]

(翻訳:Kaori Koyama)