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.

マルチ テナント クラウド アプリケーションの設計手法

4,700 views

Published on

本セッションでは Windows Azure におけるマルチ テナント型 SaaS アプリケーションの設計手法について解説します。マルチ テナント アーキテクチャに共通する課題である、データのパーティショニング、データの拡張性、自動化されたプロビジョニング、スケーラビリティの向上などについて議論します

Published in: Technology
  • Be the first to comment

マルチ テナント クラウド アプリケーションの設計手法

  1. 1. Microsoft Architect Forum 2013マルチテナントクラウドアプリケーションの設計手法Masashi Narumotomasashin@microsoft.com
  2. 2. アジェンダ
  3. 3. Demo :Multi-tenant Application
  4. 4. マルチテナントの必要性と課題• 運用コスト• コードベース管理• テナント間の干渉• カスタマイズ要求• Service Level Agreement
  5. 5. マルチテナントの考慮事項 ストレージの選択とパーティショニング データスキーマの拡張性 パーティショニング-それ以外の要素 スケーラビリティ プロビジョニング ユーザー認証の選択肢 管理とモニタリング UIの拡張性 課金
  6. 6. ストレージの選択 IaaS vs. PaaS SQL vs. NoSQL Key Value, Document,Column Family or Graph
  7. 7. IaaS vs. PaaS機能 SQL on VM SQL Database分離レベル インフラストラクチャレベルでの分離 複数ユーザーの同居スロットリング 無し 有りドメインへの参加 ドメインへ参加可能、Windows 統合認証が可能 不可能コンパティビリティ オンプレミスのSQLサーバーと完全互換SSIS, SSAS, SSRSなどのフル機能をサポート移行シナリオでは、変更の必要がない限定的な機能移行シナリオにおいてサポートされている機能の検証が必要暗号化サポート 有り 無しスケーラビリティ X-Large VM, 8 cores, 14GB RAM, 16 TB disk までスケールアップ可能最大で150GB、Federationによるスケールアウトのサポートコスト コストが高い コストが比較的低い管理工数 プロビジョニングと仮想マシンの管理が必要 管理はほとんど不要SLA OOBではSLAは保障されない(Always Onが必要)99.9%
  8. 8. 機能 SQL NoSQLインターオペラビリティ 多くのANSIやISO標準によってほとんどの製品間で互換性がある標準化されたAPI (ODBC, SQL/CLI) により、異なるベンダーの製品に対して統一されたアプリケーションからのアクセスが可能APIやデータフォーマットもベンダーごとに異なり、製品間の互換性はあまりないベンダーが異なると、アプリケーションからのアクセスは書き換えが必要コンプレックスデータの格納複雑なデータタイプは冗長性を排除するために正規化され複数のテーブルに格納される。データの取得には複雑なSQLクエリーを実行しなければならない。ORMによる抽象化は可能だが、非効率でもある複雑なデータタイプでも一か所に格納することができるので、アプリケーションとデータベース間のミスマッチは発生しない。非正規化されたデータを扱うコストと引き換えに速いデータアクセスが可能.クエリーの実行 リレーショナルデータのグルーピングやサマリーに最適化されている非リレーショナルで複雑なデータを扱うのは苦手単一アグリゲートからのキーによる値の取得に最適化されているサマリーやグルーピングは別途Map/Reduceの実行を必要とするスケーラビリティ 分散トランザクションやDB間クエリーをサポートするためScale-upに向いているいくつかのベンダーはクラスタリングやShardingによって分散環境をサポートしているScaling-outシナリオに最適化されている.ほとんどの製品はクラスタリングやShardingを標準サポート.大容量データセットの性能大容量データセットのリード・ライトにはかなりのチューニングを必要とする大容量データセットのアクセスに最適化されているデータの一貫性 ACID一貫性を提供する。分散環境ではパフォーマンスが犠牲となる分散環境におけるBASEトランザクションを前提とした設計単一アグリゲート内でのACIDをサポートするケースもあるインテグレーション 複数のアプリケーション間での共有が容易。RDBがアプリケーションを統合する役割を果たす。単一のアプリケーションのために使われることが多い。アプリケーション間の統合はアプリケーションによって行われる
  9. 9. Key Value Stores 大規模ハッシュテーブル Key/Valueペアとして格納 キーを使用したアクセスに最適 単純なクエリーをサポート Windows Azure Table
  10. 10. Document database 非正規化データ 単一クエリーですべてのデータを取得 JSONやXMLなどのデータ格納に最適 Windows Azure Blob,Mongo DB
  11. 11. Column family database カラムが複数の値を持つ ROWごとに異なるカラムのレイアウトを持つ 特定カラムのIndexをサポート 特定カラムへのアクセスに最適 HBase, Cassandra
  12. 12. Graph database ノードとエッジそれぞれがプロパティを持つ エッジは方向性を持つ ネットワーク状の関連構造を表現するのに最適 Neo4j
  13. 13. ストレージのパーティショニングサブスクリプションによる分離ストレージアカウントによる分離高分離レベル 低分離レベルテーブル・コンテナによる分離SQLデータベースによる分離SQLテーブルによる分離パーティションキーによる分離SQLテーブル共有モデルテナント間の干渉が低いシンプルな課金カスタマイズが容易スロットリングの心配が少ないコストが低い(SQL DB)テナント数の制限がない管理が容易
  14. 14. テーブルストレージの分離adatumadatumfabrikamfabrikamfabrikamcontosoadatum_surveyAadatum_surveyBfabrikam_surveyAfabrikam_surveyBfabrikam_surveyCContoso_surveyAadatumfabrikamcontoso
  15. 15. データスキーマの拡張テナントA:アンケート結果と社内キャンペーンIDを関連づけたいテナントB:アンケート結果とプロダクト名を関連づけたい
  16. 16. テーブルストレージの拡張性テナントごとに別テーブル複数スキーマを持つ単一テーブル単一テーブルと拡張用の別テーブル
  17. 17. 拡張フィールドへのアクセス
  18. 18. パーティショニング-それ以外の要素 Web/Workerロール キュー サービスバス キャッシュ ACS VM/VNET Diagnosticデータ Management API certs
  19. 19. インスタンス境界の設計 マルチインスタンス・シングルテナント シングルインスタンス・マルチテナント マルチインスタンス・マルチテナント
  20. 20. インスタンス境界の設計• コスト• コードベース管理• Service Level Agreement• スケーラビリティ• リソースの制限• 認証と承認• カスタマイゼーション• ALM• 課金• 3rdパーティコンポーネント• レギュレーション
  21. 21. キャッシュのパーティショニング• Named Cacheによる分離• Regionによる分離• インスタンス共有• ストレージ分離戦略との整合性を考慮
  22. 22. Web/Workerロールのパーティショニングサブスクリプションによる分離高分離レベル 低分離レベルCloud Serviceによる分離 ロールインスタンスの共有テナント間の干渉が低いシンプルな課金カスタマイズが容易コストが低いテナント数の制限がない管理が容易
  23. 23. Webリクエストのルーティング URLパスhttp://surveys.tailspin.com/fabrikam サブドメインhttp://fabrikam.tailspinsurveys.com カスタムドメイン名のマッピングhttp://surveys.fabrikam.com 認証、SSL、プロビジョニングへの影響を考慮
  24. 24. Queueのパーティショニング
  25. 25. Workerロール Webロールの負荷軽減 Loadの平準化 スケーラビリティ タスクのアサイン キューによる優先度コントロール ペシミスティック vs. オプティミスティック同時アクセス制御 プログレストラッキング
  26. 26. スケーラビリティ 非同期コール 小さいインスタンスをSO 自動化 スケーラビリティユニット テストによるボトルネックの削除
  27. 27. ストレステスト Visual Studio Load Test 高負荷による例外の発見 ボトルネックの発見 ストレージIO CPU負荷 ネットワーク転送 キュー
  28. 28. プロビジョニング リソースのセットアップ コンフィグレーション カスタマイゼーション 認証方式の設定 プロセスの自動化
  29. 29. ユーザー認証 既存STSとのSSO 1stパーティIdPの提供 3rdパーティーIdPとの連携 Claim based Identity管理
  30. 30. 管理とモニタリング テスタビリティ スクリプトによる管理の自動化 コンフィグレーション システム診断 エンドポイントの保護
  31. 31. その他の考慮事項 サブスクリプションモデル 課金 Service Level Agreement Throttling On-boarding プロセス
  32. 32. まとめ データタイプに応じて適切なストレージを選択 ストレージとその他要素のパーティショニング戦略 Workerロールの実装と考慮事項 スケーラビリティ戦略とテスト ユーザー認証における3つの選択肢 マルチテナント環境の管理
  33. 33. Microsoft Architect Forum 2013Resources Developing Multi-tenant Applications in the Cloud http://msdn.microsoft.com/en-us/library/ff966499.aspx http://WAG.codeplex.com http://pnp.azurewebsites.net/en-us/ http://windowsazure.com
  34. 34. その他のデザインパターン データアクセス コンカレンシー制御 キュー管理 ワークフロー
  35. 35. データアクセス-Delayed write
  36. 36. データアクセス-Directly write
  37. 37. Workerロール タスクごとにWorkerロールをアサインするか、1つのロールで複数タスクを実行 コスト、スケーラビリティ、実装の容易さで決定
  38. 38. Optimistic concurrency controlClientAClientB5 : Ch9, Jan-1, 31 : Ch9, Jan-2, 21 : Ch9, Jan-2, 21 : Ch9, Jan-2, 22: Ch9, Jan-2, 5 HTTPの標準メカニズムを使用 – Etag とIf-Match エンティティの取得 – Etagとしてバージョンを取得 ローカルでエンティティの更新 – レイティングの変更 バージョンチェック付きアップデート - IF-Match with Etag バージョンがマッチしたら成功, 新たにバージョンを更新 バージョンがマッチしなければエラー、Precondition failed (412)9 : Ch9, Jan-3, 6If-Match:1 Ch9, Jan-2, 5If-Match:1 Ch9, Jan-2, 4Version Rating1: Ch9, Jan-2, 41: Ch9, Jan-2, 5Error: 4122: Ch9, Jan-2, 5
  39. 39. Scheduler - Supervisor
  40. 40. Scheduler - SupervisorUserplaces anew orderWorkerRole task(“Supervisor”)SB Topics“neworder”OrdersJob StoreThe order and a ProcessOrderrecord are inserted using the samedatabase transaction, and the userreceives the confirmation that thenew order has been placed12“Checks-out” the “failed” or“timeout” records andresume the process fromwhere it failedOrderId:154, LockedBy: null,LockedUntil: null,ProcessCount:0, Status: Notprocessed, Timeout:xx secId:154, Ammount:$ 1000,Address…One-to-onerelationshipSB replyqueueWorkerRole task(“Scheduler”)WebRoleSends the “new order”message to TopicsAsynchronously4The worker rolereceives “orderreceived” messagefrom queue6Update the record w/“request sent”5Gets the record w/ “Notprocessed” owned by WR3Update the record w/“request received”7“Check-out”:Update ProcessOrdersSetLockedBy =‘unique worker roleinstance ID’,LockedUntil = now + XWhereStatus = (Not processed ORProcessed with Errors) ANDLockedUntil < now
  41. 41. Progress tracking
  42. 42. BLOBストレージのPaging
  43. 43. async Task<int> AccessTheWebAsync(){HttpClient client = new HttpClient();Task<string> getStringTask =client.GetStringAsync("http://msdn.microsoft.com");DoIndependentWork();string urlContents = await getStringTask;return urlContents.Length;}Source codes
  44. 44. データスキーマの拡張 コンフィギュレーション ディクショナリー アセンブリーのReflection バージョン管理 データアクセスレイヤーとの相性
  45. 45. データスキーマの拡張• クエリーのパフォーマンス• トランザクション要件• コードの複雑さ• データ管理• スケーラビリティ• ジオロケーション
  46. 46. Windows Azureの優位性 パフォーマンス: Windows AzureがNo.1 Writeにおいて第2位のAWSより 56%速く,Readにおいて第2位のHPCloud Object Storageより39%速い 可用性: Windows AzureがNo.1 Windows Azureの平均レスポンスタイムは第2位のAmazon S3より25%速い スケーラビリティ:AzureとAWSが他を大きくリード Amazon S3 は平均0.6% 、Windows Azure は1.9%. OpenStackベースのHP とRackspace は23.5% と26.1%を示した。
  47. 47. Windows Azureの優位性 パフォーマンスと可用性においてNo.1 オンプレミスとの対称アーキテクチャ ハイブリッド構成をサポートする機能グループ IaaS, PaaS, SaaSに一環したアーキテクチャ あらゆるシナリオに対応する豊富な選択肢 開発環境の充実 サポート体制 エンタープライズにおける実績 世界規模のパートナーシップ

×