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

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

View Slide

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

View Slide

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

View Slide

株式会社カケハシの紹介

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

バッチワークフロー比較
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 

View Slide

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

View Slide

MWAA使ってみた! 

View Slide

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

View Slide

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

View Slide

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

View Slide

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,
)

View Slide

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

View Slide

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

View Slide

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

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

kakehashi

More Decks by kakehashi

Other Decks in Technology

Featured

Transcript