21
AWSにおけるバッチ処理の ベストプラクティス 都元ダイスケ 2014-06-28 @ Sapporo #cmdevio

AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

AWSにおけるバッチ処理の ベストプラクティス

都元ダイスケ 2014-06-28 @ Sapporo

#cmdevio

Page 2: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

自己紹介• よく訓練されたアップル信者、都元です。 • Webアプリ屋出身のAWS屋

• Classmethod所属

• AWS歴 2.5年

• @daisuke_m

CloudFormationEC2S3

Glacier

ElasticMapReduce

AutoScaling

ELB

CloudFrontRDS

DynamoDBElastiCache

RedShift

IAM

CloudWatch

BeanstalkData Pipeline

OpsWorks

CloudHSM

CloudSearch

SWF

SQS

SNSSES Transcoder

Route53VPCDirectConnect

StorageGateway

Mechanical Turk

CloudTrail

AppStream

Kinesis

Page 3: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

バッチ処理とは?

‣ リアルタイム処理の対義語。

‣ らしいのだが厳密な話は抜きだ。

‣ 直感的に乱暴に。

HTTPリクエストに応答するための処理以外のもの

#cmdevio

Page 4: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

要するに‣ 運用上必要な情報を、随時担当者が抽出したりするためのアドホック(場当たり的)処理。

‣ データ移行とか、ちょっとした集計とか。

‣ 随時発生するバックグラウンド処理。

‣ ジョブスケジューラにトリガされる処理。

‣ 遅延処理や定時処理。

#cmdevio

Page 5: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

Design for failure (障害を見越した設計)

‣ まずはAZ障害に耐える設計を!

‣ AWSは比較的カジュアルにEC2インスタンスに再起動を要求w

‣ だからMulti-AZで冗長化。

‣ WebサーバはELBによる クラスタリング構成

‣ RDBサーバはMulti-AZによるMaster-Slave構成

#cmdevio

Page 6: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

バッチ on AWS

‣ バッチサーバをAWSにどのように実装するか。

‣ アドホック処理は素朴にどうぞ。

‣ バックグラウンド処理は?

‣ ジョブスケジューラ処理は? cron

#cmdevio

Page 7: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

cronの問題点

冗長化できない…

#cmdevio

いや、できなくぁないですよ? でも、します?

Page 8: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

Producer & Consumer‣ producerというのはデータを生産する生産者

‣ consumerというのはデータを消費する消費者

‣ Queue(FIFOバッファ)で2者がつながる

#cmdevio

Page 9: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

‣ producerはSQSにジョブリクエストを投げるだけ

‣ consumerはSQSをポーリングし、リクエストを拾い次第Workerとして実作業を担う

!

‣ 可用性 (availability) を意識したら拡張性 (scalability) をも手に入れた!

#cmdevio

Page 10: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

SQS (AWSで提供するマネージド分散キュー)

‣ サービスレベルで Multi-AZ 冗長化対応済み

‣ スケーラブル

‣ であるがゆえに受け入れるべき制約

‣ 順序保証しない(厳密にFIFOじゃない)

‣ at least once delivery

‣ Workerの処理は順序不問で冪等がベスト。#cmdevio

Page 11: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

#cmdevio

Page 12: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

Workerの実装

‣ Queueをポーリングする

‣ メッセージが来次第処理する

‣ メッセージの処理が成功したことを、Queueに宣言する

#cmdevio

Page 13: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

めんどくさい 定型的な処理

#cmdevio

Page 14: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

Beanstalk worker tier

‣ Beanstalkは一般的に、ELB+Webサーバの構成を提供してくれるデプロイ環境である。

‣ だけどね。ELB+Webサーバだけではなくてね。

‣ Queue+Workerサーバの環境も提供。

#cmdevio

Page 15: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

worker / web tier

#cmdevio

Page 16: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

aws-sqsd

#cmdevio

Page 17: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

sample application

#cmdevio

Page 18: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

ジョブスケジューラ

‣ この問題が未解決

‣ スケジュールに合わせたSQSメッセージ発行

‣ 可用性(AZダウン耐性)

‣ 拡張性(トリガが増えても大丈夫)

#cmdevio

Page 19: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

Quartz と Brian‣ QUARTZ

‣ JavaのOSSジョブスケジューラ

‣ RDBMSをセマフォとした分散・同期

‣ Brian by

‣ QUARTZをラップしたBeanstalkアプリ

‣ Web tier / internal ELBで使うとよい#cmdevio

Page 20: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

#cmdevio

Page 21: AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

Developers.IO Job Worker 三部作

http://bit.ly/aws-worker-sqshttp://bit.ly/aws-worker-beanstalkhttp://bit.ly/aws-worker-brian