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

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

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

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

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

発表者:田中 清

D879794ea42768ea417f970914430d56?s=128

Medley Inc.

March 21, 2017
Tweet

More Decks by Medley Inc.

Other Decks in Technology

Transcript

  1. AWSで バッチ処理 〜開発本部・TechLunch〜 株式会社メドレー 田中清

  2. 1. バッチ処理と 2. Step FunctionsとAWS Batch 3. Step Functionsお試し

  3. ▪ じめに ・サーバーあまりやったことない人向けに、まず「バッチ処理って何よ?」  話します ・そ 後、徐々にAWSに寄った話になります ・AWS 各サービス 名前が似てたり種類も多い で、聞いてて「?」って

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

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

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

    ここ最近 バッチ関連 ・旧来 典型的なバッチ処理が徐々にリアルタイム化へ  (ログ集計→分析ツール サイクルが1日1回からリアルタイムにとか) ・それもあって、バッチ用インスタンス上で単一 重い appを実行するよりも、  キューイング的に複数コンポーネント 組み合わせ方式に流れていってる気がする
  7. 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などで参照/分析
  8. 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上で実行(インスタンスタイプ、分散用に台数確保) ・ジョブとして登録したアプリやコンテナイメージをスケジューラが実行
  9. 2.Step FunctionsとAWS Batch サービス リリース状況 概要/ユースケース 導入しやすさ キーワード Step functions

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

    Black Belt Online Seminar 2017 AWS Batch」より
  11. 2.Step FunctionsとAWS Batch(おまけ) 構成要素 概要 ジョブ ・コンテナ化されたアプリ( = 1作業単位) ・コンテナイメージ、コマンド、パラメータ

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

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

    worldで作成済(省略)) ・コンソールからStep Functionを選び、GetStarted 1.state machine名 2.タスク定義 3.ビジュアルで確認
  15. 3. Step Functionsお試し ▪ タスク定義補足 ・Typeでタスクタイプ指定   paralleやchoiceなど ・Resourceで使用するLambda指定 ・Nextで次に実行されるタスク指定

  16. 3. Step Functionsお試し ▪ 作成されたState Machine ここからテスト実行で きる

  17. 3. Step Functionsお試し ▪ テスト実行結果 個々func 結果が わかる(失敗すると 赤)

  18. 3. Step Functionsお試し ▪ 感想 Pros ・既存 Lambdaをそ まま使用できて楽そう ・フロー定義や実行結果がビジュアルで確認できる

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

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