バンダイナムコエンターテインメント、DeNA、リクルートテクノロジーズが語ったデータ基盤改革、「何を」「なぜ」「どのように」：Google Cloud Data Platform Dayで説明（2/2 ページ）

　なお、上記のWebアプリケーションへのアクセスは、認証プロキシの「Cloud IAP」を通じ、DeNAが社内で使っている「G Suite」のアカウントで認証を行うようになっているという。

リクルートテクノロジーズはスケールするセルフサービスデータ基盤を構築

　リクルートテクノロジーズは、社内の社内の「Oracle」「MySQL」「PostgreSQL」といったデータベース、そして「Salesforce」や「kintone」「Amazon S3」などの社外サービスから同社プロダクトに関するデータを引き出し、アナリストによる分析や機械学習、事業システムにつなげるETL（抽出／変換・加工／ロード）基盤「Garuda」を、GCP上に構築した。

　きっかけは、従来のオンプレミスにおけるデータ基盤が、障害耐性と拡張性の観点で、限界に近づいていたことにあるという。

　データは指数関数的に増加し、運用負荷が増すばかりで、基盤エンジニアは開発に手が回らない状況になっていた。この悪循環から脱し、本番データベースの運用担当者、分析者の双方が喜ぶような仕組みを作ることを目指したという。具体的には、本番データベースへの負荷が低い一方、アナリストなどがエンジニアの介在なしに、データ取得以降のプロセスを自身で完結できるような、セルフサービス指向の基盤を実現したかった。

　「データエンジニアは、データベース管理者とユーザーの間で板挟みの状況になっていた。そこでETLに関わるデータエンジニアをAPIに変えた。これで、プラットフォームとして定義した仕様で、ユーザー側がETLを行えるようになった」（リクルートテクノロジーズ データプラットフォーム部 白鳥昇治氏）。

　リクルートテクノロジーズでは、データ分析プロセスを「取得」「加工」「保存」「分析」の段階に分割し、ETL処理はコンテナとしてパーツ化して、Google Kubernetes Engine（GKE）上で実行する設計とした。処理はKubernetesのCronJobとして、並列度を制御し、優先度の高いものから行う。

　データベースなどから取り込んだデータは、OSSのembulkによってフィルター、型変換を加えた上でGCEに保存、これをcloudsdkでBigQueryにロードしている。embulkを採用した主な理由は、入力プラグインの豊富さにあったという。

　リクルートテクノロジーズでは、上記のETL処理を抽象化し、APIやWebユーザーインタフェースとして分析者に提供、セルフサービスで活用できるようにしている。