AWS Step Functionsで実現するジョブ基盤 -プロダクトチームを支える基盤づくり-

AWS Step Functionsで実現するジョブ基盤
プロダクトチームを支える基盤づくり

株式会社hacomono プラットフォーム部プラットフォーム2G
有働 開(Kai Udo)

Platform Engineering Meetup #12
https://platformengineering.connpass.com/event/348986/

Transcript

1. Last Update 2022.03.16 AWS Step Functionsで実現するジョブ基盤 プロダクトチームを支える基盤づくり
2. 2 自己紹介 • 有働 開(ウドウ カイ) ◦ GitHub,Qiita @u-kai • 経歴 ◦ 2020年~2024年 製造業にて社内クラウド基盤・開発基盤の企画 /構築など ◦ 2024/07~ hacomono プラットフォーム部に所属
3. 3 会員管理・予約・振替・キャンセル・決済・請求管理・売上管理・債権管理 入退館・EC・POS・本人認証カメラ・QRリーダー・ ・総合フィットネスクラブ ・ヨガ・ピラティス ・パーソナルジム ・24時間ジム フィットネスクラブ ・屋外運動場 ・屋内運動場 ・体育館 ・水泳プール ・学校 ・レジャー施設 公共運動施設 ・Jリーグ（サッカー） ・Bリーグ（バスケットボール） ・野球チーム・サッカーチーム etc スポーツチーム ・スイミングスクール ・ダンス・バレエスクール ・ゴルフスクール ・テニススクール ・カルチャースクール ・空手・体操スクール ・サッカースクール 運動スクール ウェルネス施設の手続きをすべてデジタル化 ウェルネス産業を、新次元へ。
4. 約9,000店舗・施設での導入実績 ヨガ・ピラティス パーソナルジム 24時間ジム 総合スポーツクラブ 運動スクール プロスポーツ（サッカー・バスケ） 公共運動・学校施設 ゴルフ サウナ・エステ コワーキング
5. 　　　　　 5 Confidential Corporate Book 組織構成 Engineering Organization Product データ デザイン 開発 基盤 CTO室 IoT データ戦略部 UX部 運用保守部 モバイル部 SRE部 プラットフォー ム部 インターン CTO室 QA部 リアーキテク チャ＆イネー ブルメント部 Engineering Office部 IoT部 デザイン部 フルタイム 128名 業務委託 32名 （2025年3月現在） PM PM部 新規事業 開発室 データ基盤部 新規事業 開発室 情報 システム サポート サポート部 フィーチャー 部 情報 システム部
6. 6 hacomonoのプラットフォーム部 ミッション 「プラットフォーム部の役割は、各サービスやプロダクトで共通して使われる機能を提供し、 hacomonoがグロースするhacoを提供する」1) 体制 • メンバー6名 + VPoPE(VP of Platform Engineering) 1):https://techblog.hacomono.jp/entry/2024/04/09/1100 2): https://techblog.hacomono.jp/entry/2022/12/20/070000 3): https://techblog.hacomono.jp/entry/2023/08/22/110000 4): https://techblog.hacomono.jp/entry/2024/12/02/000000 実績 • マルチテナントアーキテクチャの構築・運用2) • モジュラーモノリスの設計・基盤の構築3) • feature-flag基盤の構築・運用4) • 新ジョブ基盤 (job-manager)の構築・運用 など...
7. 7 job-managerの概要 • ジョブ実行やSagaパターンなどを達成するための社内の新しいジョブ基盤 • 中身はAWS StepFunctions(以下SFn)とAWS Lambda(以下Lambda)などを組み合わせた基盤 • SFnでフローをオーケストレーションし、 Lambdaは任意のAPIを叩いて処理を実行
8. 8 job-managerで達成したいこと 以下のような課題達成のために job-managerの設計/開発を開始 1. マイクロサービス・マルチプロダクト化に向けて 2. 既存ジョブ基盤で抱えている課題解決に向けて 3. プロダクトチームへのジョブ開発 /運用の委譲に向けて
9. 9 1. マイクロサービス・マルチプロダクト化に向けて • 開発生産性向上などの目的でマイクロサービスを狙っていきたい • 会社の成長に伴ってマルチプロダクト化が計画 /実行されつつある 実行をオーケストレーションするワークフロー管理ツールが必要に • 複数のAPIを決まった順序で実行する用途が増えてくる ◦ Aサービスでデータを取得→Bサービスへデータ同期→外部サービスへ同期... • ジョブの非同期実行や長期実行、補償などによる一貫性が必要になってくる • etc…
10. 10 job-managerによる複数 APIを実行するジョブの実現 ユーザー情報を全て取得 エラー発生時には エラーハンドリング job-managerによって複数APIの実行をオーケストレーション可能に →マイクロサービス・マルチプロダクト化した際のジョブ基盤を準備できた ユーザー情報の更新 ジョブの結果を登録
11. 11 2. 既存ジョブ基盤の課題 既存ジョブ基盤はお客様環境毎に ECSを定期的に起動し、Rakeタスクを実行 → シンプルな構成かつモノリスなロジックのため、開発難易度が低くジョブの追加も容易 しかし お客様環境毎にECS Taskを一斉に起動 既存のジョブ基盤 • 高頻度に実行されるジョブが存在 & コンテナの起動時間が長くコスト効率が悪い • お客様増加によるECSや外部APIなどのRateLimitへの懸念 • モノリスなロジックのため並列実行が難しい • Rake内で複雑なワークフローを組むのは難しい
12. 12 job-manager利用によって解決する課題 • サーバレスアーキテクチャの利用によって 全ECSコストの約20%を削減 お客様環境毎にECS Taskを一斉に起動 既存ジョブ基盤 job-manager 任意の並列度でAPIを実行 • 分散されているAPIのオーケストレーションを可能にしたことで ◦ 流量調整が容易に ◦ 並列実行性向上 ◦ 再実行性向上 • 複雑なワークフローをAWSマネージドな機能で作成可能に
13. 13 3. プロダクトチームへ開発 /運用の委譲 しかし • SFnやAWSの基本知識や細かい仕様を把握する必要がある • hacomonoアーキテクチャの把握や、ジョブに必要なデータ収集などの難しさも 単にAWSを利用してもらうのではなく、 プラットフォームとして必要な機能を搭載 し、 最終的にはプロダクトチームにジョブの開発 /運用を委譲できる状態に持っていく ことを 一つの目標にjob-managerを開発 プロダクトチームが自律的な開発 /運用を可能な状態を目指したい
14. 14 施策1: コード自動生成による開発コストの削減 • プロダクトチームにジョブの開発 /運用を行ってもらうためにコード自動生成を実装 • ジョブの並列実行数や、叩くAPIの仕様などをyamlに記述→コマンド実行だけで、 必要なコード一式(IaC含む)が生成されるようにした gen-code -new example-job
15. 15 施策2: Deployフローの整備 • 生成されたコードを即座にDeploy可能にするためにGitHub Actionsを整備 • コード生成後、ジョブとデプロイ対象環境を選択するだけでデプロイ可能に 自動生成されたhoge jobを 検証環境にデプロイっと
16. 16 • 全てのフローが稼働するかをチェックする E2Eテストを整備 • IAM設定やAPI指定などのよくあるミスを未然に防げるように • コード自動生成によってE2Eテストのコードも自動生成されるようにした • GitHub Actionsへも実装→簡単かつ誰でも安全に実行できるようにした 施策3: E2Eテストの整備 hoge jobのテストっと … OK問題なさそう
17. 17 施策4: feature-flag基盤を使った安心安全なリリース • 社内feature-flag基盤によってjob-manager実行可否をお客様環境単位で選択可能にした • feature-flagはyamlで設定し、GitHub Actions実行により配布される仕組み1) 1): https://techblog.hacomono.jp/entry/2024/12/02/000000 とりあえず検証環境と パイロット環境にだけ適用しよ
18. 18 プロダクトチームで開発 /運用可能？？ job-managerのDeploy フロー提供 job-managerのE2Eテスト提供 実行 feature-flag基盤の提供 設定/反映 実行 job-managerのコード自動生成提供 カスタマイズ (Optional) API(≒プロダクト機能)の実装・テスト・デプロイ・運用 プラットフォーム部 プロダクトチーム job-managerの開発ではなく、機能開発に注力できるようにした 今後もフィードバック/改善要望いただきながら、目標に近づけていく予定 設定/実行 変更の検証/適用 job-managerコンポーネントやツールの バージョンアップ 機能の 開発~運用 ジョブの開発 ジョブのテスト ジョブのデプロイ ジョブのリリース ジョブの運用
19. 19 現状の社内利用について • プロダクトチームへjob-managerを普及中 • 既存ジョブ基盤からコスト削減効果が高いジョブを job-managerに移行中 • 外部APIに依存している新規ジョブをjob-managerで実装済み and 実装中 ◦ 流量調整によるRateLimitエラーの回避を実現 ◦ 並列実行数向上によるジョブ実行の効率向上が実現 • 一部のチームのみがjob-managerに関心があり普及活動が十分ではない いくつかのジョ ブでは狙い通り まだまだ普及 活動に力を入 れるべき
20. 20 これから • さらに普及していく プラットフォーム部 リアーキテクチャ＆ イネーブルメント部 プロダクトチーム 協力 フィードバック・改善要望 採 採 改善 • 既存ジョブからの移行 • 機能FB • 適用箇所の特定 • 普及方法の模索 • 移行ライブラリなどの開発援助 など • フィードバック/要望を基に改善を続ける 価値提供 普及活動
21. 21 まとめ • StepFunctinos、Lambdaなどを利用したジョブ基盤job-managerについて紹介 • job-managerはマイクロサービス・マルチプロダクトの APIをオーケストレーションするジョブ基 盤 • 並列実行、流量調整、既存ジョブからのコストダウンが可能 • プロダクトチームが開発/運用できるような施策を実施 • 今後もjob-managerの社内普及と機能改善を進めていく
22. https://www.hacomono.jp/