Windows Azure Storage:
Best Practices and Internals
2013/11/4 R.1.0

kyrt Takekazu Omi
takekazu.omi@kyrt.in
@takekazuomi
自己紹介

近江 武一
• Windows Azure (特にTable)の構築支援
• アーキテクチャ設計、検証
twitter: @takekazuomi
github: https://github.com/takekazuomi
htt...
Agenda
• Introduction to Storage
• Internals
• Coding with Azure Table Storage
• Azure Table and SQL Database
• Appendix

...
Introduction to Storage
Windows Azure Storageのご紹介

2013/11/4

kyrt @takekazuomi

4
Windows Azure Storage
• Cloud Storage – Anywhere and anytime access
• Blob, Tables and Queue

• Highly Durable, Available ...
Abstractions - Blob, Table, Queue
Storageは3種類ある

Table

Blob
REST file system
• Block/Page
• Data 共有- image, video …
• Big...
Azure Storage 基盤
• 3つは、共通のAzure Storage基盤の上に構築
• Azure内でも諸々の用途に利用
Diagnostics

Table

CDN

CloudDrive

Blob

OS/Data Disk
...
Internals

2013/11/4

kyrt @takekazuomi

8
Design Goals
• 強い一貫性の元での高い可用性の実現(Highly Available with Strong
Consistency)
• 障害や分断に直面してもデータアクセスを提供

• 永続性(Durability)
• デー...
Windows Azure Storage Concepts
Container

Blobs

https://<account>.blob.core.windows.net/<container>

Account

Table

Enti...
Storage Account単位のパフォーマンスター
ゲット
• Blob, Table ,Queueのpartition

• Blobは、URL毎、Tableは、 partition key、Queueはqueue毎で別のpartitio...
partition ?
•
•
•
•
•

Azure Storageは分散ストレージ
データはPartitionに分割して処理される
Partitionへの分割はコードでコントロールできる
実際にpartitionがどのように分散されるかは...
Windows Azure Storageの
アーキテクチャーコンポーネント
DNS参照
blob, table, queueへ
のアクセス

ロケーション
サービス
アカウント管理

VIP

DN
S

front end

VIP

fr...
3つのレイヤ - Architecture Layers inside
Stamps
• stream layer
• このレイヤでデータをディスクに永続化。DFSのようなもの。stream と呼ば
れるファイルを使い。保存方法とリプリケーショ...
stream layer
• stream へのWriteは、Appendのみ
• Open/Close/Delete/Rename/Read/Apped/Concat
stream //bar

pointer of extent E1

B...
sealed extentの最適化
• シールされたextentをreplication -> erasure codingで最適化
• リード・ソロモン符号を使って最適化
• 単純に3重にリプリケーションした場合3倍のコストだが1.3-1.5...
partition layer architecture
watch lease
read

front end

partition map
table

update

partition
manager

update lease

as...
partition layer
• Object Table
• partition layerの主な仕事はOTの管理と運用
• OT内は、Range Partition( low-keyからhigh-keyまで)に分かれてい
て、 Range...
range partition の処理
write

read

memory table

row page cache

bloom filter

partition layer

commit log stream
meta data ...
Dynamic Load Balancing – stream layer
• 複数レプリカからのRead ロードバラン
シング
• レイテンシー/ロードをモニタリング
してダイナミックにレプリカを選択
します。95% レイテンシーで追加の
レ...
Architecture Summary
• Durability: 全てのデータは3つのレプリカに保存される
• Consistency: 全てのコミットは3つのレプリカにわたって成功
したときに完了する
• Availability: 3つ...
Best Practices

2013/11/4

kyrt @takekazuomi

22
Best Practices- 共通(1)
• 1400byte未満の小さいメッセージでは Nagle Algorithm を無効
にする
• ServicePointManager.UseNagleAlgorithm = false;

• ...
Best Practices- 共通(2)
• Accountのスケーラビリティターゲットを理解する
• 必要なら複数のstorage accountを使う
• partition分割を意識する

• Cacheを上手く使う
• Cacheミス...
Best Practices- 共通(3)
• 送受信を最適化する
• Blob:range read, metadata, head request
• Table:Upsert、Merge、Projection、Top
• Queues:U...
Blob Best Practice
• read sizeと、write sizeを合わせる

• 大きなblockのblobの小さなレンジを読むのは避ける
• CloudBlockBlob.StreamMinimumReadSizeInBy...
Table Best Practice
• hotspotを避けるようにPartitionKey, RowKey を選択する
• Table Scanはコストが高い – レイテンシーが重要なシナリオでは避け
る

• Batchを使う:同一Pa...
Queue Best Practice
• messageの処理はidempotentに

• もしwokerがmessageを削除出来ずに落ちた場合、messageは再度visibleに
なる

• Update Messageの利点

• ...
Designing
Azure Table Storage

2013/11/4

kyrt @takekazuomi

29
Characteristics of Azure Table Storage
大きな特徴
1.
2.
3.
4.
5.
6.

Schema less
Partition
Range Query
Strong Consistency
Hi Sc...
仕様:Azure Table (1)
• Table Names
• 名前は3-63文字まで、case-insensitive

• Property
• Property 名は、case-sensitive で、最大 255 文字まで. Pr...
仕様:Azure Table (2) - Property Types
WCF Data Services
type

Common Language Runtime
type

Details

Edm.Binary

byte[]

An ...
Data Modeling Considerations for Azure
Table Application
• flexible schema
• key 設計
• partition 設計
• Data Modeling Decisio...
Entityの設計
• データ・モデルを考える際に
• Partitionにどのようにデータを配置するかでトランザクションが使え
るかが決まる
• EntityのKeyを何にするかでQueryの可否(パフォーマンス)が決まる
• Entityを...
pattern of Table and Partition usage
• Table分割の2つのPattern
• Table : Class = 1:1
• Table : Class = 1:N

• Partition は、Table...
Table : Class = 1:1
• Single Class, Single Table
mapping
• 別Classのデータは同一
Partitionに入らない

2013/11/4

Person

Inbox
Outbox
F...
Table:Class = 1:N
• データの粒度 を考えて
Partition を分割
• 読込アクセス(Read)とトラ
ンザクション(Write)に注目
Table
Data

インデックス

Log

kyrt @takekazuom...
keyの設計
• Azure TableではKeyの設計が非常に重要
• PartitionKeyの選択
• 同一Partition内のものはEGTでAtomicに処理出来る
• 複数PartitionのデータをAtomicに処理するような分散...
Keyの採番
• 採番(=連番と考えない)
• Uniq性

• Uniqであれば良いなら、GUIDなどを利用。クライアントの演算だけで採番できるの
で非常に高速に採番可能です

• Uniq性 + 時系列での増加(減少)

• 時間を元にした...
その他
• Embedded
• one to one, one to manyのパターンはシリアライズしてプロパティに
埋め込む策がある
• 正規化を崩すが読み込みPerformanceは良い。更新時を検討する

2013/11/4

kyr...
Windows Azure Storage Client Library
2.1
まず最初に
• Introducing Storage Client Library 2.1 RC for .NET and
Windows Phone 8
• ...
LastLogonDate

TableEntity
• Entityは、TableEntity から派生
して作成
• TableEntity Class は、3つのシ
ステムプロパティ、ETag、シリ
アライザ、デシリアライザが実
装
•
...
Write Operation
• Entityを用意して
var person = new Person()
TableIOperation Class の
{
static method を呼んで操作の
FirstName = "Harp"...
Write Option
Entityの更新系の操作は6種類
• Insert
•
•

POST
http://msdn.microsoft.com/en-us/library/windowsazure/dd179433.aspx

• Up...
Read Operation
var query = from ent in currentTable.CreateQuery<CustomerEntity>()
where ent.PartitionKey == “users” && ent...
Query のコスト
Queryのパターン

効率

1

PartitionKey == “SciFi” and RowKey == “Star Wars”

Single entity lookup 、これは最も効率が良い

2

Part...
Query Options
3つしか無い
• $top
• 取得件数、1000件以下に制限

• $filter
• 演算子で使えるのは、eq, gt, ge, lt, le, ne と and, not, or

• $select
• 取得...
Retry
Azure Storageではホットスポットが発生して動的負荷分散が動くと操作がエラー
になる場合がある(これは規定の動作)
そのような場合に備えて、アプリケーション側ではリトライロジックを用意が必
要。
デフォルトは、Expone...
HTTP Result Code と Retry の関係
• IRetryPolicyを実装してカスタムリトライを実装できる
• retryable/Non-retryable なエラーという考えがある

• 400番台と501, 505がNo...
Entity Group Transaction
entity group transaction (EGT)の要件
• トランザクション内の全てのエンティティは同一PartitionKey で無ければな
らない(Tableも同じ)
• ent...
Appendix

2013/11/4

kyrt @takekazuomi

51
Azure Storage Client
• .NET Framework

• https://github.com/WindowsAzure/azure-sdk-for-net

nuget

• node.js

• https://gi...
最後に
• Internalの部分は、Azure Storage TeamがSOSPで発表した内容に基づい
ています。
• 23rd ACM Symposium on Operating Systems Principles (SOSP)
"W...
Upcoming SlideShare
Loading in...5
×

Windows Azure Storage:Best Practices and Internals

7,389

Published on

http://kyrt.in/

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,389
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
20
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Windows Azure Storage:Best Practices and Internals

  1. 1. Windows Azure Storage: Best Practices and Internals 2013/11/4 R.1.0 kyrt Takekazu Omi takekazu.omi@kyrt.in @takekazuomi
  2. 2. 自己紹介 近江 武一 • Windows Azure (特にTable)の構築支援 • アーキテクチャ設計、検証 twitter: @takekazuomi github: https://github.com/takekazuomi http://kyrt.in 2013/11/4 kyrt @takekazuomi 2
  3. 3. Agenda • Introduction to Storage • Internals • Coding with Azure Table Storage • Azure Table and SQL Database • Appendix 2013/11/4 kyrt @takekazuomi 3
  4. 4. Introduction to Storage Windows Azure Storageのご紹介 2013/11/4 kyrt @takekazuomi 4
  5. 5. Windows Azure Storage • Cloud Storage – Anywhere and anytime access • Blob, Tables and Queue • Highly Durable, Available and Massively Scalable • 容易にinternet scaleのアプリケーションが構築可能 • 8.5 trillion stored objects • 900K request/sec on average (2.3+ trillion per month) • 従量課金 • 簡単でOPENなREST APIで公開 • 複数のクライアントライブラリのサポート .NET, Java, Node.js, Python, PHP, Ruby 2013/11/4 kyrt @takekazuomi 5
  6. 6. Abstractions - Blob, Table, Queue Storageは3種類ある Table Blob REST file system • Block/Page • Data 共有- image, video … • Big Data - raw data/logs … • Backup – SQLDatabase, file backup • Disks – mount VHDs 2013/11/4 structure data • • • • key/value schema less scale partationed sorted set kyrt @takekazuomi Queue Reliable messaging system • component/role間結合 • 非同期タスクスケジュ ラーの実装 • process/work flowsの構 築 6
  7. 7. Azure Storage 基盤 • 3つは、共通のAzure Storage基盤の上に構築 • Azure内でも諸々の用途に利用 Diagnostics Table CDN CloudDrive Blob OS/Data Disk Media Services Queue Azure Storage Clusters 2013/11/4 kyrt @takekazuomi 7
  8. 8. Internals 2013/11/4 kyrt @takekazuomi 8
  9. 9. Design Goals • 強い一貫性の元での高い可用性の実現(Highly Available with Strong Consistency) • 障害や分断に直面してもデータアクセスを提供 • 永続性(Durability) • データの複数の複製の保持、(regions を跨いた) • スケーラビリティ(Scalability) • zettabytes へのスケール • 世界中からアクセスできるglobal namespaceの提供 • meet peak traffic での、automatically scale out と load balance Additional details can be found in the SOSP paper: • “Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency”, ACM Symposium on Operating System Principals (SOSP), Oct. 2011 2013/11/4 kyrt @takekazuomi 9
  10. 10. Windows Azure Storage Concepts Container Blobs https://<account>.blob.core.windows.net/<container> Account Table Entities https://<account>.table.core.windows.net/<table> Queue Messages https://<account>.queue.core.windows.net/<queue> 2013/11/4 kyrt @takekazuomi 10
  11. 11. Storage Account単位のパフォーマンスター ゲット • Blob, Table ,Queueのpartition • Blobは、URL毎、Tableは、 partition key、Queueはqueue毎で別のpartition • partitionのパフォーマンスターゲット • 2,000 tran/s(queue/table) • 480Mbps/s (blob) • アカウント全体 • 20,000 tran/s(table,queue)※ • 受信 – 10GBps • 送信 – 15GBps 参照: http://blogs.msdn.com/b/windowsazure/archive/2012/11/02/windowsazure-s-flat-network-storage-and-2012-scalability-targets.aspx 2013/11/4 kyrt @takekazuomi 11
  12. 12. partition ? • • • • • Azure Storageは分散ストレージ データはPartitionに分割して処理される Partitionへの分割はコードでコントロールできる 実際にpartitionがどのように分散されるかは負荷で変わる Partition=物理マシン1台ではない。パーテションの数を増やしても 性能务化しない(Consistent hashingのvirtual nodeの考えと似て る) • Partitionを跨いだ処理は一貫性が保証されない(分散トランザク ションはサポートしてない、読み取り一貫性も無い) • 内部的にIDC内で3重化、GEO-REPLICATIONで複製を選択すると6 重に保存される 2013/11/4 kyrt @takekazuomi 12
  13. 13. Windows Azure Storageの アーキテクチャーコンポーネント DNS参照 blob, table, queueへ のアクセス ロケーション サービス アカウント管理 VIP DN S front end VIP front end partition layer s partition layer s stamp間リプリケーション stream layer stream layer stamp内リプリケーション stamp内リプリケーション storage stamp 2013/11/4 storage stamp kyrt @takekazuomi 13
  14. 14. 3つのレイヤ - Architecture Layers inside Stamps • stream layer • このレイヤでデータをディスクに永続化。DFSのようなもの。stream と呼ば れるファイルを使い。保存方法とリプリケーションを実装する。streamは、 extentのordered list • このレイヤは、Blob, Tableなどの構造やセマンティックに依存しない。 • partition layer • 高レベルのデータ構造(blob, table, queue)を実装 • オブジェクトに対するトランザクションの順序付、一貫性の確保を実装 • オブジェクトデータのキャッシュ • front end • リクエストのpartition server へ転送 • serverと、 partitionの割り振りを管理するpartition mapを保持 2013/11/4 kyrt @takekazuomi 14
  15. 15. stream layer • stream へのWriteは、Appendのみ • Open/Close/Delete/Rename/Read/Apped/Concat stream //bar pointer of extent E1 B1 1 B1 2 ・ ・ ・ extent E1 - sealed 2013/11/4 B1 x pointer of extent E2 B2 1 B2 2 ・ ・ ・ extent E2 - sealed B2 x pointer of extent E3 B3 1 B3 2 ・ ・ ・ B3 x extent E1 - sealed kyrt @takekazuomi pointer of extent E4 B4 1 B4 2 B4 3 extent E1 - unsealed 15
  16. 16. sealed extentの最適化 • シールされたextentをreplication -> erasure codingで最適化 • リード・ソロモン符号を使って最適化 • 単純に3重にリプリケーションした場合3倍のコストだが1.3-1.5倍の コストに低減できる この辺りは日々改善 • Local Reconstruction Codes (LRCs) • LRCは3つの障害があっても100%の復元でき、3つのレプリカや 6+3リードソロモンより耐久性に優れている。 • LCRはリードソロモンより14%データオーバーヘッドが小さく、少な いデータフラグメントの読み込みで復旧することができる 2013/11/4 kyrt @takekazuomi 16
  17. 17. partition layer architecture watch lease read front end partition map table update partition manager update lease assign partition partition server 1 paxos lock service partition server 1 partition server 1 partition layer stream layer 2013/11/4 kyrt @takekazuomi 17
  18. 18. partition layer • Object Table • partition layerの主な仕事はOTの管理と運用 • OT内は、Range Partition( low-keyからhigh-keyまで)に分かれてい て、 Range Partitionは スタンプ内のパーティション サーバー 分散し ます • Range Partitionの範囲は負荷によって変動 • Range Partitionとpartition serverの割り振りは、 Partition Manager (クラスタ)が行い。調停にはPaxosロック サービス が使われます 2013/11/4 kyrt @takekazuomi 18
  19. 19. range partition の処理 write read memory table row page cache bloom filter partition layer commit log stream meta data stream row data stream blob data stream stream layer 2013/11/4 kyrt @takekazuomi 19
  20. 20. Dynamic Load Balancing – stream layer • 複数レプリカからのRead ロードバラン シング • レイテンシー/ロードをモニタリング してダイナミックにレプリカを選択 します。95% レイテンシーで追加の レプリカからのパラレル読み込みが 開始されます。 front end P • write load balancing • レイテンシー/ロードをモニタリング してレプリカセットをsealし、別の nodeの新しいextentを割り当てます • capacity load balancing • nodeが十分なDiskを持つように、レ プリカのデータの遅延移動が行われ ます。 partition layer M P P P stream layer P P
  21. 21. Architecture Summary • Durability: 全てのデータは3つのレプリカに保存される • Consistency: 全てのコミットは3つのレプリカにわたって成功 したときに完了する • Availability: 3つのレプリカのどからでも読むことができる。 もし、書込み時になにか問題があった場合も新しいextentに追 記することができる • Performance/Scale: Retryの原因となるレイテンシーの95%は、 Auto scale out とload balance によるもの。(based on load/capacity) 2013/11/4 kyrt @takekazuomi 21
  22. 22. Best Practices 2013/11/4 kyrt @takekazuomi 22
  23. 23. Best Practices- 共通(1) • 1400byte未満の小さいメッセージでは Nagle Algorithm を無効 にする • ServicePointManager.UseNagleAlgorithm = false; • Expect 100-Continueを無効にする • ServicePointManager.Expect100Continue = false; • default connection limitを増やす • ServicePointManager.DefaultConnectionLimit = 100; (Or More) • Storage accountと、computing instance/userを近くに置く • computing instanceとstorage accountは同一データセンター内 2013/11/4 kyrt @takekazuomi 23
  24. 24. Best Practices- 共通(2) • Accountのスケーラビリティターゲットを理解する • 必要なら複数のstorage accountを使う • partition分割を意識する • Cacheを上手く使う • Cacheミスのときだけstorageにfall backする • account/ partitionの限界を越えられる • 複数partitionに負荷を分散することでスパイクを排除する • HTTPSを使う 2013/11/4 kyrt @takekazuomi 24
  25. 25. Best Practices- 共通(3) • 送受信を最適化する • Blob:range read, metadata, head request • Table:Upsert、Merge、Projection、Top • Queues:Update Message、Batch Size • アプリケーションレイヤーではparallelを使う • 無制限なparallelはレイテンシーの务化、スロットリングを引き起こす • storage serviceのLoggingと、Metricsを有効にする • API経由あるいは、Portalで有効にできます • clientのdebugやperformance問題の解決に役立ちます • 指定したretention intervalで自動的に削除されます 2013/11/4 kyrt @takekazuomi 25
  26. 26. Blob Best Practice • read sizeと、write sizeを合わせる • 大きなblockのblobの小さなレンジを読むのは避ける • CloudBlockBlob.StreamMinimumReadSizeInBytes/ StreamWriteSizeInBytes • block blobは、blockのリストとして管理されるので • 複数のファイルをアップロードする良い方法は? • 同時に複数のファイルをアップしましょう • blobをアップロードするもっと速い方法は? • parallel block upload を使って下さい。 • single blob = one partition • 単一blobへのアクセスはpartition targetに制限される • 複数のblobへのアクセスはスケールする 2013/11/4 kyrt @takekazuomi 26
  27. 27. Table Best Practice • hotspotを避けるようにPartitionKey, RowKey を選択する • Table Scanはコストが高い – レイテンシーが重要なシナリオでは避け る • Batchを使う:同一PartitionKeyでは複数のEntityを同時に更新 できる • Schema-less: 複数のTypeを同一のTableに入れる • Indexは1つだけ( PartitionKey, RowKey ):複数のIndexが必 要な場合は複合キーを検討する • Entity Locality:ソート順の近い場所に必要なものを置く • 関連するEntityを近い場所に置くことでIOが軽減されてPerformanceが 向上する 2013/11/4 kyrt @takekazuomi 27
  28. 28. Queue Best Practice • messageの処理はidempotentに • もしwokerがmessageを削除出来ずに落ちた場合、messageは再度visibleに なる • Update Messageの利点 • visibility timeを延長やステートを保存できる • Message Count • queueの溜り具合を現す、 worker の scale の目処になる • Dequeue Count • poison messages の発見、invisibility time の妥当性確認に使える • 大きなメッセージはBlobs に • 大きなバッチ処理時等に throughput が向上する(大きなものはQueueに積ま ない) • 複数 Queuesの利用 • single queue = partition 、partition targetに制限される 2013/11/4 kyrt @takekazuomi 28
  29. 29. Designing Azure Table Storage 2013/11/4 kyrt @takekazuomi 29
  30. 30. Characteristics of Azure Table Storage 大きな特徴 1. 2. 3. 4. 5. 6. Schema less Partition Range Query Strong Consistency Hi Scalability Low cost RDB(SQL)に比べて5,6は優位、他のK/VSに比べると、3,4は特徴 的。 2013/11/4 kyrt @takekazuomi 30
  31. 31. 仕様:Azure Table (1) • Table Names • 名前は3-63文字まで、case-insensitive • Property • Property 名は、case-sensitive で、最大 255 文字まで. Property 名は、 C# identifiers と XML specification 準拠(注:dashは使えない) • Propertyの数は、最大255個(system property 3個を含む) • データサイズは全 property の合計が最大で1MBまで • PartitionKey と RowKeyの Propertyで使えない文字、’/’, ’’, ’#’, ’? ’, U+0000 to U+001F, U+007F to U+009F • PartitionKeyとRowKeyは、最大1KBまで http://msdn.microsoft.com/en-us/library/windowsazure/dd179338.aspx 2013/11/4 kyrt @takekazuomi 31
  32. 32. 仕様:Azure Table (2) - Property Types WCF Data Services type Common Language Runtime type Details Edm.Binary byte[] An array of bytes up to 64 KB in size. Edm.Boolean bool A Boolean value. Edm.DateTime DateTim A 64-bit value expressed as Coordinated Universal Time (UTC). The supported DateTime range begins from 12:00 midnight, January 1, 1601 A.D. (C.E.), UTC. The range ends at December 31, 9999. Edm.Double double A 64-bit floating point value. Edm.Guid Guid A 128-bit globally unique identifier. Edm.Int32 Int32 or int A 32-bit integer. Edm.Int64 Int64 or long A 64-bit integer. Edm.String String A UTF-16-encoded value. String values may be up to 64 KB in size. 2013/11/4 kyrt @takekazuomi 32
  33. 33. Data Modeling Considerations for Azure Table Application • flexible schema • key 設計 • partition 設計 • Data Modeling Decisions • Embedding • Referencing • Atomicity • Operational Considerations • Data Lifecycle Management • Large Number of Collections 2013/11/4 kyrt @takekazuomi 33
  34. 34. Entityの設計 • データ・モデルを考える際に • Partitionにどのようにデータを配置するかでトランザクションが使え るかが決まる • EntityのKeyを何にするかでQueryの可否(パフォーマンス)が決まる • Entityを分割する価値 • 正規化のメリットは限られている、同一Entityに入れられる物は入れてしまう • 集計等でPartitionを跨いた処理が必要 • システムの主たる目的が、OLTPかOLAPかの性格付けは初期段階でする。OLTP なら、Azure Tableは向いているがOLAP的に使うのはAzure Tableだけでは無理 でHadoop等の併用を検討する • アドホックな集計でなくある程度安定したものなら専用のINDEXデータをトラン ザクション時に生成する まずは、Partitionを考えてみよう 2013/11/4 kyrt @takekazuomi 34
  35. 35. pattern of Table and Partition usage • Table分割の2つのPattern • Table : Class = 1:1 • Table : Class = 1:N • Partition は、Table+ PartitionKeyで決まる • Table : Class = 1:1では、 同一 Classしか同じPartitionに入れられない。 • Table : Class = 1:N では、複数のClassを同一 Partition に入れられる • その他(Table分けると便利なこと) • Table単位で削除できる(現在一括削除は、Storage Account単位と、 これだけ) 2013/11/4 kyrt @takekazuomi 35
  36. 36. Table : Class = 1:1 • Single Class, Single Table mapping • 別Classのデータは同一 Partitionに入らない 2013/11/4 Person Inbox Outbox Friend kyrt @takekazuomi 36
  37. 37. Table:Class = 1:N • データの粒度 を考えて Partition を分割 • 読込アクセス(Read)とトラ ンザクション(Write)に注目 Table Data インデックス Log kyrt @takekazuomi オブジェクトのデータ Index 2013/11/4 内容 ストレージの変更履歴ログ 37
  38. 38. keyの設計 • Azure TableではKeyの設計が非常に重要 • PartitionKeyの選択 • 同一Partition内のものはEGTでAtomicに処理出来る • 複数PartitionのデータをAtomicに処理するような分散トランザクショ ンの仕組みは無い • Partitionには同時アクセス数の上限がある • 複数のEntiryの場合 • 基本的な考えは、Single RootのTreeになるようにする • 単一Entity依存関係無しの場合 2013/11/4 kyrt @takekazuomi 38
  39. 39. Keyの採番 • 採番(=連番と考えない) • Uniq性 • Uniqであれば良いなら、GUIDなどを利用。クライアントの演算だけで採番できるの で非常に高速に採番可能です • Uniq性 + 時系列での増加(減少) • 時間を元にした値+乱数(あるいはGUID)を利用します。時間はTickを元にすると Longで表現することができます。またTickのリバースキー(例:Int64.MaxValue-Tick 等)を使うと逆順にもできます。乱数が必要なのは時間だけだと衝突する可能性が低 くないからです。採番速度は衝突の頻度次第です。乱数の代わりにGUIDを使えば上 記と同等の速度で採番可能です • Uniq性 + 連続の番号 • 連番を生成するのはAzure Tableだけだと楽観的ロックを使わざるえません。読んで 書かないといけないので、成功した場合でも100ms以上の時間が必要です。非常に遅 いので、使える場面が限定されます。 どの方法も重複した場合のリトライロジックを入れた方が無難 2013/11/4 kyrt @takekazuomi 39
  40. 40. その他 • Embedded • one to one, one to manyのパターンはシリアライズしてプロパティに 埋め込む策がある • 正規化を崩すが読み込みPerformanceは良い。更新時を検討する 2013/11/4 kyrt @takekazuomi 40
  41. 41. Windows Azure Storage Client Library 2.1 まず最初に • Introducing Storage Client Library 2.1 RC for .NET and Windows Phone 8 • http://blogs.msdn.com/b/windowsazurestorage/archive/2013/07/12 /introducing-storage-client-library-2-1-rc-for-net-and-windowsphone-8.aspx • Announcing Storage Client Library 2.1 RTM & CTP for Windows Phone • http://blogs.msdn.com/b/windowsazurestorage/archive/2013/09/07 /announcing-storage-client-library-2-1-rtm.aspx 2013/11/4 kyrt @takekazuomi 41
  42. 42. LastLogonDate TableEntity • Entityは、TableEntity から派生 して作成 • TableEntity Class は、3つのシ ステムプロパティ、ETag、シリ アライザ、デシリアライザが実 装 • https://github.com/WindowsAzure/azure-sdk-fornet/blob/master/microsoft-azureapi/Services/Storage/Lib/Common/Table/TableEntity.cs#L3 1 • ReadEntity/WriteEntityの overrideでプロパティへの保存 形式を変更可能 • ITableEntity を実装することで 自前実装可 2013/11/4 public class Person : TableEntity { public Person() { PartitionKey = "Customer"; RowKey = Guid.NewGuid().ToString(); } public string FirstName { get; set; } public string LastName { get; set; } public DateTime? LastLoginDate { get; set; } } kyrt @takekazuomi 42
  43. 43. Write Operation • Entityを用意して var person = new Person() TableIOperation Class の { static method を呼んで操作の FirstName = "Harp", オブジェクトを作成して、 LastName = "Walter", LastLoginDate = DateTime.UtcNow.Date.AddDays(-10) Table Client の Executeを呼ぶ }; のが基本 • Batchの場合は、 var insertOperation = TableOperation.Insert(person); TableBatchOperation に table.Execute(insertOperation); TableIOperation を入れて Executeで実行 • TableIOperationでは、Entity として、ITableEntity を受け 入れる 2013/11/4 kyrt @takekazuomi 43
  44. 44. Write Option Entityの更新系の操作は6種類 • Insert • • POST http://msdn.microsoft.com/en-us/library/windowsazure/dd179433.aspx • Update • • PUT If-Match有り http://msdn.microsoft.com/en-us/library/windowsazure/dd179427.aspx • Delete • • DELETE http://msdn.microsoft.com/en-us/library/windowsazure/dd135727.aspx • Merge • • MERGE If-Match有り http://msdn.microsoft.com/en-us/library/windowsazure/dd179392.aspx • Insert or Merge • • MERGE If-Match無し http://msdn.microsoft.com/en-us/library/windowsazure/hh452241.aspx • Insert or Replace • • 2013/11/4 PUT If-Match無し http://msdn.microsoft.com/en-us/library/windowsazure/hh452242.aspx kyrt @takekazuomi 44
  45. 45. Read Operation var query = from ent in currentTable.CreateQuery<CustomerEntity>() where ent.PartitionKey == “users” && ent.RowKey = “joe” select ent; • LINQ式で書ける • 実は、1.xでは出来たけど、2.0で無くなって、2.1でLINQ復活 2013/11/4 kyrt @takekazuomi 45
  46. 46. Query のコスト Queryのパターン 効率 1 PartitionKey == “SciFi” and RowKey == “Star Wars” Single entity lookup 、これは最も効率が良い 2 PartitionKey == “SciFi” and “Sphere” ≤ RowKey ≤ “Star Wars” single partition 内のエンティティScan レンジ内のエンティティ数に依存 3 “Action” ≤ PartitionKey ≤ “Thriller” 複数パーテション内のエンティティScan それぞれのパーテション内のエンティティ数に依存 4 PartitionKey == “Action” || PartitionKey == “Thriller” 2つのパーテションの中だけをScanするように最適化されて いない。Tableの全てをScanする。 この場合は、2つのQueryに分けて実行することを推薦する 5 “Cars” ≤ RowKey ≤ “Star Wars” PartitionKey が指定されていないので、Table内の全てのエン ティティをScanする 6 (PartitionKey == "..." && RowKey == "...") || (PartitionKey == "..." && RowKey == "...") この場合、1のようにならずに全てのpartition がScanされる。 つまり4と同じ 2013/11/4 kyrt @takekazuomi 46
  47. 47. Query Options 3つしか無い • $top • 取得件数、1000件以下に制限 • $filter • 演算子で使えるのは、eq, gt, ge, lt, le, ne と and, not, or • $select • 取得するプロパティを指定 2013/11/4 kyrt @takekazuomi 47
  48. 48. Retry Azure Storageではホットスポットが発生して動的負荷分散が動くと操作がエラー になる場合がある(これは規定の動作) そのような場合に備えて、アプリケーション側ではリトライロジックを用意が必 要。 デフォルトは、ExponentialRetry、3つのリトライ実装が用意。 • Linear • 固定の backoff periodの待ち時間で最大リトライ数までリトライする • Exponential • backoff period を、Math.Pow(2, retryCount) * backoff period +/- 20% の待ち時間で最大リ トライ数までリトライする • No Retry • リトライしない 参考:Windows Azure ストレージ サービスの構造とリトライ ポリシーの関係に ついて • http://msdn.microsoft.com/ja-jp/windowsazure/jj647756 2013/11/4 kyrt @takekazuomi 48
  49. 49. HTTP Result Code と Retry の関係 • IRetryPolicyを実装してカスタムリトライを実装できる • retryable/Non-retryable なエラーという考えがある • 400番台と501, 505がNon-retryableなエラーコード • それ以外と、client side timeouts(408)は、retryable • http://blogs.msdn.com/b/windowsazurestorage/archive/2011/02/03/overviewof-retry-policies-in-the-windows-azure-storage-client-library.aspx • Azure Storage のエラーコード • http://msdn.microsoft.com/ja-jp/library/dd179357.aspx • 実際のコード • https://github.com/WindowsAzure/azure-sdk-for-net/blob/master/microsoftazureapi/Services/Storage/Lib/Common/RetryPolicies/ExponentialRetry.cs#L71 • Blob側とコードを共有しているので上記説明と少し違う 2013/11/4 kyrt @takekazuomi 49
  50. 50. Entity Group Transaction entity group transaction (EGT)の要件 • トランザクション内の全てのエンティティは同一PartitionKey で無ければな らない(Tableも同じ) • entity は、 transaction 内に一回だけ出現できます。そして、1つだけの操作 がそれに対して許されます。 • transaction には、最大 100 のエンティティ、最大4MBのPayloadが許されま す。 • 全てのエンティティは、 Table Service Data Model に沿っていなければいけ ません。 • 上記の条件をクリアすれば、BatchOperationでまとめて処理できま す。 • EGTは、MultiPart MimeのRequestで一括で送られ、良いパフォーマ ンスが出ます(条件が良いと10倍以上早くなります) 2013/11/4 kyrt @takekazuomi 50
  51. 51. Appendix 2013/11/4 kyrt @takekazuomi 51
  52. 52. Azure Storage Client • .NET Framework • https://github.com/WindowsAzure/azure-sdk-for-net nuget • node.js • https://github.com/WindowsAzure/azure-sdk-for-node npm • java • https://github.com/WindowsAzure/azure-sdk-for-java maven • python • https://github.com/WindowsAzure/azure-sdk-for-python PyPI • ruby • https://github.com/WindowsAzure/azure-sdk-for-ruby gem • php • https://github.com/WindowsAzure/azure-sdk-for-php 2013/11/4 kyrt @takekazuomi PEAR 52
  53. 53. 最後に • Internalの部分は、Azure Storage TeamがSOSPで発表した内容に基づい ています。 • 23rd ACM Symposium on Operating Systems Principles (SOSP) "Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency“ 翻訳もあります • Windows Azure ストレージ: 高可用性と強い一貫を両立する クラウド ス トレージ サービス • http://msdn.microsoft.com/ja-jp/windowsazure/dd439432#leaning • Best Practiceと追加の情報はBUILD 2013のセッションから拾っています • BUILD 2013 Windows Azure Storage: What’s Coming, Best Practices, and Internals • http://channel9.msdn.com/Events/Build/2013/3-541 • 全ての情報は2013/11/04時点のものです。 2013/11/4 kyrt @takekazuomi 53
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×