JAZUG CDP勉強会第二回クラウドデザインパターン超入門＝「コンピューティングの分割、配置」「オートスケーリング」

1. CDP勉強会第二回クラウドデザインパターン超入門＝「コンピューティングの分割、配置」「オートスケーリング」 Keiichi Hashimoto @k1hash

2. 平日夜で、ひゃ、130名？皆さんどのへんにモチベーションがあって、何が聞きたいのか ①近江さん ②平日夜早く帰りたくない ③職場の帰宅理由 ①一方的に難しい用語でなじられたい ②

3. アンケートよろしくお願いします • http://enq-maker.com/33yr0ws • １，２分で終了します。 3

4. スピーカー紹介橋本圭一シグマコンサルティング株式会社代表取締役 Cloudlive株式会社代表取締役副社長 Micorosoft Windows Azure MVP(2010-2012) Sitecore CMS MVP(2011-2014) クラウド利用促進機構アドバイザー第四回おバカアプリ選手権優勝(第二回、第五回参加) Microsoft Azure、CMS、ECをベースとして、サービスの開発に従事。クラウドでは、他の企業と協力しての新規事業開発。

5. JAZUGのご紹介  Japan Azure User Group 略称：JAZUG(じゃずゆーじー)  コミュニティ活動概要: 「Azureを通じて、技術、交流、実ビジネスを楽しむ。」“ちょっと興味がある =ゆるふわな方”から“実ビジネスで使うんだよね”な方まで大歓迎！ゆるふわコミュニティです。  GROUP はFBで。Japan Azure User Group https://www.facebook.com/groups/jazug/  大阪(関西Azure研究会)、福岡(ふくあず)、仙台、名古屋、札幌、Azureしなの  Twitter: #jazug  一緒に運営してくれるメンバーを募集中です。

6. JAZUGのHPから Facebookグループへのご参加お願いします。 6

7. JAZUG４周年イベント  DoorKeeperよりご参加ください。  http://jazug.doorkeeper.jp/events/13866  2014 9/20(Sat)

8. JAZUG４周年関連イベント 9月13日 JAZUG札幌支部第4回勉強会feat.CLR/H～デプロイ王子からAzureを学ぼう！ 9月20日（同日開催） JAZUG 福岡（ふくあず） MSコミュニティ合同勉強会 & JAZUG4周年記念連動 9月27日関西Azure研究会/JAZUG 秋のAzure収穫祭

9. 本よろしくです！クラウドデザインパターン Azureを例としたクラウドアフリケーション設計の手引き http://amzn.to/1oTJNVH 15人のコミュニティメンバーで半泣きになりながら監訳しました 9

10. 今日のお品書き • パターンではなく、ガイダンスの方になります。 • とても入門よりです。 • Compute Partitioning Guidance コンピューティングの分割 • Autoscaling Guidance オートスケール・ガイダンス社内や、勉強会で皆さんが学んだことを紹介できるようになることをゴールにしたいと思っています。 10

11. Compute Partitioning Guidance • コンピューティングの分割、配置 • 論理的な配置、物理的な配置 11

12. Autoscaling Guidance • オートスケールガイダンス 12 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure

13. Azureスライド MS公式のAzureスライド (IaaS、VPN、AD、スケールなど多岐に渡って用意) http://www.slideshare.net/MicrosoftAzure_Japan/ 社内での紹介、勉強会などで使えます。 13

14. 本日のガイダンス要旨 • コンピューティングを適切に分割することは、クラウド上におけるアプリケーションの非機能要件を満たすことに、大きく影響する。 • 分割したコンポーネント毎にリソースを検討し、必要に応じて自動スケールする。効果的にスケールするためには、この分割が重要である。 14

15. 分割とは＝論理的な分割 • フロントのWEBサイト • 管理用のWEBサイト • API • バックグラウンド処理、バッチ • キャッシュ • ファイルストレージ • 永続的なデータストア 15

16. 論理的な分割の例 16 Microsoft Azure データセンター Webロール Webロール一般ユーザーロードバランサーフロントエンドキャッシュバックエンド Workerロール BLOB SQL Database ロードバランサー管理サイト Webサイト管理ユーザーキュー CDN

17. Azure Symbols/Icon Set 17 • 設計や構成図作成に便利なアイコン集 http://www.microsoft.com/en-us/download/details.aspx?id=41937

18. 論理的な分割(フロント側の細分化) • フロントのWEBサイト • キャッシュが有効なページ • キャッシュもアプリ全体と、ユーザー別など • キャッシュが無効なページ • (検索機能など)処理負荷が重いページ →ARRなどを用いて、同一URLで稼働するインスタンスを分けたりする 18

19. フロント＝論理的な分割の例 19 Microsoft Azure データセンター一般ユーザーロードバランサーフロントエンド (HTMLキャッシュ) EC-Portal EC-Portal 検索 (非キャッシュ) Webロール Webロール Webロール ARR(URLリライト)を利用して、別のインスタンスで処理する。カート＝特定の発売日以外負荷がない検索＝常に負荷があるカート(非キャッシュ)

20. クラウドにおける論理的な分割 • コンピューティング、キャッシュ、ストレージ、DBなど論理的な分割とクラウドプラットフォームが用意するサービスが対比しているケースが多い。よって論理的な分割は慣れの問題ともいえる。 • これに非機能要件を加えて、落とし込んでいく。 20

21. 非機能要件とコンピューティング分割の考慮 ①可用性 ②性能／拡張性(パフォーマンスとスケーラビリティ) ③運用／保守性(デプロイと更新) ④セキュリティ ⑤移行性 ⑥システム環境、エコロジー 21

22. ①可用性Availability(アベイラビリティ） • システムが継続して稼働できる能力 • 適切なコンピューティングリソースの割当 • SLAの順守＝最小限のダウンタイム • デザインパターンだと以下と関連 • Health Endpoint Monitoring Pattern • Queue-based Load Leveling Pattern • Throttling Pattern • Multiple Datacenter Deployment Guidance 22

23. デザインパターンのサンプルコード http://www.microsoft.com/en-us/download/details.aspx?id=41673 23

24. ①可用性-クラウドの場合 • クラウドでSLA(可用性など品質保証)が異なる • また、品質保証しているが、未達時の返金のみ約束 Azureの場合はSLAは、以下に詳しく載っています。年間停止時間稼働率動作不能時間 99.9999% 32秒 99.999% 5分15秒 99.99% 52分34秒 99.9% 8時間46分 99% 3日15時間36分 • Azureスライド「S92 Microsoft Azure SLA について」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/presentations

25. ①可用性-クラウドの場合 • 例えば、平日日中のみ保証するもの • SLAが99％など年間87時間は止まって良いもの • 上記に近い条件のクリティカルでないサービス • は、この要件を考慮せず、プラットフォームメンテナンスで深夜に止まる、物理的な障害があった場合のプロビジョニング時間を許容することもできる。 25

26. ①可用性-Azureの場合 • コンピューティングサービスで可用性の担保が異なる 26 仮想マシン(IaaS)の場合、負荷分散セットで複数の仮想マシンでエンドポイントを構成する必要がある。プラットフォームメンテナンス等でダウンする場合がある。また、台数の制限はない。クラウドサービス(PaaS)の場合、複数のインスタンスでエンドポイントを構成する必要がある。プラットフォームメンテナンス等でダウンする場合がある。また、台数の制限はない。 WEBサイト(PaaS)の場合、単一のインスタンスでも可用性を保証している。台数の制限がある。L(4core)を10台まで。サブスクリプションとしてはコア数制限があるのでコア数を大幅に増やす場合制限解除する必要がある。

27. ①可用性-Azureの場合(DR) • 利用しているサービスでDR対策の実現が異なる • 自動で切り替わる、自前で切り替える • ストレージ(地理冗長、読み取り地理冗長、ゾーン冗長) • コンピューティング • トラフィックマネージャー • SQL Database(Premium-ActiveGeoReplication) (Basic,Standard) 27

28. ②性能／拡張性 • 必要とされる性能に対して、適切なコンピューティングリソースを用意する必要がある。 • ３秒以内のレスポンス • 15秒以上ウエイトしないエラーを返す(処理をためない) • スケールアップ、スケールアウトで性能を叶える • 負荷に対するスケール対応、自動スケール • 各サービスを効果的に使うストレージ、CDN、キャッシュ 28

29. スケールアップとスケールアウト 29 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure

30. ストレージを活用したハイパフォーマンス • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure 30

31. キャッシュ • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure 31

32. ②適切なリソース、サイズ • アプリケーション内の各コンポーネントはそれぞれ異なるメモリー、バンド幅、CPUなどのリソース必要条件を持つ。 • アプリケーション上のそれぞれのパートに対して、要件にあったホスティング、インスタンスのサイズを選ぶ。 32

33. Azureインスタンスのスケールアップ 33 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure

34. ②適切なリソース・サイズ • 需要が大幅に変動した場合は、より小さいサイズのホストへ変更する。閑散期。コストメリット的に重要。 • オートスケーリングを通して、インスタンスの増減を随時、適切に行う。 34

35. ②性能＝バックグラウンドタスク • アプリケーションがバックグラウンド処理を実行する場合、これらのタスクは分割の候補として適することが多い。 • バックグラウンドタスクが一般的にむいている処理は、多くのI/Oやネットワークを使用し処理を非同期に実行する。 • 外部のサービス呼び出しながら長時間に渡る処理や、大量のデータを定期的に処理する、といったバッチ操作は、バックグラウンドタスクとしてワーカーロールに分割したりバッチ処理としてプログラム化し、仮想マシンに配置するのが適切。 35

36. ②プロセス間通信 • プロセス間のタスクは、別のコンピュートインスタンスと、共有メモリ、プライベートHTTP、あるいはTCPエンドポイント、非同期メッセージ、名前付きパイプ、データストア、あるいはグローバルキャッシュなどを使用して、コンポーネント間でコミュニケーションを取る必要がある。 • 非常に通信量の多いコンポーネント、あるいは互いに強く依存しているコンポーネントは、コミュニケーションのオーバーヘッドを低減するために同じインスタンスにホストする。 36

37. ③運用、保守性 • コンポーネントによってアップデートとデプロイは、異なった周期を持っている。 • 同じアップデート周期を持つコンポーネントでグループ化を行なうと、よりスムーズに管理できる。 37

38. ③管理とメンテナンス • アプリケーションの管理、モニタリングとメンテナンスにかかるコストと労力は、デプロイされるインスタンスの種類や数、リソースの種類様々なアイテムの範囲にある程度依存する。 • アプリケーションを分割することは、管理、モニタリングとメンテナンスのオーバーヘッドを増加させるが、それらは必ずしも比例関係にはない。 • 管理やメンテナンスは、一般的にプラットフォームが提供するツールやシステム、既存のツールやシステムを利用、拡張することで、自動化、省力化できる。 38

39. ③依存性 • いくつかのコンポーネントは依存関係にあり、分けることが難しいケースがある。 • 同じコンピュートインスタンスにホストすることで、コンポーネント同士のプロセス間コミュニケーションコストを最小限にする利点がある。 39

40. ③実行時のコスト(課金) • クラウド環境にデプロイされた全てのコンピュートインスタンスは、そのリソース量に対して請求される。 • よって、アプリケーションが稼働するインスタンスを分割することは、一般的にランタイムコストを増加させる。 • コストを節約するには、オートスケールを実装することで、コンピュートリソースを適切に管理し、可用性を維持しながら、変動する需要や負荷の対象となるアイテムに関してはランタイムコストを最小限に抑えることができる。 40

41. ④セキュリティ • パーティションがセキュリティ境界にどう影響するかを考慮することは極めて重要。 • セキュリティを高めるためにはアプリケーションを分割させる必要がある。 • 分割したコンポーネントあるいはコンピュートインスタンス毎にタスクを割り当て、独立したコンポーネントやマルチテナント内のサービスを分離する。関連するパターン GateKeeperパターン 41

42. ⑥システム環境 • コンポーネント要件や制限によってホストが異なる。 • 例えば、オペレーティングシステムに特別な設定が必要とされるサードパーティーコンポーネントは、仮想マシン上にホストされる必要がある。 42

43. オートスケーリング • クラウドプラットフォームで自動化したリソース提供 • インスタンスだけでなくストレージ、キャッシュなど全てのリソース利用において検討 • 負荷に対するSLAの準拠 • リソースの最適化 • コストの最適化 • 今後の主戦場の一つ 43

44. オートスケールとは 44 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure

45. スケール方式の実装 • 主要なスケール要因を設定するレスポンス時間、キューの長さ、CPU、メモリ使用率 • 監視コンポーネント • 意思決定ロジック＝閾値を評価 • プロビジョニングと解除 45

46. 自動スケール検討事項「頻度」 • 頻度が多すぎてはいけない＝システムが不安定に平均的なアクセスが増える→インスタンス増やす平均的な負荷が落ちる→インスタンス減る→再度不安定に • 極端な話、インスタンスを減らすことに関しては手動でも良い 46 スケールを減らす頻度が多すぎると都度不安定に。

47. 「ステートレス」にする • 特定のインスタンスでの実行を必要としない • 水平化した、いずれかのインスタンスで処理される「ステートレス」な設計に 47 特定のインスタンスでしか出来ない処理を作るとインスタンスを増やせなくなる。

48. イミュータブル・インフラストラクチャー • 不変なインフラストラクチャー • 一度サーバーを作成したら構成変更を加えない • つまりホスト環境を都度新規作成する。 • いつでも廃棄、生成可能。 • 安定するうえに、スケールしやすい。 48 旧環境は廃棄 Azureだとクラウドサービスがもともとこの思想で作られている(SWAPして廃棄)

49. 「長時間タスク」の対応 • スケールイン、スケールアウトどちらでも影響なくする • スケールの途中でデータが失われることがないように • 大きすぎる場合は、分割する • 分割したうえ、チェックポイントを設け、途中のデータを保持する 49

50. 「スケールユニット」の検討 • 複数のコンポーネントで構成されている場合、 • 一緒にスケールさせる必要のある「スケールユニット」として扱う必要がある。 • 例）１万ユーザー増えるたびに1WEBサイト、２ワーカーロール等。 50

51. Azureにおけるオートスケール 51 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure

52. スケジュールによるオートスケールの設定 52 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure

53. Azureクラウドサービスのオートスケールの設定 53 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure

54. Enterprise Library • Microsoft Enterprise Library Autoscaling Application Block • SQL Databaseのサイズ変更やストレージのアカウント追加など、ポータルが提供する自動スケール以外のこともできる • http://msdn.microsoft.com/en-us/library/hh680892%28v=pandp.50%29.aspx 54

55. Azure Management Library • Microsoft Azure Monitoring Services Management Library • Nugetからダウンロード可能 • https://www.nuget.org/packages/Microsoft.WindowsAzure.Management.Monitoring/0.10.2-preview • http://blogs.msdn.com/b/cie/archive/2014/02/20/how-to-use-windows-azure-monitoring-services- management-library-to-create-an-autoscale-rule.aspx 55

56. アンケートよろしくお願いします • http://enq-maker.com/33yr0ws • １，２分で終了します。 56

JAZUG CDP勉強会第二回クラウドデザインパターン超入門＝「コンピューティングの分割、配置」「オートスケーリング」

You are reading a preview.

Check these out next

JAZUG CDP勉強会第二回クラウドデザインパターン超入門＝「コンピューティングの分割、配置」「オートスケーリング」

More Related Content

Slideshows for you (8)

Similar to JAZUG CDP勉強会第二回クラウドデザインパターン超入門＝「コンピューティングの分割、配置」「オートスケーリング」 (20)

More from Keiichi Hashimoto (13)

Recently uploaded (20)