はじめに
こんにちは！今回はANDPADの各種ログを分析するためのデータ基盤を担当しているエンジニアからデータ基盤の変遷について紹介させていただきます。ANDPADのデータ基盤に興味がある方はぜひ過去の記事も合わせてご覧ください。
本記事では過去のデータ基盤が抱えていた課題と、チームがどうやってその課題を解決してきたか*1について紹介します。
基盤の構成
各種データソースからログを収集し BigQuery に投入する部分が本記事のスコープとなります。
過去の基盤は Amazon EKS 上で Digdag+Embulk を使用していました。
現在の基盤は Amazon ECS 上で Luigi を使用しています。
課題
データの量
過去のデータ基盤には処理データ量に比例して処理時間が伸びるという問題がありました。テーブルの増加やサービスの成長に伴うデータ量の増加により処理時間は13時間を超え、さらに毎月1時間ずつ処理時間が伸びていました。この記事で言及しているように、ANDPADの開発組織は3年後にすべてを10倍に成長させることを目指しています。更新が追いつかなくなる未来が見えており早急な対応が必要でした。
データの種類
過去のデータ基盤はANDPADの単一のRDSのみロードすることが機能要件となっていました。そのため他部署で利用されているSaaSの対応や、サーバーのログなど新しくデータソースを追加したいという依頼に対しレスポンス良く対応できておりませんでした。また開発組織がマイクロサービスを導入したことで今後分析対象のRDSが増えていくことが見込まれており、依頼に素早く応えられる仕組みが必要でした。
解決方法
基本的にLuigiを採用し、自前でコードを書いて作り込んでいくことで解決しました。Luigi を採用した理由は、短期間での構築が求められていて、アサインされたエンジニアに Luigi の経験があったためです。
また今後のデータ活用や採用していく人材を考えたときに、RubyやJavaでなく、Pythonで開発できたほうが都合が良さそうというのもあり、全面的にリプレイスを行いました。
データの量
Luigiで並列実行可能にすることで解決しました。過去の基盤はEKSで構築されていましたが、単一のコンテナでしか動いておらず、転送するデータ量が増えると処理時間も比例して伸びていく状態でした。
新しい基盤では実行基盤をECS*3に変更し、スケールアウト可能な設定にしました。データ量が増えたとしても並列実行数を増やすことで処理時間の伸びを抑えることが可能になりました。現在は7種類のRDSで250を超えるテーブル、3種類の他社プロダクトに対応していますが、10コンテナ以上並列に実行しているため、トータルで2時間程度で収まっています*4
データの種類
徐々に抽象化していくことで対応しました。RDSと他社プロダクトのデータはdumpする処理は違えど、BigQueryに取り込む処理だったり、アクセス管理だったりは同じように書けます。そのため他社プロダクトなどは新たにdumpする処理を書くだけで良くなっています。また新規RDSについては認証やタイムゾーンの設定はありますが、基本的にテーブル名とスキーマを追加すれば動くようになっています。
副産物
またLuigiは1 schedulerに対し、複数workerを起動してジョブを消化するためFargate Spotと相性が良く、安く運用できています。新しい基盤の2021年10月のECS使用料金は120ドル程度でした。*5
まとめ
過去の基盤はデータの量とデータの種類について課題がありました。
データの量に関しては、並列実行可能な基盤を採用することで解決しました。
データの種類に関しては、徐々に抽象化し、変更に強い設計を採用することで解決しました。
その結果スケーラビリティが高く、データソースを追加変更しやすく、120ドル/月とコストが安い基盤が出来上がりました。
さいごに
ANDPADではデータ基盤エンジニアに限らず様々なエンジニアを募集しています！
興味を持たれましたらぜひ下記リンクからご応募ください。
