Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Real World Cloud Architectures
~CDPの概念と実装~
Speaker:
JAZUG 酒井達明
JAZUG 森島政人
GoAzure 2015 Session 1-3
自己紹介
酒井 達明 (さかい たつあき)
株式会社ランドコンピュータ
JAZUGアドバイザ(通称:組長)
Microsoft MVP - Microsoft Azure
Microsoft Regional Director(~Jun. 20...
自己紹介
森島 政人 (もりしま まさひと)
株式会社 pnop
JAZUG コアメンバ
Microsoft MVP – Microsoft Azure
twitter:@statemachine
Blog:http://statemachin...
すべてはここから始まった…
Credit:ESO/IDA/Danish 1.5 m/R. Gendler and C. Thöne
クラウドデザインパターン
• MS patterns & practies の一部
• JAZUGとして監訳に参加
• クラウドアプリケーション設計の手引き
• 8つの問題領域
• 24のパターン、10のダイダンス
それぞれ密接に関連している
...
24のパターンと10のダイダンス
パターン
ガイダンス
アジェンダ
回復性のあるクラウドアーキテクチャデザインのガイダンス
高可用性を実現するためのアプリケーション戦略
障害に強いアプリケーション構築のための戦略
回復性のあるクラウドアーキテクチャ
デザインのガイダンス
Credit:Y. Beletsky (LCO)/ESO
オンプレミス&クラウドの前提の違い
オンプレミス クラウド
• 少数の高信頼ハードウェアで構成
• ハイエンドサーバー
• 基本的にLANで構成
• 障害が発生しないことが前提
• 障害発生は異常事態と認識
• アプリケーション障害時に停止
•...
回復性の実現で考慮すべきポイント
ワークロードによるアプリケーション分類
ライフサイクルモデルの確立
可用性モデルと可用性プランの確立
障害点と障害モード、障害の影響の特定
ワークロードによるアプリケーション分類
アイテムの選択
Eコマースサイトの例
チェックアウト トラッキング
ライフサイクルモデルの確立
• ターゲットによって異なるライフサイクル
鉄道
1 2 3 4 5 6 7 8 9 10 11 12
金融 運輸
1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11...
可用性
• 冗長性
𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑖𝑙𝑖𝑡𝑦 =
𝑈𝑝𝑡𝑖𝑚𝑒
𝑈𝑝𝑡𝑖𝑚𝑒 + 𝐷𝑜𝑤𝑛𝑡𝑖𝑚𝑒
𝐴 = 1 − (1 − 0.1)3
= 99.9%
A (90%)
B (90%)
C (90%)
A (99.9%) B (99.9%) C...
Windows Azure ストレージ
3重化されたストレージ
• CAP定理における可用性
と分断耐性を保障
• 常に2ノード以上が生存
し、障害ノードを分離し、
新たなノードで状態回復
を図る
自律性
構成する要素間の独立性および依存度の削減
関連する機能をサービス内の自律的な単位に集約
依存関係を調査(コンポーネント、データ、外部エンティティなど)
自律的な単位に対し個別更新を可能にするアジリティの実現
きめ細かなスケーリングの制御...
サービスの依存関係と回復性の確保
共通的な確認事項
• API呼出回数および頻度、API呼出サーバ数に対する
制約の有無
• 可用性の目標達成状況に関する公開情報の種別
• サービス正常性状態の通知方法
• SLAの有無
• 他のサードパーティ...
サービスの依存関係と回復性の確保
サードパーティー提供のサービス利用時の確認事項
• コモディティサービスであるか否か
• インターフェイスに対する他サービス プロバイダー
との相互運用性の確保状況
• 有償の場合に提供されるSLAのレベル
自...
可用性モデルと可用性プランの確立
全体的なSLA
Jazz Club BlackCat
予約サイト
SLA
残りの時間
ライブスケジュール検索
店舗案内等
SLA
先行予約
チケット予約
SLA
一般予約
OnとOffのパターン
かつ高いSLA...
可用性を考慮したアーキテクチャの例
Webサイト
データベース/
ストレージ
バックエンド
プロセス
メッセージキュー
外部サービス
障害点と障害モード&影響の解析
障害点 障害モード 影響
ストレージの接続
ネットワーク遮断
Webサイトで利用するデータの参
照&更新不可
ネットワーク遅延
Webサイト表示の遅延および表示
内容の不正
メッセージキューの
接続
ネットワーク...
高可用性を実現するための
アプリケーション戦略
Credit:ESO/T. Schmidt
高可用性を実現するためのアプリ戦略
非同期通信と持続的キュー
障害検出と再試行ロジック
参照データ パターン
トランザクション データパ ターン
スケーラビリティのパターン
非同期と持続的キュー
• 可用性を高めるには疎結合されたサービスの間で
非同期通信が有効
• 非同期通信を実現するためにキューが利用できる
• 非同期メッセージ(Asynchronous Messaging) 入門
• キューベースの負荷平準化...
非同期メッセージングのシナリオ
• ワークロード分離
• 時間的な分離
• 負荷分散
• 負荷平準化
• クロスプラットフォームの統合
• 非同期ワークフロー
• 信頼性の高いメッセージング
• 回復性のあるメッセージ処理
• …
キューによる時間的な分離
• 通常はサービス提供時間帯が異なる場合に適用
• 依存サービス停止時のリカバリ手段としても有効
• 高信頼メッセージングサービスを適用することで
さらに耐障害性が向上
7:00~23:30受付
毎日24時間
申込可能
キューベースの負荷平準化 パターン
• Queue-based Load Leveling Pattern
• 変動するリクエストの負荷を、キューを介することで
平準化
• 突然の負荷増大によるサービス停止を回避
リクエストは
さまざまな頻度
...
障害検出と再試行ロジック
・リトライしてますか?
・クラウドの特性は…
クラウド
• 大量の安価なハードウェアで構成
• ローエンドサーバー
• インターネットの利用が前提
• 障害の発生は通常のイベント
• 障害発生時にはサーバーを分離
• ...
リトライの考慮点
500 Internal Server Error
500 Internal Server Error
200 OK
• リトライするのかしないのか?
• リトライの間隔
• リトライの回数 例えば、403 Not Found...
リトライパターンの実装例
• Azure Storage Client Library での例
–NoRetry クラス
–LinearRetry クラス
–ExponentialRetry クラス
GitHubに、SDKソースが公開されていま...
スケーラビリティのパターン
自動スケール (Autoscaling) ガイダンス
ストットリング (Throttling) パターン
競合コンシューマー(Compenting
Consumer) パターン
関連するパターン
スケーラビリティのパターン
• スケールアップとスケールアウト
0 1 2 3 4 5 6 7 8
インスタンス数
スループット
インスタンス能力
必要な能力
スケール
アップ
スケール
アウト
キャパシティプランニングとスケール単位
時間
能力
負荷
サーバーが x 人の顧客を処理する際、 i ノードが必要となり、
j のジョブキューと, k のストレージアカウントが必要…
足りなくなる
前に増やす
障害に強いアプリケーション
構築のための戦略
一般的なAzureの障害シナリオ
アプリケーションエラー
データの破損
ネットワークの停止
依存サービスのダウン
データセンターのダウン
Azureのダウン
依存サービスのダウン
サーキットブレーカー(Circuit Breaker) パターン
• 依存先のサービス障害を検知し遮断器の役割を果たす
• 繰り返しの試行を防ぎ、連鎖的な障害を発生を防ぐ
• リトライパターンとの組み合わせが有効
サーキットブレーカー パターン
• 3つの状態で管理
• 利用可能:Closed
• 利用不可:Open
• 回復中:Half Open
成功カウントが
閾値を超え
失敗カウントが
閾値を超え
タイムアウト
タイマーが満了
実行に失敗
成功 o...
データセンターのダウン
• 複数データセンターへの配置
(Multiple Datacenter Deployment)ガイダンス
• データレプリケーションと同期
(Data Replication and Sync) ガイダンス
• Tra...
Traffic ManagerによるマルチGeo
地理的冗長化で
最大6重化
> 500 マイル
Windows Azure ストレージ
地理的冗長化による耐障害性向上
まとめ
• CDPには、クラウド活用の
エッセンスがつまっている
• オンプレとクラウドの違いを
知れば、百戦殆うからず
• Azure / CDP の活用を!
参考資料&URL
• Microsoft patterns & practies
http://msdn.microsoft.com/en-us/library/ff921345.aspx
• Cloud Design Patterns
htt...
ご静聴ありがとうございました
Upcoming SlideShare
Loading in …5
×

Real World Cloud Architectures ~CDPの概念と実装~

1,338 views

Published on

GoAzure 2015 Session 1-3
Real World Cloud Architectures ~CDPの概念と実装~
Speaker : SAKAI Tatsuaki, MORISHIMA Masahito

Published in: Software
  • Be the first to comment

Real World Cloud Architectures ~CDPの概念と実装~

  1. 1. Real World Cloud Architectures ~CDPの概念と実装~ Speaker: JAZUG 酒井達明 JAZUG 森島政人 GoAzure 2015 Session 1-3
  2. 2. 自己紹介 酒井 達明 (さかい たつあき) 株式会社ランドコンピュータ JAZUGアドバイザ(通称:組長) Microsoft MVP - Microsoft Azure Microsoft Regional Director(~Jun. 2015) twitter:@tatsuakisakai Blog:http://tatsuakisakai.net/ 趣味はマウンテンバイク&ロードバイク
  3. 3. 自己紹介 森島 政人 (もりしま まさひと) 株式会社 pnop JAZUG コアメンバ Microsoft MVP – Microsoft Azure twitter:@statemachine Blog:http://statemachine.hatenablog.com/ 趣味は自動二輪
  4. 4. すべてはここから始まった… Credit:ESO/IDA/Danish 1.5 m/R. Gendler and C. Thöne
  5. 5. クラウドデザインパターン • MS patterns & practies の一部 • JAZUGとして監訳に参加 • クラウドアプリケーション設計の手引き • 8つの問題領域 • 24のパターン、10のダイダンス それぞれ密接に関連している 日経BP社 2014年6月出版
  6. 6. 24のパターンと10のダイダンス パターン ガイダンス
  7. 7. アジェンダ 回復性のあるクラウドアーキテクチャデザインのガイダンス 高可用性を実現するためのアプリケーション戦略 障害に強いアプリケーション構築のための戦略
  8. 8. 回復性のあるクラウドアーキテクチャ デザインのガイダンス Credit:Y. Beletsky (LCO)/ESO
  9. 9. オンプレミス&クラウドの前提の違い オンプレミス クラウド • 少数の高信頼ハードウェアで構成 • ハイエンドサーバー • 基本的にLANで構成 • 障害が発生しないことが前提 • 障害発生は異常事態と認識 • アプリケーション障害時に停止 • 大量の安価なハードウェアで構成 • ローエンドサーバー • インターネットの利用が前提 • 障害の発生は通常のイベント • 障害発生時にはサーバーを分離 • 障害を考慮したアプリケーション 設計が必要
  10. 10. 回復性の実現で考慮すべきポイント ワークロードによるアプリケーション分類 ライフサイクルモデルの確立 可用性モデルと可用性プランの確立 障害点と障害モード、障害の影響の特定
  11. 11. ワークロードによるアプリケーション分類 アイテムの選択 Eコマースサイトの例 チェックアウト トラッキング
  12. 12. ライフサイクルモデルの確立 • ターゲットによって異なるライフサイクル 鉄道 1 2 3 4 5 6 7 8 9 10 11 12 金融 運輸 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 スポーツ 小売 J F M A M J J A S O N D J F M A M J J A S O N D 1 2 3 4 5 6 7 8 9 10 11 12 航空 AM PM AM PM AM PM AM PM
  13. 13. 可用性 • 冗長性 𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑖𝑙𝑖𝑡𝑦 = 𝑈𝑝𝑡𝑖𝑚𝑒 𝑈𝑝𝑡𝑖𝑚𝑒 + 𝐷𝑜𝑤𝑛𝑡𝑖𝑚𝑒 𝐴 = 1 − (1 − 0.1)3 = 99.9% A (90%) B (90%) C (90%) A (99.9%) B (99.9%) C (99.9%) 𝐴 = 𝐴𝑖= 99.7% • システムの組合せ
  14. 14. Windows Azure ストレージ 3重化されたストレージ • CAP定理における可用性 と分断耐性を保障 • 常に2ノード以上が生存 し、障害ノードを分離し、 新たなノードで状態回復 を図る
  15. 15. 自律性 構成する要素間の独立性および依存度の削減 関連する機能をサービス内の自律的な単位に集約 依存関係を調査(コンポーネント、データ、外部エンティティなど) 自律的な単位に対し個別更新を可能にするアジリティの実現 きめ細かなスケーリングの制御の実現 手動介入に非依存な自律的コンポーネントで構成されるワークロード
  16. 16. サービスの依存関係と回復性の確保 共通的な確認事項 • API呼出回数および頻度、API呼出サーバ数に対する 制約の有無 • 可用性の目標達成状況に関する公開情報の種別 • サービス正常性状態の通知方法 • SLAの有無 • 他のサードパーティーによる同等のサービス提供の 有無
  17. 17. サービスの依存関係と回復性の確保 サードパーティー提供のサービス利用時の確認事項 • コモディティサービスであるか否か • インターフェイスに対する他サービス プロバイダー との相互運用性の確保状況 • 有償の場合に提供されるSLAのレベル 自社内の企業全体のクラウド サービス利用時の確認事項 • サービス提供組織に対し通常と異なる SLAを交渉す ることは可能か?
  18. 18. 可用性モデルと可用性プランの確立 全体的なSLA Jazz Club BlackCat 予約サイト SLA 残りの時間 ライブスケジュール検索 店舗案内等 SLA 先行予約 チケット予約 SLA 一般予約 OnとOffのパターン かつ高いSLAが要求される
  19. 19. 可用性を考慮したアーキテクチャの例 Webサイト データベース/ ストレージ バックエンド プロセス メッセージキュー 外部サービス
  20. 20. 障害点と障害モード&影響の解析 障害点 障害モード 影響 ストレージの接続 ネットワーク遮断 Webサイトで利用するデータの参 照&更新不可 ネットワーク遅延 Webサイト表示の遅延および表示 内容の不正 メッセージキューの 接続 ネットワーク遮断 外部サービスとの連携不可 ネットワーク遅延 外部サービスとの連携に遅延発生 Webサイトへのレスポンス低下 ポイズンメッセージ 外部サービス処理の不正終了 再試行の繰り返しによる閉塞発生
  21. 21. 高可用性を実現するための アプリケーション戦略 Credit:ESO/T. Schmidt
  22. 22. 高可用性を実現するためのアプリ戦略 非同期通信と持続的キュー 障害検出と再試行ロジック 参照データ パターン トランザクション データパ ターン スケーラビリティのパターン
  23. 23. 非同期と持続的キュー • 可用性を高めるには疎結合されたサービスの間で 非同期通信が有効 • 非同期通信を実現するためにキューが利用できる • 非同期メッセージ(Asynchronous Messaging) 入門 • キューベースの負荷平準化 パターン Queue-based Load Leveling Pattern
  24. 24. 非同期メッセージングのシナリオ • ワークロード分離 • 時間的な分離 • 負荷分散 • 負荷平準化 • クロスプラットフォームの統合 • 非同期ワークフロー • 信頼性の高いメッセージング • 回復性のあるメッセージ処理 • …
  25. 25. キューによる時間的な分離 • 通常はサービス提供時間帯が異なる場合に適用 • 依存サービス停止時のリカバリ手段としても有効 • 高信頼メッセージングサービスを適用することで さらに耐障害性が向上 7:00~23:30受付 毎日24時間 申込可能
  26. 26. キューベースの負荷平準化 パターン • Queue-based Load Leveling Pattern • 変動するリクエストの負荷を、キューを介することで 平準化 • 突然の負荷増大によるサービス停止を回避 リクエストは さまざまな頻度 で送られる メッセージはより 一貫した頻度で 処理される
  27. 27. 障害検出と再試行ロジック ・リトライしてますか? ・クラウドの特性は… クラウド • 大量の安価なハードウェアで構成 • ローエンドサーバー • インターネットの利用が前提 • 障害の発生は通常のイベント • 障害発生時にはサーバーを分離 • 障害を考慮したアプリケーション 設計が必要・クラウドアプリの特性は… リトライ(Retry) パターン
  28. 28. リトライの考慮点 500 Internal Server Error 500 Internal Server Error 200 OK • リトライするのかしないのか? • リトライの間隔 • リトライの回数 例えば、403 Not Found なら? リトライすべきでない復帰コード、 例外もある。
  29. 29. リトライパターンの実装例 • Azure Storage Client Library での例 –NoRetry クラス –LinearRetry クラス –ExponentialRetry クラス GitHubに、SDKソースが公開されています。
  30. 30. スケーラビリティのパターン 自動スケール (Autoscaling) ガイダンス ストットリング (Throttling) パターン 競合コンシューマー(Compenting Consumer) パターン 関連するパターン
  31. 31. スケーラビリティのパターン • スケールアップとスケールアウト 0 1 2 3 4 5 6 7 8 インスタンス数 スループット インスタンス能力 必要な能力 スケール アップ スケール アウト
  32. 32. キャパシティプランニングとスケール単位 時間 能力 負荷 サーバーが x 人の顧客を処理する際、 i ノードが必要となり、 j のジョブキューと, k のストレージアカウントが必要… 足りなくなる 前に増やす
  33. 33. 障害に強いアプリケーション 構築のための戦略
  34. 34. 一般的なAzureの障害シナリオ アプリケーションエラー データの破損 ネットワークの停止 依存サービスのダウン データセンターのダウン Azureのダウン
  35. 35. 依存サービスのダウン サーキットブレーカー(Circuit Breaker) パターン • 依存先のサービス障害を検知し遮断器の役割を果たす • 繰り返しの試行を防ぎ、連鎖的な障害を発生を防ぐ • リトライパターンとの組み合わせが有効
  36. 36. サーキットブレーカー パターン • 3つの状態で管理 • 利用可能:Closed • 利用不可:Open • 回復中:Half Open 成功カウントが 閾値を超え 失敗カウントが 閾値を超え タイムアウト タイマーが満了 実行に失敗 成功 or 失敗が閾値を超えない 成功が閾値を超えない
  37. 37. データセンターのダウン • 複数データセンターへの配置 (Multiple Datacenter Deployment)ガイダンス • データレプリケーションと同期 (Data Replication and Sync) ガイダンス • Traffic Manager の活用 • ストレージでは「読み取りアクセスGeo冗長」の適用 • SQL Database で提供されるGeo冗長の適用
  38. 38. Traffic ManagerによるマルチGeo
  39. 39. 地理的冗長化で 最大6重化 > 500 マイル Windows Azure ストレージ 地理的冗長化による耐障害性向上
  40. 40. まとめ • CDPには、クラウド活用の エッセンスがつまっている • オンプレとクラウドの違いを 知れば、百戦殆うからず • Azure / CDP の活用を!
  41. 41. 参考資料&URL • Microsoft patterns & practies http://msdn.microsoft.com/en-us/library/ff921345.aspx • Cloud Design Patterns http://msdn.microsoft.com/en-us/library/dn568099.aspx • フェールセーフ: 回復力のあるクラウド アーキテクチャに関するガイダンス http://msdn.microsoft.com/ja-jp/library/azure/jj853352.aspx • Azure アプリケーションの災害復旧と高可用性 http://msdn.microsoft.com/ja-JP/library/azure/dn251004.aspx • 「クラウドデザインパターン ~Azureを例としたアプリケーション設計の手引き」 日経BP社刊(ISBN:978-4-8222-9833-3) • Cloud Design Patterns – Sample Code http://www.microsoft.com/en-us/download/details.aspx?id=41673
  42. 42. ご静聴ありがとうございました

×