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

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

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

akkino/D-En

March 20, 2021
Tweet

More Decks by akkino/D-En

Other Decks in Technology

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