[AWS Summit 2012] クラウドデザインパターン#5 CDP バッチ処理編

1. AWSクラウドデザインパターン -バッチ処理編-

2. 自己紹介 名前 大谷晋平 所属 アマゾンデータサービスジャパン株式会社ソリューションアーキテクト ID Facebook: shot6 好きなAWSサービス Amazon S3

3. AWSクラウドデザインパターンとは... AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したもの。

4. 例えば... (Web Storage Archive) 解決したい課題  構造サーバで大量に発生するログを一元管理したい クラウドでの解決容量無制限ウェブストレージを利用し、キャパシティを気にすることなく格納可能 実装 EC2上でローテートされたログをAPI等のツールを利用しS3に転送 利点ディスクスペース管理が不要になり、堅牢性の高いストレージでログを管理 注意点 AutoScale時には、停止前に該当ログの退避の仕組みを実装する必要がある

5. Webでノウハウを共有WIKIhttp://aws.clouddesignpattern.org/index.php FACEBOOK https://www.facebook.com/awscdp

6. 書籍でノウハウを共有Amazon Web Services クラウドデザインパターン設計ガイド http://www.amazon.co.jp/dp/4822211967/

7. CDPカテゴリ (2012.09.13現在) 基本  静的コンテンツを処理  運用保守 Snapshot Web Storage Bootstrap Stamp Direct Hosting Cloud DI Private Distribution Stack Deployment Scale Up Cache Distribution Ondemand Disk Server Swapping Rename Distribution Monitoring Integration 可用性を向上 Web Storage Archive  データをアップロード Weighted Transition Multi-Server Write Proxy Hybrid Backup Multi-Datacenter Storage Index Floating IP Direct Object Upload Deep Health Check  ネットワーク  リレーショナルデータベース On-Demand NAT 動的コンテンツを処理 DB Replication Backnet Read Replica Functional Firewall Scale Out In-memory DB Cache Operational Firewall Clone Server Sharding Write Multi Load Balancer NFS Sharing WAF Proxy NFS Replica  バッチ処理 Cloud Hub State Sharing Queuing Chain URL Rewriting Priority Queue Rewrite Proxy Job Observer Cache Proxy Scheduled Autoscaling Scheduled Scale Out

8. シナリオバッチ処理編

9. 今回のシナリオをご紹介する前に...雲写真販売編雲写真を大きく販売開始業者も多数参加、巨大販売サイトにまさかの大人気

10. 今回のシナリオまさかの

11. 本実装シナリオの狙いEコマースサイトをとりあげ、を高めるパターンを中心にAWSを活用した実装方法を解説

12. おかげさまでECサイト好調サムネイルの生成が追いつかない！

13. 初期の構成オリジナル画像アップロード ec.clouddesignpattern.org ロードバランサゾーン1a ゾーン1b サムネイル生成 EC2 EC2 インスタンスインスタンス S3ストレージ MySQL DB MySQL DB インスタンススタンバイ

14. 問題発生 (その１)問題：サムネイルの生成が間に合わないソリューション： ”Queuing Chain”パターンキューを使ってサムネイル処理を分離

15. QueueChainパターン

16. SQSで、サムネイル生成を分離オリジナル画像アップロード ec.clouddesignpattern.org ロードバランサゾーン1a ゾーン1b オリジナルの S3アップロード EC2 EC2 インスタンスインスタンスワーカーサムネイル生成 S3 MySQL DB MySQL DBストレージインスタンススタンバイ

17. Queuing Chainパターンのポイントサムネイルの生成処理をメインフローから切り離すプロセス S3へオリジナルのアップロード アップロードした画像のサムネイル生成 作成完了通知他パターンの適用可能性 Direct Object Uploadパターン

18. 問題発生 (その2)問題：プレミアム会員のサムネイル生成処理などをもっと高速に終えたい (スタンダード会員のコストを減らしたい)アクション： “Priority Queue”パターンキュー配下のワーカーインスタンスの性能を差別化して、より高速に処理

19. Priority Queueパターン

20. 複数のキューで優先順位付けサムネイル生成通常会員用キュー優良会員用キュー小さめインスタンスタイプ大きめインスタンスタイプインスタンス数も絞るワーカーインスタンス数も増し増しワーカー S3 ストレージ

21. Priority Queueパターンのポイント優先度によってキューのワーカーの処理能力を変える インスタンスタイプやインスタンスの数ビジネスの変化に応じやすい他パターンの適用可能性 Job Observerパターン 優良会員：アグレッシブなオートスケール 通常会員：スタンダードなオートスケール

22. Priority Queueパターンのポイントサイズ、アップロード方法、保存方法も変更可能 サイズ アップロードサイズを変える アップロード方法 優良会員には並列アップロードさせる 保存方法 S3であれば、スタンダードかRRS バージョニング

23. 問題発生 (その3)問題：民放TV CMキャンペーンでアップロードが 100倍に！でもいつ放映か正確にわからない！アクション： “Job Observer”パターンキュー配下のワーカーインスタンスをキューの滞留量によってオートスケールさせる

24. JobObserverパターン

25. アーキテクチャ図 CloudWatch Alarm 閾値ワーカーワーカーワーカーキューの滞留量を見て、ワーカーをオートスケールワーカーワーカーワーカー S3 ストレージ最小、最大のインスタンス数を決めておける

26. Job Observerパターンのポイントキューの滞留量によってワーカーの数を自動的に増減させる CloudWatchでモニタリング AutoScalingでインスタンスを自動増減クラウドの特性である、オートスケールで運用の負荷を大きく削減可能

27. Job Observerパターンのポイントいつ適用すべきでないか 急激な負荷が見込まれる場合 既に予見できている場合 Scheduled Autoscalingを使う

28. Scheduled Autoscalingパターン

29. 問題発生 (その4)問題：サムネイルだけでなく、スマホなどの各種デバイスにリサイズさせたい。しかも対応デバイスは写真家の販売要望にあわせたいアクション：複数のキューに並列で処理させて、結果だけ集約させる？

30. SQSだけを利用する場合の課題判定ロジックなどが入ると全体のバッチ処理のフロー判定が面倒 キューの間でのやりとり 状態の管理 実行エラーの管理これらはSQS外でやる必要がある

31. そこでSWFの登場ですSWFとは ワークフローの状態とフロー管理のサービス 今までの一連のフローを管理してくれるデサイダー ワークフローの条件判定をするワーカー 各タスクを実行する業務ロジック

32. SWFのフローサムネイル画像開始変換・アップロードユーザオリジナル画像の変換 iPhone用画像変換・アップのアップロードタスクロード判定 Android用画像変換・アップロード終了完了通知

33. アーキテクチャ図 SWF サムネイル変換タスク画像アップロード画像生成タスクデサイダー iPhone用画像変換タスクフロー条件判定・オリジナル画像の Android用画像変換タスクアップロード・ユーザ毎の変換タスク・返還後の画像アップロード

34. SWFの典型的な使い方

35. オンプレミスとの連携も容易

36. SQS vs SWFシンプルな並列処理はSQSのみで実装するのが楽 複雑な条件分岐がない 複雑なリトライ条件などがない複雑なバッチ処理を実行する場合には SWFは一つの選択肢になりえる 順次、並行、集約、リトライなどをカバー Flow Frameworkにより、容易に実行可能 ただ現状はまだUSでの展開のみ

37. 様々な対策を経てバッチ処理もスケーラブルかつコストを抑えて実行可能！

38. デザインパターンの推移

39. アドバンスドトピック

40. 1.スケーラビリティについてスケーラビリティの今までの考え方 事前に予測する方法(プロアクティブ)スケーラビリティのこれからの考え方 プロアクティブ x リアクティブ プロアクティブに事前に読める場合はアーキテクチャ・設計・実装に入れておく ある一定時刻で起動・停止を繰り返す リアクティブに反応できるようにしておく その反応時間がどれくらいが適切か

41. 2.システム境界を明確に分離するシステムのバウンダリデータベースメッセージシステム間のインタフェースとして SQS、S3などを使うストレージ

42. 当然オンプレミスとの連携でもシステムのバウンダリデータベースメッセージシステム間のインタフェースとして SQS、S3などを使うストレージ

43. Pub-SubもSNSで可能システムのバウンダリメッセージ

44. Hadoop環境も同様 Hadoopバウンダリマスターノード EMR コアノードワーカーノード

45. 3.リアルなクラウドバッチ処理実例データを中心としたクラウドのバッチ処理

46. 4.その他適用可能なパターンAggressive Scale Out Conservative Scale InパターンDeep Health CheckパターンSWFを使ったジョブフローの自動化Harakiriパターン Auto Scale Out/Custom Scale In

47. まとめデザインパターンを活用しキューを使って並列処理部分を分離する事で、スケールするバッチ処理構築が可能にバッチ処理の処理量の変動に対応可能な、スケールするバッチが低コストで実現可能にシステムが拡大しても、運用者の負担を削減する仕組みづくりが可能に

48. まとめ (改善ｘ革新) 今までできていたことを、改善より早く、簡単に、安く実現できる今までできなかったことが革新実現できる

49. CDPでAWSをもっと楽しく

50. ご清聴ありがとうございました。 FACEBhttps://www.facebook.com/awscdp

SlideShare for iOS

Views

Actions

Embeds 0

Report content

Transcript