大規模計算基盤としてのBigQuery導入事例

ツール導入前の課題

弊社では、eScanというETRMツールを開発しております。ETRM(Energy Trading and Risk Management)とは、エネルギー取引にまつわるリスクを管理するソフトウェアで、電力の調達データ・販売量データ・電力市場の価格・燃料価格などを元にユーザが抱えるリスクを可視化し管理できます。

リスクの算出にあたっては、大規模なデータをもとに高度な計算を行う必要があります。

サービス開始当初は、Node.js上で計算処理が実装されていましたが、データ量の増加や機能拡充に伴い、次第にリソースを逼迫するようになり、またその処理自体の遅さが目立つようになりました。

あるときには、想定以上のインプットデータで計算が行われてOOMが発生するなど、限界が見えていました。

また、ユーザ数の増加に伴い計算が行われる頻度が上がっており、並列での処理が難しいNode.jsから他の基盤への移行を検討することになりました。

• Spark

• 大量データの取り扱いが容易か
• 並列で処理が可能か
• リソースの管理を気にしなくてもいいか

• 大量データの取り扱いが容易か
  • テラバイト規模のデータも高速で処理できる
• 並列で処理が可能か
  • 可能
• リソースの管理を気にしなくてもいいか
  • フルマネージドなサービスなので任せることができる

その他にも下記の点が魅力的でした。

• JavaScript　UDFを駆使してSQLだけでは対応が難しい複雑な処理を組み込めること
• 全社的にGoogle Cloudを利用している、かつBigQueryは他サービスで導入済みであったこと

計算基盤をBigQueryに移行した後は想定通り、計算をより高速に、またデータ量が増大しても、性能に大きな劣化がなく安定した状態で実行できるようになりました。 計算時間は移行前と比べて25倍以上の高速化に成功しています。

フルマネージドなので、リソースの心配もほぼなくなり、同時に複数個の計算を走らせても問題なく実行できる環境になりました。

計算の途中結果を残して置けることも大きな利点となりました。

Node.jsでの計算では、途中結果を何処かに保持する処理のオーバーヘッドが大きく実現することができなかったのですが、BigQueryに移行後は、計算を数十のステップに分割し、各ステップで途中結果をテーブルに保存し、次のステップでその結果を使って処理を行っていくような作りにしたことで、一連の計算結果を簡単に参照することが可能になりました。

また、他のGCPサービスとの連携のしやすさも優れた点です。

ユーザのインプットデータは基本的にはCloud SQL(PostgreSQL)に保存されており、計算時にはそれらを使用します。

BigQueryからCloud SQL 連携クエリ(いわゆるEXTERNAL QUERY)を用いることで、簡単にCloud SQL内のデータにアクセスすることができます。

さらに、計算結果をCSVとしてCloud Storageにエクスポートすることも難なく行うことが可能で、入口と出口をシームレスに繋ぐことができるのは大きな利点であると考えます。

当然といえば当然ではありますが、Node.js/TypeScriptで実装されていた処理を、SQLに書き換える膨大な作業を行う必要がありました。 移行後にも、一定期間古い基盤を生かしたまま並行稼働させ、計算ロジックに誤りがないかを確認して、万全を期しました。

また、どうしてもSQLで表現することが難しいロジックがあり、そこに対応できるかが危ぶまれました。 ただ、BigQueryにはユーザ定義関数をJavaScriptで実装し組み込むことができる機能があるので、それを活用することでロジックを移行することができました。

ローカルでの動作確認・テスト実行が難しい点も課題となりました。 実環境に向けて開発を行うと、どうしても費用面で懸念が発生します。 また、各開発者の環境の分離も上手くコントロールする必要があります。 そこで、eScanではBigQuery EmulatorというOSSを用いることにし、動作確認やテストを行っています。

BigQueryはDWHとしての使い方が一般的だと思いますが、eScanではこのように、優れた高速性や分散処理性能を活かして、大規模なデータに対する複雑な計算を任せています。 活用していくなかで感じるのは、他のGCPサービスとの連携のしやすさです。 すでにGCPを使っているのであれば、BigQueryを選択するメリットは大きいのではないかと思います。