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

Transcript

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

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

3. 遠藤 大輔 Daisuke Endo 株式会社ゆめみ • 2019年, 株式会社ゆめみに入社 • 趣味はドラム,

   コンガ演奏 • Twitter: @DddEndow 好きなAWSのサービス：Step Functions

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

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

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

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

   l ミドルウェア l フレームワーク わざわざ用意するのめんどう →サクッと作りたい！

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

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

10. そこで AWS Step Functions

11. AWS Step Functions • サーバーレスな関数オーケストレーター • イベント駆動型のワークフローを構築 • 並列処理, 例外処理,

    再試行ロジックなどを管理可能 • Lambdaなど他のサービスと組み合わせ可能

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

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

14. それが

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

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

17. というわけで

18. 作りました

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

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

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

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

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

24. 並列処理

25. None

26. Step Functions

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

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

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

    並列処理 Mapステート

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

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

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

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

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

35. Lambdaのクォータ • リクエスト数/秒の制限 • 同時実行数の10倍 • 一万ぐらいまではすぐにあげてくれる • それ以上は実績やデータが必要 •

    GetFunction APIのリクエスト制限 • 100リクエスト/秒 • コールドスタートの際に実行 • デプロイパッケージの取得などに利用

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

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

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

39. Step Functionsのデータサイズ制限 • タスク, ステート, 入出力のデータサイズ • 約260KBの制限 • Mapステートの前後で制限オーバー

    • Map全体で受け渡すデータ量で計算 • 300B/ユーザー x 1000人 = 300KB

40. Step Functionsのデータサイズ制限 • S3に一時保存することで回避 • 各ユーザーのKey(ID)だけ渡す • S3が強い読み込み整合性をサポート • 上書きPUT,

    DELETEしても即座に反映 • 不要なパラメータはMapの最後に削除 ユーザーIDの配列 必要なデータのみ渡す ユーザーデータ

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

42. 古いデータを参照してしまう問題 • 10分間隔であればLambdaの実行基盤がリセットされ ると予想 →実際には稀に実行基盤が残っていて古いデータを参照 • ハンドラー外にしたのが裏目に • 実行基盤がリセットされるタイミングは制御できない •

    S3のオブジェクトのMetadataにバージョン情報を追加 してチェックすることで対策

43. データベース接続

44. None

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

46. コネクション数の節約 • Lambdaハンドラー外でDBコネクションを生成 • コネクションが切断した場合にLambdaの実行基盤を終了 するエラーハンドリングが必要 • RDS Proxy •

    数百->数十程度に圧縮可能 両方を組み合わせることで 数千→数十コネクションまで節約

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

48. CI/CD

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

    Stack Stack CloudFormation

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

    ログやメトリクスの管理がしやすい • どのリソースで障害が発生したかがすぐにわかる

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

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

53. ログ・X-Ray

54. ログ • Step Functionsの実行ログを収集可能 • Step Functions独自のステータスで出力 • ちょっとクセがある •

    エラーの内容にLambdaやStateの情報が含まれない • デバッグが大変 • （アップデート待ってます）

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

56. まとめ

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

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

    低コスト • 必要な時に必要なだけ

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

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

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