Help us understand the problem. What is going on with this article?

Step Functions & Fargate バッチでやらかしたこと

この記事について

この記事は Opt Technologies Advent Calendar 2019 17日目の記事です。
担当プロダクトで利用したStep Functionsにて、失敗を通じて得た知見をまとめたものです。

自分について

中途入社して1年ちょっとのエンジニア。チームマネージャになって半年くらい。
入社してからクラウドインフラを学習し始め現在もチーム内で主に担当をしていますが、アプリケーションコードも状況に応じて実装する感じです。
昨年はこんな記事書きました。

やらかし背景

著者の担当プロダクトにて、外部APIから取得できるそこそこのサイズのデータをプロダクト側のDBに格納する処理があります。
ELT的なステップを踏んで処理することを検討しStep Functionsを採用しました。

image.png

  • Extractorが外部APIからデータファイル(csv)を取得しS3バケットに格納
  • Loaderがデータファイルを中間テーブルに格納
  • Transformerが変換SQLを実行し成形済みデータにしてテーブルに格納 image.png

一般的にはStep FunctionsではLambdaで処理を記述すると思うのですが、

  • 当時Lambdaの起動時間限界が5分と短く不安が大きかった
  • Webサーバや、今回の処理とは別のいくつかのバッチ処理をECS(Fargate)で実現していたため、そちらに寄せておいた方がコード管理上楽そうだった

という理由で、デファクトから外れることを認識しつつも、ここではFargateバッチを採用しました。

ところが、これが原因でいくつかのつらみを生んでしまったのでした。

つらみ1: 立ち上がりが遅い

当たり前といえば当たり前なのですが、Fargateは起動に時間がそこそこかかります。我々のプロダクトのバッチだとおおよそ45sec程度。
Step Functionsの立ち上がり直後にSlackへ通知をするような処理が必要なのですが、通知が来るまでに約1min程度かかりました。

つらいといえばつらいんですが、要件的に致命的な問題にならないため、ひとまずこちらは気にせずそのまま突き進みました。

つらみ2: 処理結果を次処理で利用することができない

当初はこんな感じで処理を進める予定でした。

image.png

ところが、Fargateバッチの出力は以下のようになります。

Fargate出力
{
  "name": "Extractor",
  "output": {
    "Attachments": [
      {
        "Details": [
          {
            "Name": "subnetId",
            "Value": "subnet-XXXXXXXXXXXXXXXXX"
          },
          {
            "Name": "networkInterfaceId",
            "Value": "eni-XXXXXXXXXXXXXXXXX"
          },
          {
            "Name": "macAddress",
            "Value": "XX:XX:XX:XX:XX:XX"
          },
          {
            "Name": "privateIPv4Address",
            "Value": "xx.xx.xx.xx"
          }
        ],
        "Id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "Status": "DELETED",
        "Type": "eni"
      }
    ],
    (略)
  }
}

標準出力に吐いた結果とか出てくることを期待しましたが、淡い期待でした。
ECSタスクに関する詳細情報が出てきます。
なんとか他の手段で次のステートへ受け渡す方法を考えてみましたが、結局見つからず。

苦肉の策として、ステートマシンの入力側で対処しました。

ステートマシンの入力
{
  "StagingTable": "STAGING_XXXXXXXX_YYYYMMDDHHmmssfff",
  "S3Path": "Sync/Staging/XXXXXXXX/YYYYMMDDHHmmssfff/"
}

ステートマシンへの入力の時点で取得ファイルの格納S3ディレクトリ名と、作成する中間テーブル名を渡しています。
衝突を避けるため、外部APIから取得するデータのアカウントID(XXXXXXXX)と
実行日時(ミリ秒単位:YYYYMMDDHHmmssfff)で分けました。
既にだいぶつらい感じの作りですが…なんとかこれにより共通のデータに対してアクセスすることには成功できました。

さて、これでようやく実装できるぞ、と思って動かしてみたら、次の問題が発生しました。

つらみ3: ThrottlingExceptionの大量発生

さてこれで元気に動いてくれそうだなということで実装しまして。
では…ということで動かしてみたら、狙い通りうまくいきました!
ここでめでたしめでたし、となればいいのですが、現実は非情なものでした。

今回の処理は並行実行を結構な数で行うケースが想定されます。
その確認のため負荷試験を行ったところ、ボコボコとエラーで停止してしまいました。

そのときのエラーがこちら。

{
  "resourceType": "ecs",
  "resource": "runTask.sync",
  "error": "ECS.AmazonECSException",
  "cause": "Rate exceeded. (Service: AmazonECS; Status Code: 400; Error Code: ThrottlingException; Request ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx)"
}

調べてみると、どうもECSタスク起動のためのECS APIコール数が秒間1回までという制限にひっかかっていたらしく、
リトライ設定をしても結構な確率で再衝突しました。結果リトライ上限に達し無事死亡……。

取り急ぎの対応としては、リトライのバックオフレート設定です。

"Retry": [
  {
    "ErrorEquals": [ "States.Timeout" ],
    "MaxAttempts": 0
  },
  {
    "ErrorEquals": [ "States.ALL" ],
    "IntervalSeconds": 10,
    "MaxAttempts": 5,
    "BackoffRate": 3.0
  }
]

https://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/concepts-error-handling.html#error-handling-retrying-after-an-error

リトライタイミングがそれなりに散ってくれたので、ステートマシン全体の処理完了時間を犠牲にはしましたが、動作するようになりました。

ちなみにこちら、Lambdaの場合はほぼ無制限…同時実行数も1,000など、圧倒的に有利ですね。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/limits.html

まとめ

Lambdaを選択できるときは迷わずLambdaを選択するのが良さそうですね……。
とはいえ現在もLambdaの制限時間は15分で、これを超えそうなバッチもいくつかある現状。
激重なバッチについては残念ながら現状維持になりそうです。
ですが、例えばSlackへの通知だとか、今回は説明都合で割愛したDBへの軽微な変更処理バッチなど、
速度面に不安のない処理については、チームで粛々とLambda化の対応を進めています。

Step FunctionsはLambda,Fargateの他にも、AWS BatchやSQS、EMR、DynamoDBなどが利用可能ですが、
組み合わせるとどんなことが起きるかについては利用前に事前調査をしなくちゃな、と思いました。
当然といえば当然のことですが、いやー、反省です。

a_sh_blue
もろもろIT系をふらふらしてた結果、スキルセットで深いものがなくなった悲しいエンジニア。 データベースが好きなので、そのあたりを軸足にして頑張りたいが、身体が追い付かなくなってきた30代。
opt
"INNOVATION AGENCY" を標榜するインターネット広告代理店。エンジニア組織 "Opt Techonologies" を中心にアドテクetc...に取り組んでいます。
https://opt-technologies.jp/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした