3フェーズに分けて振り返る atama plus データアーキテクチャ変遷

【初期フェーズ】Redash導入で専門人材不在でもデータ活用を実現（〜2020年）

会員限定コンテンツ無料登録してアーキテクチャを見る

2020年以前のatama plusでは、データへのアクセス方法として確立された手法や便利な仕組みは導入されておらず、データベース dumpを任意の開発環境にアタッチして調査したり、SQL Clientでアクセスしたりする方法が採用されていました。しかし、セキュリティ上の課題やオペレーションの煩雑性などの課題があったことから、SaaS版のRedashを導入し、初期のデータ基盤の運用をスタートしました。

稼働開始当初は、アプリケーションデータベースのReaderインスタンスに対して、Proxy serverを経由して、SaaSのRedashからクエリが実行できる仕組みとしました。2021年にSaaS版のRedash提供が終了されるタイミングで、OSS版のRedashをEC2上で動かすという構成に変更しました。

この当時は、専任のデータ組織やデータ人材はおらず、Redash基盤の構築や運用はSREチームが行っているという状況でした。しかしミニマムながらもデータ基盤を導入したことで、安全、かつ簡単にデータにアクセスできる状況になりました。saved queryやdashboardを用いてBizメンバーが事業運営するなど、開発者以外のメンバーでも容易にデータにアクセスできるようになりはじめました。

【第二フェーズ】BigQuery×TROCCO導入で高速かつ簡便なデータアクセスの実現（2021年〜2023年）

会員限定コンテンツ無料登録してアーキテクチャを見る

Redashを中心とした基盤の限界

初期アーキテクチャではRedashを用いたデータ利活用が浸透していく一方で、

• 生徒さんの学習履歴テーブルのような、大規模テーブルへのクエリが非効率
  
• Redashからのクエリはアプリケーションに最適化されたデータモデルの知識が必要で、活用できるメンバーが限られる
  

といった、さらなるデータ利活用浸透にあたっての課題が顕在化してきました。
そこで、高速に大規模テーブルに対するクエリが実行でき、データマートといった分析用途のテーブル生成管理も容易に行える分析基盤として、Google CloudのBigQueryを中心としたアーキテクチャに移行しました。

アプリケーションのデータベースはAWS上のAmazon Auroraを利用しているため、BigQueryにデータを転送するソリューションの選定も必要でした。運用負荷や管理容易性からSaaSのソリューションを選定することが優位となり、TROCCOを採用しました。また、TROCCOにはBigQueryに対してデータマートを作成する機能も提供されていたため、転送だけでなく、データマート作成にも利用することとなりました。

BigQuery×TROCCO導入による効果と、組織の変化

BigQueryを利用することで、高速なデータへのアクセスが可能となりました。また、データマート層が整備されはじめたことで、データモデルに対する知識がなくともデータに触れやすくなり、エンジニア以外の職種でのデータ利用が一段と進みました。さらに、TROCCOの強みでもある豊富なデータコネクタを活用し、SaaSデータをBigQueryに取り込んで活用する事例も出てきました。

また、このタイミングで、専任のデータサイエンティストが入社し、データ活用をより推進できる体制が強化されました。さらに、データサイエンティストを中心に、データに対するモチベーションが高い有志メンバーで構成された”ギルド”も発足し、社内でのデータ利用を後押しする構造ができ始めました。 しかし、データ基盤自体は依然SREチーム管理で、専任のデータエンジニアチームは不在のままでした。

【現在】機械学習へのデータ利用を見越したアーキテクチャへ（2024年〜）

会員限定コンテンツ無料登録してアーキテクチャを見る

OLAP・機械学習利用に向けたアーキテクチャの改善へ

データ基盤の成長や、データ利用のニーズが拡大するにあたって、GUI操作が前提となっているTROCCOでは、データ転送処理やデータマート管理に加えて、バージョン管理やCI/CDなどのコードベースで対応する必要がある部分において、負が大きくなっていきました。

具体的には、OLAP（Online Analytical Processing：オンライン分析処理）的な利用や機械学習への転用を進めるにあたって、データ基盤自体のstaging環境の必要性が増してきたのですが、容易に実現できない状況であったり、TROCCOではCDC（Change Data Capture）を利用せずにバッチでのデータ転送を行っていたため、よりリアルタイム性の高いデータの利用要望に応えられないなどのケースが発生しており、リアーキテクチャを再検討することにしました。

この第三フェーズにおいては、全面的にTROCCOに依存していた状況から、自社の状況に合わせてより柔軟に、適切なツールを選択するようにしました。

• アプリケーションデータの転送を、TROCCOからGoogle CloudのDatastream（マネージドCDCサービス）に置き換え
  
• データマートなどの分析用データ作成を、TROCCOからGoogle CloudのDataform（マネージドデータ変換サービス）に移行
  
• 一連のデータパイプラインをGoogle CloudのCloud Composer（Apache Airflowをベースに構築された、マネージドのワークフロー オーケストレーションサービス）で実行するように変更
  
• データ基盤リソースは全てTerraformでコード管理
  

尚、DatastreamでCDCを行うため、データ基盤がアプリケーションデータベースのWriterインスタンスを向くように変更する必要がありました。検討初期はこの構成に懸念があり、Readerインスタンスに対してKafkaを用いてデータパイプラインを構成する構想もあったのですが、運用にかかる負荷やリソースコストなどを総合的に検討して上記の構成を採用しました。

また、移行においてはDatalake層をファサード的に扱い、利用者がデータ基盤の変更をほぼ意識しなくてもいいような形で裏側のシステムだけ入れ替えて移行できるように工夫しました。

リアーキテクチャの成果とデータ利活用の変化

データ基盤をTerraformでコード管理できるようになったこと、データパイプラインをComposerで管理できるようになったことで、データ基盤の拡張性が非常に高くなりました。その結果、念願であったデータ基盤のstaging環境を用意することができました。これによりプロダクトでのOLAPとしてのデータ基盤の活用なども進めやすくなっています。
また、各種SaaSデータはTROCCOで転送する構成を維持しており、データ転送のソリューションが適材適所で利用できる状態になってきていると思います。

また、このタイミングでデータ基盤を専任で取り扱うデータエンジニアリングの組織が誕生し、データの利活用を行うプロダクトエンジニアやデータサイエンティストと、データ基盤を開発するデータエンジニアで協力できる体制が整い始めています。

前述のデータに関するギルド活動も継続して行っています。
ギルドは現在6名体制（2024年7月時点）で、週一で各部署・職種からのデータ関連の課題感を共有したり、Q毎のデータ系テーマを決める際に課題感を持ち寄って、何を改善するべきかの相談を行ったりもしています。
ギルドは基本的にはリソースを持たない有志の集まりなので、重いタスクを遂行することはあまりしていませんが、社内用ダッシュボードを作成し普及したり、データカタログ整備やwarehouseのメンテナンス、BizメンバーがSQLを組み立てる際のサポート等、全社的によりデータ利活用が進むような取り組みを継続しています。

atama plusのデータ利活用における今後の展望

これまで、大きく3段階のデータ基盤進化を超えてきたことにより、プロダクトや意思決定にデータを用いるハードルが低くなってきている事を実感しています。

一方、まだまだ課題は山積みです。今後はデータ組織として以下のような挑戦を通して、全社的にさらなるデータ利活用を推進していきたいと考えています。

• データカタログなどのサポーティブツールの充実
  
• データ収集が追いついていないサブシステム、他プロダクトのデータ基盤の構築（特にセンシティブデータを取り扱うコンポーネントのデータを安全に利用できる基盤の構築）
  
• データ組織の拡大、スコープの拡張
  

これらの挑戦を通して、教育ドメインにおけるデータカンパニーというポジションをより強く狙っていきたいと思っています。

最後に、atama plusでは、一緒に山積みの課題に挑戦してくれるデータエンジニアを募集しています。
少しでも興味を持ってくださっている方は、お気軽に求人へご応募、もしくは私、前田（ @kzk_maeda）までDMください。お待ちしています！

https://findy-code.io/companies/554/jobs/R3Zc3_L0d2J07（Findy内のatama plus データエンジニア求人ページが開きます）