こんにちは、スナックミーでデータエンジニアをしている加藤です。
スナックミーではここ最近、データ利用に対する注目度が高まってきています。
それに伴い構築を開始したデータ基盤が安定運用できるようになってきたので、今回はこのデータ基盤について構築当初から安定運用までを振り返ってみたいと思います。
データ基盤の重要性
簡単にデータ基盤について書いておきます。
意思決定のための分析や現状をモニターするためなど、様々なデータ利用の用途に対応するためには利用しやすい形でデータが整備されている必要があります。
整備がなされていないと、どうやって目的のデータを取得して良いかわからなかったり、データを取得したいのにクエリが重すぎてかけることが実質不可能になってしまったり、データ利用の効率や広がりに悪影響しかありません。
そうしたデータの効率的な利用や整備されたデータの蓄積・管理のためには、ある程度コストを投下してデータ基盤を構築することが重要になると考えています。
構築前: 整備されていなかった状態
かなり簡略化していますが、構築前は以下のような構造になっており、下に挙げるようないくつかの問題が発生していました。
重たいクエリ・取得できないデータ
弊社ではデータの社内での可視化にRedashをメインに使用していました。
そしてRedashのデータソースとして主に、本番DBとして稼働しているAuroraとログ系などを集積しているS3をAthena経由でクエリできるようにしているものがありました。
そのため、Auroraに対してクエリをかける場合はものによってはクエリが重く負荷をかけてしまったり、Athenaの場合は元がログなどの非常に大量のデータであるため重すぎてRedashで可視化することが難しかったりしていました。
業務アプリ用DBと分析用DBの違い
次にデータを分析しようとなった場合の必要なデータの形式の違いの問題もありました。
例えば以下の画像のようなユーザーの会員ステータスを管理するテーブルがあった場合、アプリケーションのDBでは今の状態が分かることが重要で過去データは特に必要にならないケースも多いです。
大して、例えばユーザーの会員動向を分析しようとする場合にはそうしたステータスデータもヒストリカルにログデータとして扱いたいことが多々あります。
もちろん、アプリケーションDBにおいてもログのような形を取って最新のものだけ扱ったり、別途履歴テーブルを用意したりすれば解決するかもしれませんが、必要に迫られる頻度が少ないデータソースについてはそうした対策を取っておらず、分析的に扱いづらいデータがいくつもありました。
上の構成図のところでスプレッドシートが登場していることに気づいた人もいるかもしれません。
スプレッドシート、便利ですよね。扱いも簡単だし、共有もすぐにできるし。
けれど、多重参照や複雑な関数の入れ子が発生すると途端に職人技が必要になるものへと変貌します。
弊社でも、Redashからダウンロードしたデータをスプレッドシートで再集計して管理する、などといったことが行われていました。
結果的に、同じようなデータがやや異なる集計ロジックによって重複してしまったり、値を定数で入れてしまったために元の値がなんなのか分からなくなってしまったりということが発生していました。
ローカルを交えたMVP的な動き
さてここからは実際に構築へ向けて動き出してからの話になります。
しかしながら、どんなアーキテクチャにするのか？どの技術リソースを使うのか？テーブル構造はどんな戦略でいくのか？などなど、考慮すべきことがたくさんあります。
加えて、構築に時間はかかるけれどデータを利用したい側の需要は待ってくれません。構築に時間をかけるほどに本番DBに負荷はかかり続け、スプレッドシートは量産されていきます。さらには社内的な理解を得るためにも早急にMVP的なものを作って動かしていく必要があると感じていました。
そこで、以下のような構成でMVPとして、速さ優先で実稼働させることを意識しました。
Redashから各人が各々データを引き出していたところを、RedashAPI経由でローカルPCでデータを取得し、加工・整理してからスプレッドシートAPIでスプレッドシートに格納しています。そしてこれを早朝などにバッチ処理として実行し、最終的なデータの可視化にはGoogle DataPortalを利用しました。これにより、データをグラフィカルにダッシュボードとしてモニターすることができるようになりました。
またスプレッドシートに再格納する際、データウェアハウス・データマートとしての区別・構造を意識してデータ整備も併せて行なっていたため、分析用途で大規模なデータを取得する場合にも役立つことがありました。
そして何より、この形で爆速でMVPとして動き始めることができたことで、データ利用者側の需要やどういう可視化が必要とされていて、そのためにはどのようなテーブル構造が適しているのかなど、利用面の調査を兼ねることができたのが大きかったです。時間をかけて基盤を作っても誰にも使われないのでは意味がありませんからね。
当然いくつも問題点はあって
- 結局本番DBには接続してしまっている
- これについては、この処理の実行を早朝にすることで、ひとまず常時負荷がかかる状態は回避することにしました。
- スプレッドシートの増加
- スプレッドシートの数だけ見ればそうなんですが、ロジックによって管理されているのでどのデータソースからどのシートへとデータ挿入されているのかが追えるという点でそこまで大きな問題ではないと考えていました。
- セキュリティ面
- これが一番ですね。ローカルPCでゴニョゴニョしてしまっている点については、いったん仕方ないと受け入れて目をつぶることにしました。
AWS MWAAを活用したデータ基盤の構築
そんなこんなでMVPの運用をしてイメージを固めつつ、実際の基盤構築を並走して行いました。
見出しにもある通り、ワークフローエンジンにはAirflow (AWS MWAA) を利用し、ウェアハウス製品にはBigQueryを利用することに決めました。
MWAAを選んだ理由としては、初期のキャッチアップコストはかかるものの拡張性が高く、データのやりとりに関する管理がしやすいことが最大の利点でした。また弊社ではほとんどのリソースがAWS上に存在しているので、MWAAを利用すれば種々のサービスとの接続がしやすいことも魅力でした。
ウェアハウスについても今となってはRedshift serverlessが候補に上がりますが、当時はコスト的にBigQuery一択だった感じですね。
少し記事が長くなってしまったので、構築の困った点やポイントなどはまた記事を分けて書こうと思いますが、現在は以下のような構成になっています。
課題を解決した点は以下です。
- 本番DBからは夜間バッチでBigQueryにデータをコピーし、後続ではコピーされたBigQueryからデータを取得するようにしているので、本番DBには負荷がかからなくなった
- ログ系など、S3に大量に収集されていた非定型含むデータもAWS Lambdaでの処理を挟むことで扱いやすくなった
- データマートの整備によって、各人ごとにバラバラだった集計処理を一元化した
- Redashでのアクセスについても、重たいクエリであってもウェアハウスに対してであればデータが取得しやすくなった
などです。加えて開発面で言えば
- SQLによる処理について、コードを全て一元管理できるようになった
- データウェアハウス、データマートの拡張については、非常に簡単に行えるようになった
- 全体を一つのワークフローで管理するようになったことで、これまで一切考慮できていなかった冪等性やリトライ、エラー検知がやりやすくなった
基盤管理しているデータは日に日に増えており、今では5つのチーム (5つのダッシュボード)、約300テーブルほどのデータマートが運用されています。
データが扱いやすくなったことで、各チームのMTGで必ずダッシュボードを見る習慣をつけてもらったり、そこから現状の把握や次の施策への考察が生まれたりなど、より良い循環が生まれていると感じています。
今後もさらにデータ基盤を拡張させていき、データ利用を促進していきたいと思っています。
最後に
今回はデータ基盤の構築について振り返ってみました。
記事中でも書きましたが、現状動いているデータ基盤については別に記事を書いて詳細を説明していこうと考えています。
データ周りの業務はうまく各チームと連携できれば、実際の意思決定と密接に関わることができるので非常にやりがいを感じられる分野です。
スナックミーではデータ周りの開発業務を担当してくれるデータエンジニア募集しています！
興味があればぜひお話しを聞きにきてください！
meety.net
engineers.snaq.me
