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

Transcript

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


2. 自己紹介
 福田 貴之
 株式会社カケハシ データ基盤 ProductOwner 兼 エンジニア
 経歴
 •

   某Y!2007年新卒でモバイル向けサービス開発運用 
 • ソーシャルゲーム会社でログ基盤を約6年くらいみてた 
 • あとはベンチャーをいくつか...(HR Saasとか) 
 • 2020年より現職
 好きなAWSサービス: ECSFargate
 


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

   まとめ


4. 株式会社カケハシ の紹介

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

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


   経営診断サービス


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

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


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

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


    


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

    コードで管理されていなかった


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

13. 何故ワークフローエンジンを使うか • cron(CloudWatchEventsなど)では駄目なのか?
 ◦ 依存関係のない単発のJOBがある程度ならこちらの方が楽 
 • バッチを運用してると困ってくること
 ◦ ジョブごとの依存関係をコードで管理したい....

    
 ◦ retry処理や成否通知処理をそれぞれのJobに実装したくない... 
 ◦ どこまで終わっているのか状態管理をしてほしい... 
 ◦ どの部分にどれくらい時間がかかっているのか観測したい... 
 ◦ 失敗時にそこから再集計しやすいようにしたい... 
 • 最初からワークフローを導入するのはオーバースペックな場合も


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


15. AWSマネージドワークフロー所感
 • Glue Workflow
 ◦ Glue Job/Glue Crawlerだけのワークフローなら作るのは一番ラク 
 ◦

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


16. MWAA使ってみた!


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


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


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


    • (冪等に作っておけば)再集計も楽
 
 


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

21. まとめ • スタートアップであっても状況に応じてワークフローを使い分けるのはアリ
 • 初期工数を考えればチーム/メンバーが少数であればStepFunctionsや GlueWorkflowからバッチワークフロー運用するのはアリ
 ◦ なんならCloudWatchEvents(cron)のままでも良い場合もある 
 •

    AWS環境が分かれてプロダクト/チームが複数存在するようになってきたらMWAAを 導入するのはアリ
 
 


22. カケハシは絶賛採用実施中です!! カジュアル面談からでも!! • サーバサイドエンジニア • フロントエンドエンジニア • SRE • データエンジニア

    • プロダクトマネジャー • 開発ディレクター(スクラムマ スター） https://herp.careers/v1/kakehashi