データ分析

Redshift から BigQuery への移行: Discord 社の導入事例から学ぶ

GCP Gaming 1.jpg

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

編集者注: 今回は、ゲーマー向けの音声、動画、テキスト チャット アプリの開発メーカーである Discord 社にお話を伺います。Discord は、何百万もの顧客に対して同時に優れたユーザー エクスペリエンスを実現し、需要に対応しなければなりません。自社の成長を後押しするために、同社は Redshift から Google Cloud の BigQuery への移行をどのように実現したのかをご覧ください。 

Discord のチャットアプリは、月間 5,000 万人以上のユーザーをサポートしています。これまで数年間、データ ウェアハウス ソリューションとして Amazon Redshift を使用してきましたが、技術的およびビジネス上の理由により、BigQuery への完全移行を実施しました。それ以降、ユーザーにより早くサービスを提供できるようになり、AI、ML 機能の組み込みや、コンプライアンスの確保も可能になりました。

BigQuery への移行へと導いた課題

Discord では、技術的およびコスト面において Redshift の限界に直面していると認識し始めてから、Redshift の代替ソリューションについて検討するようになりました。ビジネスの成長に合わせてデータ ウェアハウスをスケーリングするには、新しいソリューションが必要なことは明白でした。技術面については、使用量の拡大がこのペースで続けば、6 か月で DC2 タイプのクラスタサイズの上限(コンピューティング ノード 128 個)に達することがわかりました。Redshift の使用コストも課題になりつつありました。それまで、使用コストだけで月に何十万ドルもかかっていました。これに加えて、ストレージや、Google Cloud と AWS 間のネットワーク(上り(内向き) / 下り(外向き))のコストもかかります(Google Cloud はチャット アプリケーション用にすでに利用していました)。

そこで、Google Cloud のネイティブ ソリューションをいくつか検討し、最も理にかなったソリューションとして BigQuery に目を付けました。その決定要因となったのは、Google Cloud の規模の大きさ(Discord より大きな有名企業を顧客に抱えていること)、Discord のデータ格納場所からの近さ、データ読み込みのためのパイプラインが Google Cloud にすでに確立していたことが挙げられます。また、BigQuery は完全にサーバーレスであるため、ハードウェアの事前プロビジョニングや管理が不要なことも主な理由の一つです。さらに、BigQuery Reservations と呼ばれる最新機能のメリットも享受できます。この機能では、スロットの使用容量が固定されているため、コストが大幅に削減されます。

移行のトレードオフと課題

移行前と移行中の準備を行う必要がありました。最初の課題は、Redshift と BigQuery がどちらも分析ワークロードを処理するように設計されているものの、非常に異なることでした。

たとえば、Redshift には非正規化されたテーブルセットがあります。この場合、各アプリケーション イベントが独自のテーブルになり、ほとんどの分析クエリは結合する必要があります。また、ユーザー維持率に関する分析クエリを実行するには、さまざまなイベントやテーブルのデータを分析する必要があります。そのため、このように多くの結合が必要なワークロードを実行する際、そのままの状態だとパフォーマンスに違いが生じました。以前、Discord は大量のデータの ORDER BY と行数に依存していましたが、そのメソッドは制限付きで BigQuery でサポートされています。Redshift と BigQuery はパーティショニングの方法が異なり、データ レイアウトが違うため、ユーザー ID などの結合はそれほど速くありません。そこで、JOIN フィールドでタイムスタンプのパーティショニングとクラスタリングを使用し、BigQuery のパフォーマンスを向上させました。一方で、BigQuery の他の側面はすぐに大きなメリットをもたらしたため、移行する価値がありました。メリットには、管理の容易さ(1 つのプロバイダに対して複数のプロバイダ、メンテナンスの時間枠がない、バキュームと分析が不要)、スケーラビリティ、コスト パフォーマンスなどが挙げられます。

ほかにも、この移行を行ううえで、いくつの事項を考慮しました。10 万行を超える SQL を BigQuery 構文に変換する必要があったため、ZetaSQL ライブラリと PostgreSQL パーサーを使用して変換ツールを実装しました。これを行うために、オープンソース パーサーを分岐させ、既存の Redshift SQL をすべて解析できるように文法を変更しました。この構築は、今回の移行において大変な部分でした。このツールは、テンプレート化された Redshift から抽象構文ツリー(解析ツリーとも呼ばれる)をたどり、BigQuery 用にテンプレート化された同等の構文を出力できます。さらに、BigQuery をサポートするために、事前に集計されたデータのビューの構築方法を再設計しました。BigQuery Reservations を使用して固定スロットモデルに移行したことで、ワークロードの分離、一貫したパフォーマンス、コスト予測が可能になりました。移行の最後の手順は、移行後の新しいパラダイムに慣れ、新しい運用モデルについて関係者を教育することでした。

Redshift から BigQuery に移行したことで、Discord の状況は大きく変わりました。パフォーマンスのボトルネックとキャパシティの制約を克服できただけでなく、ビジネスに関する実用的な分析情報を大胆に活用できるようになりました。Discord 社 機械学習部門技術リーダー兼マネージャー Spencer Aiello 氏

データ基盤として BigQuery を使用する

BigQuery への移行を完了して以来、スケール、ユーザー プライバシー、GDPR への準拠に関する目標を達成できています。今ではDiscord のレポート、ダッシュボード、機械学習、データ探索のすべてのユースケースを BigQuery がサポートしています。毎日、データストアに対して何千ものクエリが実行されていますが、BigQuery と同様にクエリをスケーリングするのは Redshift では不可能だったでしょう。

BigQuery によって、ビジネスを中断することなくスムーズに業務を遂行し続けることができています。これはわれわれにとって新鮮でした。なぜなら、Redshift の使用を止める前は、夜間メンテナンスの実施だけで 12 時間以上のダウンタイムが発生していたからです。このようなバキューム オペレーションは失敗することもあり、データの取り込みが可能になるまで 24 時間以上も社内 SLA を超過していました。以前はこのような課題に対処するために、Redshift でテーブルの削除と切り捨てを積極的に行う必要がありました。それが原因で、分析情報が不完全になったり、精度が低くなったりしていました。

BigQuery に移行することで、その他のメリットもありました。たとえば、ユーザーデータのリクエストにかかる料金が安くなり、データを受け取る時間が短縮されました。また、BigQuery のストリーミング入力によって、機械学習のテストを確認し、AI Platform からの結果をリアルタイムでモデル化できるようになりました。信頼性と安全性、財務、Discord 利用状況分析の新しいユースケースを簡単にサポートできるようにもなりました。「BigQuery は Discord が行うすべての分析の基盤となっている」といっても過言ではありません。

リソースの制約を心配することなく、一貫したパフォーマンスをユーザーに提供できることは、大きなメリットです。現在では、リソースについてあまり考えなくても、毎日、数百テラバイト以上のデータに対する何千ものクエリをサポートできるようになりました。複数のチーム間で分析情報を共有でき、BigQuery の AI 機能と ML 機能を活用する次のステップへと進む準備ができています。

詳細については、DiscordBigQuery のウェブサイトをご覧ください。

- By Discord 社