Statsig、Spark から BigQuery に移行して新機能を活用

※この投稿は米国時間 2023 年 6 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

Statsig は、何百もの企業で使用されている最新の機能管理を備えたテスト プラットフォームです。Statsig のエンドツーエンドの製品分析プラットフォームは、統合されたフィーチャー ゲート（フラグ）、カスタム指標、リアルタイム分析ツールなどを使用してテストの簡素化と迅速化を図り、データドリブンな意思決定と確実な機能リリースを実現します。企業はリアルタイム イベント ストリーム データを Statsig のデータ プラットフォームに送信しますが、そのイベント数は 1 日あたり平均 300 億件を超え、前月比で 30～40% 増加しています。

こうしたイベント量の急増に伴い、当社の Spark ベースのデータ処理では、パフォーマンスの問題、パイプラインのボトルネック、ストレージ制限が定期的に発生していました。この急速なデータの増加によって、チームは製品に関する分析情報を時間どおりに提供することができず、悪影響が及んでいました。また、継続的な Spark の調整作業を行っていたため、機能のバックログを維持することも困難になっていました。当社のエンジニアリング チームは、お客様のために新機能を構築するのではなく、Spark のランタイムとクラウドの費用増大を抑えるために時間を費やしていたのです。

BigQuery を導入することで、Spark で繰り返される再設計のスパイラルから抜け出し、データクラウドに移行することで、お客様に焦点を当て、スケーラブルなテスト プログラムの実行に役立つ新機能を開発できるようになりました。

データの増加に伴うジレンマ

Statsig では、データの処理量が急速に増加していました。1 か月前に行った仮定や最適化は、翌月には意味をなさなくなってしまいます。私たちのチームは Spark のパフォーマンス調整に精通していましたが、それぞれの変更のメリットは長く続かず、実装とほぼ同時に陳腐化してしまいました。月日が経つにつれ、データチームは新しいデータ製品や機能の構築ではなく、Spark クラスタの最適化と調整に多くの時間を費やすようになりました。そして、私たちはデータクラウド戦略を変える必要があることに気付いたのです。

私たちは、同様のデータ スケーリングの課題に直面していた企業やスタートアップからアドバイスを求めることにしました。圧倒的に推奨されたのは、「BigQuery を使用する」というものでしたが、当初は乗り気ではありませんでした。当社が BigQuery に移行するには、まったく新しいデータ ウェアハウスと GCP へのクラウド間移行が必要になるためです。

ここで、全社的なハッカソンの期間中に、2 人のエンジニアが最もリソース消費量の多いジョブで BigQuery をテストすることにしました。驚いたことに、この最適化されていないジョブは、現在の細かく調整された設定よりもきわめて高速、かつ低費用で終了したのです。この結果を受け、私たちは BigQuery への移行をこれ以上無視できなくなりました。そして、さらなる調査に乗り出したのです。

BigQuery の調査

BigQuery の検討を始めて最初に理解しなければならなかったのは、実際にジョブを実行する方法でした。Spark では、面倒な構成、エグゼキュータなどの概念の仮想マシンへのマッピング、必要なすべてのトラッキングとバリエーションのためのオーケストレーション パイプラインの作成に慣れていました。

そのため、BigQuery でジョブを実行しようとしたとき、プロジェクトに割り当てられたスロット数を構成するだけでよいことに驚かされました。BigQuery を使うだけで、クエリのパフォーマンスに影響を与える何百もの設定を行う必要がなくなったのです。また、最初の BigQuery の移行テストを実行する前でさえ、通常チームが完了しなければならない、費用のかかる面倒な最適化のタスクリストを用意する必要がありませんでした。

BigQuery を調べていくと、さらに多くのサーバーレス最適化の機能があることがわかりました。これは、BigQuery ですぐに使用できることに加え、Spark で抱えていた多くの問題に対処します。たとえば、Spark では 1 つのタスクが停止することがよくありました。これは、仮想マシンが失われたり、適切な VM シェイプを作ったりする必要があったからです。BigQuery の自動スケーリングを使用すると、SQL ジョブはきめ細かく定義され、必要に応じて複数のジョブ間でリソースを移動させることができます。別の例として、Spark ではシャッフルされたデータがマシンのディスクを圧迫してしまい、ストレージの問題が発生することがありました。BigQuery には、個別にメモリ内シャッフル サービスがあるため、チームがシャッフル ディスクサイズの予測やサイズ設定について心配する必要はありません。

この時点で、Spark の DevOps から BigQuery のサーバーレス アーキテクチャへの移行は、労力に見合うだけの価値があることは明らかでした。

Spark から BigQuery への移行

パイプラインを移行する際、大規模なコードブロックを書き換えなければならない状況に直面し、新しいバグが発生しやすい状況に陥りました。そのため、大規模な書き換えを行うことなく、この移行を同時に実施する方法が必要でした。Dataproc は、この目的に対応できる非常に便利なツールです。Dataproc は、Spark クラスタをスピンアップするためのシンプルで柔軟な API を提供し、以前の Spark デプロイで慣れ親しんだ構成や最適化のすべてにアクセスできるようにします。

さらに、BigQuery は Apache Spark のストアド プロシージャを使用した直接的な Spark 統合を提供しています。これにより、BigQuery にネイティブなフルマネージドのサーバーレス Spark エクスペリエンスが提供され、BigQuery SQL から Spark コードを直接呼び出すことができます。また、BigQuery オートスケーラーの一部として構成し、SQL を実行できるあらゆるオーケストレーション ツール（dbt など）から呼び出すことが可能です。

このように、BigQuery SQL と Spark の複数のオプションを組み合わせることができるため、BigQuery にすぐに移行しても、移行全体をスケジュールに合わせてロールアウトできる柔軟性を備えています。

BigQuery で、機能構築に再び取り組む

BigQuery を使用することで、パフォーマンスの向上、直接的な費用削減、データ パイプラインのエラー率の低減を実現できました。しかし、BigQuery の導入でビジネスが大きく変化したのは、これまで持っていなかった新しいリアルタイムの機能を活用できるようになったことです。その例をいくつかご紹介します。

1. 最新かつ高速なデータ結果

Spark クラスタでは、お客様が特定の詳細を確認したい場合、数万件もの考えられ得る結果を毎日事前に計算する必要がありました。毎日確認されるのはごく一部の結果でしたが、どの結果が必要になるかを予測できなかったため、すべてを事前に計算しておく必要がありました。BigQuery では、クエリの実行速度が非常に速いため、お客様が必要なときに特定の結果を計算できるようになりました。私たちは、費用のかかるジョブを実行せずに済み、お客様にとっても最新のデータを入手できるというメリットがあります。

2. リアルタイムの意思決定機能

BigQuery への移行が始まって以来、BigQuery のほぼリアルタイムでの計算能力を活用したいくつかの新機能をロールアウトして、お客様のリアルタイムの意思決定能力を強化しています。

1）Metrics Explorer。お客様は、リアルタイムで指標データをクエリできます。

2）詳細の確認機能。お客様は、Spark ジョブが処理されるのを 15 分間待つことなく、特定のユーザーの詳細を即座に掘り下げることができます。

3）ウェアハウス ネイティブなソリューション。お客様は、独自の BigQuery プロジェクトを使用して分析を実行できます。

Spark から BigQuery に移行したことで、多くのワークフローが簡素化され、費用も大幅に削減できました。それと同様に重要なことは、大量のデータを容易に処理できるようになり、常に対応に追われていたデータチームの負担が減り、お客様のために優れた製品をより迅速に構築できるようになったことです。

BigQuery を使ってみる

BigQuery の使用を開始する方法はいくつかあります。新規のお客様には、BigQuery のお支払いに使用できる無料クレジットを $300 分進呈します。すべてのお客様は、10 GB のストレージと 1 か月あたり最大 1 TB のクエリを無料で利用できます。クレジットに対する課金はありません。これらのクレジットは、BigQuery の無料トライアルにお申し込みいただくと獲得できます。まだご決断されていない場合は、クレジット カードの登録が不要な BigQuery サンドボックスをぜひお試しください。

ISV にとっての Built with BigQuery のメリット

Google は、Built with BigQuery のイニシアチブを通じて、Statsig のようなテック企業が Google のデータクラウド上で革新的なアプリケーションを構築できるよう、テクノロジーへのシンプルなアクセス、有益な専任のエンジニアリング サポート、共同市場開拓プログラムなどを提供しています。

Statsig の詳細

企業は、新機能がビジネスに与える影響を理解し、さまざまなオプションをテストし、顧客の成功とビジネスへの影響のバランスを図る最適な構成を特定したいと考えています。しかし、これらのテストを実行するのは困難です。単純なミスによって判断を誤ったり、標準化できていないことで結果の比較が困難になったりして、ユーザーの信頼が低下する可能性があります。また、テスト プログラムの実装が不十分な場合、ボトルネックとなって機能リリースが遅れたり、場合によっては、チームがテストを完全にスキップしたりすることがあります。Statsig は、エンドツーエンドの製品テストと分析プラットフォームを提供し、企業が最高水準のテストツールを活用できるようにします。

テストプロセスの改善をご希望の場合は、statsig.com のウェブサイトにアクセスし、当社のプラットフォームが提供する機能についてぜひご確認ください。十分な無料枠と Slack の専門家コミュニティで、お客様の取り組みを成功に導くようサポートします。Statsig でビジネスの成長を促進し、データの可能性を最大限に引き出しましょう。

- Statsig、ソフトウェア エンジニア Pablo Beltran 氏
- Google、グループ プロダクト マネージャー Christopher Crosbie