enterprise cloud design pattern 大量データ処理アーキテクチャの構築
DESCRIPTION
TRANSCRIPT
上坂貴志 | ACE株式会社NEXTSCAPE
本日の内容
1. 前編の振り返り
2. ACEのご紹介
3. Cloud Design Pattern とは
4. 今回の大量データ処理の概要
5. Microsoft Azure におけるPaaSとScaling
6. Scalingを前提とした大量データ処理用アーキテクチャ
7. クラウド汎用パターン あらゆるプロジェクトで使用推奨
1.前編の振り返り
トリニティで Cloud Design Pattern を支援
• 技術観点 3つと実現指向のアーキ・トレンド “トリニティ”
2014 (C) Arichika Taniguchi, All rights reserved.
• 入力と処理、出力の分割
• 長時間ロードの分割非同期
• 疎結合での負荷移動の容易さ
• 負荷単位でのSLAと制御運用性
• トランザクションの整合性
• 処理中の緩い整合性の許容完全性
Business
Architect
Code
Architect
Infra(Model)
Architect
Science
2.ACEのご紹介
Microsoft Azure パートナーコンソーシアム
Azure Council Experts（略称：ACE／エース）アジュール評議会は、Microsoft Azure を利用した技術やサービスを提供するリーディングカンパニーが集結し、普及ならびに技術者の育成、ノウハウの共有などでコラボレーションを展開するパートナーコンソーシアム。
顧客企業・団体技術者
一般社団法人 Azure Council Experts について
http://a-c-e.biz/
Microsoft Azure パートナーコンソーシアム
【書籍の出版】
【ACE加盟企業による定例会＆ワーキンググループの活動の様子】
Azure Council Experts 著日本マイクロソフト 監修発行：日経BP社編集：日経SYSTEMSページ数：176Pターゲット：アーキテクト、システムエンジニア
一般社団法人 Azure Council Experts について
スピーカー自己紹介
• 株式会社ネクストスケープ（ACE理事企業）Microsoft Partner of the Year 2012 Windows Azure パートナー アワード 受賞（日本13,000事業所中）
Microsoft Partner of the Year 2013Windows Azure パートナー アワード(System Integrator) 受賞（日本14,000事業所中）
2013 Microsoft Worldwide Partner AwardCloud Partner of the Year 世界2位（世界3,000事業所中）
こんな会社です• 配信ソリューション
• Microsoft Azure導入支援
• DRMソリューション(PlayReady)
• システム・インテグレーション
• Sitecore(CMS)導入支援
スピーカー自己紹介
• 上坂貴志（うえさかたかし）株式会社ネクストスケープでアーキテクトやってます。
東京出身のおっさんです。
Twitter, Blogやってません。更新めんどい。
.NET, Java, PHP, JavaScriptなど使います。
最近の活動
第1回 Build Insider OFFLINE（登壇）
Cloud Days Tokyo 2014 Spring（MicrosoftブースにてAzure紹介）
Codezineにて記事公開（Visual Studio Online）
InfoQでDDD連載始めました！ .NETでドメイン駆動開発～ValueObject 前編、後編～
3.Cloud Design Pattern とは
Cloud Design Pattern とは
http://msdn.microsoft.com/en-us/library/dn568099.aspx
24のデザインパターン
10のガイダンス
コードサンプル
Cloud Design Pattern とは
10のガイダンス
24のデザインパターン
可用性 管理と監視
データ管理 パフォーマンスとスケーラビリティ
設計と実装 弾力性
メッセージング セキュリティ
⇒ 8つのカテゴリに分類
10のガイダンス
非同期メッセージング入門
オートスケールガイダンス
キャッシュガイダンス
アプリケーション分割ガイダンス
データ整合性入門
データパーティション分割ガイダンス
データレプリケーション＆同期ガイダンス
インストルメンテーションとテレメトリガイダンス
複数データセンター展開ガイダンス
サービスメータリングガイダンス
Cloud Design Pattern とは
24のデザインパターン
キャッシュアサイドパターン
回路ブレーカーパターン
補正トランザクションパターン
競合する消費者パターン
リソース統合計算パターン
コマンドクエリ分離パターン(CQRS)
イベントソースパターン
外部構成ストアパターン
フェデレーション Idパターン
ゲートキーパーパターン
エンドポイントヘルス監視パターン
インデックステーブルパターン
リーダー選挙パターン
マテリアライズドビューパターン
パイプとフィルターパターン
優先度キューパターン
キューベースのロード平準化パターン
リトライパターン
実行時再構成パターン
スケジューラエージェントスーパーバイザーパターン
Shardingパターン
静的コンテンツホスティングパターン
抑制パターン
係員付きパーキングサービスキーパターン
Cloud Design Pattern とは
4.今回の大量データ処理の概要
• 楽曲データを配信用に加工する処理（パッケージング）
今回の大量データ処理の概要
楽曲コンテンツ エンコード処理 トランスコード処理 暗号化処理 アップロード
• エンコード処理にかかる処理時間1曲あたり、2分半～3分半。これが120万曲。
120万 x 3分 = 6万時間！（2500日）
5.Microsoft Azure におけるPaaSとScaling
Microsoft Azure におけるPaaSとScaling
• PaaSとは、アプリケーションが稼動するための基盤(Platform)がサービスとして提供されたもの。
アプリケーション
OS
仮想化
サーバー
ストレージ
ネットワーク
ミドルウェア
アプリケーション アプリケーション
オン・プレミス IaaS PaaS
Runtime
データ
OS
仮想化
サーバー
ストレージ
ネットワーク
ミドルウェア
Runtime
データ
OS
仮想化
サーバー
ストレージ
ネットワーク
ミドルウェア
Runtime
データ
アプリケーション
SaaS
OS
仮想化
サーバー
ストレージ
ネットワーク
ミドルウェア
Runtime
データ
ユーザーが管理
クラウドベンダーが管理
ユーザーが管理
ユーザーが管理
クラウドベンダーが管理
クラウドベンダーが管理
Microsoft Azure におけるPaaSとScaling
Scalingとは要求される作業量に応じて性能・処理能力を増減すること。
Scalingには垂直スケール（ScaleUp）と水平スケール（ScaleOut）の2つがある。
Scale
Up
ScaleOut
Microsoft Azure におけるPaaSとScaling
• Microsoft Azure の場合PaaSに対してスケールの例
インスタンス数（PaaS数）を入力して保存するだけ！（手動によるスケール）
Microsoft Azure におけるPaaSとScaling
Microsoft AzureにおけるPaaS
• クラウドサービスという名称
• VisualStudioから簡単にデプロイ可能• JenkinsなどのCIツールを使用したデプロイも可能(Azure Powershell使用）
• WebRole（Web用）と、WorkerRole（バッチ用）の2種類をホスト
• StagingとProduction環境• Stagingにデプロイして稼働確認→Productionへスワップ！（ボタン一発）
• リモートデスクトップで接続可能
Microsoft Azure におけるPaaSとScaling
Microsoft AzureにおけるScaling
• Webの管理画面から手動でインスタンス数を増減可能
• オートスケールを設定可能• CPU負荷に応じて増減• 参照するメッセージQueueの数に応じて増減• スケジュール設定で増減
6.ScaleOutを前提とした大量データ処理用アーキテクチャ
処理A 処理B
• Scalingを用いて大量に並列処理をするために並列処理と並列処理のつなぎにQueueを使用する
ScaleOutを前提とした大量データ処理用アーキテクチャ
処理A用のメッセージ Queue 次処理用のメッセージ Queue
Azure の Queueは2種類
Storage Queue最大メッセージ サイズ：64 KBメッセージの最大 TTL：7日間キューの最大数：無制限
Service Bus Queue最大メッセージ サイズ：256 KBメッセージの最大 TTL：無制限キューの最大数：10,000
ScaleOutを前提とした大量データ処理用アーキテクチャ
• Queue数をベースにオートスケール
AutoScale
PaaS
メッセージ Queue
Queue数によるスケール設定
1インスタンス当たりに処理するQueueの数• 増減しきい値に相当
総インスタンス数のMin値、Max値
１度に増減するインスタンス数
AutoScale
PaaS
メッセージ Queue
ScaleOutを前提とした大量データ処理用アーキテクチャ
• タスクの統合
楽曲コンテンツ エンコード処理 トランスコード処理 暗号化処理 アップロード
負荷高 負荷低 負荷低
楽曲コンテンツ
エンコード処理トランスコード処理
暗号化処理 アップロード
別処理
ScaleOutを前提とした大量データ処理用アーキテクチャ
• 最終形
楽曲コンテンツ エンコード処理トランスコード処理
暗号化処理
アップロード
メッセージ Queue
Queue投入 メッセージ Queue
AutoScale
AutoScale
ScaleOutを前提とした大量データ処理用アーキテクチャ
使用した Cloud Design Pattern
競合する消費者パターンスループット、スケーラビリティと可用性の向上と、作業負荷を最適化するために同時に複数のメッセージを処理することを可能にする
パイプとフィルターパターンタスク要素のデプロイとスケーリング処理を別々に実行することにより、パフォーマンス、スケーラビリティ、および再利用性を向上できる
リソース統合計算パターン計算リソースの使用率を高め、クラウドでホストされるアプリケーションの処理の実行に関連するコストと管理オーバーヘッドを減らすことができる
ScaleOutを前提とした大量データ処理用アーキテクチャ• 競合する消費者パターン
• 概要• スループット、スケーラビリティと可用性の向上と、作業負荷を最適化するために同時に複数のメッセージを処理することを可能にします。
• 戦略• クラウドで実行されるアプリケーションが多数の要求を処理することを可能にします。
• 一般的な手法は、各要求を同期的に処理するのではなく、要求をメッセージングシステムを通して他の非同期にサービスに渡すことです。
• この戦略は、要求の処理中、アプリケーションのビジネスロジックがブロックされないようにするのに役立ちます。
メッセージ Queue
アプリーケーションインスタンスメッセージ生成
サービスインスタンスメッセージ処理
パイプライン
ScaleOutを前提とした大量データ処理用アーキテクチャ• パイプとフィルターパターン
• 概要• 複雑な処理を実行するタスクを再利用可能な一連の個別要素に分解します。このパターンはタスク要素をデプロイとスケーリング処理を別々に実行することによってパフォーマンス、スケーラビリティ、および再利用性を向上できます。
• 戦略• 1 つのタスクを実行するそれぞれの個別のコンポーネント (またはフィルター) のセットに処理を分解します。
• 各コンポーネント(またはフィルター)が受信し、出力するデータの形式を標準化することで、パイプライン内で複数のコンポーネント(またはフィルター) を組み合わせることができる。
メッセージ Queue フィルター メッセージ Queue フィルター
ScaleOutを前提とした大量データ処理用アーキテクチャ• リソース統合計算パターン
• 概要• 複数のタスクまたは操作を 1 つの計算ユニットに統合します。このパターンはコンピューティングリソースの使用率を増加し、クラウドでホストされるアプリケーションでの処理を実行するために必要なコストと管理オーバーヘッドを削減できます。
• 戦略• タスクは、環境によって提供される機能に基づいて、様々な基準や機能に関連したコストに応じてグループ化することができます。
• 一般的なアプローチは、そのスケーラビリティ、有効期間、および処理の要件に関して同様のプロファイルを持っているタスクを探します。
• これらのタスクを一つのグループの単位としてスケールできます。
Task A
Task E
計算ユニット
計算ユニット
Task B
計算ユニット
Task C
計算ユニット
Task D
計算ユニット
Task A
Task E
計算ユニット
計算ユニット
Task B
Task CTask D
7.クラウド汎用パターンあらゆるプロジェクトで使用推奨
クラウド汎用パターンあらゆるプロジェクトで使用推奨
• Retryパターン
• 概要
• クラウドでは一時的な障害は珍しくない。障害発生時にその影響を最小限に抑える。
• 戦略• 障害を示すエラーが一時的でない、または繰り返し要求しても成功する可能性が無い場合、アプリケーションは操作を中止し、適切な例外を報告する必要がある。 (例：資格情報が無効なため、何度挑戦しても失敗する)
• 報告された例外が通常は起こりえないものや極希少なものの場合、極めて異常な事情によってその例外が引き起されている可能性がある。（例：ネットワークパケットの破損）このような場合は同一の障害が繰り返される可能性は低いし、再要求は恐らく成功するので直ちに再試行を行う。
• 障害の原因が一般的な接続の問題や接続先がビジー状態によるものの場合、接続時の問題が解決するか、接続先のタスクがクリアされるまで短時間の待ち時間が必要な場合がある。このような場合、アプリケーションは要求を再試行する前に適切な時間を待つ必要がある。
アプリケーション サービス
1
500
2
500
3
200
クラウド汎用パターンあらゆるプロジェクトで使用推奨
• Retryパターン実装例
private int retryCount = 3;
public async Task OperationWithBasicRetryAsync(){
int currentRetry = 0;
for (; ;){
try{
// 外部サービスの呼び出し.
await TransientOperationAsync();
// Return or break.break;
}catch (Exception ex){
Trace.TraceError("Operation Exception");
currentRetry++;// 一時的なエラーか判定。
if (currentRetry > this.retryCount || !IsTransient(ex)){
// 一時的なエラーではない場合、リトライしない
throw;}
}
// リトライの待機。
Await.Task.Delay();}
}
// リモートサービス非同期呼び出しメソッド.
private async Task TransientOperationAsync(){
...}
private bool IsTransient(Exception ex) {
// 例外が一時的なものか判定// 例外のタイプのチェックだけでよい場合もあるが、時には例外のプロパティ値のチェックも必要
if (ex is OperationTransientException)return true;
var webException = ex as WebException;if (webException != null){
// web exceptionのStatusが以下のStatus値のいずれかの場合、一時的なエラーとみなす
return new[] { WebExceptionStatus.ConnectionClosed,WebExceptionStatus.Timeout,WebExceptionStatus.RequestCanceled }.
Contains(webException.Status);}
// 追加の例外チェックはここに実装
return false;}
クラウド汎用パターンあらゆるプロジェクトで使用推奨
• でもAzureのSDKを使用する場合は先ほどのような実装はしませんStorageアクセスの場合のRetry実装例
• 最初からRetryの仕組みが用意されています。
CloudStorageAccount storageAccount = new CloudStorageAccount(new StorageCredentials(Configs.StorageAccountNameSupply, Configs.StorageAccountKeySupply), true);var client = storageAccount.CreateCloudBlobClient();client.RetryPolicy = new Microsoft.WindowsAzure.Storage.RetryPolicies.ExponentialRetry(TimeSpan.FromSeconds(2), Configs.RetryMaxCount);
using Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling;
・・・var sqlConn = new SqlConnection(sqlConnString);var policy = new RetryPolicy<SqlDatabaseTransientErrorDetectionStrategy>(retryCount: 3, initialInterval: TimeSpan.FromSeconds(30), increment: TimeSpan.FromSeconds(30));sqlConn.OpenWithRetry(policy);
Microsoft Azure SQLの場合のRetry実装例• Enterprise Library - Transient Fault Handling Application Block - Windows Azure SQL Database integration
• 拡張メソッドと実装済みの戦略が提供されています。
クラウド汎用パターンあらゆるプロジェクトで使用推奨
エラーNo エラー内容
4050110929
サービスは現在ビジー状態
10928 同時要求の最大制限が 180 を超えたため要求を拒否
10053 サーバーから結果を受信するときにトランスポート レベルのエラーが発生。クライアントが切断
10054 サーバーから結果を受信するときにトランスポート レベルのエラーが発生。サーバーが切断
10060 Socket接続エラー。サーバーが見つからない
40197 要求の処理中にソフトウェアやハードウェアのアップグレードのためのサービス停止、ハードウェア エラー、またはその他のフェールオーバーの問題が発生
40540 要求処理中にエラーに遭遇。再試行を。
40613 サーバー上のデータベースが使用不可
233 未サポートバージョンのSQLServerへ接続しようとした;サーバービジーで新しい接続を生成できなかった;メモリ不足で新しい接続を生成できなかった
64 接続は成功したが、ログインに失敗した
20 接続先のSQLServerインスタンスはencryptionをサポートしていない
SqlDatabaseTransientErrorDetectionStrategyが一時的なエラーである、と判定するエラーの種類
※TimeoutException も一時的なエラーと判定される
• 外部構成ストアパターン
• 概要
• 複数のアプリケーションやインスタンスで構成設定を共有する。
• 戦略• 外部記憶装置に構成情報を格納し、迅速かつ効率的に読み取りおよび設定を更新するために使用できるインターフェイスを提供する。
• 外部ストアの種類は、アプリケーションのホスティング、ランタイム環境に依存する。
• クラウドでホストされているシナリオでは通常、クラウド・ベースのストレージサービス。もしくはデータベース、他のシステムになる可能性もある。
クラウド汎用パターンあらゆるプロジェクトで使用推奨
Application
外部構成ストアApplication
Application
クラウド・ストレージ
データベース
代替オプション
クラウド汎用パターンあらゆるプロジェクトで使用推奨
