タグから見つける

タグから見つける

職種を選択

事業領域を選択

MANABIYAに登壇しました

初めまして。リクルートライフスタイル（以下、RLS）のデータ分析基盤において運用チームリーダーをしている白子（@y0shirak0)です。

先日開催されたMANABIYA -TERATAIL DEVELOPER DAYS-に参加させていただき、弊社秋本と一緒に登壇もさせていただきました。

今回は、登壇したセッションの内容と当日で伝えきれなかった内容の補足をメインにお届けします。

main

セッション内容

今回のセッションでは、RLSの30もあるサービスの各種データを一手に集め集計処理などをおこなっている社内分析基盤の構成や、分析基盤で利用している各DWHの選定理由・利用用途、そして分析基盤の課題をシステムと運用を用いてどう解決しているかの実例をお話しさせていただきました。

slideshareで登壇資料を公開しておりますので、ぜひご覧ください。

ここからは、セッションではお伝えしきれなかった補足情報をメインにお話しさせていただきます。

社内分析基盤

弊社の分析基盤の構成は下記になります。

architecture

データウェアハウス（以下、DWH）は、Oracle Exadata・Amazon Redshift・Google BigQuery・TreasureDataを利用しており、データのストア先・ハブとしてS3をメインで利用しております。

弊社の分析基盤が作られたのは2011年ごろで、その頃はHadoopクラスタ15台からスタートしたのですが、そこからHadoopからTreasureDataに移行したり、RedshiftやBigQueryを導入し始めたりと2011年の頃と比べるとかなり構成は変わりました。
現在では約4,000のテーブル、約4,500億のレコードを保持し、1,200ユーザから利用される規模の分析基盤までに成長しました。
ちなみに、ユーザとは弊社内の分析基盤を利用する人たちを指しております。

各DWHの選定理由と利用用途について

Oracle Exadata

弊社では元々IBMのNetezzaを利用していたのですが、EOSLに伴いOracleのExadataに移行しました。

Netezza後継機のPureDataではなく、Exadataを選定した大きな理由としては以下になります。

  • Exadata間でのDataGuardのよる冗長構成

    グループ会社であるリクルートテクノロジーズがすでにExadataを運用していたため、
    そのExadataとDataGuardを使い冗長構成を取ることができるため、耐障害性を上げることが可能です。

  • DBLINKでのOracleDBとのシームレスな接続

    事業側のデータベースがOracleを利用しているため、DBLINKを用いシームレスな接続が可能です。
    現在は1日1回、事業側のDBからデータ連携をしているのですが、今後は1時間に1回など連携タイミングも早めることができるかなと考えています。

ただ、Oracle Exadataはあくまでオンプレなので、ハードウェアやミドルウェアの運用が発生したり、スケールアウトが容易ではなかったりと運用上辛い部分も多いです。

Amazon Redshift

AWSが提供しているDWH製品です。
RedshiftはPostgreSQLがベースとなっているため、RDBのPostgreSQLと同じようなクエリを実行できるのが大きな魅力の一つかなと思います。
ちなみに、BLT分析基盤で一番最初に導入したクラウド環境のDWHになります。

Amazon Redshiftを選定した大きな理由としては以下になります。

  • ODBC/JDBCを利用して外部のBIツールとの接続が可能

    弊社では主にTableauを利用して集計・分析をしているユーザが多いため、ODBC/JDBCを利用して接続できるのは重要

  • CRUD処理が可能

    集計・分析に利用するためのデータマートを作成することが多いため、CRUD処理ができることは必須条件

  • マネージドサービス

    クラウドサービスでは常識ですが、ハードやミドルウェアの運用をしなくてもいいのは大変助かります。
    オンプレの運用は結構運用負荷が高いので…

Google BigQuery

GoogleがGCPで提供しているDWH製品です。
Redshiftと比べると後発のクラウドサービスですが、さすがというべきか、優れた点がたくさんあります。

Google BigQueryを選定した大きな理由としては以下になります。

  • キャパシティプランニングが不要

    先だってキャパプラをせずに利用することができます。将来、データ量がどのくらい増えるのか見立てが難しいので、キャパプラをしなくてもいい(=どれだけデータを入れても大丈夫)というのはビックデータ基盤にとって重要な要素です。

  • 他の組織、他社とでもデータ共有が容易

    グループ会社などがBigQueryを利用している場合は、プロジェクトの参照権限を付与することで他社のBigQueryにあるデータが参照できるようになるため、データ連携周りはだいぶ楽になります。（別途処理を実装しなくてもよい）

  • データロード処理とクエリ処理が影響し合わない

    BigQueryでは、データロード処理とクエリ処理では利用するリソースが違うため、もし大量データをBigQueryにロードしても、バッチ処理やユーザがアドホックに発行するクエリのレスポンスには影響しません。
    大量の行動ログをロードする環境として最適です。

TreasureData

TreasureData社が提供している、クラウド型データマネジメントサービスになります。
元々は、オンプレHadoopの代替として導入しておりました。
マネジメントサービスであることと、連携できるサービス数が多いのが特徴かなと思います。

TreasureDataを選定した大きな理由としては以下になります。

  • SDKが充実している

    Javascript SDKから、Android SDK, iOS SDKなどSDKが充実しているため、ネイティブアプリ等からTreasureDataへのログ連携が容易に実装できます。

  • 対応している連携サービスが多い

    上記の説明にも記述しましたが、連携できるサービスが多いので、他システムとの連携を容易に行うことができます。（例えば、GCSだったりSalesforceだったり）

課題をシステムと運用で解決する話

分析基盤を長年運用を続けていくと様々な課題が積み上がります。
本セッションでは、下記3つの課題に絞ってお話しさせていただきました。

  • 増えるデータ

  • 複雑な連携

  • 増える負荷

上記3つの課題に対する解決策として、システム面では Data Lake という概念が、運用面では Not Data Swamp(沼池) という方針が必要になると弊社は考えております。

Data Lake

Data Lake とは様々なデータを一箇所に集めることで他システムの連携をしやすくする仕組みです。
弊社では、現状RedshiftをメインのDWHとして使用しているため、AWS S3を Data Lake として利用しております。

弊社ではこの DataLake を使った仕組みとして下記のようなものを取り入れ課題を解決しようとしております。

  • Redshift Spectrum

    S3上のデータに対して、S3からRedshiftにロードしたりすることなく分析ができる仕組みです。
    「増えるデータ」の課題に対応します。
    弊社ではロードするテーブル数が4,000にものぼるため、ロードだけでもRedshiftにかなり負荷をかけていたのですが、その負荷が軽減されるのはRedshiftのパフォーマンス観点でかなり助かります。
    ただし、Spectrum経由でのクエリ実行だと通常よりも結果出力に時間がかかってしまうため、すべてのデータをSpectrum化するよりも、よく利用されるホットデータはRedshiftにロードし、一時参照のコールドデータはSpectrumでS3のデータを直接参照しに行くといいです。

  • Migaloo(社内プロジェクト)

    DataLakeをデータハブとすることで連携をしやすくする仕組みです。
    「複雑な連携」の課題に対応します。
    昨今の技術革新を鑑みると、今利用している製品よりもよりよい新製品が現れる前提で仕組みを作るのが重要だと考えています。

  • Google BigQuery

    元々行動ログをRedshiftにロードしていたのですが、選定理由でも説明したようにデータロード処理とクエリ処理を別リソースを利用するBigQueryに持たせることで、「増えるデータ」の課題に対応します。
    また、行動ログの分析でRedshiftではなくBigQueryをユーザに使ってもらうことで「増える負荷」の課題にも対応します。

  • 退避Redshift

    データ量やバッチ処理数、利用ユーザ数が増えてきたことにより、Redshiftのパフォーマンスがだんだん遅くなってきました。
    そして、Redshiftが遅いと利用者から不満が出てきたため、データ鮮度を求めないクエリなどを逃がすクラスタを新設しました。
    それを退避Redshiftと言います。
    毎週土曜日にRedshiftのスナップショットを使い、退避Redshiftを立てています。
    退避Redshiftにデータ鮮度を求めないクエリなどを逃がすことで「増える負荷」の課題に対応します。

Not Data Swamp

Not Data Swamp とは運用面での考え方になります。
ただデータを溜め続けるだけですと意味をなさず、どんどんデータが濁っていく(沼池になる)ので「どうユーザに使ってもらうか」を考えて、運用をまわしていくことも大切だと考えております。

Not Data Swamp を意識した仕組みとして次のものがあります。

  • George(社内プロジェクト)

    退避Redshiftでも鮮度の高いデータを分析したいというユーザの要望があったため、データロード用のSlack Botを実装しました。
    ユーザがSlackでテーブル名を呟くことで、S3に保管している最新のデータを退避Redshiftにロードする仕組みです。

  • Event Driven Upload

    ユーザ自身が持つtsvデータなどをRedshiftで分析したい要望がたまにあるのですが、エンジニアでもないユーザにとってみればファイルをRedshiftにロードするだけでも大変です。
    そこで、ユーザがもつファイルなどを簡単なブラウザ上の操作でRedshiftにロードする仕組みを実装しました。
    ユーザ自身が持つデータをRedshiftにロードしづらいという不満を解消しています。

スポンサー

弊社もBRONZEスポンサーとして協力させていただいておりました。

今回はブース出展などは行なっていなかったのですが、次回はブース出展も一緒に行いたいです！

最後に

素敵な場をご提供いただいた、MANABIYA運営の方々には非常に感謝しております。

今回のセッションでは、弊社の分析基盤についてと課題についてのシステム・運用を用いた解決方法をお話しさせていただいたのですが、もっと具体的な話や実際の現場の話もできればよかったのかなと思います。

次の機会では、もっと深掘った話をできればと思っております！