ブックウォーカー社のデータ基盤について(2023秋)

ブックウォーカー社のデータ基盤について

こんにちは、メディアサービス開発部サービス分析課の佐藤です。ブックウォーカー社で全社横断のデータ基盤を構築しています。

ブックウォーカー社に入社したのは2022年4月でしたが、それから1.5年が経ち、データ基盤の形が見えつつあります。 まだまだ理想形には程遠い状態ではありますが、構築中であるデータ基盤の現在地をご紹介したいと思います。

背景

まず、データ基盤の構築はあくまでサービス分析課の一業務であり、必要に駆られて行っている作業です。 サービス分析課は下記のミッションを掲げた、組織全体のデータ活用を促進するためのチームです。

データとコミュニケーションによる課題解決の功績をもってデータ文化の規範となり、各部門が本質的課題に正しく立ち向かえるよう支援する。

このため、データ基盤にかける労力はできる限り抑えたいと考えており、基盤構築が進んで安定稼働の軌道に乗ればまた別の業務へ乗り出すこととなります。 その未来を見据え、下記の2つの方針を持ってデータ基盤構築を行っています。

  • セルフサービスの推進
  • 作業の省オペレーション化

構築自体にはどうしても時間がかかってしまいますが、運用の手間は極限まで引き下げるつもりでいます。

データ基盤設計における技術選定

上記の背景に基づいて、構築後の運用負荷が軽くなるように技術選定と基板設計を行いました。

ブックウォーカー社では多数のサービスを運営しています。データ基盤ではこれらのサービスの運営・開発に用いる様々なデータを取り扱います。データ基盤計画の手始めとして、多種多様なデータをどこにかき集めるかが問題になりました。検討の結果、下記の3点を主な理由としてBigQueryを採用することになりました。

  1. Google AnalyticsやFirebase Analyticsなどのクライアントログとのシームレスな連携
  2. Google Workspaceと連携したアカウント管理
  3. 既にLookerStudio(当初はData Portal)とGoogle Sheetsを利用していたこと

Google AnalyticsFirebase Analyticsは既に導入されており、ここから新たなクライアントログへの移行やそのログ基盤を構築する余力を確保できる見込みがありませんでした。もちろんBigQueryへエクスポートした後に転送することで、他の設計でもこれらのログを扱うことはできますがどうしても取り回しの手間が発生してしまいます。また、他のGoogle Marketing Platform製品も積極的に利用されており、それらGoogle周辺エコシステムとのシナジーを考えてのこともありました。

データ基盤利用者のアカウント管理もできるかぎり省力化したいところです。個別にIAMを管理したりSAMLによるアカウント連携を用意したりする手間も惜しいため、既に全社的に導入されているGoogle Workspaceアカウントをそのまま活用することにしました。 これにより既に社内で利用していたGoogle Groupsを扱って部署単位でのユーザー管理ができるようになり、データ基盤側でのユーザー管理はほとんど手間がかからなくなりました。これもGoogle周辺エコシステムとのシナジーと言えるでしょう。

AWSとGoogle Cloudをまたいだクロスクラウドなシステムになってしまうことは懸念点であり、今後もなにかボトルネックとなってしまうのではないかとずっと不安があります。しかし上記の、特にクライアント側でのログについてはデータ基盤の一存ではどうにもならない話でもあるためこういった技術選定となりました。 結果としてデータ基盤はGoogle Cloudに主軸を置き、省力化のためにマネージドサービス製品をフル活用して構築することになりました。

データ基盤設計の現在地

下記の図が2023年10月現時点でのデータ基盤の外観図です。

現状のデータ基盤外観図

構築に利用した主な技術スタックは下記のとおりです。

  • 言語: Python (AWS LambdaとCloud Functions内)
  • IaC: Terraform
  • CI/CD: GitHub Actions
  • DWH: BigQuery
  • ログ: Google Analytics, Firebase Analytics
  • AWS側バッチ: Step Functions, Lambda, Glue, SAM
  • GCP側バッチ: Cloud Functions, Data Transfer, schedule query in BigQuery
  • BI: Looker Studio, Google Sheets(connected sheet)

使用言語にこだわりはありませんでしたが、AWS Lambda, AWS Glue, Cloud Functionsを採用する必要があり、すべての環境で揃えられる言語だったためPythonを主に採用しています。

Infrastructure as a Codeとして、AWSとGoogle Cloud両方の管理が必要なためTerraformを利用し、GitHub Actions内でCI/CDを実行しています。

ログについて、クライアントサイドのログはGoogle AnalyticsとFirebase Analyticsを利用してGA4 BigQuery ExportによりBigQueryへ集めていますが、サーバーのアクセスログは各サービスからバラバラの方法で提供されています。図にあるように、別プロジェクトのBigQueryのデータセットに置かれてるものもあれば、S3経由で提供されるものもあり、あるいは全くアクセスログを取得していないサービスもあります。 アクセスログの取り回しは目の前にある大きな課題です。

各種サービスのデータベースからデータを集約する部分に関しては過去の記事に詳細な情報がまとまっています。ぜひご覧ください。

現在データ基盤の活用方法はLooker StudioGoogle Sheetsのコネクテッドシートなどの集計系が大半を占めています。 活用手段のバラエティが少ないことは課題に感じています。今後、もっとサービス開発を支援できるようにデータ基盤を活用の場を探しています。

計画中の構成

前項でいくつかは挙げましたが、現状のデータ基盤にはいくつもの課題があります。

  • 各地に散らばっているデータを取り込むのが大変
  • データの更新頻度が日次で、待たされてしまう
  • スケジュールクエリの依存関係がわかりにくい
  • 活用先が少ない

そこでこれらの課題を解決するため、現在計画中のデータ基盤はこのような外観となっています。

計画中のデータ基盤外観図

現在地との差分を抑えつつ、計画について説明していきます。

アクセスログ取り込み経路の統合

AWS ECSのFireLensからFluentBit経由でPub/Subへアクセスログを送る仕組みを開発中です。 この仕組みにより、各地に分散したアクセスログを統合的に運用できるようになる目論見です。

FireLensからBigQueryへのログ投入については様々な設計パターンがありますが、Pub/Subを活用してカスタムスキーマBigQuery Subscriptionを利用する設計計画です。他の設計候補との比較検討などについては、完成次第また記事を書こうと思います。

DBデータ取り込み頻度向上

現在RDSのスナップショットとStep Functionsを利用し、サービスのデータを日次で取り込んでいます。しかし、ものによっては数時間毎などのもっと早い頻度でのデータ更新が求められます。 そういった今よりも高頻度なデータ更新をMySQL、PostgreSQLなどDBの種類を問わず統合的に扱うため、DatastreamによるChange Data Capture(CDC)を検討しています。
更新頻度が数時間程度であればCDC以外にもS3にダンプして転送など様々な手段があるのですが、今後様々な利用ケースがありうると考えて調査対象の一つとしています。

データ処理パイプライン

スケジュールクエリは手軽で便利な仕組みですが、一方で全社的にデータ基盤の加工処理として使い倒すには色々と機能が足りてないのと、bqコマンド等によるシステム的運用が難しく感じています。

そこでDataformへ徐々に移行することを計画しています。 このようなデータ加工パイプライン製品について、よくdbtとDataformの比較記事を見かけますが、Google Cloudへの統合が済んだ今、BigQueryを採用している弊データ基盤ではこちらのほうがメリットがあると考えた次第です。
また、最終的にはできればエンジニアの補助無しで、非エンジニアが独自にデータ加工パイプラインを組めるようにしたいという魂胆もあります。
この辺も工夫が必要になると思うので、移行が進んだ日にはまた記事にします。

データエンジニア募集中

現在開発中のデータ基盤について、現状と計画中の概要について説明しました。技術選定は一朝一夕では成らず、試行錯誤が必要になると思っています。今後も開発や運用を通して新しい技術要素に置き換えたり、今利用している技術をさらに使いやすくなるような改良もしていく予定です。

ブックウォーカーではデータ基盤を整え、誰もがデータ分析を行えるデータの民主化を推進しています。 電子書籍ストア、マンガ連載サービス、読書SNSなど出版分野のデータを扱うデータ基盤を一緒に作りませんか?

出版文化からイノベーションを生み出すためにも、我々と共にデータ基盤を作り上げてくれるデータエンジニアを募集しています。ぜひブックウォーカーの採用情報ページからご応募ください。