Transcript T1-401
萩原 正義
アーキテクト
マイクロソフト株式会社
アプリケーション開発を通じて
Azure を理解する
Windows Azure
Scale out 設計の指針
開発手法
まとめ
インメモリデータだけで可用性を実現可能か？
複数の Replica（複製）をノード間で持ち合う
primary と secondary（replica）
書き込みは primary へ
ノードの障害： 別ノードを参加させ複製
primary の複製、secondary の複製
ノード間の通信障害： 2つの問題
Replica への複製（log shipping）をデータ更新と非同期
で実行
Replica を持つノードからの応答を多数決で判断
Scale out による負荷分散、スケーラビリ
ティの実現
トランザクションスループット
同時アクセスユーザ数
データ量
データ/インスタンス（インメモリ）を膨大な
ノードが分担
mod N だと負荷分散はするが、ノードの追加、削
除での再配置コストが高く、ノード数増大で限界
consistent hashing ノードの追加、削除による再配
置の局所化
ノードとデータ/インスタンスの双方に ID を振る
時計周りの最初のノード（Chord）、ID が数値的に最も
近い（Pastry）などが代表的アルゴリズム
Azure は双方向 Chord
到達までのホップ数と経路表のエントリー数はトレードオフ
ノード数が増大しないとペイしない（no-hop を超える
ノード数）
ノード数が少なければ全員は全員を知っていればよい
ノードが自律的に障害を監視し、到達経路を自動調整
全体を管理するノードが直接到達させることも可能
データ/インスタンスの冗長化、一貫性などは上位プロト
コルが解決
構造化オーバーレイの抽象化レイヤー
ルーティング層
DHT （Distributed Hash Table）
上位アプリケーション
出典： Towards a Common API for Structured Peer-to-Peer Overlays
データオーバーレイによる可用性
Service
C, D
Instance
C, D
C, D
D
C,
A,B,
E,
F,
B,
A, B,
A, A,
B,
E, F
E,F,H
E, F
Service
Instance
A, B
C, D, K, L
E, F
D,G,
C,
C,C,D,
D,
C,
G, H,
I,
D,G,J H
905I, J
53
53
f(G) = 4601
Primary から自動
フェイルオーバー
で最も近い
secondary へ
Service
Instance
5000
1
G
5501
5501
6435
Service
G
Service
Request
可用性のために複
製を使う
Service
E,E,
Instance
E,F,
F,FH
X
G, H
E, F, I, J
Service
K,
L
Instance
I,I,Instance
J,
I,I,J,JJG
K, L,
L,E,E,
K,
K,K,L,L,G,
G, H
K,
L
K,LL
K,
A,
B,I, I,J,
A,
B,
A,A,
B,B,G,
I, J
I, JJ
Replica
Size = 3
F,HH
F,
2128
0
Logical Partitions
Service Instances
A, B
C, D
E, F
G H
X
I, J
K, L
Consistency、Availability、Partition 定理
C
A
•
Consistency + Availability
• 単一サイト / クラスタデータ
ベース
A
•
Consistency + Partition
• 分散データベース / 分散ロック
A
•
Availability + Partition
• 分散キャッシュ / DNS
P
C
P
C
P
一貫性よりも可用性
スケーラビリティのパターン
機能、データ、トランザクションの分割
アーキテクチャ定義
1.
機能分割： SOA に基づくサービス単位化
2.
データ分割： partition scheme に従う水平分割
アプリケーション設計（ユースケース依存）
3.
分散トランザクションの回避： 分割したデータ間の一貫性の確保
4.
非同期による機能分割： メッセージ転送の信頼性の設計（exactonce semantics、in-order）
5.
キャッシュの設計： 主に読み取りデータ向け
（仮想化： partition、データベース、ノードの追加削除による可用
性、スケーラビリティ）
概念、論理レベル： 分割
機能領域（SOA）
もの／こと分析（DOA）マスター／トラン
ザクションデータの配置
役割、用途の分離
関数従属性を持つまとまりの分離（正規化）
静的／動的データ、データ量の大小で垂直分割
Customer
Portal
凡例
Supplier
Portal
INTERNET
INTERNET
Firewall
Browser Client
Business Process
Service
アプリケーション
アーキテクチャ
WebSite
Management
Customer
Setup
Business Entity
Service
Sales Force
Portal
Customer
Service Portal
INTRANET
eSales
CRM
Catalog
Management
Order
Managemen
t
Campaigns
Customer
Service
Shopping
Carts
Market
Syndication
Sales Force
& Leads
Customer
Self Service
Seller
Reporting
Collaborative
Planning
Stock
Replenishme
nt
コンポーネント
アーキテクチャ
Source &
Manage
Suppliers
Customer
Management
サービス
アーキテクチャ
New Application
Code
New Application
Database
Demand
Fulfillment
コンポーネント
アーキテクチャ
Legacy Package
Legacy Application
Legacy Database
Sales & Marketing
Production
Engineering
Accounting
Stores &
Purchasing
安定性
マスターデータ
バージョン管理された
参照データ
メッセージ
トランザクション
データ
通常
いいえ
はい
はい
はい
正規化
不変性
はい
とても
変化しやすい
場合により
はい：
各バージョンで
一度だけ
書き込み
場合により
はい：
一度だけ
書き込み
場合により
いいえ
(例、カート)
バージョン管理された参照データ、メッセージは更新なし
データ類型化の例
同時更新 適用技術
パーティション分割
非常に高い （更新）、
キャッシュ&
同時性 レプリケーション
（参照）
変更なし
キャッシュ&
レプリケーション
（参照）
変更なし
キャッシュ&
レプリケーション
（参照）
ローカル
データベース
非常に低い （更新）、
キャッシュ&
同時性 パーティション分割
（参照）
トランザクションデータ集計
計画系、在庫、サマリー
マスターデータ
参照のみ
データ
ウェアハウス
ＡＰ１
ＡＰ２
トランザクション
データ
ＡＰ３
ＡＰ４
トランザクション
データ
ETL
AP： rich client、
Web page、
business logic、
service provider、
Azure Web role など
論理、物理レベル
複合化：非正規化（主に Azure Table の場合）
非同期を考慮したトランザクション（一貫性）ス
コープ
分割
Partition scheme と Partition Key の決定
SDS Container による分割
コンポーネント/サブシステムへの分類
（プロセスからの利用）、ネットワーク配置は
まだ考慮しない。
製品、部品カタログ管理
Car type
Code
Year
CRM
*
データモデル管理
アプリケーション
Part used
Quantity
Cost
1
*
*
1
Car repair
Entry Date, Exit Date
Faults presented
Code: 共通メタデータ
User Directory
1
*
Car
Serial Number
Color
1
共通 Entity
Part
Code
Description
1
*
Customer
Code
Name
Trading partners
（Manufacturers,
Inventories）
Repair made
*
Problem solved
Labor description
Wasted hours
Employee
Code
Name
*
*
ERP
Accounts Receivable
1
*
Due date, payment date
Installment number
Value, ...
Web サーバ
ビジネスロジック
ロードバランサ
データベース
Azure Table による設計例
Table は表ではないが、テーブルプログラミングモデルを持つ
Table のエントリは Partiton Key の違いで物理ノードに分散配置
物理設計で Partition Key 付与（なくてもよい）
実際の Partition Key はアプリケーション依存処理で決定してもよい
氏名、地域、サプライヤ、時期、特定属性など操作（検索）スコープを
考慮
Partition
Key
Customer
id
Row Key
変更
日時
Property 3
住所
（都道府県）
…. Property N
記述
100211
2008/3/3
神奈川県
…. 萩原さん
100211
2008/7/26 東京都
萩原さん
100212
2008/4/11 東京都
野村さん
100214
2007/1/1
千葉県
福井さん
100214
2009/1/1
千葉県
福井さん
関係テーブル
Partitioning Key
CId
Conf
Title
1
PDC
2
Tech
Ready
TId
CId
Track Title
1
1
Cloud
Compute
1
Windows Azure テーブル
2
Row Key
Conf
Id
Track
Id
Session
Id
Conf
Title
Track
Subject
Session
Subject
1
Null
Null
PDC
Null
Null
1
1
Null
Null
Cloud
Compute
Null
1
1
1
Null
Null
Live
Meeting
2
Null
Null
Tech
Ready
Null
Null
2
1
Null
Null
SQL
Server
2008
Null
2
2
1
Null
Null
SQL Server
FILESTREA
M
Row group
SQL Server
2008
Row group
SId
CId
TId
Session
Subject
1
1
1
Live Meeting
1
2
1
SQL Server
FILESTREAM
Primary Key
Entity は、データ分割=partition 単位
その性質上、物理モデルだが、トランザクショ
ンや意味のまとまりとして概念、論理レベルで
定義
Key-value で value に key-value をネスト
Entity 間のトランザクションを禁止するこ
とで、データ分割と分散トランザクション
の回避の両方を実現： scalability pattern
Table のトランザクションモデル
Entity の CUD は ACID トランザクション
Partition の R は スナップショット隔離レベル
Table 間のトランザクションはなし
コミット前のトランザクション実行操作で
Queue に記録を残し、クラッシュ時は
Queue の記録に基づき、再実行
検索や join の実装は関数型の領域
F#、Dryad、MapReduce（C++）
E： 記憶の単位
C： 一貫性の単位
A： フェイルオーバーの
単位（パーティション）
ADO.NET Data Services による
Table Entities は CLR Class で定義
[DataServiceKey("PartitionKey", "RowKey")]
public class Customer
{
// Partition key – Customer Last name
public string PartitionKey { get; set; }
// Row Key – Customer First name
public string RowKey { get; set; }
// User defined properties here
public DateTime CustomerSince { get; set; }
public double Rating { get; set; }
public string Occupation { get; set; }
}
.NET（C#）
using (TransactionScope scope =
new TransactionScope(TransactionScopeOption.Required, options))
{
string strCmd = "SQL to Execute";
conn = new SqlClient.SqlConnection("Connection to DB1");
conn.Open();
objCmd = new SqlClient.SqlCommand(strCmd, conn);
objCmd.ExecuteNonQuery();
}
Seasar2 container（Java)
出典： IBM developerWorks Japan
@TransactionAttribute(TransactionAttributeType.NEVER)
public class XxxService {
public void foo() {
・・・
}
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void bar() {
・・・
}
}
Queue（トランザクションデータ） から Table、
Blob（マスターデータ） を参照
SDS
Authority
SDS
Container
Account
Container
Movies
Blob
Block
MOV1.AVI
Block
AAAB
垂直分割
Block
AAAC
Catalog
Car Resale
Account
Order
Entry
Table
Entity
Products
VWGOLF
水平、垂直分割 MINICOOPER
（ボトルネックの課題）
Queue
Message
Orders
Order#=001
2
Order#=001
3
水平分割
Block
AAAA
SDS による設計例
データモデルで定義
データ特性の一種と
考える
検索スコープ、join
のスコープから決定
同質 Container と異
質 Container の2種
負荷分散、並列処理
のために分割する
Car
Resale
Catalog
Authority
Container
Product
Entities
検索スコープ
検索し、挿入
Order Entry
Container
Order
Entities
Join
Customer
Entity
Order
Detail
Entities
論理、物理レベル
ドメインドリブン設計のドメインモデルとのマップ
一貫性の解決法
REST Resource とのマップ
URI scheme の決定
SDS / ADO.NET Data Services（on-premise）
その他
キャッシュ
キャッシュ配置と有効期限
スキーマ変更の戦略
出典： Using ADO.NET Entity Framework in Domain-Driven Design:
A Pattern Approach
名詞（Resource）を発見する
URI Template による表現
/{expense-id}/{line-item}
操作開始の Resources の定義
開始の URI、http://expenses.example.com/v1
Resource
URI
Bill の経費報告書
/users/bill/expenses
経費報告書 #123
/users/bill/expenses/123
すべての経費報告書 （見る権限があるもの）
/expenses/
すべての未承認（新規など）の経費報告書
/expenses;pending (new, etc.)
Bill の未承認の経費報告書
/users/bill/expenses;pending
経費報告書 #123 のデータ項目
/users/bill/expenses/123/line_items
経費報告書 #123 のデータ項目の2 行目
/users/bill/expenses/123/line_items/2
2006年の経費報告書
/2006/expenses/
2006年の未承認の経費報告書
/2006/expenses;submitted
Layer
Presentation
Client
（Ajax、
Smart
Client）
Resource
Web
Server
（SDS
Container）
Logic/Domain
Entity
Application
Server
（SOA
service）
Data
Data
Server、
（Cloud
DB）
トランザクション・コンテキスト
インターネット
ロード
バランサ
Web
ロール
ワーカー
ロール
ストレージサービス
•N-tier モデル
•密結合が前提
•障害がないことが前提
•ACID トランザクションが前提
•データ層がボトルネック
•新しいアーキテクチャ
•Scale out
•Key-value データ
•非一貫性モデル
•非同期
•REST、AtomPub
•関数型での処理
Transaction 1
Client
Order
Transaction 2
Shipping
Order
Transaction 3
Notify
Shipping
データオーバーレイによる可用性
Service
C, D
Instance
C, D
C, D
D
C,
A,B,
E,
F,
B,
A, B,
A, A,
B,
E, F
E,F,H
E, F
Service
Instance
A, B
C, D, K, L
E, F
D,G,
C,
C,C,D,
D,
C,
G, H,
I,
D,G,J H
905I, J
53
53
f(G) = 4601
Primary から自動
フェイルオーバー
で最も近い
secondary へ
Service
Instance
5000
1
G
5501
5501
6435
Service
G
Service
Request
可用性のために複
製を使う
Service
E,E,
Instance
E,F,
F,FH
X
G, H
E, F, I, J
Service
K,
L
Instance
I,I,Instance
J,
I,I,J,JJG
K, L,
L,E,E,
K,
K,K,L,L,G,
G, H
K,
L
K,LL
K,
A,
B,I, I,J,
A,
B,
A,A,
B,B,G,
I, J
I, JJ
Replica
Size = 3
F,HH
F,
2128
0
Logical Partitions
Service Instances
A, B
C, D
E, F
G H
X
I, J
K, L
Immediate
Consistency
Eventual
Consistency
No
Consistency
オークション、
送金
検索エンジン
課金、
営業ステータス
特定のユーザ
プロファイル
非一貫性の解決
ローカル replica 変更の遅延による非一貫性
Azure Storage の上位のアプリケーション
が一貫性モデルを構築
SDS Container など
操作毎の一貫性条件
トランザクションスコープを非同期処理により
分割
例、カタログ、注文、与信、決済、在庫、顧客
情報など
データストリームによる Unit of Work
出典： http://www.cascading.org/
Azure によるスケーラビリティの実現
SOA に基づく機能分割
機能分割に従ったデータ分割
Entity 定義によるデータ分割と分散トランザクション回避
Role によるサービス契約、コンポーネント化、ホスト選択
Queue による非同期通信と信頼性のある転送
キャッシュの利用
アーキテクチャ先行定義の原則
データ類型化とデータアーキテクチャ
ドメインモデルとアプリケーションアーキテクチャ
論理レベルの設計モデルの選択
REST Resource とのマップ
パラダイムの選択、抽象化モデルの定義
トランザクションスコープ、一貫性要求と補償処理
© 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.