自己紹介
福田貴之氏（以下、福田）：「スタートアップにおけるデータ基礎バッチワークフローの変遷」と題して、株式会社カケハシの福田が発表します。自己紹介です。株式会社カケハシで、データ基盤のプロダクトオーナー兼エンジニアやってます。
経歴としては、2007年新卒で、某Yでモバイル向けサービス開発・運用などをやり、あとソーシャルゲームが流行っていたので、そのあたりでログ基盤を6年ぐらい見ていました。あとベンチャーをいくつかまわって、2020年より現職のカケハシにジョインした感じです。AWSサービスはECSとFargateが非常に楽で、すごく好きだなあという感じです。
アジェンダと株式会社カケハシの紹介
今日のアジェンダですが、カケハシの紹介をちょっとさせてください。あと、さっき言ったように、ワークフローの変遷というところで、以前の弊社のワークフローの構成。、あと、問題点があり、ワークフローエンジンいろいろ調べてみて「直したいな」という選定をしつつ、最終的にAWSで2020年にリリースされた、Amazon Managed Workflows for Apache Airflow (MWAA)を使ってみた。最後、まとめになっています。
カケハシの紹介をします。カケハシのMission、Visionは「日本の医療体験をしなやかに」「明日の医療の基盤となる、エコシステムの実現」という感じです。ちょっとこれだけだと何をやってるかわからないんですが。
事業内容としては、みなさんお医者さんに行って、薬をもらうために処方箋をもらって、薬局に持っていくと思いますが、その調剤薬局で使われるシステムの「Musubi」と、薬局で経営診断をできる「Musubi Insight」。あと、実際に患者さんと薬局がつながるためのBtoBtoCみたいなサービスである「Pocket Musubi」という事業をやっています。これ以外にもいくつかサービスもありますが、主にはこの3つをやっています。
弊社は、2021年3月に5周年になりました。社員数134人、平均年齢35歳と、わりと大人な会社かな、という感じで。非常に働きやすいのでぜひ、という話をしつつ、本題に入ります。
株式会社カケハシのデータ基盤構成と課題
「スタートアップにおけるデータ基盤のバッチワークフローの変遷」というタイトルです。弊社のデータ基盤構成を、まず見てもらいたいなと思います。
これはざっとした概要図です。サービスはDynamoDBで作られて、データを抜いて、いろいろ集計したいという話があります。DynamoDBは2020年の年末ぐらいに、DynamoDB Exportのような感じでガッとバルクで抜くものも出てきましたが、Lambdaをつないで生データ抜いて、いったんS3に置いて、複数のデータを加工したいのでGlue Job書いて、最終的にS3に置きます。これらはStep Functionsで管理されています。
さらにこの処理結果を使う別のチームが存在していて。この人たちはGlueだけでいい感じなので。「Glue Jobだけであれば、Glue Workflows使うほうがいいよね」という感じで、AWS環境が分かれつつ、ワークフローも分かれつつのアーキテクチャ構成になってます。
見たとおりですが、チームも別々で、どこで何が動いてるか、全部を把握するのが難しくなってきてた話が2020年ぐらいにありました。
あと、再集計の困難さもけっこう問題になっていました。上からバッチがバンバンと叩かれますが、上のあたりで集計が止まった場合。再集計しますが、下の人たちはどうやって知るんだっけ？ と。きちんとAWSとAWSの間をSQSでつないでたらいいですが、そこまで作り込んでもいないところもあって、ちょっと面倒くさいなという問題もあります。
あとちょっと管理観点の問題というか、Step FunctionsもGlue Workflowsも、Webコンソールからポチポチとワークフロー作れるのはいいですが、コードで管理されてないのは、今後、人が増えて運用するにはつらい感じはなってました。
ワークフローエンジンの選定
ワークフローエンジン、Step Functionsに寄せるのか、それともOSSにするのか、ちょっといろいろ考えてみました。
「どうしてワークフローエンジン使うの？ もうGlueでいいんじゃないの？」という話もあると思いますが、「それはそうだな」という話で。依存関係のない単発のジョブならこちらのほうが楽なので、ワークフローは無理に入れる必要はないかな、とも思っています。
ただ、バッチ運用をしていると、困ることはたくさんあると思っていて。先ほど言ったような話ですが、ジョブごとの依存関係をコード管理したり。あと、retry処理や成否処理のような「普通やるよね？」ということを、それぞれのGlueやLambdaに実装したくない話もあったり。
あとは再集計の話だとは思いますが、「どこまで終わってるのか状態管理してほしい」とか。運用の観点だと、「どれくらい時間がかかってるか観測したりとか、再集計しやすいようにしたい」みたいな話が、運用してくると徐々にあると思います。
そのため、最初からワークフロー入れる必要はないとは思いますが、「こういうことがあったら入れたいよね」という話があります。
バッチワークフローは、有名どころだとAirflowや、Digdag、Argo Workflows、Luigiなどいろいろあります。とはいえ弊社はスタートアップなので、マネージドでやりたいと。そうなると、AWSのStep Functions、Glue WorkflowsとマネージドのApache Airflowのどれかなのかなという感じで、3つでちょっと比較検討してみました。
僕が最初にパッと入ったときに、このあたりの使い分け、どういうときにどれを使ったらいいのかは、わりとわからないと思って。所感ですが、「こういう使い分けなのかな」と思って、まとめたのがこちらになります。
Glue Workflowsは、Glue Job／Glue Crawler、Glue 何たらをつなげるワークフローを作るだけなら、一番楽なものなのかと思っています。
だいたいファイルがS3に吐かれていて、ETL処理して、Athenaで見たいというのが、あるあるな事例だと思っていて。そういう用途だと、わりとマッチするのではないかは思っています。ただ、コンソールのジョブ一覧が増えてくると、ちょっとつらい気分になったりもします。
Step Functionsです。Glue Workflowsよりも多少面倒くさいですが、自由度はかなりある感じです。豊富なAWSサービスとの連携もあり、思想としてコードを書かずに、いろろなAWSサービスと連携できるワークフローが作れるのかな、というイメージです。こちらはちょっとがっつり僕が書いて運用した感じではなく、今あるものを見て感じたことなので、ちょっと違うのかもしれないです。
Airflowです。Airflowは一番上だけAWSですが、マネージドで運用してくれるのは楽だという話で。あと、（スライドの）下3つはAirflow自身の利点かとは思います。
かなり書く必要がありますが、ワークフローがコードで管理できる。あと、拡張性があるというか、結局自分でPythonを書けという話になりがちな話もあります。ここが一番Airflow使う動機になるのかとも思いますが、UIがわかりやすく、再集計などがすごくやりやすいというメリットを感じました。
株式会社カケハシの選択と運用
弊社は、マネージドのAirflowを使ってみました。これは、AmazonのMWAAのアーキテクチャ図です。見た感じ、ワークフローの状態管理するメタデータベースをAmazon Auroraで作って、Scheduler/WorkerがFargateで動いてたら、「まあ落ちないよな」という感想を抱いています。ちょっとこのあたり、勉強会などがあったらぜひ聞きたい感じです。
実際に弊社がどういう運用をしてるかです。それぞれのAWS環境では、管理したバッチワークフローを、別の環境、Apache Airflowから一元管理するようにしました。クロスアカウントでGlueなどを叩く場合は、AssumeRoleするような実装をAirflow上で実現しました。
実際に運用してみて良かった点は、先ほどのアーキテクチャ構成から、多少落ちてても、そのうち復旧する感じは受けていましたが、ぜんぜん問題は起きていない現状です。特に運用していてうれしいのは、DAGやワークフローの反映が、S3にアップロードするだけで即反映されるのは、わりと試すのにすごく楽だなという感じです。
このあたりはAirflow自身の話です。pluginファイルにしておけば、同じようなワークフローを量産しやすいとか。Airflowの利点をそのまま書いてるだけですが、非常に安心感があり、わかりやすくワークフローが再構成できた感じになっています。
運用で辛いこと
実際に運用するにあたり、つらいかもなと思うのが、かなりコードを書いたというのはあります。当然、再利用は可能だし、通知やretry処理のようなものを作り込む必要はありません。ちょっと話が前後していますが、Glueを呼ぶのはboto3で書くようなことを、関数を実装して、毎回呼ぶようなDAGを作る必要があります。
一部オペレーター、ECSタスクをバッチ起動するようなものは用意されていて、非常に簡単に書けるものもありますが、最初はわりとコード書く必要がありました。
あと弊社の使い方としては、AWS環境をまたいでAssumeRoleする必要がありました。1時間で切れるため、バッチが重かったら途中で死ぬので、そのあたりを考慮した実装も必要でした。
あとはAirflowを知らないと「何を言っているんだ」という話ですが、DAGというワークフローを管理するものと、それを関数化したpluginファイルのようなものが2つあり、pluginファイルの反映だけすごく時間がかかるのは、ちょっとつらいなという感じです。DAGはS3にアップロードしたら一瞬ですが、pluginファイルは再起動が必要なのがちょっとつらいです。
スタートアップでもワークフローを使い分けるのはあり
まとめとして、スタートアップであっても状況に応じてワークフローを使い分けるのはありだと思ってます。いきなりフルスペックなAirflowを使う必要性はたぶんなく、チーム、メンバー少数であれば、Step FunctionsやGlue Workflowsからバッチワークフローを運用するのは、ぜんぜんありだと思っています。
弊社のようにAWS環境が分かれて、プロダクトチームが複数存在するようになってきて、「一元管理したいよね」という状況になったら、Airflowを導入するのはありではないか、という感想になります。
というところで、最後に絶賛募集中ですという広告を挟んで以上になります。
質疑応答
司会者：はーい。ありがとうございまーす。ジョブワークフローとか、1回入れると楽ですが、大変ですよね。
福田：そうそう。最初がかなりハードルあります（笑）。
司会者：ちょっといくつか質問がきているので、見ていきます。「Glue JobからRDSにデータを登録する際に、データ量が大きい（数億レード越え）場合に、書き込みに時間がかかったなどの経験はありましたか」。Glueのジョブは、わりとヘビーに使っていましたか。
福田：そうですね。弊社ではわりとGlue Jobをヘビーに使っていますが、僕はS2、S3toS3なので。僕ではないチームが、わりとGlue Job to RDSをやっていますが、Glue Jobは2台以上起動するので、RDSから読んだり書いたりするはあんまり得意じゃないイメージです。単一のファイルをガッと入れて。僕もつらそうだな、というイメージがあります（笑）。
司会者：そうですね。福田さんの認識どおりかな、という感じです。いわゆるデータマート的な感じで、「集計したデータを入れましょう」とかはありだとは思いますが、「ビッグデータはビッグデータのまま入れます」みたいなときには、そもそも対象として適切ではないのではないか、というのはあります。
状況がぜんぜんわかりませんが、そもそもRDSが適切なのかは見直してもいいかもしれません。
福田：あと、「それ、入れるんだったらGlueなの？」のようなところもちょっとあるかもしれないです。
司会者：そうですね、ありがとうございます。2つ目、「MWAAはどう呼んでいますか」。
福田：いやあ、わかります。どこを略称にしているのか、すごくわかりづらいですよね。マネージのワークフロー、Apache Airflow、AWSみたいなの、どこかにあったっけみたいな、そういう気分になります。
司会者：僕もよくわからなず、MWAAと呼んでいます。次、「MWAAのAirflow2.0は検討されていますか」。
福田：5月の中旬ぐらいにきていましたね。
司会者：どうしてますか。
福田：Airflowは、スケジューラーが単一障害点になりがちな課題を解決するみたいな話も2.0の利点としてあって。ただ1.0はFargateで動いてるから、だいたい戻ってくるのでは？ という気はしつつも、当然きちんと追いかけていかないといけないので、そのあたりは順次上げていこうかなとは思っています。
司会者：確かに。機能的に必要かという話と、取り残される、世代が開くとけっこうつらくなる、みたいな。
福田：書き方がちょっと変わる話も聞くので、ちょっと早めにキャッチアップはしたい感じはします。
司会者：そのあたりの考え方は、けっこう大事かもしれませんね。特に1世代上がるときは警告が出るだけだけど、2つ飛ぶと完全に移行できないとかよくあるので。あ、いい質問がきましたね。「医療サービスとのことですが、データのセキュリティはけっこう気をつけていますか」。
福田：いや、そうですね。そうですねというか、そこは非常にセンシティブで。特に「患者さんと処方のデータは、そもそもこういう分析基盤に載せちゃだめだよね」という話もありつつ、特に気をつけないといけないところだと認識はしてがんばっています。
司会者：このあたりは、何か適切にIAMのロールや、バケット分けるなど。バケットポリシーとIAMロールあたりでコントロールしてる感じですか。
福田：そうですね。我々は仕方ないので全部見れますが、社員の人たちには「ここまでの範囲は見せられる」とか、そういう感じです。当然、利活用に関して、「そもそも社外に出しちゃだめだよね」とかもきちんと規定されてはいます。
司会者：そもそもビジネス上や、法的要件のルールがあるんですよね。
福田：そうですね。ありつつ、それに従ってAWSの機能で、と話だと思っています。
司会者：正しいというか、Well-Architectedに書いてある内容そのままのような、模範的な回答で僕は安心して聞いてました。
福田：（笑）。
司会者：ありがとうございます。では、今日はそんなところでちょうどいい時間になってきたので、福田さんありがとうございました。
福田：ありがとうございました。
