Step Functions Expressで作るフルマネージドなサーバーレスバッチ

JAWS Days 2021
https://jawsdays2021.jaws-ug.jp/timetable/track-c-1500/

Transcript

1. Step Functions Expressで作る
   フルマネージドなサーバーレスバッチ
   遠藤 大輔
   

   View Slide

2. はじめに
   • コメント待ちしております！
   • jawsdays2021
   • jawsug
   • jawsdays2021_C
   

   View Slide

3. 遠藤 大輔
   Daisuke Endo
   株式会社ゆめみ
   • 2019年, 株式会社ゆめみに入社
   • 趣味はドラム, コンガ演奏
   • Twitter: @DddEndow
   好きなAWSのサービス：Step Functions
   

   View Slide

4. よくあるバッチ処理の
   めんどくささ
   

   View Slide

5. 外部API
   バッチ
   サーバー
   ユーザーデータ
   取得
   

   View Slide

6. 外部API
   バッチ
   サーバー
   ユーザーデータ
   取得
   5〜10分毎
   処理時間：数分
   実装も簡単
   

   View Slide

7. 外部API
   バッチ
   サーバー
   ユーザーデータ
   取得
   5〜10分毎
   処理時間：数分
   実装も簡単
   l サーバー
   l ミドルウェア
   l フレームワーク
   わざわざ用意するのめんどう
   →サクッと作りたい！
   

   View Slide

8. AWS Lambdaなら
   全部解決する？
   

   View Slide

9. AWS Lambda
   処理が複雑になると…
   • コードがスパゲッティ化
   • 責務が大きくなりすぎる
   • 並列処理が辛い
   

   View Slide

10. そこで
    AWS Step Functions
    

    View Slide

11. AWS Step Functions
    • サーバーレスな関数オーケストレーター
    • イベント駆動型のワークフローを構築
    • 並列処理, 例外処理, 再試行ロジックなどを管理可能
    • Lambdaなど他のサービスと組み合わせ可能
    

    View Slide

12. 並列処理
    例外処理
    条件分岐
    

    View Slide

13. でも、あまり現実的なアーキテクチャではなかった
    • 料金
    • DBコネクション問題
    • Lambdaのコールドスタート
    

    View Slide

14. それが
    

    View Slide

15. 料金(2019/12)
    →Step Functions Express Workflows
    DBコネクション問題(2020/7)
    →RDS Proxy
    Lambdaのコールドスタート(2019/9)
    →1分から1秒に改善
    

    View Slide

16. AWSがサーバーレスバッチを
    作れと言っている！！
    

    View Slide

17. というわけで
    

    View Slide

18. 作りました
    

    View Slide

19. • 数万ユーザーの処理が30秒で完了
    ユーザー毎に外部API実行 + DBに書き込み
    • コストも1万円/月以下
    （Step Functions, Lambda）
    

    View Slide

20. （もう全部サーバーレスバッチでいいんじゃない？）
    

    View Slide

21. でも大変なことや辛いこともたくさんあった
    

    View Slide

22. でも大変なことや辛いこともたくさんあった
    今回のメインコンテンツ
    

    View Slide

23. アジェンダ
    • 並列処理
    • データベース接続
    • CI/CD
    • ログ・X-Ray
    

    View Slide

24. 並列処理
    

    View Slide

25. View Slide

26. Step Functions
    

    View Slide

27. ①対象ユーザーを一覧取得
    ②外部APIへリクエスト
    ③データ処理&保存
    

    View Slide

28. ①対象ユーザーを一覧取得
    ②外部APIへリクエスト
    ③データ処理&保存
    ユーザー単位で
    並列処理
    

    View Slide

29. Mapステート
    • Step Functionsの状態の一つ
    • タスク単位で並列処理が可能
    • パラメータ一個で同時実行数を制御可能
    • キューやイベントの管理不要
    並列処理
    Mapステート
    

    View Slide

30. ユーザー単位で
    並列処理
    

    View Slide

31. なんか二重になってない？
    

    View Slide

32. https://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/amazon-states-language-map-state.html
    Mapステートの同時実行数
    • 並列数の上限は無限
    • 同時実行数は約40が上限
    • →多重にすることで（たぶん）対策
    

    View Slide

33. これで一安心！
    X-Rayで性能を確認してみよう！
    

    View Slide

34. これで一安心！
    X-Rayで性能を確認してみよう！
    →LambdaのPendingが大量に…
    

    View Slide

35. Lambdaのクォータ
    • リクエスト数/秒の制限
    • 同時実行数の10倍
    • 一万ぐらいまではすぐにあげてくれる
    • それ以上は実績やデータが必要
    • GetFunction APIのリクエスト制限
    • 100リクエスト/秒
    • コールドスタートの際に実行
    • デプロイパッケージの取得などに利用
    

    View Slide

36. Lambdaのクォータ
    • Mapの並列数を200ぐらいにしたらスムーズに
    • 急ぎでないなら40ぐらいでいいかも
    • Mapを多重にする意味あまりないんじゃ
    

    View Slide

37. まるっとうまく動くようになった！
    

    View Slide

38. まるっとうまく動くようになった！
    →ユーザー数増やしたらStep Functionsから
    エラー出るようになった…
    

    View Slide

39. Step Functionsのデータサイズ制限
    • タスク, ステート, 入出力のデータサイズ
    • 約260KBの制限
    • Mapステートの前後で制限オーバー
    • Map全体で受け渡すデータ量で計算
    • 300B/ユーザー x 1000人 = 300KB
    

    View Slide

40. Step Functionsのデータサイズ制限
    • S3に一時保存することで回避
    • 各ユーザーのKey(ID)だけ渡す
    • S3が強い読み込み整合性をサポート
    • 上書きPUT, DELETEしても即座に反映
    • 不要なパラメータはMapの最後に削除
    ユーザーIDの配列
    必要なデータのみ渡す
    ユーザーデータ
    

    View Slide

41. S3 APIの実行コスト削減と差分対策
    • Lambda実行のたびにS3から取得すると高コスト
    • ハンドラー外で取得
    しかし…
    

    View Slide

42. 古いデータを参照してしまう問題
    • 10分間隔であればLambdaの実行基盤がリセットされ
    ると予想
    →実際には稀に実行基盤が残っていて古いデータを参照
    • ハンドラー外にしたのが裏目に
    • 実行基盤がリセットされるタイミングは制御できない
    • S3のオブジェクトのMetadataにバージョン情報を追加
    してチェックすることで対策
    

    View Slide

43. データベース接続
    

    View Slide

44. View Slide

45. RDS Proxy
    • DBコネクションのプーリング&共有が可能
    • Lambdaがコネクションを使い潰す問題を解決
    • IAM接続とID/Pass接続の二種類
    

    View Slide

46. コネクション数の節約
    • Lambdaハンドラー外でDBコネクションを生成
    • コネクションが切断した場合にLambdaの実行基盤を終了
    するエラーハンドリングが必要
    • RDS Proxy
    • 数百->数十程度に圧縮可能
    両方を組み合わせることで
    数千→数十コネクションまで節約
    

    View Slide

47. 書き込み処理をまとめる
    • 1ユーザー毎に書き込み処理を行うのはNG
    • Kinesisで100人ずつにまとめてバルクアップデート
    • Step FunctionsやX-Rayで追跡できなくなるのが欠点
    

    View Slide

48. CI/CD
    

    View Slide

49. CodePipeline
    GitHub
    pull
    sam build
    sam package
    Template file
    Stack
    Stack
    Stack
    CloudFormation
    

    View Slide

50. Stackを分割するメリット
    • 複数のグループ毎にリソースを展開できる
    • パラメータを書き換えるだけ
    • エンタープライズコネクションなどで効果を発揮
    • 物理的・論理的にセキュア
    • ログやメトリクスの管理がしやすい
    • どのリソースで障害が発生したかがすぐにわかる
    

    View Slide

51. テンプレートを使い回す
    ことでこんなことも
    

    View Slide

52. Stackを分割するデメリット
    • リソースが大量に生成される
    • Step Functions用のLambdaダッシュボードがなかった
    ら心が折れてた
    

    View Slide

53. ログ・X-Ray
    

    View Slide

54. ログ
    • Step Functionsの実行ログを収集可能
    • Step Functions独自のステータスで出力
    • ちょっとクセがある
    • エラーの内容にLambdaやStateの情報が含まれない
    • デバッグが大変
    • （アップデート待ってます）
    

    View Slide

55. X-Ray
    • Step Functionsに対応(2020/9)
    • ワークフロー全体を監視可能
    • 並列処理も時系列で見れる
    

    View Slide

56. まとめ
    

    View Slide

57. まとめ
    • 並列処理
    • データベース接続
    • CI/CD
    • ログ・X-Ray
    

    View Slide

58. サーバーレスバッチという選択肢
    • 開発に集中できる
    • リソースやミドルウェアを気にする必要が（あまり）ない
    • 高性能
    • サーバーレスだからこそできる設計
    • 低コスト
    • 必要な時に必要なだけ
    

    View Slide

59. リソースに縛られないバッチシステム
    →より効率良く価値を提供
    

    View Slide

60. 宣伝
    AWS Summitに登壇します
    セッションタイトル
    「サーバー立てっぱなしはもったいない！
    サーバーレスのみで構築する
    中頻度&短時間バッチ」
    

    View Slide

61. Thank you for watching!
    YUMEMI.inc, Daisuke Endo
    Twitter: @DddEndow
    

    View Slide