Nature でデータエンジニアをしている原( @toohsk )です。 データ分析を行う一方で、Nature に所属しているメンバーが幅広くデータの参照、分析ができるようになるためにデータ分析基盤の構築も行っています。 今回は、Nature で構築しているデータ分析基盤を紹介したいと思います。
どのようなデータ基盤にしたいのか
Nature の重要なカルチャーでもありますが、Nature においてProduct Driven で事業が進みます。
Nature におけるプロダクトは、スマートフォンのアプリのみならず、ハードウェアやファームウェアなどの開発が含まれます。したがって、一重にエンジニアといえど、得意な技術領域は幅広くなります。また、エンジニア以外のメンバーも含めてサービスのデータにアクセスし、ファクトベースに意思決定できる環境を用意したいと考えています。
このような背景の中で、分析が高速に周り、スケールできる分析基盤の構築を目指しています。
データ基盤のアーキテクチャ図
Nature で構築しているデータ基盤の概要図です。以降に要素毎の選択理由を説明していきます。
ソースデータとデータストレージ
アプリケーションのデータやRemo からアップロードされるセンサーデータは主に以下のコンポーネントに蓄積しています。
- Aurora
- S3
- DynamoDB
KPI として観測したいデータの多くは、Aurora とS3 に格納されているので、現在はこの2つのデータを対象にデータ基盤を構築しています。
なぜBigQeury を採用したのか
現在は集計をBigQuery で実行できるように目指していますが、上記のデータ基盤を構築するまでは、Athena でS3 のデータに対してクエリを実行していました。BigQuery を採用しようと考えた背景には以下のような理由があります。
また、BigQuery を採用するかどうかを検討していたときは、BI Tool も様々な選択肢がある中でどれを使うかも未定でした。この観点からも多くのBI Tool に接続しやすいストレージを選択しておくことで、幅広い選択肢を残すことができると考えました。
Workflow
OSS を始め、フルマネージドなワークフローも含めると様々あると思います。その中で代表格として以下が挙げられると思います。
今回はArgo Workflows を採用しました。
なぜArgo Workflows を採用したのか
Argo Workflows はKubernetes ベースのワークフローになります。したがって、各ジョブがコンテナがベースになります。
また、Workflow の定義はYAML フォーマットで記述することができます。
上述したように、Nature には様々な領域で優秀なエンジニアがいます。一方で、データエンジニアは2022年4月現在ではまだ少ないため、タスクの優先度やスケジュールによってはエンハンスが遅くなってしまう可能性があります。このような状況では致し方ない側面はあるものの、データエンジニアが少ないことが原因でちょっとしたログの処理や定期処理したいことが後回しになってしまうことは心苦しいものがあります。
Argo Workflows のように、Workflow の定義やタスク自体を特定の言語のみに依存せずに記述できることは、このハードルを下げることにつながります。もちろん、SQL を実行するだけのコンテナを用意し、SQL さえ用意できれば組み込める。といった汎用的なコンテナを用意し、実行しやすい環境も整備しています。
そして、OSS として公開されているコンテナを利用できるのも一つのメリットになります。例えばSlack に通知するようなコンテナなどです。
まだデータエンジニアのみがELT 処理を記述している段階ですが、データエンジニア以外のエンジニア、ひいては、会社のメンバーがコントリビュートできるようになればいいなと考えています。
まとめと展望
現在取り組んでいるNature のデータ基盤に関して触れてみました。Redis に格納されているデータのように、まだ整理できていないデータがまだたくさんあります。これらのデータをアクセスしやすいように整理することで、社内のデータ活用や分析、MLOpsの基盤など幅広く活用できるようにしていきたいと思っています。
Nature では、データにアクセスしやすい環境整備、分析をサポートし、データの価値をユーザに還元できる分析基盤を開発するデータエンジニアを募集しています。
Nature のデータ周りの環境は、開発の余地しかないデータ基盤や分析環境です。カジュアル面談などでたくさん議論できればと思いますので、御気軽に申し込みください。
