AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05
- 2. 自己紹介 • よく訓練されたアップル信者、都元です。 • Webアプリ屋出身のAWS屋 • Classmethod所属 • AWS歴 2.5年 • @daisuke_m CloudFormation EC2S3 Glacier ElasticMapReduce AutoScaling ELB CloudFrontRDS DynamoDB ElastiCache RedShift IAM CloudWatch Beanstalk Data Pipeline OpsWorks CloudHSM CloudSearch SWF SQS SNS SES Transcoder Route53VPC DirectConnect StorageGateway Mechanical Turk CloudTrail AppStream Kinesis
- 3. バッチ処理とは？ ‣ リアルタイム処理の対義語。 ‣ らしいのだが厳密な話は抜きだ。 ‣ 直感的に乱暴に。 HTTPリクエストに応答するための処理以外のもの #cmdevio
- 4. 要するに ‣ 運用上必要な情報を、随時担当者が抽出したりする ためのアドホック（場当たり的）処理。 ‣ データ移行とか、ちょっとした集計とか。 ‣ 随時発生するバックグラウンド処理。 ‣ ジョブスケジューラにトリガされる処理。 ‣ 遅延処理や定時処理。 #cmdevio
- 5. Design for failure （障害を見越した設計） ‣ まずはAZ障害に耐える設計を！ ‣ AWSは比較的カジュアルにEC2 インスタンスに再起動を要求ｗ ‣ だからMulti-AZで冗長化。 ‣ WebサーバはELBによる クラスタリング構成 ‣ RDBサーバはMulti-AZによる Master-Slave構成 #cmdevio
- 6. バッチ on AWS ‣ バッチサーバをAWSにどのように実装するか。 ‣ アドホック処理は素朴にどうぞ。 ‣ バックグラウンド処理は？ ‣ ジョブスケジューラ処理は？ cron ？ #cmdevio
- 8. Producer & Consumer ‣ producerというのはデータを 生産する生産者 ‣ consumerというのはデータを 消費する消費者 ‣ Queue（FIFOバッファ）で 2者がつながる #cmdevio
- 9. ‣ producerはSQSにジョブリクエストを投げるだけ ‣ consumerはSQSをポーリングし、リクエストを 拾い次第Workerとして実作業を担う ‣ 可用性 (availability) を意識したら 拡張性 (scalability) をも手に入れた！ #cmdevio
- 10. SQS （AWSで提供するマネージド分散キュー） ‣ サービスレベルで Multi-AZ 冗長化対応済み ‣ スケーラブル ‣ であるがゆえに受け入れるべき制約 ‣ 順序保証しない（厳密にFIFOじゃない） ‣ at least once delivery ‣ Workerの処理は順序不問で冪等がベスト。 #cmdevio
- 11. #cmdevio
- 12. Workerの実装 ‣ Queueをポーリングする ‣ メッセージが来次第処理する ‣ メッセージの処理が成功したことを、Queueに 宣言する #cmdevio
- 14. Beanstalk worker tier ‣ Beanstalkは一般的に、ELB+Webサーバの 構成を提供してくれるデプロイ環境である。 ‣ だけどね。ELB+Webサーバだけではなくてね。 ‣ Queue+Workerサーバの環境も提供。 #cmdevio
- 15. worker / web tier #cmdevio
- 18. ジョブスケジューラ ‣ この問題が未解決 ‣ スケジュールに合わせたSQSメッセージ発行 ‣ 可用性（AZダウン耐性） ‣ 拡張性（トリガが増えても大丈夫） #cmdevio
- 19. Quartz と Brian ‣ QUARTZ ‣ JavaのOSSジョブスケジューラ ‣ RDBMSをセマフォとした分散・同期 ‣ Brian by ‣ QUARTZをラップしたBeanstalkアプリ ‣ Web tier / internal ELBで使うとよい #cmdevio
- 20. #cmdevio