Upload
nomura-kazuyuki
View
2.186
Download
4
Embed Size (px)
DESCRIPTION
本セッションでは Windows Azure におけるマルチ テナント型 SaaS アプリケーションの設計手法について解説します。マルチ テナント アーキテクチャに共通する課題である、データのパーティショニング、データの拡張性、自動化されたプロビジョニング、スケーラビリティの向上などについて議論します
Citation preview
アジェンダ
Demo :Multi-tenant Application
マルチテナントの必要性と課題
• 運用コスト
• コードベース管理
• テナント間の干渉
• カスタマイズ要求
• Service Level Agreement
マルチテナントの考慮事項
ストレージの選択とパーティショニング
データスキーマの拡張性
パーティショニング-それ以外の要素
スケーラビリティ
プロビジョニング
ユーザー認証の選択肢
管理とモニタリング
UIの拡張性
課金
ストレージの選択
IaaS vs. PaaS
SQL vs. NoSQL
Key Value, Document,
Column Family or Graph
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%
機能 SQL NoSQL
インターオペラビリティ 多くのANSIやISO標準によってほとんどの製品間で互換
性がある
標準化されたAPI (ODBC, SQL/CLI) により、異なるベ
ンダーの製品に対して統一されたアプリケーションか
らのアクセスが可能
APIやデータフォーマットもベンダーごとに異なり、製品間の互
換性はあまりない
ベンダーが異なると、アプリケーションからのアクセスは書き換
えが必要
コンプレックスデータの
格納
複雑なデータタイプは冗長性を排除するために正規化
され複数のテーブルに格納される。データの取得には
複雑なSQLクエリーを実行しなければならない。
ORMによる抽象化は可能だが、非効率でもある
複雑なデータタイプでも一か所に格納することができるので、ア
プリケーションとデータベース間のミスマッチは発生しない。
非正規化されたデータを扱うコストと引き換えに速いデータアク
セスが可能.
クエリーの実行 リレーショナルデータのグルーピングやサマリーに最
適化されている
非リレーショナルで複雑なデータを扱うのは苦手
単一アグリゲートからのキーによる値の取得に最適化されている
サマリーやグルーピングは別途Map/Reduceの実行を必要とす
る
スケーラビリティ 分散トランザクションやDB間クエリーをサポートする
ためScale-upに向いている
いくつかのベンダーはクラスタリングやShardingに
よって分散環境をサポートしている
Scaling-outシナリオに最適化されている.
ほとんどの製品はクラスタリングやShardingを標準サポート.
大容量データセットの
性能
大容量データセットのリード・ライトにはかなりの
チューニングを必要とする
大容量データセットのアクセスに最適化されている
データの一貫性 ACID一貫性を提供する。分散環境ではパフォーマンス
が犠牲となる
分散環境におけるBASEトランザクションを前提とした設計
単一アグリゲート内でのACIDをサポートするケースもある
インテグレーション 複数のアプリケーション間での共有が容易。RDBがアプ
リケーションを統合する役割を果たす。
単一のアプリケーションのために使われることが多い。アプリ
ケーション間の統合はアプリケーションによって行われる
Key Value Stores
大規模ハッシュテーブル
Key/Valueペアとして格納
キーを使用したアクセスに最適
単純なクエリーをサポート
Windows Azure Table
Document database
非正規化データ
単一クエリーですべてのデータを取得
JSONやXMLなどのデータ格納に最適
Windows Azure Blob,
Mongo DB
Column family database
カラムが複数の値を持つ
ROWごとに異なるカラムのレイアウトを持つ
特定カラムのIndexをサポート
特定カラムへのアクセスに最適
HBase, Cassandra
Graph database
ノードとエッジそれぞれがプロパティを持つ
エッジは方向性を持つ
ネットワーク状の関連構造を表現するのに最適
Neo4j
ストレージのパーティショニング
サブスクリプションによる分離ストレージアカウントによる分離
高分離レベル 低分離レベル
テーブル・コンテナによる分離SQLデータベースによる分離SQLテーブルによる分離
パーティションキーによる分離SQLテーブル共有モデル
テナント間の干渉が低いシンプルな課金カスタマイズが容易スロットリングの心配が少ない
コストが低い(SQL DB)テナント数の制限がない管理が容易
テーブルストレージの分離
adatumadatum
fabrikam
fabrikam
fabrikam
contoso
adatum_surveyAadatum_surveyB
fabrikam_surveyA
fabrikam_surveyB
fabrikam_surveyC
Contoso_surveyA
adatumfabrikam
contoso
データスキーマの拡張
テナントA:アンケート結果と社内キャンペーンIDを関連づけたい
テナントB:アンケート結果とプロダクト名を関連づけたい
テーブルストレージの拡張性
テナントごとに別テーブル
複数スキーマを持つ単一テーブル
単一テーブルと拡張用の別テーブル
拡張フィールドへのアクセス
パーティショニング-それ以外の要素
Web/Workerロール
キュー
サービスバス
キャッシュ
ACS
VM/VNET
Diagnosticデータ
Management API certs
インスタンス境界の設計
マルチインスタンス・シングルテナント
シングルインスタンス・マルチテナント
マルチインスタンス・マルチテナント
インスタンス境界の設計• コスト
• コードベース管理
• Service Level Agreement
• スケーラビリティ
• リソースの制限
• 認証と承認
• カスタマイゼーション
• ALM
• 課金
• 3rdパーティコンポーネント
• レギュレーション
キャッシュのパーティショニング
• Named Cacheによる分離
• Regionによる分離
• インスタンス共有
• ストレージ分離戦略との整合性を考慮
Web/Workerロールのパーティショニング
サブスクリプションによる分離
高分離レベル 低分離レベル
Cloud Serviceによる分離 ロールインスタンスの共有
テナント間の干渉が低いシンプルな課金カスタマイズが容易
コストが低いテナント数の制限がない管理が容易
Webリクエストのルーティング
URLパスhttp://surveys.tailspin.com/fabrikam
サブドメインhttp://fabrikam.tailspinsurveys.com
カスタムドメイン名のマッピングhttp://surveys.fabrikam.com
認証、SSL、プロビジョニングへの影響を考慮
Queueのパーティショニング
Workerロール
Webロールの負荷軽減
Loadの平準化
スケーラビリティ
タスクのアサイン
キューによる優先度コントロール
ペシミスティック vs. オプティミスティック同時アクセス制御
プログレストラッキング
スケーラビリティ
非同期コール
小さいインスタンスをSO
自動化
スケーラビリティユニット
テストによるボトルネックの削除
ストレステスト
Visual Studio Load Test
高負荷による例外の発見
ボトルネックの発見
ストレージIO
CPU負荷
ネットワーク転送
キュー
プロビジョニング
リソースのセットアップ
コンフィグレーション
カスタマイゼーション
認証方式の設定
プロセスの自動化
ユーザー認証
既存STSとのSSO
1stパーティIdPの提供
3rdパーティーIdPとの連携
Claim based Identity管理
管理とモニタリング
テスタビリティ
スクリプトによる管理の自動化
コンフィグレーション
システム診断
エンドポイントの保護
その他の考慮事項
サブスクリプションモデル
課金
Service Level Agreement
Throttling
On-boarding プロセス
まとめ データタイプに応じて適切なストレージを選択
ストレージとその他要素のパーティショニング戦略
Workerロールの実装と考慮事項
スケーラビリティ戦略とテスト
ユーザー認証における3つの選択肢
マルチテナント環境の管理
Microsoft Architect Forum 2013
Resources
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
その他のデザインパターン
データアクセス
コンカレンシー制御
キュー管理
ワークフロー
データアクセス-Delayed write
データアクセス-Directly write
Workerロール
タスクごとにWorkerロールをアサインするか、1つのロールで複数タスクを実行
コスト、スケーラビリティ、実装の容易さで決定
Optimistic concurrency controlClient
AClient
B
5 : Ch9, Jan-1, 3
1 : 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, 6
If-Match: 1 Ch9, Jan-2, 5If-Match: 1 Ch9, Jan-2, 4
Version Rating1: Ch9, Jan-2, 41: Ch9, Jan-2, 5
Error: 4122: Ch9, Jan-2, 5
Scheduler - Supervisor
Scheduler - SupervisorUser
places a
new order
WorkerRole task
(“Supervisor”)
SB Topics
“new
order”
Orders
Job Store
The order and a ProcessOrder
record are inserted using the same
database transaction, and the user
receives the confirmation that the
new order has been placed
1
2
“Checks-out” the “failed” or
“timeout” records and
resume the process from
where it failed
OrderId:154, LockedBy: null,
LockedUntil: null,
ProcessCount:0, Status: Not
processed, Timeout:xx sec
Id:154, Ammount:$ 1000,
Address…
One-to-one
relationship
SB reply
queue
WorkerRole task
(“Scheduler”)
WebRole
Sends the “new order”
message to Topics
Asynchronously4
The worker role
receives “order
received” message
from queue
6Update the record w/
“request sent”5
Gets the record w/ “Not
processed” owned by WR
3
Update the record w/
“request received”7
“Check-out”:
Update ProcessOrdersSet
LockedBy = ‘unique worker role instance ID’,
LockedUntil = now + XWhere
Status = (Not processed OR Processed with Errors) AND
LockedUntil < now
Progress tracking
BLOBストレージのPaging
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
データスキーマの拡張
コンフィギュレーション
ディクショナリー
アセンブリーのReflection
バージョン管理
データアクセスレイヤーとの相性
データスキーマの拡張
• クエリーのパフォーマンス
• トランザクション要件
• コードの複雑さ
• データ管理
• スケーラビリティ
• ジオロケーション
Windows Azureの優位性 パフォーマンス: Windows AzureがNo.1
Writeにおいて第2位のAWSより 56%速く,Readにおいて第2位のHP
Cloud 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%を示した。
Windows Azureの優位性 パフォーマンスと可用性においてNo.1
オンプレミスとの対称アーキテクチャ
ハイブリッド構成をサポートする機能グループ
IaaS, PaaS, SaaSに一環したアーキテクチャ
あらゆるシナリオに対応する豊富な選択肢
開発環境の充実
サポート体制
エンタープライズにおける実績
世界規模のパートナーシップ