Upgrade to Pro — share decks privately, control downloads, hide ads and more …

210629 Stockmark Tech Meetup #1 AWSを活用したCPU/GPU環境の並列化

210629 Stockmark Tech Meetup #1 AWSを活用したCPU/GPU環境の並列化

Stockmark

July 02, 2021
Tweet

More Decks by Stockmark

Other Decks in Technology

Transcript

  1. インフラ選定結果 翻訳処理環境(GPU環境):AWS Batch + Amazon EC2 • GPUを利用可能、かつ、配列ジョブで並列処理を実装しやすいことからを採用 • 並列数を記事数に応じて変えるため、事前に

    Lambda で必要な並列数を算出 既存処理環境(CPU環境):Amazon ECS + AWS Fargate • EC2は他サービスと連携しづらいため既存処理環境も差し替え • 既に一部タスクを ECS + Fargate で実行できる状態にしていたので他タスクへ拡張 ワークフローエンジン:AWS Step Functions • AWSサービスとの連携しやすさ+社内での利用実績から採用
  2. AWS Batch の配列ジョブを使用する際の注意点 配列ジョブは便利だが、指定できる子ジョブの数は2〜1000で1は設定不可 並列数が1の場合、通常のジョブへの分岐が必要 "Check Chunk Num": { "Next":

    "Check Array Size", "Type": "Task", "Resource": "arn:aws:lambda:xxxxxxxxxxxxx", "ResultPath": "$.chunk_num" }, "Check Array Size": { "Type": "Choice", "Choices": [ { "And": [ { "Variable": "$.chunk_num.body.array_size", "NumericGreaterThanEquals": 2 } ], "Next": "Translate JA to EN Array" } ], "Default": "Translate JA to EN" },
  3. インフラ再構築のポイント Infrastructure as Code (IaC) • コードで書いてある通りにインフラの追加・削除・変更が可能  → 開発環境で試行錯誤しやすい、本番環境反映時の負担軽減とミス防止 •

    コードが設計書としても機能する → 引き継ぎしやすい CI/CD • GitHub で特定のタグを付与すると CodeBuild で自動デプロイ用のワークフローが実行され る(CPU/GPU環境別のイメージのbuild&push、ECSとBatchの定義更新) → 開発環境/本番環境へのデプロイ時の負担軽減とミス防止
  4. バッチの高速化 目的 • ユーザ数が増えても一定時間でバッチ処理が終わるようにする 手段 • 処理対象のテーマ数/ユーザー数に応じて並列数が上がる仕組みにする 選択肢 • Step

    Functions の Map ステートを使用する ◦ ECS Fargate ◦ Lambda • AWS Batch の配列ジョブを使用する ◦ AWS Batch(EC2) ◦ AWS Batch(Fargate)
  5. Step Functions の Map ステート Map ステート • 配列を渡すと配列の各要素を入力として共通の処理を実行できる •

    各タスクが処理対象のユーザーを識別できるように配列を与えれば良い (例:[0, 1, 2,..] → 0はid:1-999のユーザ、1はid:1000-1999のユーザ...) 候補1:Map ステート + ECS Fargate • 現行インフラの延長でできそうだったので最初に検討 候補2:Map ステート + Lambda • フィード生成処理をFargateではなくLambdaで実行するパターン 並列数決定Lambda フィード生成
  6. Step Functions の Map ステート:検討結果 候補1:Map ステート + ECS Fargate

    → ❌ • RunTask API(ECSタスクをコールするAPI)の制約により断念 ◦ Mapステートは並列数の数だけAPIを呼び出すが、APIの呼び出しは同一アカウントで1 秒につき1回までという制限がある 候補2:Map ステート + Lambda → ❌ • Lambdaのメモリ10GBの制限がネックになるのが見えていたのであまり検討してない
  7. AWS Batch の配列ジョブ:検討結果 候補1:配列ジョブ + EC2 → ❌ • 処理自体は可能だが、ホストを考慮した工夫が必要

    ◦ 1インスタンス上で複数のコンテナが大量の書き込み(モデル/辞書のDL)をすると、EBS のI/Oのパフォーマンスが低下し、ジョブ終了時にAWS Batchが行うコンテナチェックがタ イムアウトする ◦ EBSへ課金する、1インスタンス1コンテナしか起動できないようなインスタンスタイプを選 択する、イメージにモデル/辞書を入れておく(未検証)、等が必要 候補2:配列ジョブ + Fargate → ⭕ • ホストの考慮が不要、かつインスタンスの起動がないので高速 注:FargateはGPUを利用できないので翻訳処理では引き続きEC2を利用
  8. サーバレスな並列処理環境について得た知見 並列処理をする場合は1〜3の順番で環境を検討すると良い(2021/06時点では) 1. Step Functions の Map ステート + Lambda

    • vCPU:6、メモリ:10GB、タイムアウト:15分 の制約内で処理できる場合 2. AWS Batch の配列ジョブ + Fargate • vCPU:4、メモリ:30GB の制約内で処理できる場合 3. AWS Batch の配列ジョブ + EC2 • 1, 2で対応できない場合(GPUなど) 並列数を増やす代わりに1タスクあたりの 負荷を減らせば、1,2でかなりの範囲をカ バーできる
  9. まとめ 翻訳処理の導入(GPU並列処理環境の構築) • 英語記事のレコメンド精度を上げるために翻訳処理を導入 • ベクトル生成、フィード生成処理を ECS Fargate + Step

    Functions に移行 • 翻訳用に AWS Batch(EC2)の配列ジョブを採用 バッチの高速化(CPU並列処理環境の構築) • ユーザー数の増加に耐えるよう、フィード生成処理を並列化 • フィード生成処理を ECS Fargate から AWS Batch(Fargate)の配列ジョブへ移行