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

Microsoft Architect Forum 2013
マルチテナントクラウド
アプリケーションの設計手法
Masashi Narumoto
masashin@microsoft.com

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)
テナント数の制限がない
管理が容易

テーブルストレージの分離
adatum
adatum
fabrikam
fabrikam
fabrikam
contoso
adatum_surveyA
adatum_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ロールの実装と考慮事項
 スケーラビリティ戦略とテスト
 ユーザー認証における３つの選択肢
 マルチテナント環境の管理

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ロール
をアサインするか、１つの
ロールで複数タスクを実行
 コスト、スケーラビリティ、
実装の容易さで決定

Optimistic concurrency control
Client
A
Client
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, 5
If-Match:
1 Ch9, Jan-2, 4
Version Rating
1: Ch9, Jan-2, 41: Ch9, Jan-2, 5
Error: 412
2: Ch9, Jan-2, 5

Scheduler - Supervisor
User
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
Asynchronously
4
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 ProcessOrders
Set
LockedBy =
‘unique worker role
instance ID’,
LockedUntil = now + X
Where
Status = (Not processed OR
Processed with Errors) AND
LockedUntil < now

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に一環したアーキテクチャ
 あらゆるシナリオに対応する豊富な選択肢
 開発環境の充実
 サポート体制
 エンタープライズにおける実績
 世界規模のパートナーシップ

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

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

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

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

More from Kazuyuki Nomura

More from Kazuyuki Nomura (11)

Recently uploaded

Recently uploaded (10)