data consistency 入門 data partitioning ガイダンス
TRANSCRIPT
ざっくり学ぶData Consistency 入門 &
Data Partitioning ガイダンス
@Masayuki_Ozawa
自己紹介• もう金麦の山は減ってきているころだろうか。インタ
ビューしたとき、小澤さんの自宅には金麦が大量にあふれていたそうだ。(DB Online の掲載分より抜粋)– http://enterprisezine.jp/dbonline/detail/5841
• コミュニティ活動– Azure : JAZUG (http://r.jazug.jp/) – SQL Server : SQLTO (http://sqlto.net)– ブログ : SE の雑記
(http://engineermemo.wordpress.com)
2
お話しさせていただく範囲• Data Consistency 入門
– データの整合性
• Data Partitioning ガイダンス– データの分割
• パッと見、データベースのガイダンスのようにとれるかもしれませんが、データベースに限定される概念ではありません。
• 情報(データ)を更新する場合に適用できるデザインパターンです。
• 各パターンのポイントをざっくり紹介いたします。
3
Data Consistency 入門
4
Data Consistency とは？？
• Data Consistency
→ データ整合性– 結果に矛盾のないデータとなっている
• 二種類の整合性モデルの紹介– 強い整合性 (Strong Consistency)
– 結果整合性 (Eventual Consistency)
5
強い整合性 (Strong Consistency)
6
一般的なお話
• データへのアクセス時に最新の情報を取得できることが保証される
7
処理の一例
8
データ A
データ B
データ C
データ D
処理 A4 つのデータ (項目)
が更新できたら処理を完了
強い整合性
9
データ A
データ B
データ C
データ D
処理 A
処理 B
処理 A の一連の流れが完了していないため、同一のデータを使う
処理 B の要求がブロック※RDBMS ではロックの競合
処理が完了しておらず整合性が取れていない、データにはアクセスができない
センター B
センター A
複数の拠点間のデータを利用
10
データ A
データ B
データ C
データ D
処理 A
ネットワーク遅延ネットワーク障害
処理 B
障害の状況によりデータにアクセスできない
期間が長くなる可能性がある
センター B の応答停止が長い場合には、手動でロー
ルバックする等も検討
データストア B
データストア A
異なるデータストアを利用
• データを複数のデータストアに分散してもよい– データストア→データベースに限定されない。
11
データ A
データ B処理 A
データ C
異なるデータストアをまたがるトランザクションをサポートしているか??
そもそも強い整合性がサポートされるか?
マスター
データのレプリカをする場合の考慮
• データを複製する場合、強い整合性の範囲外でレプリカに変更を伝えることを検討する– マスター / レプリカ間で一時的に整合性が崩れるが、複製がされていなくても処理を完了とする
12
データ A
データ B
処理 A
レプリカ
データ A
データ B
マスターへの変更をもってトランザクションを完了とし、
レプリカへの反映はトランザクションの対象範囲外とする
結果整合性 (Eventual Consistency)
13
一般的なお話
• 長い間、データの更新がなければ、結果的に、全ての更新処理が反映され、全てのレプリケーションを含めたデータの一貫性が保たれる、とする。
Wikipedia より
14
結果整合性
15
データ A
データ B
データ C
データ D
処理 A A~Dの更新が終わらなくてもデータへのアクセスを許可
一部のデータの更新の状態でもデータへのアクセスを許可する
結果整合性
16
データ A
データ B
データ C
データ D
処理 A
処理 B
複数のデータの更新をもって処理を完了とする場合でも途中でアクセス可能
このデータの更新はまだ未完了
どのタイミングのデータにアクセスをさせるか
更新中のデータトランザクション開始時点で
確定されているデータ
17
データ A
データ A’
処理 A
データ A
更新
ロールバック
処理 B
データ A
データ A’
処理 A
データ A
更新
ロールバック
データのコピー(バージョニング)
へのアクセスex)SI/RCSI
ダーティーリード
ex)NOLOCK
処理 B
結果整合性
18
データ A
データ B
データ C
データ D
処理 A一連の処理が終了
その結果は矛盾していない??
処理を完了
結果整合性
19
データ A
データ B
データ C
データ D
処理 A
その結果は矛盾していない??
失敗の内容に基づいて処理を実施
一連の処理が終了
最終的に処理の整合性を担保し矛盾のない状態にする
失敗した場合の対応• すべての処理が完了できない場合の対応を考慮
– データに整合性が保たれない状態でアクセスが可能– システムとして結果整合性が保たれることを保障
• 処理の失敗への対応– 失敗した操作を再度実行し処理の結果を反映する
• 複数回実行しても結果が同じに保たれる (べき等)
• データ整合性が保てないことへの対応– 補正ロジックによりシステム的に整合性がある状態に修正
• 在庫不足により注文を確定できないことを通知 (キャンセル通知)
• アクション (失敗した操作のリトライ/補正ロジック) を明確にしておく
20
どちらが必要とされるかを検討• 結果整合性はクラウド環境の分散データを管理するのによく
好まれるモデル– データのロックによる競合を避け、同時実行性を低下させない– 処理中のデータにアクセスできることによる整合性担保を考慮– 複製タイミングにタイムラグがあるレプリカを読み取り操作で
使うことも検討
• 短期間だけデータのロックで済むのであれば強い整合性を実装することも検討できる– 短時間であれ、アクセスできないタイミングがあることは考慮
する必要がある
21
Data Partitioning ガイダンス
22
Data Partitioning とは??
• パーティショニング
– データを特定の分割単位で複数のデータストアに分散して格納する
– 複数のデータストア
• 同一の筐体の異なる論理領域
• 異なる筐体の領域
• 異なる種類のデータストア
23
パーティショニングの目的
24
パーティショニングの目的
• スケーラビリティの改善
• パフォーマンスの改善
• 可用性の改善
• セキュリティの改善
• 運用の柔軟性
25
スケーラビリティの改善
26
H/W
データ
H/W
データ
H/W
データ
H/W
データ
スケールアップ
いずれスケールアップ限界に到達する
パーティションに分割し異なるH/Wに配置(スケールアウト)
パフォーマンスの改善
27
パーティション 1
データ A
パーティション 2
データ B
データ A
データ B
処理処理
パーティション単位に並列に実行
パーティションに応じてデータを配置する場所を分散できる
- マスターは 1 拠点で集中管理- トランザクションは処理に近い場所で管理
データストア B
可用性の改善
28
データストア
データ A
データ B
処理
データストア A
データ A
データ B
処理
ログデータ
マスター最新のトランザクション
データストアの停止がすべてのデータに波及
H/W 障害計画メンテナンス
一部のデータストアのデータにのみアクセス
ができない状態
パーティション B
セキュリティの改善
29
データストア
セキュリティレベル A
セキュリティレベル B
セキュリティ設定の境界がデータストア(パーティション)の場合にデータの重要度に応じたセキュリティ最適化が煩雑に
パーティション A
セキュリティレベル A
セキュリティレベル B
セキュリティの個別最適化が柔軟に行える
運用の柔軟性
30
データストア
データ A
データ B
パーティション 1
データ A
パーティション 2
データ Bデータストアがバックアップ
リストア境界の場合、データ B のみバックアップ
するのが難しい パーティション (データストア)単位でのバックアップリストアを実施可能
- メンテナンス単位- コストの低いストア- 監視レベルの変更- 異なる種類のストア
分割手法
31
分割の方法
• 水平分割 (シャーディング)
• 垂直分割
• 機能分割
32
水平分割
33
水平分割
34
同一のスキーマ
パーティション(シャード)キーに基づいて分割- レンジ- ハッシュ
シャード シャード
SQL Database ではElastic Scale Preview
水平分割の考慮点
35
• 負荷を均等にするためには特定のシャードにデータが偏らないようにする
• 定期的なシャードのメンテナンス• 分割の定義を更新する必要があるか• 既存シャードの分割/結合の必要性
• シャードをホストするサーバーのスケール上限に達しないように注意• スケールアップ上限• シャード数の上限
• 全シャードに保持しておきたい情報の管理• マスターテーブルの最新化
Azure Subscription and Service Limits, Quotas, and Constraintshttp://azure.microsoft.com/ja-jp/documentation/articles/azure-subscription-service-limits/
垂直分割
36
垂直分割
37
異なるスキーマ
利用パターン (例 : 頻繁に一緒に利用される項目) に基づいて分割する- 商品の基本情報(名称/金額)- 在庫/最終注文日- 拡張テーブル機密性の高い情報を分割する- カード番号- セキュリティコード
一つのエンティティ (実体) を複数のエンティティに部分的に正規化
垂直分割の考慮点
38
• 頻繁に検索される項目のサイズを小さくする• 分割をしすぎて、頻繁に複数の項目を合わせないと一つの情報
をなさないのでは効果が薄い
• 変更の頻度を考慮• 変更の少ない項目と多い項目を分割する。
• 変更の少ない項目 : マスター用途で参照が多い• 変更の多い項目 : トランザクション用途で参照が少ない
• 情報の重要性• データの重要性によってセキュリティレベルを変更する
• カード情報• セキュリティ番号
機能分割
39
機能分割
40
在庫データ 顧客データ
トランザクションヒストリー
マスター
データをコンテキストまたはサブドメインにより分割
機能分割の考慮点
41
• サイズに応じてデータストアのスケールを変更• データのコンテキストによってデータストアの性
能を調整することが可能• データサイズの上限に注意
• コンテキスト単位でデータを分割するため、トランザクション系のデータについては必要となるデータストアのサイズが大きい可能性がある
• ノードで許容される上限に注意する• 求められる性能に応じて他の分割と併用も検討
• 機能分割 + 水平分割
設計の考慮点
42
設計の考慮点
• スケーラビリティの向上
• クエリパフォーマンスの向上
• 可用性の向上
43
スケーラビリティの向上• 現在と将来のスケーラビリティを考慮
– パーティション (データ) ストアの垂直スケーリングの上限を来ないようにする• 性能上限 (処理能力 / 帯域)• パーティション数の上限
– 水平分割時に処理要求の多いシャードがある場合は注意• データのさらなる分割 / シャードキーの見直しが必要となるこ
とも
– 将来的にも想定したデータ母数で分散がされているか• データが増えすぎる場合はデータのアーカイブも検討
44
クエリパフォーマンスの向上
• 分割した結果どれを満たせばよい??– データサイズ
– 目標応答時間
• ターゲットとするクエリの調査– 遅いクエリ / 頻繁に実行されるクエリで使用する
データはどれか?• 単純にインデックスを適用すれば解消するケースではない??
– 取得したデータの項目の利用頻度• 利用頻度の高いデータを高性能なデータストアに
45
可用性の向上• パーティション単位で最適化
– データストアの配置場所の拠点のオフピーク時間帯で実施• オフピーク時間帯でメンテナンスが実施できるか?
– 複製対象 / 複製頻度の調整• 重要なデータのみを短い頻度で複製
• 障害発生時のアクセス不可能なデータの最小限化– 障害が発生しているパーティションのデータのみアクセスをすること
ができない– 特定のパーティションのみを復元
• 運用粒度の最適化– 重要なデータが格納されているパーティションを高品質なデータスト
アに配置– パーティションによって監視レベルを変更
46
検討事項• 複数シャードに対してのクエリの透過実行
– 全シャードをまたいでクエリを実行する必要はある??
• パーティションを容易に特定できる– 必要に応じてパーティションマップを保持
• ツールがパーティションに対応しているか– 各パーティションに直接アクセスできない場合は特に注意
が必要– 管理 / 運用ツールの対応状況– ETL ツール等でデータを追加する場合の対応
47
もっと詳しく知りたい方は
48
• ペーパー
• Kindle
各種取り揃えています!!
Cloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications
http://msdn.microsoft.com/en-us/library/dn568099.aspx
次回 CDP 勉強会
• 第4回 クラウドデザインパターン勉強会
– 2014-11-18（火）19:00 - 21:30
– http://jazug.doorkeeper.jp/events/16501
• Asynchronous Messaging 入門 第２回
• Data Replication and Synchronization ガイダンス
49