Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Data consistency 入門 data partitioning ガイダンス

1,074 views

Published on

  • Be the first to comment

Data consistency 入門 data partitioning ガイダンス

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

×