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

Speaker:

JAZUG 酒井達明

JAZUG 森島政人

GoAzure 2015 Session 1-3

自己紹介

酒井達明（さかいたつあき）

株式会社ランドコンピュータ

JAZUGアドバイザ（通称：組長）

Microsoft MVP - Microsoft AzureMicrosoft Regional Director(~Jun. 2015)

twitter：@tatsuakisakai

Blog：http://tatsuakisakai.net/

趣味はマウンテンバイク&ロードバイク

自己紹介

森島政人（もりしままさひと）株式会社 pnop

JAZUG コアメンバ

Microsoft MVP – Microsoft Azure

twitter：@statemachine

Blog：http://statemachine.hatenablog.com/

趣味は自動二輪

すべてはここから始まった…

Credit:ESO/IDA/Danish 1.5 m/R. Gendler and C. Thöne

クラウドデザインパターン

• MS patterns & practies の一部

• JAZUGとして監訳に参加

• クラウドアプリケーション設計の手引き

• 8つの問題領域

• 24のパターン、10のダイダンスそれぞれ密接に関連している

日経BP社 2014年6月出版

24のパターンと10のダイダンス

パターン

ガイダンス

アジェンダ

回復性のあるクラウドアーキテクチャデザインのガイダンス

高可用性を実現するためのアプリケーション戦略

障害に強いアプリケーション構築のための戦略

回復性のあるクラウドアーキテクチャデザインのガイダンス

Credit:Y. Beletsky (LCO)/ESO

オンプレミス＆クラウドの前提の違い

オンプレミス クラウド

• 少数の高信頼ハードウェアで構成

• ハイエンドサーバー

• 基本的にLANで構成

• 障害が発生しないことが前提

• 障害発生は異常事態と認識

• アプリケーション障害時に停止

• 大量の安価なハードウェアで構成

• ローエンドサーバー

• インターネットの利用が前提

• 障害の発生は通常のイベント

• 障害発生時にはサーバーを分離

• 障害を考慮したアプリケーション設計が必要

回復性の実現で考慮すべきポイント

ワークロードによるアプリケーション分類

ライフサイクルモデルの確立

可用性モデルと可用性プランの確立

障害点と障害モード、障害の影響の特定

ワークロードによるアプリケーション分類

アイテムの選択

Eコマースサイトの例

チェックアウト トラッキング

ライフサイクルモデルの確立

• ターゲットによって異なるライフサイクル

鉄道

１ 2 3 4 5 6 7 8 9 10 11 12

金融 運輸

１ 2 3 4 5 6 7 8 9 10 11 12 １ 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 １ 2 3 4 5 6 7 8 9 10 11 12

航空

AM

PM

AM

PM

AM

PM

AM

PM

可用性

• 冗長性

𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑖𝑙𝑖𝑡𝑦 =𝑈𝑝𝑡𝑖𝑚𝑒

𝑈𝑝𝑡𝑖𝑚𝑒 + 𝐷𝑜𝑤𝑛𝑡𝑖𝑚𝑒

𝐴 = 1 − (1 − 0.1)3 = 99.9%

A (90%)

B (90%)

C (90%)

A (99.9%) B (99.9%) C (99.9%)

𝐴 = 𝐴𝑖= 99.7%

• システムの組合せ

Windows Azure ストレージ

3重化されたストレージ

• CAP定理における可用性と分断耐性を保障

• 常に２ノード以上が生存し、障害ノードを分離し、新たなノードで状態回復を図る

自律性

構成する要素間の独立性および依存度の削減

関連する機能をサービス内の自律的な単位に集約

依存関係を調査（コンポーネント、データ、外部エンティティなど）

自律的な単位に対し個別更新を可能にするアジリティの実現

きめ細かなスケーリングの制御の実現

手動介入に非依存な自律的コンポーネントで構成されるワークロード

サービスの依存関係と回復性の確保

共通的な確認事項

• API呼出回数および頻度、API呼出サーバ数に対する

制約の有無

•可用性の目標達成状況に関する公開情報の種別

•サービス正常性状態の通知方法

• SLAの有無

•他のサードパーティーによる同等のサービス提供の

有無

サービスの依存関係と回復性の確保

サードパーティー提供のサービス利用時の確認事項

•コモディティサービスであるか否か

•インターフェイスに対する他サービス プロバイダー

との相互運用性の確保状況

•有償の場合に提供されるSLAのレベル

自社内の企業全体のクラウド サービス利用時の確認事項

•サービス提供組織に対し通常と異なる SLAを交渉す

ることは可能か?

可用性モデルと可用性プランの確立

全体的なSLA

Jazz Club BlackCat予約サイト

SLA残りの時間

ライブスケジュール検索店舗案内等

SLA先行予約

チケット予約

SLA一般予約

OnとOffのパターンかつ高いSLAが要求される

可用性を考慮したアーキテクチャの例

Webサイト

データベース/ストレージ

バックエンドプロセス

メッセージキュー外部サービス

障害点と障害モード＆影響の解析障害点 障害モード 影響

ストレージの接続

ネットワーク遮断Webサイトで利用するデータの参照&更新不可

ネットワーク遅延Webサイト表示の遅延および表示内容の不正

メッセージキューの接続

ネットワーク遮断 外部サービスとの連携不可

ネットワーク遅延外部サービスとの連携に遅延発生Webサイトへのレスポンス低下

ポイズンメッセージ外部サービス処理の不正終了再試行の繰り返しによる閉塞発生

高可用性を実現するためのアプリケーション戦略

Credit:ESO/T. Schmidt

高可用性を実現するためのアプリ戦略

非同期通信と持続的キュー

障害検出と再試行ロジック

参照データ パターン

トランザクション データパ ターン

スケーラビリティのパターン

非同期と持続的キュー

• 可用性を高めるには疎結合されたサービスの間で非同期通信が有効

• 非同期通信を実現するためにキューが利用できる

• 非同期メッセージ（Asynchronous Messaging） 入門

• キューベースの負荷平準化 パターンQueue-based Load Leveling Pattern

非同期メッセージングのシナリオ

• ワークロード分離

• 時間的な分離

• 負荷分散

• 負荷平準化

• クロスプラットフォームの統合

• 非同期ワークフロー

• 信頼性の高いメッセージング

• 回復性のあるメッセージ処理

• …

キューによる時間的な分離

• 通常はサービス提供時間帯が異なる場合に適用

• 依存サービス停止時のリカバリ手段としても有効

• 高信頼メッセージングサービスを適用することでさらに耐障害性が向上

7:00～23:30受付毎日24時間申込可能

キューベースの負荷平準化 パターン

• Queue-based Load Leveling Pattern

• 変動するリクエストの負荷を、キューを介することで平準化

• 突然の負荷増大によるサービス停止を回避

リクエストはさまざまな頻度で送られる

メッセージはより一貫した頻度で処理される

障害検出と再試行ロジック

・リトライしてますか？

・クラウドの特性は…

クラウド

• 大量の安価なハードウェアで構成

• ローエンドサーバー

• インターネットの利用が前提

• 障害の発生は通常のイベント

• 障害発生時にはサーバーを分離

• 障害を考慮したアプリケーション設計が必要・クラウドアプリの特性は…

リトライ(Retry) パターン

リトライの考慮点

500 Internal Server Error

500 Internal Server Error

200 OK

• リトライするのかしないのか？

• リトライの間隔

• リトライの回数 例えば、403 Not Found なら？リトライすべきでない復帰コード、例外もある。

リトライパターンの実装例

• Azure Storage Client Library での例

–NoRetry クラス

–LinearRetry クラス

–ExponentialRetry クラス

GitHubに、SDKソースが公開されています。

スケーラビリティのパターン

自動スケール (Autoscaling) ガイダンス

ストットリング (Throttling) パターン

競合コンシューマー（CompentingConsumer) パターン

関連するパターン

スケーラビリティのパターン

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

0 1 2 3 4 5 6 7 8インスタンス数

スループット

インスタンス能力

必要な能力

スケールアップ

スケールアウト

キャパシティプランニングとスケール単位

時間

能力

負荷

サーバーが x 人の顧客を処理する際、 i ノードが必要となり、j のジョブキューと, k のストレージアカウントが必要…

足りなくなる前に増やす

障害に強いアプリケーション構築のための戦略

一般的なAzureの障害シナリオ

アプリケーションエラー

データの破損

ネットワークの停止

依存サービスのダウン

データセンターのダウン

Azureのダウン

依存サービスのダウン

サーキットブレーカー(Circuit Breaker) パターン

• 依存先のサービス障害を検知し遮断器の役割を果たす

• 繰り返しの試行を防ぎ、連鎖的な障害を発生を防ぐ

• リトライパターンとの組み合わせが有効

サーキットブレーカー パターン

• 3つの状態で管理• 利用可能：Closed

• 利用不可：Open

• 回復中：Half Open成功カウントが閾値を超え

失敗カウントが閾値を超え

タイムアウト

タイマーが満了

実行に失敗

成功 or 失敗が閾値を超えない

成功が閾値を超えない

データセンターのダウン

• 複数データセンターへの配置(Multiple Datacenter Deployment）ガイダンス

• データレプリケーションと同期(Data Replication and Sync) ガイダンス

• Traffic Manager の活用

• ストレージでは「読み取りアクセスGeo冗長」の適用

• SQL Database で提供されるGeo冗長の適用

Traffic ManagerによるマルチGeo

地理的冗長化で最大６重化

> 500 マイル

Windows Azureストレージ

地理的冗長化による耐障害性向上

まとめ

• CDPには、クラウド活用のエッセンスがつまっている

• オンプレとクラウドの違いを知れば、百戦殆うからず

• Azure / CDP の活用を！

参考資料＆URL

• Microsoft patterns & practieshttp://msdn.microsoft.com/en-us/library/ff921345.aspx

• Cloud Design Patternshttp://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 Codehttp://www.microsoft.com/en-us/download/details.aspx?id=41673

ご静聴ありがとうございました