これまで小ネタは書いたけど、なぜApache Airflow (以下Airflow)使ってるのか、Cloud Composerを使わずGoogle Kubernetes Engine(以下GKE)を使っているのか等そもそも論的なことは書いてなかったので、忘れないうちにまとめ。
データ基盤を作る理由
シニアジョブでは社長を筆頭に営業上に必要な数字を管理画面で見れるようにしてデータを活用しています。
でもアプリケーションと同じDBを使っているため、負荷の問題などもあり、いろいろと限界が来てました。
そこで、イマドキの会社では当たり前になっているデータ基盤を構築し、アプリケーションとは分けてデータを利用できるようにしようと思いました。
参考にしたのは下記の記事。
ワークフローエンジンの選定
BigQueryは以前ビズオーシャンでも使ってたけど、DBからのデータ移行は開発サーバーでバッチ処理を行っていました。
しかし、それはあんまりイマドキではなく、上記の記事であるように、最近はGCPのCloud Composer等、ワークフローエンジンの利用がいろんなところでおすすめされているため、調査をしました。
選択肢としては下記のようなものがありました。
参考:
qiita.com
ワークフローエンジンの選択肢
Cloud Composer
GCPが提供するマネージドのAirflow。複雑なAirflowをサクッと動かせますが後述するように、動かすだけで月4万円以上かかります。
Cloud Data Fusion
こちらもGCPのマネージドETL。コードではなくGUI上でできるようですが、むしろコードで管理したいので除外。情報も少ない。
Cloud Data Fusion | Google Cloud
Digdag
Fluentdでおなじみの Treasure Data社製のワークフローエンジン。オープンソース。タスクはyamlで書きます。
www.digdag.io
Argo
Kubernetes向けに作られたもの。オープンソース。こちらもyamlでタスクを書きます。
Jenkins、Rundeck
イマドキ感不足。前職で使ったけどもう触りたくない
Airflow を選んだ理由
GCP, BigQuery との親和性
まず大前提としてBigQueryを使うというのがあるので、GCPのマネージドがあるということが一番大きいです。
BigQueryはもちろんCloud Storageなどを使うライブラリも充実しており、情報も多いです。
GCP系であれば驚くほど少ないコードでタスクを書けます。
タスクをPythonで書ける、本体もPython
まずDAGと呼ばれるタスク定義を書くのがPython。
なにか困っても大抵のことはできそうだし、一番好きな言語なのでポイント高いです。yamlは仕方なく書くけど好きじゃない。
本体もPythonなので詳しく知りたくなっても読みやすいです。
また、WEBサーバーにはFlask, タスクキューにはCelery, メタデータDBの接続にはSQLAlchemy, 時間系にはPendulumなど有名どころのライブラリの組み合わせでもあるのでPythonアプリケーションの教材としても優秀だと思います。
Airbnbのブランド力
名前もおそらくAirbnbのWorkflowだからAirflowなのでしょうか。
私がPaul Grahamのファンであり、現在は引退したもののAirbnbがY Combinatorの出資先でもあるのでポイント高いです。
検索情報の多さ
Cloud Composerのユーザーも多くみられ、検索数でもDigdagよりも多いようです。
実際構築する際に困ったことはだいたいググって解決できました。
公式ドキュメントも充実しています。
画面がかっこいい
大したことやってなくても見た目がかっこいいです。
Cloud Composerではなく自分でAirflowをGKEで動かすことにした理由
お金の問題
Airflowはかなり複雑なAirflowをポチっと構築、運用してくれるCloud Composerは超便利ですが、対価としてお金がかかります。
アメリカのリージョンを使い最低にしてもCloud Composerだけで月400ドルの見積もりとなってしまいました。プラスでディスクやネットワーク代もかかり、東京リージョンも使いたいので現実的には600ドル前後でしょうか。
リージョンやマシン数によっても違うので下記から計算できます。
Google Cloud Platform 料金計算ツール
しかし、導入段階の自社においては、どれだけ使うかもわからないし、そんなに性能も信頼性も必要ありません。
Cloud Composerではノード数を3以下にできないかったり、メタデータDBにCloud SQLを使ったりと、現時点では圧倒的オーバースペックです。
全部GKEで動かせばおそらく月150ドル程度、BigQuery、ネットワーク代などを加えてもトータルで300ドル程度に抑えられそうです。
また一旦動かせたら、そんなに手もかからないはず。
ざっと日本円で月3万円ぐらいは節約できるので、本番環境における直接的なコストだけ考えても年約36万円節約できます。
まだ動かして数日で、テスト的なタスクしかやってないけど2週間で1万5千円くらい。
GKEのノードn1-standard-2(CPU:2、メモリ:7.5GB)1台で動かせています。
知識の問題
正直最初Cloud Composerを使った時は、DAGは何となく分かるけど、Airflowがどんな構造をしているのか、何をしているのかが全くわかりませんでした。
しかし、自分で構築してみるといろんなところでハマりまくり、いろんな設定を触ったり、本体のソースコードを読んだり、そのおかげで感覚的につかめてきました。
また下記のDockerで動かせるサンプルがあったのが大きいです。
github.com
また、今回は外向けのIPを固定する必要があったのでCloud NATを使った設定も実践することができました。
ローカル環境で開発したい
新規に構築するとのなると開発環境がほしいですが、Cloud Composerで開発環境も作ってしまうとまた月数万が飛んでいってしまうことになります。
社内にデータエンジニアが何人もいるような大きな会社であれば全然安いと思いますが、シニアジョブは現状エンジニア職2人(募集中)で、データまわりをやるのは現状私一人という状況では超高い。
またCloud ComposerはいろいろとGoogleが手を付けており、ローカルで同じようなAirflow環境を再現するのは難しいです。
Docker+GKEであれば同じコンテナを使用することができますので、環境差異も少なくストレスなく開発できます。