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

「オートスケーリング」

Keiichi Hashimoto

@k1hash

平日夜で、ひゃ、130名？

皆さんどのへんにモチベーションがあって、何が聞きたいのか①近江さん ②平日夜早く帰りたくない ③職場の帰宅理由

①一方的に難しい用語でなじられたい ②

アンケートよろしくお願いします

• http://enq-maker.com/33yr0ws

• １，２分で終了します。

3

スピーカー紹介

橋本 圭一シグマコンサルティング株式会社 代表取締役

Cloudlive株式会社 代表取締役 副社長

Micorosoft Windows Azure MVP(2010-2012)Sitecore CMS MVP(2011-2014)クラウド利用促進機構 アドバイザー第四回おバカアプリ選手権 優勝(第二回、第五回参加)

Microsoft Azure、CMS、ECをベースとして、サービスの開発に従事。クラウドでは、他の企業と協力しての新規事業開発。

JAZUGのご紹介

Japan Azure User Group略称：JAZUG(じゃずゆーじー)

コミュニティ活動概要:「Azureを通じて、技術、交流、実ビジネスを楽しむ。」“ちょっと興味がある=ゆるふわな方”から“実ビジネスで使うんだよね”な方まで大歓迎！ゆるふわコミュニティです。

GROUP はFBで。Japan Azure User Group

https://www.facebook.com/groups/jazug/

大阪(関西Azure研究会)、福岡(ふくあず)、仙台、名古屋、札幌、Azureしなの

Twitter: #jazug

一緒に運営してくれるメンバーを募集中です。

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

6

JAZUG４周年イベント

DoorKeeperよりご参加ください。

http://jazug.doorkeeper.jp/events/13866

2014 9/20(Sat)

JAZUG４周年関連イベント

9月13日

JAZUG札幌支部第4回勉強会feat.CLR/H～デプロイ王子からAzureを学ぼう！

9月20日 （同日開催）

JAZUG 福岡（ふくあず） MSコミュニティ合同勉強会 & JAZUG4周年記念連動

9月27日

関西Azure研究会/JAZUG 秋のAzure収穫祭

本よろしくです！

クラウドデザインパターン Azureを例としたクラウドアフリケーション設計の手引き

http://amzn.to/1oTJNVH

15人のコミュニティメンバーで

半泣きになりながら監訳しました

9

今日のお品書き

• パターンではなく、ガイダンスの方になります。

• とても入門よりです。

• Compute Partitioning Guidance

コンピューティングの分割

• Autoscaling Guidance

オートスケール・ガイダンス

社内や、勉強会で皆さんが学んだことを紹介できるようになることをゴールにしたいと思っています。

10

Compute Partitioning Guidance

• コンピューティングの分割、配置

• 論理的な配置、物理的な配置

11

Autoscaling Guidance

• オートスケールガイダンス

12

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

AzureスライドMS公式のAzureスライド

(IaaS、VPN、AD、スケールなど多岐に渡って用意)http://www.slideshare.net/MicrosoftAzure_Japan/

社内での紹介、勉強会などで使えます。

13

本日のガイダンス要旨

• コンピューティングを適切に分割することは、

クラウド上におけるアプリケーションの非機能要件を

満たすことに、大きく影響する。

• 分割したコンポーネント毎にリソースを検討し、必要に応じて自動スケールする。効果的にスケールするためには、この分割が重要である。

14

分割とは＝論理的な分割

• フロントのWEBサイト

• 管理用のWEBサイト

• API

• バックグラウンド処理、バッチ

• キャッシュ

• ファイルストレージ

• 永続的なデータストア

15

論理的な分割の例

16

Microsoft Azure データセンター

Webロール

Webロール

一般ユーザー

ロードバランサー

フロントエンド

キャッシュ

バックエンド

Workerロール

BLOB

SQL Database

ロードバランサー

管理サイト

Webサイト

管理ユーザー

キュー

CDN

Azure Symbols/Icon Set

17

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

論理的な分割(フロント側の細分化)

• フロントのWEBサイト

• キャッシュが有効なページ

• キャッシュもアプリ全体と、ユーザー別など

• キャッシュが無効なページ

• (検索機能など)処理負荷が重いページ

→ARRなどを用いて、同一URLで稼働するインスタンスを分けたりする

18

フロント＝論理的な分割の例

19

Microsoft Azure データセンター

一般ユーザー

ロードバランサー

フロントエンド(HTMLキャッシュ)

EC-Portal

EC-Portal

検索(非キャッシュ)

Webロール

Webロール

Webロール

ARR(URLリライト)を利用して、別のインスタンスで処理する。

カート＝特定の発売日以外負荷がない検索＝常に負荷がある

カート(非キャッシュ)

クラウドにおける論理的な分割

• コンピューティング、キャッシュ、ストレージ、DBなど論理的な分割とクラウドプラットフォームが用意するサービスが対比しているケースが多い。よって論理的な分割は慣れの問題ともいえる。

• これに非機能要件を加えて、落とし込んでいく。

20

非機能要件とコンピューティング分割の考慮

①可用性

②性能／拡張性(パフォーマンスとスケーラビリティ)

③運用／保守性(デプロイと更新)

④セキュリティ

⑤移行性

⑥システム環境、エコロジー

21

①可用性Availability(アベイラビリティ）

• システムが継続して稼働できる能力

• 適切なコンピューティングリソースの割当

• SLAの順守＝最小限のダウンタイム

• デザインパターンだと以下と関連

• Health Endpoint Monitoring Pattern

• Queue-based Load Leveling Pattern

• Throttling Pattern

• Multiple Datacenter Deployment Guidance

22

デザインパターンのサンプルコード

http://www.microsoft.com/en-us/download/details.aspx?id=4167323

①可用性-クラウドの場合

• クラウドで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

①可用性-クラウドの場合

• 例えば、平日日中のみ保証するもの

• SLAが99％など年間87時間は止まって良いもの

• 上記に近い条件のクリティカルでないサービス

• は、この要件を考慮せず、プラットフォームメンテナンスで深夜に止まる、物理的な障害があった場合のプロビジョニング時間を許容することもできる。

25

①可用性-Azureの場合

• コンピューティングサービスで可用性の担保が異なる

26

仮想マシン(IaaS)の場合、負荷分散セットで複数の仮想マシンでエンドポイントを構成する必要がある。プラットフォームメンテナンス等でダウンする場合がある。また、台数の制限はない。

クラウドサービス(PaaS)の場合、複数のインスタンスでエンドポイントを構成する必要がある。プラットフォームメンテナンス等でダウンする場合がある。また、台数の制限はない。

WEBサイト(PaaS)の場合、単一のインスタンスでも可用性を保証している。台数の制限がある。L(4core)を10台まで。

サブスクリプションとしてはコア数制限があるのでコア数を大幅に増やす場合制限解除する必要がある。

①可用性-Azureの場合(DR)

• 利用しているサービスでDR対策の実現が異なる

• 自動で切り替わる、自前で切り替える

• ストレージ(地理冗長、読み取り地理冗長、ゾーン冗長)

• コンピューティング

• トラフィックマネージャー

• SQL Database(Premium-ActiveGeoReplication)

(Basic,Standard)

27

②性能／拡張性

• 必要とされる性能に対して、適切なコンピューティングリソースを用意する必要がある。

• ３秒以内のレスポンス

• 15秒以上ウエイトしないエラーを返す(処理をためない)

• スケールアップ、スケールアウトで性能を叶える

• 負荷に対するスケール対応、自動スケール

• 各サービスを効果的に使う ストレージ、CDN、キャッシュ

28

スケールアップとスケールアウト

29

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

ストレージを活用したハイパフォーマンス

• 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

31

②適切なリソース、サイズ

• アプリケーション内の各コンポーネントはそれぞれ異なるメモリー、バンド幅、CPUなどのリソース必要条件を持つ。

• アプリケーション上のそれぞれのパートに対して、要件にあったホスティング、インスタンスのサイズを選ぶ。

32

Azureインスタンスのスケールアップ

33

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

②適切なリソース・サイズ

• 需要が大幅に変動した場合は、より小さいサイズのホストへ変更する。閑散期。コストメリット的に重要。

• オートスケーリングを通して、インスタンスの増減を随時、適切に行う。

34

②性能＝バックグラウンドタスク

• アプリケーションがバックグラウンド処理を実行する場合、これらのタスクは分割の候補として適することが多い。

• バックグラウンド タスクが一般的にむいている処理は、多くのI/Oやネットワークを使用し処理を非同期に実行する。

• 外部のサービス呼び出しながら長時間に渡る処理や、大量のデータを定期的に処理する、といったバッチ操作は、

バックグラウンドタスクとしてワーカーロールに分割したりバッチ処理としてプログラム化し、仮想マシンに配置するの

が適切。

35

②プロセス間通信

• プロセス間のタスクは、別のコンピュート インスタンスと、共有メモリ、プライベートHTTP、あるいはTCPエンドポイント、非同期メッセージ、名前付きパイプ、データストア、あるいはグローバ ル キャッシュなどを使用して、コンポーネント間でコミュニケーションを取る必要がある。

• 非常に通信量の多いコンポーネント、あるいは互いに強く依存しているコンポーネントは、コミュニケーションのオーバーヘッドを低減するために同じインスタンスにホストする。

36

③運用、保守性

• コンポーネントによってアップデートとデプロイは、異なった周期を持っている。

• 同じアップデート周期を持つコンポーネントでグループ化を行なうと、よりスムーズに管理できる。

37

③管理とメンテナンス

• アプリケーションの管理、モニタリングとメンテナンスにかかるコストと労力は、デプロイされるインスタンスの種類や数、リソースの種類様々なアイテムの範囲にある程度依存する。

• アプリケーションを分割することは、管理、モニタリングとメンテナンスのオーバーヘッドを増加させるが、それらは必ずしも比例関係にはない。

• 管理やメンテナンスは、一般的にプラットフォームが提供するツールやシステム、既存のツールやシステムを利用、拡張することで、自動化、省力化できる。

38

③依存性

• いくつかのコンポーネントは依存関係にあり、分けることが難しいケースがある。

• 同じコンピュート インスタンスにホストすることで、コンポーネント同士のプロセス間コミュニケーションコストを最小限にする利点がある。

39

③実行時のコスト(課金)

• クラウド環境にデプロイされた全てのコンピュート インスタンスは、そのリソース量に対して請求される。

• よって、アプリケーションが稼働するインスタンスを分割することは、一般的にランタイムコストを増加させる。

• コストを節約するには、オートスケールを実装することで、コンピュートリソースを適切に管理し、可用性を維持しながら、変動する需要や負荷の対象となるアイテムに関してはランタイム コストを最小限に抑えることができる。

40

④セキュリティ

• パーティションがセキュリティ境界にどう影響するかを考慮することは極めて重要。

• セキュリティを高めるためにはアプリケーションを分割させる必要がある。

• 分割したコンポーネントあるいはコンピュート インスタンス毎にタスクを割り当て、独立したコンポーネントやマルチテナント内のサービスを分離する。

関連するパターン GateKeeperパターン

41

⑥システム環境

• コンポーネント要件や制限によってホストが異なる。

• 例えば、オペレーティングシステムに特別な設定が必要とされるサード パーティー コンポーネントは、仮想マシン上にホストされる必要がある。

42

オートスケーリング

• クラウドプラットフォームで自動化したリソース提供

• インスタンスだけでなくストレージ、キャッシュなど全てのリソース利用において検討

• 負荷に対するSLAの準拠

• リソースの最適化

• コストの最適化

• 今後の主戦場の一つ

43

オートスケールとは

44

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

スケール方式の実装

• 主要なスケール要因を設定する

レスポンス時間、キューの長さ、CPU、メモリ使用率

• 監視コンポーネント

• 意思決定ロジック＝閾値を評価

• プロビジョニングと解除

45

自動スケール検討事項「頻度」• 頻度が多すぎてはいけない＝システムが不安定に

平均的なアクセスが増える→インスタンス増やす

平均的な負荷が落ちる→インスタンス減る→再度不安定に

• 極端な話、インスタンスを減らすことに関しては手動でも良い

46

スケールを減らす頻度が多すぎると都度不安定に。

「ステートレス」にする

• 特定のインスタンスでの実行を必要としない

• 水平化した、いずれかのインスタンスで処理される「ステートレス」な設計に

47

特定のインスタンスでしか出来ない処理を作ると

インスタンスを増やせなくなる。

イミュータブル・インフラストラクチャー• 不変なインフラストラクチャー

• 一度サーバーを作成したら構成変更を加えない

• つまりホスト環境を都度新規作成する。

• いつでも廃棄、生成可能。

• 安定するうえに、スケールしやすい。

48

旧環境は廃棄

Azureだとクラウドサービスがもともとこの思想で作られて

いる(SWAPして廃棄)

「長時間タスク」の対応

• スケールイン、スケールアウトどちらでも影響なくする

• スケールの途中でデータが失われることがないように

• 大きすぎる場合は、分割する

• 分割したうえ、チェックポイントを設け、途中のデータを保持する

49

「スケールユニット」の検討

• 複数のコンポーネントで構成されている場合、

• 一緒にスケールさせる必要のある「スケールユニット」として扱う必要がある。

• 例）１万ユーザー増えるたびに1WEBサイト、２ワーカーロール等。

50

Azureにおけるオートスケール

51

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

スケジュールによるオートスケールの設定

52

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

Azureクラウドサービスのオートスケールの設定

53

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

Enterprise Library

• Microsoft Enterprise Library Autoscaling Application Block

• SQL Databaseのサイズ変更やストレージのアカウント追加など、ポータルが提供する自動スケール以外のこともできる

• http://msdn.microsoft.com/en-us/library/hh680892%28v=pandp.50%29.aspx

54

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

アンケートよろしくお願いします

• http://enq-maker.com/33yr0ws

• １，２分で終了します。

56