⚡

個人開発のサービスへ大胆にBigQueryを選定した理由

2023/03/20に公開

GCP

はじめに

筆者はVRコウコクというサービスを開発しています。
これは数あるVRChatのワールドに個人や企業が広告を出稿できるサービスです。

このサービスでは、DBにGoogle BigQueryを全面採用しています。
どのようなシーンで使っているというと、ユーザーからの広告へのリクエストをデータベースにアクセスログとして記録する場面です。
ログはPV数の推移やユーザー属性の解析、広告料の計算などに使われます。

個人開発のサービスで、Google BigQueryを採用するのは比較的珍しいケースではないでしょうか？
本記事では、VR広告配信システムにGoogle BigQueryを採用した理由を解説します。

技術選定で大切なもの

技術選定で大切なのは最先端の格好いいイケてる技術を選定することではなく、要件を整理し、個々のユースケースに最適な技術を選択することです。

筆者は広告配信サービスで必要な要件は、以下だと考えました。

大量アクセスに耐えうるスケーラビリティを持ち合わせていること
インフラ管理の手間がかからないこと(インフラ要員がいないため)
高度なデータ分析を行えること
アクセスがないときにコストを抑えられる構造になっていること

採用した理由

技術者としての先行投資

技術選定として「安牌」を選択し続けるという戦略があります。
ここでの「安牌」とは一般に普及しており、枯れきった技術のみを採用することを指します。

この戦略には一定の合理性があります。第一にエンジニアの確保が容易ですし、豊富なドキュメントもあります。ネットで検索すれば詰まるところを解決した記事などがいくらでも見つかるでしょう。
つまり、技術選定で「美味しいところだけ」を頂こうとする戦略です。

しかし、この考え方は長期的に見て危険です。
なぜなら、技術は新陳代謝するからです。

たとえば、勘定系で十分なナレッジが貯まっているからといって、銀行のシステムにCOBOLを採用し続ける危険性を考えてみればわかります。

また、BigQueryを採用した理由の一つに、技術者としての先行投資があります。現在、データ分析や機械学習分野のニーズが急速に発展しており、企業はこれらの分野で競争力を維持するために先行投資を行っています。

BigQueryを利用することで、こうした企業に対してニーズのあるキャリアを築くことができます。また、BigQueryはSQLをベースとしているため、従来のRDBに慣れている技術者も、スムーズにスキルを習得できます。

スケーラビリティ

広告配信システムでは、サービスがヒットしたときにアクセス数の急増が見込まれます。
従来のRDBでは、スケーラビリティの制約があるため、大規模なデータを効率的に解析するのが難しい場合があります。一方、BigQueryは、スケーラビリティに優れており、クエリを即時に実行できるため、リアルタイムでデータ分析が可能です。

たとえばBigQueryを利用すると、数テラバイト、数ペタバイトのデータに対し、数秒もしくは数分でクエリを完了できます。
これは大量のアクセスログを解析するときに、大きな力を発揮するでしょう。

コストパフォーマンス

どんなサービスでもそうですが、コスト面での考慮は欠かせません。
ビッグデータを扱えるように作られたBigQueryのストレージやクエリ処理のコストは比較的安価であるため、コストパフォーマンスが高いといえます。

そして前提として、個人開発のサービスが鳴かず飛ばずといったケースも大いに考えられます。
といいますか、個人開発に限らず新規のサービス開発者は、そのような事態を大いに想定しておくべきです。

たとえば、サービスを開発するたびに、いちいちAmazon RDSで新規のDBインスタンスを立てているのでは出費にキリがありません。

BigQueryは従量課金制を採用しており、使用したリソースに応じて課金されます。
つまり、全然サービスが使われなかったという事態になった場合、コストが抑えられます。

※ 似たような理由で個人開発ではFirestoreを使うケースも多いです。今回使わなかった理由はビッグデータにクエリを発行しデータ解析をする広告用途に向いていないと思われたからです。

これにより、初期投資を抑えることができ、システムが急激に成長してもコストを最小限に抑えることができます。
また、個人開発のサービスは放置してたらいつの間にか口コミで広がりヒットしていたなんてことも、十分にあり得ます。これは短期的に利益を出すことを求められ、サービス撤退の判断も早くしなければいけない企業では到底できない戦略です。
この戦略を実現するには、なるべく固定費を削り、サービスをなるべく安く長く存続させることが重要です。

インフラ管理

BigQueryでは、サーバーレスなフルマネージドサービスなのでインフラ管理をする必要は一切ありません。
これは個人開発のように人的リソースが少なくインフラ管理よりサービス開発にリソースを集中させたい場合に適しています。

データウェアハウスとしての充実度

既存のデータベースでは、データの収集、保管、分析が別々のシステムで行われることが多いです。しかし、BigQueryはGoogleが提供するデータウェアハウスであり、これらの機能が一元化されています。
たとえばGoogle Looker Studio(旧称: Googleデータポータル)などを用いて、容易にデータを可視化することができます。

Google Looker Studioダッシュボード画面

また、SQLを用いた柔軟なクエリが可能であるため、SQLの知識を活かし効率的な分析が実現できます。

具体的にVRコウコクでは内部でダッシュボードを作成し、日毎のPV数推移や未払いの広告料の累計などを算出してシステム管理者が閲覧できるようにしています。

BigQueryが合わないユースケース

低レイテンシが必要な要件

BigQueryは分析用途に特化したデータウェアハウスであるということを忘れてはいけません。なので極度の低レイテンシが求められるシーンでは最適ではありません。そのようなシーンではMongoDBやFirestoreのようなNoSQLが適することが多いです。

データ構造が頻繁に変わる場合

RDBMS全般にも言えることですが、データ構造が頻繁に変わるようなユースケースにあまりBigQueryは向いていません。
比較的最近ではMySQLにJSON型などが採用され柔軟にデータを格納することもサポートされてきましたが、パフォーマンスの問題やクエリが限定的であること、インデックスの作成が制限されているなどの制約が存在します。
頻繁にデータ構造が変わることが想定される場合は、やはりMongoDBやFirestoreなどのNoSQLが適しているでしょう。

高頻度のデータ更新・削除が必要な場合

BigQueryは、データの追加や大規模な分析クエリに適していますが、高頻度でのデータ更新や削除が必要なシステムには最適ではありません。これは、BigQueryのストレージ構造が頻繁な更新・削除には適していないためです。このような場合、従来のRDBやNoSQLの利用が望ましいでしょう。

MySQLで間に合う要件のとき

採用しないケースで一番これが多いのではないでしょうか？
大量のデータなどを扱う予定がなく将来的にサービスの規模感として、MySQL等で間に合う場合は、素直にMySQL等を用いるほうがいいことの方が多いでしょう。
Laravelを用いる場合など、フレームワークとデータベースが密接に対応している場合も同様です。

最後に

個人開発でGoogle BigQueryを利用するケースは、まだまだ少ないと思います。
現時点で、個人開発に人気なのはFirestore等の手軽に使うことのできるクラウドDBサービスです。

一方で、BigQueryでビッグデータを扱うことは競合サービスに対し、大きな技術的優位性を保つことになります。

是非、この記事を参考にして、個々のユースケースに応じて、BigQueryを採用してみることを選択肢の一つとして視界に入れてみてください。