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

メドレー開発部TechLunch AWSでのバッチ処理

メドレー開発部TechLunch AWSでのバッチ処理

メドレー開発部TechLunchで発表した内容を掲載しました。

メドレーで開発部では、隔週で社内勉強会が開かれています。
今回は、「AWSでのバッチ処理」というタイトルで発表し、社内のエンジニアのバッチ処理に関連したAWSの新サービス対する知見を深める機会となりました。

発表者:田中 清

Medley Inc.

March 21, 2017
Tweet

More Decks by Medley Inc.

Other Decks in Technology

Transcript

  1. 1. バッチ処理と ▪ 一定期間、もしく 一定量データを集め、まとめて一括処理を行う  例)1日 売上データを夜間に集計し、集計結果を別システムに取り込み   => バッチ型

    ▪ 時間 かかるバックグラウンドタスクをワーカープロセスで行う  例)1リクエストごとに対象者にメール送信。リクエスト内でメール処理    すると時間がかかるため、そこ 部分をワーカーで行うように    キューイング処理   => キューイング型
  2. 1. バッチ処理と Scheduler ベーシックなシステム構成イメージ S3 ・時間起動でBatchサーバ上 appが起動 ・Batch app がDBデータを取得し集計

    ・DBデータ集計結果をファイル出力し S3保存 batch app worker queuing pollling ・appがSQSにキューイング ・workeがSQSをpollingし、キューがあれ 拾う ・workerがキュー内容に応じてメール送信 バッチ型 キューイング型 SQS
  3. 1. バッチ処理と (おまけ) ▪ 設計 ポイント ・各要素が疎結合か ・途中で失敗した場合が考慮されているか(リトライ、冪等性など) ・システムコスト的に無駄がないか(夜間しか使わないインスタンスなど) ▪

    ここ最近 バッチ関連 ・旧来 典型的なバッチ処理が徐々にリアルタイム化へ  (ログ集計→分析ツール サイクルが1日1回からリアルタイムにとか) ・それもあって、バッチ用インスタンス上で単一 重い appを実行するよりも、  キューイング的に複数コンポーネント 組み合わせ方式に流れていってる気がする
  4. 1. バッチ処理と (おまけ) ▪ CLINICS ログ処理系 例 heroku app job

    worker AWS Kinesis Lambda event BigQuery ・Rails appがSideKiq(ActiveJob)を通してログデータを Kinesisへ送信 ・Kinesisがログデータを受け、そ イベントにより Lambdaが起動  (1データ毎 event発行される で なく、 Lambdaが一定時間毎にeventをpollingしている) ・Lambdaが受け取ったログデータを BigQuery 対象 tableに送信 ・BigQueryデータをre:dashなどで参照/分析
  5. 2.Step FunctionsとAWS Batch ▪ 何? ・AWS Re:Invent 2016で発表されたAWS batch処理系 新サービス

    ・AWS Batch 東京で まだ、Step Functions 東京でも使えます ▪ Step Functions 概要 ・Lambaなど 複数アプリをワークフローとして定義、実行(ビジュアル化) ・今まで Lambda to Lambdaや、SQSを介すなど自分で考慮必要 ▪ AWS Batch 概要 ・フルマネージド型 バッチ処理実行基盤 ・必要なリソース(CPU、メモリetc)を定義すれ 、AWSが必要に応じて  ECS上で実行(インスタンスタイプ、分散用に台数確保) ・ジョブとして登録したアプリやコンテナイメージをスケジューラが実行
  6. 2.Step FunctionsとAWS Batch サービス リリース状況 概要/ユースケース 導入しやすさ キーワード Step functions

    東京OK ・マイクロサービス的な複数アプリ 組合せで バッチ処理 ・アプリ間 疎結合により、汎用 性、再利用性 確保 ⇒軽い処理 組み合わせ向け ◦ マイクロサービス 的な、サーバーレ ス的な、、、 AWS Batch アメリカ み (2017/1にGA) ・本格的なバッチ基盤 (ジョブ、ジョブ定義、ジョブキュー、 コンピュート環境) ・事前に定義したDockerイメージ 実行 ⇒重いバッチ処理向け △ ビッグデータ 活 用を、、、 どちらも分散実行 可能なためユースケースに応じてどちらを使用するかを考える必要がある (個人的に マイクロサービスな APIからバッチまでいけるStep Functions 汎用性が好き)
  7. 2.Step FunctionsとAWS Batch(おまけ) 構成要素 概要 ジョブ ・コンテナ化されたアプリ( = 1作業単位) ・コンテナイメージ、コマンド、パラメータ

    組み合わせ(イメージ的に docker run)をジョブ 定義で設定する ジョブ定義 ・ジョブ 実行方法を定義(使用するコンテナイメージ、コマンド、環境変数など) ・CPUとメモリ要件 ジョブキュー ・投入された各種ジョブ 待ち行列場所 ・スケジューリングされるまで待機。優先順位指定可能 コンピュート環境 ・ジョブが実行される環境( ECS) ・CPU/メモリ要件など 応じてインスタンスが起動される( AutoScalingも) ・実行環境 ECSであり、ジョブ コンテナ上で実行される ・アプリ コンテナイメージを指定して呼び出し。 Docker HubやEC2 Container Registry(ECR)にイメージ保存/ デプロイして 利用がベースになる (使いこなすに ECS / ECR / Dockerなど 知識もあった方がいい で、ちゃんとやるに 敷居が高そうだな、と思いました)
  8. 3. Step Functionsお試し S3 EC2 GW Kinesis Lambda Step Functions

    State machine イベントソース トリガー Step Functions start exec API イベント発行 ▪ 概要 ・ワークフロー(各種Lambda 処理 流れ)をJSONで定義 ・単純なアプリ 実行だけでなく、分岐、並列、待ち、リトライなども定義可能 ・実行単位 Lambdaだけでなく、EC2上 アプリなども実行可能(Activity Task) ▪ 起動方法 ・APIで 実行となるため、単一Lambda ように時間/イベント起動 (今 ところ)できな いため、起動用Lambdaなど 組み合わせが必要になる
  9. 3. Step Functionsお試し ▪ Step Functionsを作成するに 以下 順番で行います ・必要なLambda 作成(今まで通り)

    ・Step Functionsで上記を組み合わせたフロー定義(State Machine作成) ・Step Functionsを実行するトリガー
  10. 3. Step Functionsお試し ▪ 簡単なParallel処理用 Step Functions作成 ・State Machine作成(lambda 適当なhello

    worldで作成済(省略)) ・コンソールからStep Functionを選び、GetStarted 1.state machine名 2.タスク定義 3.ビジュアルで確認
  11. 3. Step Functionsお試し ▪ 感想 Pros ・既存 Lambdaをそ まま使用できて楽そう ・フロー定義や実行結果がビジュアルで確認できる

    良い ・同じLambdaを別々 State Machineで使える で汎用性、再利用性が高まる Cons ・タスク定義 JSONめんどくさい。一度定義すると修正できない? ・Lambda自体 デプロイ管理やState Machine 管理を仕組み化しないと辛そう  (デプロイ管理 serverless framework、StateMachine CloudFormationとか)とか ・トランザクション的な管理、設計 勘所がけっこう必要になりそう  (Step Functionsがどうこうより、micro service設計的な部分)
  12. まとめと感想 ・ バッチ処理もいろんなやり方が増えてきた ・やりたいことに応じて色々選択してかないといけない  (あえてベーシックにバッチインスタンス立てて、とかも有りと思う) ・選択肢として、Step Functions / AWS Batch

    も今後視野に入れていった  方がよさげ。今後 StepFunctions、これまで バッチ 移行 AWS Batch  イメージ ・Step Functions マイクロサービスなAPIからバッチまで幅広く活用できそう ・フルマネージド 恩恵(いかに運用で楽するか)を受けるためにも  選択眼というか、コーディネートするスキルがより大事になってきた