クラウドのスケーリングの力で5時間 かかるバッチジョブを10分に短縮する / Reduce the batch job time by a 36th using the power of scaling in the public cloud

Transcript

1. (FOLJ
   0HBTBXBSB Ϋϥ΢υͷεέʔϦϯάͷྗͰ࣌ؒ ͔͔ΔόονδϣϒΛ෼ʹ୹ॖ͢Δ 1  ,(9
   4UVEZ
   (SPVQ
2. ⾃⼰紹介 Genki （⼩笠原 元気） ・最近のトピック CNDS で基調講演をしました 海外旅⾏デビュー（シンガポール） リッツ・カールトンデビュー @geivk 2
3. Agenda 今回実現したいタスク 制約条件 / タスク分割のポイント クラウドサービスの選定 スケーリングを実現するアーキテクチャ まとめ 3
4. Agenda 今回実現したいタスク 制約条件 / タスク分割のポイント クラウドサービスの選定 スケーリングを実現するアーキテクチャ まとめ 4
5. エピローグ 5 ローカルで動かすプログラムが5時間もかかる・・・ パソコンが買えないならクラウドを使えばいいじゃない
6. やりたいこと • 毎⽇・特定の時間にジョブ（プログラム）を実⾏したい • 1ジョブ5時間かかるため短縮したい 6
7. 前提条件 • 1バッチジョブ＝複数タスクで構成される 7 タスク タスク タスク バッチジョブ タスク タスク
8. タスクの内容 8 処理1 リクエスト HTTP レスポンス 処理2 50〜100回リクエスト後のデータを もとに数値計算を実⾏ 処理3 対向サービス データベース 書き込み タ ス ク
9. Agenda 今回実現したいタスク 制約条件 / タスク分割のポイント クラウドサービスの選定 スケーリングを実現するアーキテクチャ まとめ 9
10. 制約条件 • ネットワーク帯域が⾼速であること • できるだけ安価に済ませたい • 対向サービスの性質上、⽇本からリクエストする必要あり • クラウドサービスの上限値 10
11. クラウドサービスの選定のポイント ◆ 300〜400タスクをどの粒度に分割するのか ◆ バッチジョブに適したネットワーク環境を提供するサービスの検証 ◆ 安価なサービスの利⽤上の制約条件 11
12. クラウドサービスの選定のポイント ◆ 300〜400タスクをどの粒度に分割するのか ◆ バッチジョブに適したネットワーク環境を提供するサービスの検証 ◆ 安価なサービスの利⽤上の制約条件 12
13. クラウドサービスのコスト • クラウドサービスは基本従量課⾦制 • 並列実⾏しても、コスト影響が少ない → 10時間×1インスタンス ≒ 1時間×10インスタンス 13
14. タスクにかかる時間 14 タスク 60〜90秒 タスク 60〜90秒 60〜90秒 タスク 300〜400 タスク 5〜7時間 ・・・ ジ ョ ブ A
15. 3つのジョブ 15 ジョブA ジョブB ジョブC 対向サービスA 対向サービスC 対向サービスB 認証 認証 認証
16. ジョブを適正に分割するには︖ 16 タスク タスク タスク ・・・ ジョブ A-1 ジョブ A-360 ・・・
17. ジョブを適正に分割するには︖ 17 リクエスト ・・・ ジョブ A-1 ジョブ A-360 ・・・ 認 証 リクエスト 認 証 リクエスト 認 証 ◆ 認証情報の呼び出し︓3回→400回に増える ＝認証情報サービスの利⽤料⾦が133倍になる ◆ ジョブを 360 個並列で動かす ＝クラウドサービスの上限に引っかかってしまう
18. タスクの内容（再掲） 18 処理1 リクエスト HTTP レスポンス 処理2 50〜100回リクエスト後のデータを もとに数値計算を実⾏ 処理3 対向サービス データベース 書き込み タ ス ク
19. 3つのジョブ 19 ジョブA ジョブB ジョブC データベース 認証
20. ジョブを適正に分割するには︖ 20 リクエスト ・・・ ジョブ A-1 ジョブ A-36 ・・・ 認 証 リクエスト 10タスクごとに36分割 リクエスト リクエスト リクエスト ・・・ 認 証 リクエスト リクエスト リクエスト
21. Agenda 今回実現したいタスク 制約条件 / タスク分割のポイント クラウドサービスの選定 スケーリングを実現するアーキテクチャ まとめ 21
22. クラウドサービスの選定 • 定期実⾏したい • ワークフロー化したい • 並列実⾏したい • コストを削減したい 22
23. クラウドサービスの選定 • 定期実⾏したい → Amazon EventBridge Scheduler • ワークフロー化したい → Amazon Step Functions • 並列実⾏したい → Amazon Elastic Container Service • コストを削減したい → Amazon Fargate Spot 23
24. Agenda 今回実現したいタスク 制約条件 / タスク分割のポイント クラウドサービスの選定 スケーリングを実現するアーキテクチャ まとめ 24
25. アーキテクチャ 25
26. アーキテクチャのポイント（実装者向け） • Step Functions で Map を使い、ECS タスクを並列起動 26
27. アーキテクチャのポイント（実装者向け） • Step Functions で Map を使い、ECS タスクを並列起動 • Step Functions のネイティブ API の RunTask Fargate の起動は可能、Fargate Spot の起動はできない → Step Functions で CallAwsService API 経由で RunTask を実⾏ 27
28. アーキテクチャのポイント（実装者向け） • Step Functions で Map を使い、ECS タスクを並列起動 • Step Functions のネイティブ API の RunTask Fargate の起動は可能、Fargate Spot の起動はできない → Step Functions で CallAwsService API 経由で RunTask を実⾏ • CallAwsService API 経由の RunTask では エラーハンドリングができなくなるため、別で実装する必要がある 28
29. Agenda 今回実現したいタスク 制約条件 / タスク分割のポイント クラウドサービスの選定 スケーリングを実現するアーキテクチャ まとめ 29
30. まとめ • クラウドのスケーリングメリットを最⼤限活かし、5時間かかるタスクを適切 に分割し並列実⾏することで、30分に短縮できた • ビジネス要件・クラウドサービスの上限値などさまざまな制約条件がトレード オフにになるため、注意深く検討する必要がある 30
31. Thank you!