【レポート】サーバー⽴てっぱなしはもったいない︕ サーバーレスのみで構築する 中頻度&短時間バッチ処理 #PAR-29 #AWSSummit

本記事は、AWS Summit Japan 2021のセッション動画、「PAR-29: サーバー⽴てっぱなしはもったいない︕ サーバーレスのみで構築する 中頻度&短時間バッチ処理」のレポート記事です。

セッション概要

10 分に一度しか動かさないバッチ処理のためにずっと起動しっぱなしのサーバーを見てもったいないと感じたことはないでしょうか。 しかもその処理が 2,3 分もあれば全て終わってしまうとなれば尚更です。 本セッションでは AWS Step Functions を中心にサーバーレスなサービスを使用することで無駄な待機コストを無くし、かつレイテンシとスループットをできる限り上げたアーキテクチャを実際に設計・開発して得られた知見をご紹介いたします。

スピーカー

株式会社ゆめみ マーケティングソリューション事業部 遠藤 大輔 氏

セッションページURL

• https://summits-japan.virtual.awsevents.com/media/t/1_co76feu9/playlistid/1_pbtuxl3c

セッション内容

はじめに

想定聴講者

• サーバーレスサービスの特性はなんとなく知っている
• バッチ処理のアーキテクチャや実行基盤を検討中
• かんたんな処理なのにわざわざサーバーをたてることにモヤモヤしている

ゴール

• バッチ処理におけるサーバーレスアーキテクチャの使い所を理解する

バッチ処理におけるサーバーレス

異なるサービス間でのステータス同期

• 例:ユーザーがソーシャルログインした後、各ログイン先から追加情報を取得する場合
• 定期的にこの「ソーシャルログイン先から追加情報を取得してDBを更新する」という処理を行ないたい
• バッチサーバを使う
  • 空き時間がもったいない
  • DBコネクションを確保し続けてしまう
• AWSだと代わりに以下のような構成が可能
  • EventBridge → ECS → API
  • SQS or Kinesis → Lambda → API
• だけどAWSサービスでも課題が
  • ECS
    • コンテナのビルドやデプロイの時間がかかる
    • 外部リクエストの応答時間分のコストを抑えたい
  • Lambda
    • 処理が肥大化した場合の管理コスト
    • キューの例外処理の実装コスト

Step Functionsという選択肢

• イベント駆動型のワークフローを構築できる
  • 並列処理、例外処理、再試行ロジックなど
  • Lambdaなどのほかサービスと連携可能
• バッチ処理に最適
  • ワークフロー形式で統括的に管理可能
  • 並列処理とスケールの制御が容易
  • リードタイムがない
  • 必要なときに必要なだけ実行可能

Step Functions Express Workflows

Step Functionsの課題

実行回数が多い場合の料金が高い = 大量のデータ処理に向いていない

• 0.025USD/1000回の状態遷移
• 例: 6回/時間 x 24H x 30日 x 1万人 = 1,080USD/月

Step Functions Express Workflowsなら

• IoT,イベントストリーミングデータ処理など大容量イベント処理向け
• 最大実行時間5分
• 実行回数、実行時間、消費メモリで課金

比較

• 通常ワークフロー
  • 実⾏回数が少ないとお得
  • 数時間〜数ヶ⽉間継続的に⾏う処理に向いている
• Express ワークフロー
  • ⼀回あたりに扱うデータ量や時間が少ないとお得
  • 秒間n万回のような⼤量のデータ処理に向いている

→ 先ほど通常ワークフローで1,080USD/月かかると試算されたワークロードは、Expressだと 0.1USD/月

処理の⾼速化

並列処理の制御

例: 外部APIから数万ユーザー分のデータをできるだけ短時間で取得したい
→　　Step FunctionsのMapステートを使う

• 定義した⼀連の動作を並列に処理する
• 同時実⾏数をパラメータで制御可能
• スケールやキューの管理不要

リソースの制限

• Step Functions,Lambda,S3,DynamoDBといったサーバーレスなサービスのみで完結するようにする
  • リソースを気にする(負荷試験、CPUやメモリの設定、ミドルウェアのチューニング…)必要が(あまり)ない
• RDB接続のコネクション数
  • RDS Proxyを使う

初期化処理対策

• Step Functionsに初期化処理は不要
• Lambdaのコールドスタート
  • 現在はほぼ気にしなくて良いレベル(1秒前後)
  • 気になる場合はProvisioned Concurrencyを使う

柔軟かつコンパクトな開発

スタックの分割

ワークロードごとにスタックを作ってリソースを分割しましょう

• 物理的にリソースを分けましょう
• IAMで論理的なアクセス制御も行ないましょう

• なぜ?

  • 機微情報を1つのリソースで集中管理するのはリスキー

CI/CDの構築

以下を利用

• SAM
• CodePipeline
• CloudFormation

作成したパイプライン

1. GitHubからCodePipelineにコードをpull
2. CodePipelineでSAMを使ってビルド
3. ビルドアーティファクトをS3にアップロード
4. CloudFormationが前述のアップロードファイルを参照
5. 複数のCFnスタックへ、パラメーターを切り替えつつ展開

以下も使えるかも

• SAMがStep Functionsに対応した
• SAM CLI
• (SAMを)CloudFormationと組み合わせる

CI/CD構築のメリット

• 開発から余計なコストを排除
  • テストからデプロイまで⾃動化
  • テンプレート＆スタックでリソース管理が簡単
  • 開発初期から動くものをすぐに提供可能
  • 開発よりも環境構築に時間がかかる問題を解決

感想

話の流れがスムーズでわかりやすかったです。Step Functionsは便利なサービスで、最近他のAWSサービスとの統合もどんどん追加されていてより便利になってきています。Express Workflows含め、Step Functionsを設計にどんどん組み込んでいきたいなと思いました。