スタートアップにおける
 データ基盤のバッチワークフローの変遷
 株式会社カケハシ
 福田 貴之


自己紹介
 福田 貴之
 株式会社カケハシ データ基盤 ProductOwner 兼 エンジニア
 経歴
 ● 某Y!2007年新卒でモバイル向けサービス開発運用 
 ● ソーシャルゲーム会社でログ基盤を約6年くらいみてた 
 ● あとはベンチャーをいくつか...(HR Saasとか) 
 ● 2020年より現職
 好きなAWSサービス: ECSFargate
 


Agenda
 ● カケハシの紹介
 ● 弊社の以前ワークフローの構成と問題点
 ● ワークフローエンジン選定
 ● MWAA(Airflow)使ってみた
 ● まとめ


株式会社カケハシ の紹介

明日の医療の基盤となる、エコシステムの実現
 Vision 患者 医薬品 サプライチェーン 薬局 ⽇本の医療体験を、しなやかに。
 Mission

事業内容 患者満足と薬局の働き方改革を支援
 電子薬歴の先をいく
 “薬局体験”アシスタント
 薬局と患者さんがLINEでつながり、
 LINE × 薬剤師で、薬局の外での
 服薬期間中も患者を継続フォローする
 調剤薬局の
 経営診断サービス


数字で見るカケハシ社 https://www.kakehashi.life/5th-anniversary.html

スタートアップにおける
 データ基盤のバッチワークフローの変遷


以前の弊社データ基盤構成

以前のデータ基盤のアーキテクチャ構成 ● サービスはDynamoDB
 ● Lambdaで生データを抜いて、加工をGlueJob、結果は S3に、それらのジョブをStepFunctionsで管理
 ● この処理結果のS3を使う別チーム(AWSアカウント) が、GlueJobを利用して、RDSに入れたり、Athenaから 利用している。これらはGlueWorkflowで管理
 


課題に感じていたこと ● チームも別々でどこで何が動いているか全貌把握が 難しくなっている
 ● 再集計の困難さ
 ● StepfunctionsもGlueWorkflowもWebコンソールから ワークフローを作っていた
 ○ コードで管理されていなかった


ワークフローエンジン選定

何故ワークフローエンジンを使うか ● cron(CloudWatchEventsなど)では駄目なのか?
 ○ 依存関係のない単発のJOBがある程度ならこちらの方が楽 
 ● バッチを運用してると困ってくること
 ○ ジョブごとの依存関係をコードで管理したい.... 
 ○ retry処理や成否通知処理をそれぞれのJobに実装したくない... 
 ○ どこまで終わっているのか状態管理をしてほしい... 
 ○ どの部分にどれくらい時間がかかっているのか観測したい... 
 ○ 失敗時にそこから再集計しやすいようにしたい... 
 ● 最初からワークフローを導入するのはオーバースペックな場合も


バッチワークフロー比較 OSSはいくつかあるけれど、、マネージドでやりたい
 ● (OSS)Airflow
 ○ Airbnb社
 ● (OSS)Digdag
 ○ TreasureData社
 ● (OSS)Argo Workflow 
 ○ k8sネイティブ
 ● (OSS)Luigi
 ○ Spotify社OSS
 ● AWS StepFunctions
 ● AWS Glue Workflow
 ● Amazon Managed Workflows for Apache Airflow


AWSマネージドワークフロー所感
 ● Glue Workflow
 ○ Glue Job/Glue Crawlerだけのワークフローなら作るのは一番ラク 
 ○ S3をGlueJobでETL処理してAthenaで見るみたいな用途だとマッチするのでは 
 ○ コンソールのジョブの一覧性がちょっと... 
 ● StepFunctions
 ○ GlueWorkflowよりは多少めんどくさいが自由度もある 
 ○ 豊富なAWSサービスとの連携 
 ○ 思想としてコードを書かずにワークフローが作れる 
 ● MWAA(Airflow)
 ○ Airflowをマネージドで運用してくれる 
 ○ ワークフローがコードで管理できる(=かなり書く必要があるが...) 
 ○ 拡張性もある(boto3でコードを書けになりがちだが...) 
 ○ UIがわかりやすく再集計などがやりやすい 


MWAA使ってみた!


MWAAアーキテクチャ
 https://docs.aws.amazon.com/ja_jp/mwaa/latest/userguide/what-is-mwaa.html 
 ● MetaDatabaseはAurora?
 ● Airflow Scheduler/Workerは ECS Fargate?


MWAAを利用したクロスアカウントでのデータ基盤
 ● それぞれのAWS環境で管理していた バッチをMWAAから一元するようにした
 ● クロスアカウントでGlueなどを叩く場合は AssumeRoleするような実装をした


MWAA(Airflow)実際運用してみて良かった点
 ● 半年くらい運用しているが特に問題は起きてない!
 ● DAGの反映がS3にアップロードするだけで即反映される!
 ● 1度コードを書いてpluginファイルにしておけば同じようなワークフローを量産しやす い
 ● コードでワークフローが管理できる安心感(どこで誰が何をやっているのか)
 ● (冪等に作っておけば)再集計も楽
 
 


MWAA(Airflow)実際に運用するにあたって辛いかもな点
 ● わりと(かなり)コード書く必要があるかも
 ○ 再利用は可能だし通知やretry処理を作り込む必要がないとはいえ... 
 ○ 一部はOperatorsなど用意されているものもあるが(ECSなど) 
 ■ https://airflow.apache.org/docs/apache-airflow-providers-amazon/stable/operators/index. html
 ○ GlueJobをワークフロー(DAG)から呼ぶときなどboto3で実装必要 
 
 
 
 ○ AssumeRoleが1時間で切れるのでそのあたりの実装も必要 
 ● [MWAA] plugin化したファイルの反映にAirflowの再起動が必要(30分くらいかか る...)
 def exec_gluejob(**kwargs): client = boto3.client("glue") res = client.start_job_run( JobName=job_name, Arguments=job_args, )

まとめ ● スタートアップであっても状況に応じてワークフローを使い分けるのはアリ
 ● 初期工数を考えればチーム/メンバーが少数であればStepFunctionsや GlueWorkflowからバッチワークフロー運用するのはアリ
 ○ なんならCloudWatchEvents(cron)のままでも良い場合もある 
 ● AWS環境が分かれてプロダクト/チームが複数存在するようになってきたらMWAAを 導入するのはアリ
 
 


カケハシは絶賛採用実施中です!! カジュアル面談からでも!! ● サーバサイドエンジニア ● フロントエンドエンジニア ● SRE ● データエンジニア ● プロダクトマネジャー ● 開発ディレクター(スクラムマ スター） https://herp.careers/v1/kakehashi