CDP勉強会第二回
クラウドデザインパターン超入門=
「コンピューティングの分割、配置」
「オートスケーリング」
Keiichi Hashimoto
@k1hash
平日夜で、ひゃ、130名?
皆さんどのへんにモチベーションがあって、何が聞きたいのか
①近江さん ②平日夜早く帰りたくない ③職場の帰宅理由
①一方的に難しい用語でなじられたい ②
アンケートよろしくお願いします
• http://enq-maker.com/33yr0ws
• 1,2分で終了します。
3
スピーカー紹介
橋本 圭一
シグマコンサルティング株式会社 代表取締役
Cloudlive株式会社 代表取締役 副社長
Micorosoft Windows Azure MVP(2010-2012)
Sitecore CMS MVP(2011-...
JAZUGのご紹介
 Japan Azure User Group
略称:JAZUG(じゃずゆーじー)
 コミュニティ活動概要:
「Azureを通じて、技術、交流、実ビジネスを楽しむ。」“ちょっと興味がある
=ゆるふわな方”から“実ビジネス...
JAZUGのHPから
Facebookグループへの
ご参加お願いします。
6
JAZUG4周年イベント
 DoorKeeperよりご参加ください。
 http://jazug.doorkeeper.jp/events/13866
 2014 9/20(Sat)
JAZUG4周年関連イベント
9月13日
JAZUG札幌支部第4回勉強会feat.CLR/H~デプロイ王子からAzureを学ぼう!
9月20日 (同日開催)
JAZUG 福岡(ふくあず) MSコミュニティ合同勉強会 & JAZUG4周年記念連動...
本よろしくです!
クラウドデザインパターン Azureを例としたクラウドアフ
リケーション設計の手引き
http://amzn.to/1oTJNVH
15人のコミュニティメンバーで
半泣きになりながら監訳しました
9
今日のお品書き
• パターンではなく、ガイダンスの方になります。
• とても入門よりです。
• Compute Partitioning Guidance
コンピューティングの分割
• Autoscaling Guidance
オートスケール・...
Compute Partitioning Guidance
• コンピューティングの分割、配置
• 論理的な配置、物理的な配置
11
Autoscaling Guidance
• オートスケールガイダンス
12
• Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用
http://www.slideshare.n...
Azureスライド
MS公式のAzureスライド
(IaaS、VPN、AD、スケールなど多岐に渡って用意)
http://www.slideshare.net/MicrosoftAzure_Japan/
社内での紹介、勉強会などで使えます。
13
本日のガイダンス要旨
• コンピューティングを適切に分割することは、
クラウド上におけるアプリケーションの非機能要件を
満たすことに、大きく影響する。
• 分割したコンポーネント毎にリソースを検討し、必要に
応じて自動スケールする。効果的にスケ...
分割とは=論理的な分割
• フロントのWEBサイト
• 管理用のWEBサイト
• API
• バックグラウンド処理、バッチ
• キャッシュ
• ファイルストレージ
• 永続的なデータストア
15
論理的な分割の例
16
Microsoft Azure データセンター
Webロール
Webロール
一般ユーザー
ロードバランサー
フロント
エンド
キャッシュ
バック
エンド
Workerロール
BLOB
SQL Database
ロードバラ...
Azure Symbols/Icon Set
17
• 設計や構成図作成に便利なアイコン集
http://www.microsoft.com/en-us/download/details.aspx?id=41937
論理的な分割(フロント側の細分化)
• フロントのWEBサイト
• キャッシュが有効なページ
• キャッシュもアプリ全体と、ユーザー別など
• キャッシュが無効なページ
• (検索機能など)処理負荷が重いページ
→ARRなどを用いて、同一URL...
フロント=論理的な分割の例
19
Microsoft Azure データセンター
一般ユーザー
ロードバランサー
フロントエンド
(HTMLキャッシュ)
EC-Portal
EC-Portal
検索
(非キャッシュ)
Webロール
Webロール...
クラウドにおける論理的な分割
• コンピューティング、キャッシュ、ストレージ、DBなど
論理的な分割とクラウドプラットフォームが用意する
サービスが対比しているケースが多い。よって論理的な
分割は慣れの問題ともいえる。
• これに非機能要件を加...
非機能要件とコンピューティング分割の考慮
①可用性
②性能/拡張性(パフォーマンスとスケーラビリティ)
③運用/保守性(デプロイと更新)
④セキュリティ
⑤移行性
⑥システム環境、エコロジー
21
①可用性Availability(アベイラビリティ)
• システムが継続して稼働できる能力
• 適切なコンピューティングリソースの割当
• SLAの順守=最小限のダウンタイム
• デザインパターンだと以下と関連
• Health Endpoin...
デザインパターンのサンプルコード
http://www.microsoft.com/en-us/download/details.aspx?id=41673
23
①可用性-クラウドの場合
• クラウドでSLA(可用性など品質保証)が異なる
• また、品質保証しているが、未達時の返金のみ約束
Azureの場合はSLAは、以下に詳しく載っています。
年間停止時間
稼働率 動作不能時間
99.9999% 32...
①可用性-クラウドの場合
• 例えば、平日日中のみ保証するもの
• SLAが99%など年間87時間は止まって良いもの
• 上記に近い条件のクリティカルでないサービス
• は、この要件を考慮せず、プラットフォームメンテナン
スで深夜に止まる、物理...
①可用性-Azureの場合
• コンピューティングサービスで可用性の担保が異なる
26
仮想マシン(IaaS)の場合、負荷分散セットで複数の仮想マシンでエンドポイントを構成
する必要がある。プラットフォームメンテナンス等でダウンする場合がある。...
①可用性-Azureの場合(DR)
• 利用しているサービスでDR対策の実現が異なる
• 自動で切り替わる、自前で切り替える
• ストレージ(地理冗長、読み取り地理冗長、ゾーン冗長)
• コンピューティング
• トラフィックマネージャー
• S...
②性能/拡張性
• 必要とされる性能に対して、適切なコンピューティングリ
ソースを用意する必要がある。
• 3秒以内のレスポンス
• 15秒以上ウエイトしないエラーを返す(処理をためない)
• スケールアップ、スケールアウトで性能を叶える
• ...
スケールアップとスケールアウト
29
• Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用
http://www.slideshare.net/MicrosoftAzure_Ja...
ストレージを活用したハイパフォーマンス
• Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用
http://www.slideshare.net/MicrosoftAzure_J...
キャッシュ
• Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用
http://www.slideshare.net/MicrosoftAzure_Japan/s09-micro...
②適切なリソース、サイズ
• アプリケーション内の各コンポーネントはそれぞれ異なる
メモリー、バンド幅、CPUなどのリソース必要条件を持つ。
• アプリケーション上のそれぞれのパートに対して、要件に
あったホスティング、インスタンスのサイズを選...
Azureインスタンスのスケールアップ
33
• Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用
http://www.slideshare.net/MicrosoftAzur...
②適切なリソース・サイズ
• 需要が大幅に変動した場合は、より小さいサイズのホス
トへ変更する。閑散期。コストメリット的に重要。
• オートスケーリングを通して、インスタンスの増減を随
時、適切に行う。
34
②性能=バックグラウンドタスク
• アプリケーションがバックグラウンド処理を実行する場合、
これらのタスクは分割の候補として適することが多い。
• バックグラウンド タスクが一般的にむいている処理は、
多くのI/Oやネットワークを使用し処理を非...
②プロセス間通信
• プロセス間のタスクは、別のコンピュート インスタンスと、
共有メモリ、プライベートHTTP、あるいはTCPエンドポ
イント、非同期メッセージ、名前付きパイプ、データスト
ア、あるいはグローバ ル キャッシュなどを使用して、...
③運用、保守性
• コンポーネントによってアップデートとデプロイは、異
なった周期を持っている。
• 同じアップデート周期を持つコンポーネントでグループ
化を行なうと、よりスムーズに管理できる。
37
③管理とメンテナンス
• アプリケーションの管理、モニタリングとメンテナンスにか
かるコストと労力は、デプロイされるインスタンスの種類や
数、リソースの種類様々なアイテムの範囲にある程度依存す
る。
• アプリケーションを分割することは、管理、...
③依存性
• いくつかのコンポーネントは依存関係にあり、分けるこ
とが難しいケースがある。
• 同じコンピュート インスタンスにホストすることで、
コンポーネント同士のプロセス間コミュニケーションコ
ストを最小限にする利点がある。
39
③実行時のコスト(課金)
• クラウド環境にデプロイされた全てのコンピュート インス
タンスは、そのリソース量に対して請求される。
• よって、アプリケーションが稼働するインスタンスを分割
することは、一般的にランタイムコストを増加させる。
•...
④セキュリティ
• パーティションがセキュリティ境界にどう影響するかを考慮す
ることは極めて重要。
• セキュリティを高めるためにはアプリケーションを分割させる
必要がある。
• 分割したコンポーネントあるいはコンピュート インスタンス毎
にタ...
⑥システム環境
• コンポーネント要件や制限によってホストが異なる。
• 例えば、オペレーティングシステムに特別な設定が必要
とされるサード パーティー コンポーネントは、仮想マシ
ン上にホストされる必要がある。
42
オートスケーリング
• クラウドプラットフォームで自動化したリソース提供
• インスタンスだけでなくストレージ、キャッシュなど全
てのリソース利用において検討
• 負荷に対するSLAの準拠
• リソースの最適化
• コストの最適化
• 今後の主...
オートスケールとは
44
• Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用
http://www.slideshare.net/MicrosoftAzure_Japan/s0...
スケール方式の実装
• 主要なスケール要因を設定する
レスポンス時間、キューの長さ、CPU、メモリ使用率
• 監視コンポーネント
• 意思決定ロジック=閾値を評価
• プロビジョニングと解除
45
自動スケール検討事項「頻度」
• 頻度が多すぎてはいけない=システムが不安定に
平均的なアクセスが増える→インスタンス増やす
平均的な負荷が落ちる→インスタンス減る→再度不安定に
• 極端な話、インスタンスを減らすことに関しては手動でも
良い
...
「ステートレス」にする
• 特定のインスタンスでの実行を必要としない
• 水平化した、いずれかのインスタンスで処理される「ス
テートレス」な設計に
47
特定のインスタンスでしか
出来ない処理を作ると
インスタンスを増やせなくなる。
イミュータブル・インフラストラクチャー
• 不変なインフラストラクチャー
• 一度サーバーを作成したら構成変更を加えない
• つまりホスト環境を都度新規作成する。
• いつでも廃棄、生成可能。
• 安定するうえに、スケールしやすい。
48
旧環...
「長時間タスク」の対応
• スケールイン、スケールアウトどちらでも影響なくする
• スケールの途中でデータが失われることがないように
• 大きすぎる場合は、分割する
• 分割したうえ、チェックポイントを設け、途中のデータ
を保持する
49
「スケールユニット」の検討
• 複数のコンポーネントで構成されている場合、
• 一緒にスケールさせる必要のある「スケールユニット」
として扱う必要がある。
• 例)1万ユーザー増えるたびに1WEBサイト、2ワー
カーロール等。
50
Azureにおけるオートスケール
51
• Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用
http://www.slideshare.net/MicrosoftAzure_J...
スケジュールによるオートスケールの設定
52
• Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用
http://www.slideshare.net/MicrosoftAzur...
Azureクラウドサービスの
オートスケールの設定
53
• Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用
http://www.slideshare.net/Microso...
Enterprise Library
• Microsoft Enterprise Library Autoscaling Application
Block
• SQL Databaseのサイズ変更やストレージのアカウント
追加など、ポータル...
Azure Management Library
• Microsoft Azure Monitoring Services Management
Library
• Nugetからダウンロード可能
• https://www.nuget.or...
アンケートよろしくお願いします
• http://enq-maker.com/33yr0ws
• 1,2分で終了します。
56
Upcoming SlideShare
Loading in …5
×

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

1,988 views
1,726 views

Published on

7/30 の 第1回 クラウドデザインパターン勉強会 の好評を受け、第2回を開催します

今回2回目は、Compute Partitioning ガイダンスと、補正トランザクションを中心にいくつかのパターンを紹介します。
今後基礎的な内容を中心に、何回かに分けて内容を紹介していく予定です。

Published in: Internet
0 Comments
13 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,988
On SlideShare
0
From Embeds
0
Number of Embeds
33
Actions
Shares
0
Downloads
51
Comments
0
Likes
13
Embeds 0
No embeds

No notes for slide

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

  1. 1. CDP勉強会第二回 クラウドデザインパターン超入門= 「コンピューティングの分割、配置」 「オートスケーリング」 Keiichi Hashimoto @k1hash
  2. 2. 平日夜で、ひゃ、130名? 皆さんどのへんにモチベーションがあって、何が聞きたいのか ①近江さん ②平日夜早く帰りたくない ③職場の帰宅理由 ①一方的に難しい用語でなじられたい ②
  3. 3. アンケートよろしくお願いします • http://enq-maker.com/33yr0ws • 1,2分で終了します。 3
  4. 4. スピーカー紹介 橋本 圭一 シグマコンサルティング株式会社 代表取締役 Cloudlive株式会社 代表取締役 副社長 Micorosoft Windows Azure MVP(2010-2012) Sitecore CMS MVP(2011-2014) クラウド利用促進機構 アドバイザー 第四回おバカアプリ選手権 優勝(第二回、第五回参加) Microsoft Azure、CMS、ECをベースとして、サービスの開発に従事。 クラウドでは、他の企業と協力しての新規事業開発。
  5. 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. 6. JAZUGのHPから Facebookグループへの ご参加お願いします。 6
  7. 7. JAZUG4周年イベント  DoorKeeperよりご参加ください。  http://jazug.doorkeeper.jp/events/13866  2014 9/20(Sat)
  8. 8. JAZUG4周年関連イベント 9月13日 JAZUG札幌支部第4回勉強会feat.CLR/H~デプロイ王子からAzureを学ぼう! 9月20日 (同日開催) JAZUG 福岡(ふくあず) MSコミュニティ合同勉強会 & JAZUG4周年記念連動 9月27日 関西Azure研究会/JAZUG 秋のAzure収穫祭
  9. 9. 本よろしくです! クラウドデザインパターン Azureを例としたクラウドアフ リケーション設計の手引き http://amzn.to/1oTJNVH 15人のコミュニティメンバーで 半泣きになりながら監訳しました 9
  10. 10. 今日のお品書き • パターンではなく、ガイダンスの方になります。 • とても入門よりです。 • Compute Partitioning Guidance コンピューティングの分割 • Autoscaling Guidance オートスケール・ガイダンス 社内や、勉強会で皆さんが学んだことを紹介できるように なることをゴールにしたいと思っています。 10
  11. 11. Compute Partitioning Guidance • コンピューティングの分割、配置 • 論理的な配置、物理的な配置 11
  12. 12. Autoscaling Guidance • オートスケールガイダンス 12 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure
  13. 13. Azureスライド MS公式のAzureスライド (IaaS、VPN、AD、スケールなど多岐に渡って用意) http://www.slideshare.net/MicrosoftAzure_Japan/ 社内での紹介、勉強会などで使えます。 13
  14. 14. 本日のガイダンス要旨 • コンピューティングを適切に分割することは、 クラウド上におけるアプリケーションの非機能要件を 満たすことに、大きく影響する。 • 分割したコンポーネント毎にリソースを検討し、必要に 応じて自動スケールする。効果的にスケールするために は、この分割が重要である。 14
  15. 15. 分割とは=論理的な分割 • フロントのWEBサイト • 管理用のWEBサイト • API • バックグラウンド処理、バッチ • キャッシュ • ファイルストレージ • 永続的なデータストア 15
  16. 16. 論理的な分割の例 16 Microsoft Azure データセンター Webロール Webロール 一般ユーザー ロードバランサー フロント エンド キャッシュ バック エンド Workerロール BLOB SQL Database ロードバランサー 管理サイト Webサイト 管理ユーザー キュー CDN
  17. 17. Azure Symbols/Icon Set 17 • 設計や構成図作成に便利なアイコン集 http://www.microsoft.com/en-us/download/details.aspx?id=41937
  18. 18. 論理的な分割(フロント側の細分化) • フロントのWEBサイト • キャッシュが有効なページ • キャッシュもアプリ全体と、ユーザー別など • キャッシュが無効なページ • (検索機能など)処理負荷が重いページ →ARRなどを用いて、同一URLで稼働するインスタンスを 分けたりする 18
  19. 19. フロント=論理的な分割の例 19 Microsoft Azure データセンター 一般ユーザー ロードバランサー フロントエンド (HTMLキャッシュ) EC-Portal EC-Portal 検索 (非キャッシュ) Webロール Webロール Webロール ARR(URLリライト)を利用して、 別のインスタンスで処理する。 カート=特定の発売日以外負荷がない 検索=常に負荷がある カート(非キャッシュ)
  20. 20. クラウドにおける論理的な分割 • コンピューティング、キャッシュ、ストレージ、DBなど 論理的な分割とクラウドプラットフォームが用意する サービスが対比しているケースが多い。よって論理的な 分割は慣れの問題ともいえる。 • これに非機能要件を加えて、落とし込んでいく。 20
  21. 21. 非機能要件とコンピューティング分割の考慮 ①可用性 ②性能/拡張性(パフォーマンスとスケーラビリティ) ③運用/保守性(デプロイと更新) ④セキュリティ ⑤移行性 ⑥システム環境、エコロジー 21
  22. 22. ①可用性Availability(アベイラビリティ) • システムが継続して稼働できる能力 • 適切なコンピューティングリソースの割当 • SLAの順守=最小限のダウンタイム • デザインパターンだと以下と関連 • Health Endpoint Monitoring Pattern • Queue-based Load Leveling Pattern • Throttling Pattern • Multiple Datacenter Deployment Guidance 22
  23. 23. デザインパターンのサンプルコード http://www.microsoft.com/en-us/download/details.aspx?id=41673 23
  24. 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. 25. ①可用性-クラウドの場合 • 例えば、平日日中のみ保証するもの • SLAが99%など年間87時間は止まって良いもの • 上記に近い条件のクリティカルでないサービス • は、この要件を考慮せず、プラットフォームメンテナン スで深夜に止まる、物理的な障害があった場合のプロビ ジョニング時間を許容することもできる。 25
  26. 26. ①可用性-Azureの場合 • コンピューティングサービスで可用性の担保が異なる 26 仮想マシン(IaaS)の場合、負荷分散セットで複数の仮想マシンでエンドポイントを構成 する必要がある。プラットフォームメンテナンス等でダウンする場合がある。 また、台数の制限はない。 クラウドサービス(PaaS)の場合、複数のインスタンスでエンドポイントを構成する 必要がある。プラットフォームメンテナンス等でダウンする場合がある。 また、台数の制限はない。 WEBサイト(PaaS)の場合、単一のインスタンスでも可用性を保証している。 台数の制限がある。L(4core)を10台まで。 サブスクリプションとしてはコア数制限があるのでコア数を大幅に増やす場合 制限解除する必要がある。
  27. 27. ①可用性-Azureの場合(DR) • 利用しているサービスでDR対策の実現が異なる • 自動で切り替わる、自前で切り替える • ストレージ(地理冗長、読み取り地理冗長、ゾーン冗長) • コンピューティング • トラフィックマネージャー • SQL Database(Premium-ActiveGeoReplication) (Basic,Standard) 27
  28. 28. ②性能/拡張性 • 必要とされる性能に対して、適切なコンピューティングリ ソースを用意する必要がある。 • 3秒以内のレスポンス • 15秒以上ウエイトしないエラーを返す(処理をためない) • スケールアップ、スケールアウトで性能を叶える • 負荷に対するスケール対応、自動スケール • 各サービスを効果的に使う ストレージ、CDN、キャッシュ 28
  29. 29. スケールアップとスケールアウト 29 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure
  30. 30. ストレージを活用したハイパフォーマンス • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure 30
  31. 31. キャッシュ • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure 31
  32. 32. ②適切なリソース、サイズ • アプリケーション内の各コンポーネントはそれぞれ異なる メモリー、バンド幅、CPUなどのリソース必要条件を持つ。 • アプリケーション上のそれぞれのパートに対して、要件に あったホスティング、インスタンスのサイズを選ぶ。 32
  33. 33. Azureインスタンスのスケールアップ 33 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure
  34. 34. ②適切なリソース・サイズ • 需要が大幅に変動した場合は、より小さいサイズのホス トへ変更する。閑散期。コストメリット的に重要。 • オートスケーリングを通して、インスタンスの増減を随 時、適切に行う。 34
  35. 35. ②性能=バックグラウンドタスク • アプリケーションがバックグラウンド処理を実行する場合、 これらのタスクは分割の候補として適することが多い。 • バックグラウンド タスクが一般的にむいている処理は、 多くのI/Oやネットワークを使用し処理を非同期に実行する。 • 外部のサービス呼び出しながら長時間に渡る処理や、大量の データを定期的に処理する、といったバッチ操作は、 バックグラウンドタスクとしてワーカーロールに分割したり バッチ処理としてプログラム化し、仮想マシンに配置するの が適切。 35
  36. 36. ②プロセス間通信 • プロセス間のタスクは、別のコンピュート インスタンスと、 共有メモリ、プライベートHTTP、あるいはTCPエンドポ イント、非同期メッセージ、名前付きパイプ、データスト ア、あるいはグローバ ル キャッシュなどを使用して、コ ンポーネント間でコミュニケーションを取る必要がある。 • 非常に通信量の多いコンポーネント、あるいは互いに強く 依存しているコンポーネントは、コミュニケーションの オーバーヘッドを低減するために同じインスタンスにホス トする。 36
  37. 37. ③運用、保守性 • コンポーネントによってアップデートとデプロイは、異 なった周期を持っている。 • 同じアップデート周期を持つコンポーネントでグループ 化を行なうと、よりスムーズに管理できる。 37
  38. 38. ③管理とメンテナンス • アプリケーションの管理、モニタリングとメンテナンスにか かるコストと労力は、デプロイされるインスタンスの種類や 数、リソースの種類様々なアイテムの範囲にある程度依存す る。 • アプリケーションを分割することは、管理、モニタリングと メンテナンスのオーバーヘッドを増加させるが、それらは必 ずしも比例関係にはない。 • 管理やメンテナンスは、一般的にプラットフォームが提供す るツールやシステム、既存のツールやシステムを利用、拡張 することで、自動化、省力化できる。 38
  39. 39. ③依存性 • いくつかのコンポーネントは依存関係にあり、分けるこ とが難しいケースがある。 • 同じコンピュート インスタンスにホストすることで、 コンポーネント同士のプロセス間コミュニケーションコ ストを最小限にする利点がある。 39
  40. 40. ③実行時のコスト(課金) • クラウド環境にデプロイされた全てのコンピュート インス タンスは、そのリソース量に対して請求される。 • よって、アプリケーションが稼働するインスタンスを分割 することは、一般的にランタイムコストを増加させる。 • コストを節約するには、オートスケールを実装することで、 コンピュートリソースを適切に管理し、可用性を維持しな がら、変動する需要や負荷の対象となるアイテムに関して はランタイム コストを最小限に抑えることができる。 40
  41. 41. ④セキュリティ • パーティションがセキュリティ境界にどう影響するかを考慮す ることは極めて重要。 • セキュリティを高めるためにはアプリケーションを分割させる 必要がある。 • 分割したコンポーネントあるいはコンピュート インスタンス毎 にタスクを割り当て、独立したコンポーネントやマルチテナン ト内のサービスを分離する。 関連するパターン GateKeeperパターン 41
  42. 42. ⑥システム環境 • コンポーネント要件や制限によってホストが異なる。 • 例えば、オペレーティングシステムに特別な設定が必要 とされるサード パーティー コンポーネントは、仮想マシ ン上にホストされる必要がある。 42
  43. 43. オートスケーリング • クラウドプラットフォームで自動化したリソース提供 • インスタンスだけでなくストレージ、キャッシュなど全 てのリソース利用において検討 • 負荷に対するSLAの準拠 • リソースの最適化 • コストの最適化 • 今後の主戦場の一つ 43
  44. 44. オートスケールとは 44 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure
  45. 45. スケール方式の実装 • 主要なスケール要因を設定する レスポンス時間、キューの長さ、CPU、メモリ使用率 • 監視コンポーネント • 意思決定ロジック=閾値を評価 • プロビジョニングと解除 45
  46. 46. 自動スケール検討事項「頻度」 • 頻度が多すぎてはいけない=システムが不安定に 平均的なアクセスが増える→インスタンス増やす 平均的な負荷が落ちる→インスタンス減る→再度不安定に • 極端な話、インスタンスを減らすことに関しては手動でも 良い 46 スケールを減らす頻度が多すぎると 都度不安定に。
  47. 47. 「ステートレス」にする • 特定のインスタンスでの実行を必要としない • 水平化した、いずれかのインスタンスで処理される「ス テートレス」な設計に 47 特定のインスタンスでしか 出来ない処理を作ると インスタンスを増やせなくなる。
  48. 48. イミュータブル・インフラストラクチャー • 不変なインフラストラクチャー • 一度サーバーを作成したら構成変更を加えない • つまりホスト環境を都度新規作成する。 • いつでも廃棄、生成可能。 • 安定するうえに、スケールしやすい。 48 旧環境は 廃棄 Azureだとクラウドサービスが もともとこの思想で作られて いる(SWAPして廃棄)
  49. 49. 「長時間タスク」の対応 • スケールイン、スケールアウトどちらでも影響なくする • スケールの途中でデータが失われることがないように • 大きすぎる場合は、分割する • 分割したうえ、チェックポイントを設け、途中のデータ を保持する 49
  50. 50. 「スケールユニット」の検討 • 複数のコンポーネントで構成されている場合、 • 一緒にスケールさせる必要のある「スケールユニット」 として扱う必要がある。 • 例)1万ユーザー増えるたびに1WEBサイト、2ワー カーロール等。 50
  51. 51. Azureにおけるオートスケール 51 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure
  52. 52. スケジュールによるオートスケールの設定 52 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure
  53. 53. Azureクラウドサービスの オートスケールの設定 53 • Azureスライド「S09 Microsoft Azure の各機能を活用したハイパフォーマンス実現方法」より引用 http://www.slideshare.net/MicrosoftAzure_Japan/s09-microsoft-azure
  54. 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. 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. 56. アンケートよろしくお願いします • http://enq-maker.com/33yr0ws • 1,2分で終了します。 56

×