PedidosYa: BigQuery でクエリあたりの総コストが 5 分の 1 に削減

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

編集者注: PedidosYa は中南米におけるオンライン フード デリバリー サービスにおけるマーケット リーダーで、15 の市場と 400 を超える都市でサービスを展開しています。また同社は、ドイツの多国籍企業である Delivery Hero SE の主要なブランドの一つでもあります。PedidosYa のアプリのダウンロード数は 2,000 万を超えており、レストラン、小売店、ドラッグストア、特定市場などを含む 71,000 以上のオンライン パートナーにより、最高のオンライン デリバリー サービスを行っています。

PedidosYa がカスタマー エクスペリエンスを改善し、革新するには、最新の顧客データに常時アクセスできることが重要な要件です。社内の関係者も、ビジネス上の決定を迅速に行うため、より早く分析情報を取得することを必要としています。PedidosYa の経営陣は 2020 年初頭に、非常に困難な課題をデータチームに与えました。当社のチームの任務は、PedidosYa 全体で包括的な情報エコシステムを作り上げ、ユニバーサルで安全なアクセスを可能にすることで、誰もがデータを分析できるようにすることでした。またチームは、この目標を達成するためのコストを、移行ステージや運用のボトルネックを取り除くときも含めて、コントロール下に置く必要がありました。 

以前のクラウド インフラストラクチャでの課題

PedidosYa は最初に、AWS 上でデータ プラットフォームを構築しました。当社のデータ ウェアハウスは Redshift で運営され、データレイクは S3 にありました。データ分析用のユーザー インターフェースには Presto と Hue が使用されました。しかし、このインフラストラクチャの保守はあまりに大変な作業でした。当社の以前のプラットフォームは、分析ニーズの増大に対応できませんでした。たとえば、S3 に保存されているデータは Presto / Hue で補完する必要があり、運用上の大きなオーバーヘッドとなっていました。これは、Presto と当社の IAM（Identity Access Management）が、以前のエコシステムとうまく統合されていなかったことが理由です。個別のユーザーを管理し、グループや Kerberos に IAM ロールをマッピングするには、運用上の多くの時間と費用が必要でした。さらに、S3 ファイルへのアクセスをシャーディングするのは非常に複雑で、シームレスなアクセス制御リスト（ACL）を実現するのは不可能でした。

ワークロード管理の課題もありました。当社のデータ ウェアハウスは、夜を通してデータのバッチ読み込みを行っていました。アナリストの 1 人が夜間の ETL（抽出、変換、読み込み）ワークロードの間にクエリの実行をスケジュールすると、現行の ETL タスクが中断される結果になりました。これにより、データ パイプライン全体が停止しました。停止した場合、データ エンジニアが手動で修正を完了するまで待つ必要がありました。

さらに、クエリのエラーがパフォーマンスの問題によるものか、プラットフォームのリソース枯渇によるものかを突き止めるのも困難でした。原因がわかりづらいため、データ アナリストがクエリの効率を自律的に改善することも妨げられていました。データチームのメンバーは、個人のクエリを手動で検査し、パフォーマンスの問題を探す必要がありました。また、現在のアーキテクチャのリソースは際限なく無料で使用できるように思えるため、「コモンズの悲劇」状況に陥りやすい傾向がありました。さまざまな関係者チームは要件が大きく異なることもあり、すべてのチームにとって適切なインフラストラクチャを実現するのは不可能でした。

データ ウェアハウスをモダナイズする意思決定

以前のプラットフォームでの問題が次第に大きくなったため、当社の技術チームは分析環境を最新のデータ ウェアハウスに変革することを決断しました。次のデータ プラットフォームには、次のような主な条件が必要とみなされました。

• スケーラビリティ - 弾力性のあるインフラストラクチャを使用して拡張性を持たせる。

• コストのコントロール - コストの管理と透明性。これらの要素から、効率性とオーナー権限が促進されます。どちらも、誰でもデータにアクセス可能にするという目標における重要な観点です。

• メタデータの管理 - ユーザーの従来の SQL に関する知識に特化した、直感的なデータ プラットフォーム。さらに、情報エコシステムをメタデータで強化することにより、データのゲートキーパーを減らすことができます。

• 容易な管理 - チームは、サーバーレス ソリューションを使用して運用費用を減らす必要がありました。データ エンジニアは、データベース管理者やインフラストラクチャ エンジニアの役割を果たすよりも、自分たちの主要な役割に集中することを希望していました。また、チームはより高い可用性を実現し、メンテナンスの時間枠やバキューム / 分析の影響を減らすことも望んでいました。

• データ ガバナンスとアクセス権 - 各種のデータアクセス要件を持つ従業員数が増大するにつれ、ユーザーによるデータへのアクセスを把握して追跡するための、簡単かつ包括的なソリューションが必要となりました。

Google Cloud への移行

さまざまな選択肢を検討した結果、当社は意思決定に関与する各要因を解決できるのは Google Cloud であるという結論に達しました。Google Cloud のサーバーレスでマネージドな統合データ プラットフォームは、オープンソース ソリューション間のシームレスな統合と組み合わせることにより、当社の組織にとって完璧なソリューションでした。特に、ジョブ オーケストレーターとしての Airflow との統合や、Kubernetes による柔軟なオンデマンド インフラストラクチャが鍵となりました。

当社は、データの取り込みの要件を満たすため Pub/Sub および Cloud Functions と Dataflow を組み合わせて使用し、これによって Terraform でのデプロイ処理がシームレスになりました。すべてを自社の環境にプログラムで設定したため、運用時間が短縮されました。Google Cloud により、従来のプラットフォームでは約 16 時間を要したデプロイ処理が、4 時間に短縮されました。これは、GCP 上の Terraform、Cloud Functions、Pub/Sub、Dataflow、BigQuery でのデプロイ（スキーマ チェック、読み込みテスト、テーブルの作成、ビルドなど）処理を自動化しやすいことが理由の一つです。入力メッセージを Dataflow で処理することにより、機能チームの必要に合わせてスキーマの変更を要約し、計画できるようになりました。たとえば、スキーマの変更によりアラームを発生させ、その後で元レイヤのテーブル スキーマを変更できます。これによって、当社がコントロールしていないバックエンドの変更が上のレイヤに影響しないことを保証できます。

当社が Google Cloud を選択した主な理由は、コストおよびワークロードの詳細な管理と、透明性のあるログ分析です。これらの情報により、クエリのパフォーマンスについてのあらゆる問題点がよくわかり、直ちに改善できるようになりました。さらに、複数のツールを BigQuery と統合することで、大幅なコスト削減を達成できました。

これにはいくつかの理由があります。

• パイプラインのデプロイを自動化することで、データ処理プロセスの保守が大幅に簡素化されました。

• アナリストは、自分たちが行うクエリを意識するようになったため、より的確で最適化されたクエリが行われるようになりました。

• アナリストは、データポータルのダッシュボードを使用して自分たちのクエリと、関連するすべての費用を確認できます。その結果、各ペルソナが大幅に透明化されました。

これらの変更により、各ワークロードに関連するコストを簡単に管理し、特定の Google Cloud プロジェクトを使用して各自の費用センターに割り当てられます。

チェンジ マネジメントは常に問題となります。しかし、BigQuery は直感的で、SQL の基本について Hue / Hive からの習熟が困難ではありません。また、チームは BigQuery を使用して能力を拡張し、ネストした構造で正しい作業を行えるため、不要な結合を避け、クエリを効率化できます。さらに Data Catalog で、メタデータ管理に必要なすべての情報が得られるようになりました。これにより、当社のチームはデータアクセスの障壁を打破し、組織間でデータの連携を行えるようになりました。Airflow を使用してすべてをオーケストレーションすることにより、すべてのデータ ストリームを常時把握できます。各エンドユーザーはこの情報を使用して、標準的に使用されるデータ エンティティのステータスをダッシュボードで確認できます。これにより、日常的なデータ処理もより透明化されます。

最後に、Google Cloud の IAM ルールを各種製品に適用することで、データの共有とアクセスがほぼ noOps になります。社内ではロールとレベルアクセスに従い、プログラムでアクセスを実装しました。これにより、特定の事前検証済みのロールは、より多くの機密情報を参照可能になります。これらのソリューションにより、データ ガバナンスの環境の自動化が促進されます。

次の目標: Google Cloud AI / ML

BigQuery をベースとする新しいスタックにより、生産性が大幅に向上しました。PedidosYa のデータチームは、運用管理の負担から解放され、データツールとプロダクトによる付加価値に注力できるようになりました。

• 当社のデータ エンジニアは、変化し続けるトランザクションと運用のデータを統合するための十分な体制が整っています。

• dataOps チームは、インフラストラクチャを自動化し、エンドユーザーに自主性を与えることができます。

• 当社のデータ品質チームは、データの関係者に付加価値を与えることに注力できます。

• データ サイエンティストとデータ アナリストは、データの分析により多くの時間を費やせるようになり、データのゲートキーパーにデータアクセスを依頼するため費やす時間が減少しました。

現在の PedidosYa は、適切に管理されたアーキテクチャを使用して、誰でもデータにアクセスできます。当社はこのアーキテクチャの活用を始めたばかりですが、データドリブンの組織を構築するという構想の実現に近づきつつあります。次の目標は、人工知能と機械学習能力の拡大です。

プロジェクトに画期的な機械学習テクノロジーを適用する方法について、Google Cloud の 2021 年 6 月 10 日の Applied ML Summit に参加するか、後日オンデマンドでお聞きください。

-PedidosYa、シニア データ ディレクター、Pablo Fleurquin 氏