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.

Enterprise cloud design pattern 大量データ処理アーキテクチャの構築

3,814 views

Published on

Published in: Software
  • Be the first to comment

Enterprise cloud design pattern 大量データ処理アーキテクチャの構築

  1. 1. 上坂貴志 | ACE 株式会社NEXTSCAPE
  2. 2. 本日の内容 1. 前編の振り返り 2. ACEのご紹介 3. Cloud Design Pattern とは 4. 今回の大量データ処理の概要 5. Microsoft Azure におけるPaaSとScaling 6. Scalingを前提とした大量データ処理用アーキテクチャ 7. クラウド汎用パターン あらゆるプロジェクトで使用推奨
  3. 3. 1.前編の振り返り
  4. 4. トリニティで Cloud Design Pattern を支援 • 技術観点 3つと実現指向の アーキ・トレンド “トリニティ” 2014 (C) Arichika Taniguchi, All rights reserved. • 入力と処理、出力の分割 • 長時間ロードの分割 非同期 • 疎結合での負荷移動の容易さ • 負荷単位でのSLAと制御 運用性 • トランザクションの整合性 • 処理中の緩い整合性の許容 完全性 Business Architect Code Architect Infra(Model) Architect Science
  5. 5. 2.ACEのご紹介
  6. 6. Microsoft Azure パートナーコンソーシアム Azure Council Experts(略称:ACE/エース)アジュール評議会は、 Microsoft Azure を利用した技術やサービスを提供するリーディングカンパニー が集結し、普及ならびに技術者の育成、ノウハウの共有などでコラボレーション を展開するパートナーコンソーシアム。 顧客企業・団体技術者 一般社団法人 Azure Council Experts について http://a-c-e.biz/
  7. 7. Microsoft Azure パートナーコンソーシアム 【書籍の出版】 【ACE加盟企業による定例会&ワーキンググループの活動の様子】 Azure Council Experts 著 日本マイクロソフト 監修 発行:日経BP社 編集:日経SYSTEMS ページ数:176P ターゲット:アーキテクト、システムエンジニア 一般社団法人 Azure Council Experts について
  8. 8. スピーカー自己紹介 • 株式会社ネクストスケープ(ACE理事企業) Microsoft Partner of the Year 2012 Windows Azure パートナー アワード 受賞 (日本13,000事業所中) Microsoft Partner of the Year 2013 Windows Azure パートナー アワード(System Integrator) 受賞 (日本14,000事業所中) 2013 Microsoft Worldwide Partner Award Cloud Partner of the Year 世界2位 (世界3,000事業所中) こんな会社です • 配信ソリューション • Microsoft Azure導入支援 • DRMソリューション(PlayReady) • システム・インテグレーション • Sitecore(CMS)導入支援
  9. 9. スピーカー自己紹介 • 上坂貴志(うえさかたかし) 株式会社ネクストスケープでアーキテクトやってます。 東京出身のおっさんです。 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 前編、後編~
  10. 10. 3.Cloud Design Pattern とは
  11. 11. Cloud Design Pattern とは http://msdn.microsoft.com/en-us/library/dn568099.aspx  24のデザインパターン 10のガイダンス  コードサンプル
  12. 12. Cloud Design Pattern とは 10のガイダンス 24のデザインパターン 可用性 管理と監視 データ管理 パフォーマンスとスケーラビリティ 設計と実装 弾力性 メッセージング セキュリティ ⇒ 8つのカテゴリに分類
  13. 13. 10のガイダンス 非同期メッセージング入門 オートスケールガイダンス キャッシュガイダンス アプリケーション分割ガイダンス データ整合性入門 データパーティション分割ガイダンス データレプリケーション&同期ガイダンス インストルメンテーションとテレメトリガイダンス 複数データセンター展開ガイダンス サービスメータリングガイダンス Cloud Design Pattern とは
  14. 14. 24のデザインパターン キャッシュアサイドパターン 回路ブレーカーパターン 補正トランザクションパターン 競合する消費者パターン リソース統合計算パターン コマンドクエリ分離パターン(CQRS) イベントソースパターン 外部構成ストアパターン フェデレーション Idパターン ゲートキーパーパターン エンドポイントヘルス監視パターン インデックステーブルパターン リーダー選挙パターン マテリアライズドビューパターン パイプとフィルターパターン 優先度キューパターン キューベースのロード平準化パターン リトライパターン 実行時再構成パターン スケジューラエージェントスーパーバ イザーパターン Shardingパターン 静的コンテンツホスティングパターン 抑制パターン 係員付きパーキングサービスキーパ ターン Cloud Design Pattern とは
  15. 15. 4.今回の大量データ処理の概要
  16. 16. • 楽曲データを配信用に加工する処理(パッケージング) 今回の大量データ処理の概要 楽曲コンテンツ エンコード処理 トランスコード処理 暗号化処理 アップロード • エンコード処理にかかる処理時間 1曲あたり、2分半~3分半。これが120万曲。 120万 x 3分 = 6万時間!(2500日)
  17. 17. 5.Microsoft Azure における PaaSとScaling
  18. 18. Microsoft Azure におけるPaaSとScaling • PaaSとは、アプリケーションが稼動するための基盤(Platform)がサービスとして提供されたもの。 アプリケーション OS 仮想化 サーバー ストレージ ネットワーク ミドルウェア アプリケーション アプリケーション オン・プレミス IaaS PaaS Runtime データ OS 仮想化 サーバー ストレージ ネットワーク ミドルウェア Runtime データ OS 仮想化 サーバー ストレージ ネットワーク ミドルウェア Runtime データ アプリケーション SaaS OS 仮想化 サーバー ストレージ ネットワーク ミドルウェア Runtime データ ユーザーが管理 クラウドベンダーが管理ユーザーが管理 ユーザーが管理クラウドベンダーが管理 クラウドベンダーが管理
  19. 19. Microsoft Azure におけるPaaSとScaling Scalingとは 要求される作業量に応じて性能・処理能力 を増減すること。 Scalingには 垂直スケール(ScaleUp)と水平スケール (ScaleOut)の2つがある。 ScaleUp ScaleOut
  20. 20. Microsoft Azure におけるPaaSとScaling • Microsoft Azure の場合 PaaSに対してスケールの例 インスタンス数(PaaS数) を入力して保存するだけ! (手動によるスケール)
  21. 21. Microsoft Azure におけるPaaSとScaling Microsoft AzureにおけるPaaS • クラウドサービスという名称 • VisualStudioから簡単にデプロイ可能 • JenkinsなどのCIツールを使用したデプロイも可能(Azure Powershell使用) • WebRole(Web用)と、WorkerRole(バッチ用)の2種類をホスト • StagingとProduction環境 • Stagingにデプロイして稼働確認→Productionへスワップ!(ボタン一発) • リモートデスクトップで接続可能
  22. 22. Microsoft Azure におけるPaaSとScaling Microsoft AzureにおけるScaling • Webの管理画面から手動でインスタンス数を増減可能 • オートスケールを設定可能 • CPU負荷に応じて増減 • 参照するメッセージQueueの数に応じて増減 • スケジュール設定で増減
  23. 23. 6.ScaleOutを前提とした大量データ処理 用アーキテクチャ
  24. 24. 処理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
  25. 25. ScaleOutを前提とした大量データ処理用アーキテ クチャ • Queue数をベースにオートスケール AutoScale PaaS メッセージ Queue Queue数によるスケール設定 1インスタンス当たりに処理するQueueの数 • 増減しきい値に相当 総インスタンス数の Min値、Max値 1度に増減するインスタンス数 AutoScale PaaS メッセージ Queue
  26. 26. ScaleOutを前提とした大量データ処理用アーキテ クチャ • タスクの統合 楽曲コンテンツ エンコード処理 トランスコード処理 暗号化処理 アップロード 負荷高 負荷低 負荷低 楽曲コンテンツ エンコード処理 トランスコード処理 暗号化処理 アップロード 別処理
  27. 27. ScaleOutを前提とした大量データ処理用アーキテ クチャ • 最終形 楽曲コンテンツ エンコード処理 トランスコード処理 暗号化処理 アップロード メッセージ Queue Queue投入 メッセージ Queue AutoScale AutoScale
  28. 28. ScaleOutを前提とした大量データ処理用アーキテ クチャ 使用した Cloud Design Pattern 競合する消費者パターン スループット、スケーラビリティと可用性の向上と、作業負荷を最適化す るために同時に複数のメッセージを処理することを可能にする パイプとフィルターパターン タスク要素のデプロイとスケーリング処理を別々に実行することにより、 パフォーマンス、スケーラビリティ、および再利用性を向上できる リソース統合計算パターン 計算リソースの使用率を高め、クラウドでホストされるアプリケーション の処理の実行に関連するコストと管理オーバーヘッドを減らすことができ る
  29. 29. ScaleOutを前提とした大量データ処理用アーキテ クチャ • 競合する消費者パターン • 概要 • スループット、スケーラビリティと可用性の向上と、作業負荷を最適化するために同時に複数のメッセージを処理することを可能にします。 • 戦略 • クラウドで実行されるアプリケーションが多数の要求を処理することを可能にします。 • 一般的な手法は、各要求を同期的に処理するのではなく、要求をメッセージングシステムを通して他の非同期にサービスに渡すことです。 • この戦略は、要求の処理中、アプリケーションのビジネス ロジックがブロックされないようにするのに役立ちます。 メッセージ Queue アプリーケーションインスタンス メッセージ生成 サービスインスタンス メッセージ処理
  30. 30. パイプライン ScaleOutを前提とした大量データ処理用アーキテ クチャ • パイプとフィルターパターン • 概要 • 複雑な処理を実行するタスクを再利用可能な一連の個別要素に分解します。このパターンはタスク要素をデプロイとスケーリング処理を別々に実行 することによってパフォーマンス、スケーラビリティ、および再利用性を向上できます。 • 戦略 • 1 つのタスクを実行するそれぞれの個別のコンポーネント (またはフィルター) のセットに処理を分解します。 • 各コンポーネント(またはフィルター)が受信し、出力するデータの形式を標準化することで、パイプライン内で複数のコンポーネント(またはフィル ター) を組み合わせることができる。 メッセージ Queue フィルター メッセージ Queue フィルター
  31. 31. ScaleOutを前提とした大量データ処理用アーキテ クチャ • リソース統合計算パターン • 概要 • 複数のタスクまたは操作を 1 つの計算ユニットに統合します。このパターンはコンピューティング リソースの使用率を増加し、クラウドでホストさ れるアプリケーションでの処理を実行するために必要なコストと管理オーバーヘッドを削減できます。 • 戦略 • タスクは、環境によって提供される機能に基づいて、様々な基準や機能に関連したコストに応じてグループ化することができます。 • 一般的なアプローチは、そのスケーラビリティ、有効期間、および処理の要件に関して同様のプロファイルを持っているタスクを探します。 • これらのタスクを一つのグループの単位としてスケールできます。 Task A Task E 計算ユニット 計算ユニット Task B 計算ユニット Task C 計算ユニット Task D 計算ユニット Task A Task E 計算ユニット 計算ユニット Task B Task C Task D
  32. 32. 7.クラウド汎用パターン あらゆるプロジェクトで使用推奨
  33. 33. クラウド汎用パターン あらゆるプロジェクトで使用推奨 • Retryパターン • 概要 • クラウドでは一時的な障害は珍しくない。障害発生時にその影響を最小限に抑える。 • 戦略 • 障害を示すエラーが一時的でない、または繰り返し要求しても成功する可能性が無い場合 、アプリケーションは操作を中止し、適切な例外を報告す る必要がある。 (例:資格情報が無効なため、何度挑戦しても失敗する) • 報告された例外が通常は起こりえないものや極希少なものの場合、極めて異常な事情によってその例外が引き起されている可能性がある。(例: ネットワークパケットの破損)このような場合は同一の障害が繰り返される可能性は低いし、再要求は恐らく成功するので直ちに再試行を行う。 • 障害の原因が一般的な接続の問題や接続先がビジー状態によるものの場合、接続時の問題が解決するか、接続先のタスクがクリアされるまで短時間 の待ち時間が必要な場合がある。このような場合、アプリケーションは要求を再試行する前に適切な時間を待つ必要がある。 アプリケーション サービス 1 500 2 500 3 200
  34. 34. クラウド汎用パターン あらゆるプロジェクトで使用推奨 • 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; }
  35. 35. クラウド汎用パターン あらゆるプロジェクトで使用推奨 • でも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 • 拡張メソッドと実装済みの戦略が提供されています。
  36. 36. クラウド汎用パターン あらゆるプロジェクトで使用推奨 エラーNo エラー内容 40501 10929 サービスは現在ビジー状態 10928 同時要求の最大制限が 180 を超えたため要求を拒否 10053 サーバーから結果を受信するときにトランスポート レベルのエラーが発生。クライアントが切断 10054 サーバーから結果を受信するときにトランスポート レベルのエラーが発生。サーバーが切断 10060 Socket接続エラー。サーバーが見つからない 40197 要求の処理中にソフトウェアやハードウェアのアップグレードのためのサービス停止、ハードウェア エラー、またはその他のフェールオーバーの問題が発生 40540 要求処理中にエラーに遭遇。再試行を。 40613 サーバー上のデータベースが使用不可 233 未サポートバージョンのSQLServerへ接続しようとした;サーバービジーで新しい接続を生成できなかった;メモリ不足で新しい接続を生成できなかった 64 接続は成功したが、ログインに失敗した 20 接続先のSQLServerインスタンスはencryptionをサポートしていない SqlDatabaseTransientErrorDetectionStrategyが一時的なエラーである、と判定するエラーの種類 ※TimeoutException も一時的なエラーと判定される
  37. 37. • 外部構成ストアパターン • 概要 • 複数のアプリケーションやインスタンスで構成設定を共有する。 • 戦略 • 外部記憶装置に構成情報を格納し、迅速かつ効率的に読み取りおよび設定を更新するために使用できるインターフェイスを提供する。 • 外部ストアの種類は、アプリケーションのホスティング、ランタイム環境に依存する。 • クラウドでホストされているシナリオでは通常、クラウド ・ ベースのストレージ サービス。もしくはデータベース、他のシステムになる可能性もあ る。 クラウド汎用パターン あらゆるプロジェクトで使用推奨 Application 外部構成ストアApplication Application クラウド・ストレージ データベース 代替オプション
  38. 38. クラウド汎用パターン あらゆるプロジェクトで使用推奨

×