$30 off During Our Annual Pro Sale. View Details »

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

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

AWS startup 202106

kakehashi

June 11, 2021
Tweet

More Decks by kakehashi

Other Decks in Technology

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