Microsoft Architect Forum 2013

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

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

テーブルストレージの分離

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ロールの実装と考慮事項

スケーラビリティ戦略とテスト

ユーザー認証における３つの選択肢

マルチテナント環境の管理

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 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に一環したアーキテクチャ

あらゆるシナリオに対応する豊富な選択肢

開発環境の充実

サポート体制

エンタープライズにおける実績

世界規模のパートナーシップ