JAZUG CDP勉強会第二回クラウドデザインパターン超入門＝「コンピューティングの分割、配置」 「オートスケーリング」
•
13 recomendaciones•3,448 vistas
7/30 の 第１回 クラウドデザインパターン勉強会 の好評を受け、第2回を開催します 今回2回目は、Compute Partitioning ガイダンスと、補正トランザクションを中心にいくつかのパターンを紹介します。 今後基礎的な内容を中心に、何回かに分けて内容を紹介していく予定です。
Recomendados
Más contenido relacionado
La actualidad más candente
Similar a JAZUG CDP勉強会第二回クラウドデザインパターン超入門＝「コンピューティングの分割、配置」 「オートスケーリング」
Similar a JAZUG CDP勉強会第二回クラウドデザインパターン超入門＝「コンピューティングの分割、配置」 「オートスケーリング」 (20)
Más de Keiichi Hashimoto
Más de Keiichi Hashimoto (13)
JAZUG CDP勉強会第二回クラウドデザインパターン超入門＝「コンピューティングの分割、配置」 「オートスケーリング」
- 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 一緒に運営してくれるメンバーを募集中です。
- 8. JAZUG４周年関連イベント 9月13日 JAZUG札幌支部第4回勉強会feat.CLR/H～デプロイ王子からAzureを学ぼう！ 9月20日 （同日開催） JAZUG 福岡（ふくあず） MSコミュニティ合同勉強会 & JAZUG4周年記念連動 9月27日 関西Azure研究会/JAZUG 秋のAzure収穫祭
- 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
- 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
- 21. 非機能要件とコンピューティング分割の考慮 ①可用性 ②性能／拡張性(パフォーマンスとスケーラビリティ) ③運用／保守性(デプロイと更新) ④セキュリティ ⑤移行性 ⑥システム環境、エコロジー 21
- 22. ①可用性Availability(アベイラビリティ） • システムが継続して稼働できる能力 • 適切なコンピューティングリソースの割当 • SLAの順守＝最小限のダウンタイム • デザインパターンだと以下と関連 • Health Endpoint Monitoring Pattern • Queue-based Load Leveling Pattern • Throttling Pattern • Multiple Datacenter Deployment Guidance 22
- 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
- 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
- 33. Azureインスタンスのスケールアップ 33 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure
- 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
- 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