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