Data Replication and Synchronization ガイダンス

田口 一博 (@sleepy_taka )スカイコード株式会社

自己紹介

• Microsoft Azureを中心としたWebシステムの開発やシステム構築のお仕事してます。

• 2.6 Data Replication and Synchronization ガイダンスの監訳担当

2

イベント告知

3

http://r.jazug.jp/

今回の内容

• データのレプリケーションと同期

– 2.6 Data Replication and Synchronization ガイダンス(P246)

• ガイダンスをざっくりと紹介

• 実装例として、Azureに関連する部分を少々補足

4

アジェンダ

• レプリケーションと同期についての概要

• レプリケーションと同期の目的

• レプリケーションと同期を設計する際の考慮点

• レプリケーションと同期の実装例

• 関連情報

5

複数のデータセンターへのデプロイ

複数のデータセンターにアプリケーションをデプロイする利点と課題については、「2.9 Multiple Datacenter Deployment ガイダンス」をご覧ください。

第3回 Multiple Datacenter Deployment ガイダンス スライド

株式会社pnop / Cloudlive 株式会社 浅見城輝さん

http://www.slideshare.net/kuniteruasami/cdp-multiple-datacenter-deployment

6

概要レプリケーションと同期についての概要

7

レプリケーションと同期とは？

• データストア間のデータを一致させる処理

• あるデータストアから別のデータストアにデータや変更を反映および配布し、一貫性を保つ処理

8

レプリケーションが必要な理由

• パフォーマンスの向上

• 可用性の向上

• 機密データの保護

9

レプリケーション方式について

• マスター・マスターレプリケーション

• マスター・従属レプリケーション

10

マスター・マスター

11

データB

マスターAデータA

マスターBデータA

• すべてのマスターレプリカで変更が可能

• 個々のマスターレプリカに対する変更は、すべてのマスターレプリカに双方向に反映

データB

変更

データB

データC

データC変更

データC

マスター・マスター

12

データB(新)

マスターAデータA

マスターBデータA

• すべてのマスターレプリカで変更が可能

• 個々のマスターレプリカに対する変更は、すべてのマスターレプリカに双方向に反映

データB変更

データB

データB (新)

データC

変更

データC 競合

データB(新) データB (新)

マスター・従属レプリケーション

• 変更可能なレプリカ（マスター）はただ１つで、残りのレプリカは読み取り専用

• マスターレプリカの変更は、すべての従属レプリカに伝播される

13

マスターデータA

データB

データC

データC

従属データA

データB従属データA

データB更新

データC

データC

目的レプリケーションと同期の目的

14

目的別の有効活用

• パフォーマンスとスケーラビリティの改善

• 信頼性の改善

• セキュリティの改善

• 可用性の改善

15

パフォーマンスとスケーラビリティの改善(1)

• マスター・従属レプリケーションを使用

• アプリケーションは近くのレプリカからデータを取得

16

マスター

データA

データB

アプリケーション

従属

データA

データB

読み取り

一方向の同期

パフォーマンスとスケーラビリティの改善(2)

• マスター・マスターレプリケーションを使用

• アプリケーションは近くのマスターに書き込み

17

マスター

データA

データB

アプリケーション

マスター

データA

データB

読み取り/書き込み

双方向の同期

アプリケーション

読み取り/書き込み

信頼性の改善

• アプリケーションの近くアプリケーションと同じネットワーク境界内にレプリカを配置

• レプリカ間の接続に障害が発生した場合、復元時に同期

18

レプリカ

データA

データB

アプリケーション

レプリカ

データA

データB

アプリケーション

接続復元時に再度同期

セキュリティの改善

• 必要なデータを必要な場所にのみ配置

19

レプリカデータA

データB

データE

マスター

データA

データB

データC

データD

データE

データF

クラウドでは使用しないデータは、オンプレミスでのみ保持

データF

可用性の改善(1)

• アプリケーションを実行する各国のDCでレプリケーションされたデータを使用

20

日本

アプリケーション

マスター

データA

データC

アメリカ

アプリケーション

マスター

データA

データE

シンガポール

アプリケーション

マスター

データA

データD

可用性の改善(2)

• フェールオーバーまたはバックアップのためのレプリケーション

21

従属

データA

データB

アプリケーション

マスター

データA

データB

読み取り/書き込み

レプリカは最新を保持

可用性の改善(2)

• フェールオーバーまたはバックアップのためのレプリケーション

22

マスタ

データA

データB

アプリケーション

マスター

データA

データB

障害が発生した場合接続先を切り替える

レプリカを更新可能なマスタに昇格

設計時の考慮点レプリケーションと同期を設計する際の考慮点

23

出来る限りの簡素化

• 可能な限りマスター・従属レプリケーションを使用

• 複数のストアやパーティションにデータを分離

• 競合が発生する場所の削減

• 上書きを必要しないデータの管理

• クォーラムベースのアプローチを使用

24

可能な限りマスター・従属レプリケーションを使用

25

マスター

データA

データB

アプリケーション

従属

データA

データB

読み取りは基本こちら

複数のストアやパーティションにデータを分離

26

従属

データC

データD

マスター

データA

-データLA1

データLA2

データLA3

データLA4

データLA5

マスター

データC

データD

マスター

データA

-データLB1

データLB2

データLB3

データLB4

データLB5

マスター・従属

マスター・マスター

レプリケーションなし

競合が発生する場所の削減

27

本社

マスター

データC

データD

マスター

データC

データD

マスター

データC

データD

マスター

データC

データD

東京

大阪

マスター

データC

データD

マスター

データC

データD

アメリカ

マスター

データC

データD

シンガポール

マスター

データC

データD

検討事項• 同期の種類

• 同期の頻度

• 同期するデータ範囲

• 同期時の障害

• 同期の順序

• 同期の経路

• 同期するデータの暗号化

• 同期データの整合性

• 同期のコスト

28

同期の種類

• マスター・マスターレプリケーション

• マスター・従属レプリケーション

• カスタム

29

同期の頻度

同期間隔が長い場合• データが古くなる• 更新が複数のレプリカで行われる可能性が高くなり、競合の危険性

が高くなる

間隔が短い場合• ホストやネットワークの負担が増える

上記の定期的な同期の他、変更が発生するたびに、それをレプリカに伝搬させることも検討

30

同期するデータ範囲

• 各データストアが保持・同期するデータを検討

31従属

レプリカ

データD

マスター

データA

データB

データC

データD

データE

データF

クラウドでは使用しないデータは、オンプレミスでのみ保持

データA

データB

アプリケーション

同期時の障害

32

アプリケーション

レプリカ

データA

データB

アプリケーション

レプリカデータA

データB

データアクセス

データアクセス

実装レプリケーションと同期の実装例

33

同期の実装

• データストア自体が持っている機能を使用– Microsoft Azure ストレージ地理レプリケーション

– SQL Databaseのレプリケーション

– SQL Server のレプリケーションサービス

• 既存のフレームワークやソフトウェア、サービスを使用– SQLデータ同期プレビュー

– Microsoft Sync Framework

• カスタム実装– 各自で実装

34

その前に、Azureについての補足

• Azureのジオとリージョン

• Azure Storage

• SQL Database

35

AzureのGEOとリージョン

GEO リージョン

米国 米国東部 (バージニア州)米国東部 2 (バージニア州)米国中部 (アイオワ州)米国西部 (カリフォルニア州)米国中北部 (イリノイ州)米国中南部 (テキサス州)

ヨーロッパ 北ヨーロッパ (アイルランド)西ヨーロッパ (オランダ)

アジア太平洋 東南アジア (シンガポール)東アジア (香港)

日本 東日本 (埼玉県)西日本 (大阪府)

ブラジル 南ブラジル (サンパウロ州)※米国中南部 (テキサス州) への一方向レプリケーション

オーストラリア オーストラリア東部 (ニュー サウス ウェールズ州)オーストラリア南東部 (ビクトリア州)

36

セカンダリ リージョンとプライマリ リージョン

プライマリ セカンダリ

米国中北部 米国中南部

米国中南部 米国中北部

米国東部 米国西部

米国西部 米国東部

米国東部 2 米国中央部

米国中央部 米国東部 2

日本東部 日本西部

日本西部 日本東部

37http://msdn.microsoft.com/ja-jp/library/azure/dn727290.aspx

Azure Storage

• BLOB

• テーブル

• キュー

• ファイル

38

SQL Database

BASIC STANDARD PREMIUM

アップタイム SLA 99.99% 99.99% 99.99%

データベース サイズ上限 2GB 250GB 500GB

特定の時点への復元 7 日以内の任意のポイント

14 日以内の任意のポイント

35 日以内の任意のポイント

DTU B:5 S1:15S2:50

P1:100P2:200P3:800

39

• Azureのマネージドなデータ管理サービス

Azure ストレージのレプリケーション

• ローカル冗長ストレージ (LRS)

• ゾーン冗長ストレージ (ZRS)

• 地理冗長ストレージ (GRS)

• 読み取りアクセス地理冗長ストレージ (RA-GRS)

40

オプション選択方法

41

管理ポータル

ローカル冗長ストレージ (LRS)

• 単一リージョンの単一の施設内でデータのコピーを 3 つ保持

• ３つのレプリカすべてにデータが書き込まれた場合に、処理は成功

42

ローカル冗長ストレージ (LRS)

43

施設

ストレージ

データAアプリケーション データB

ストレージ

データA

データB

ストレージ

データA

データB

書き込み複製

応答

ゾーン冗長ストレージ (ZRS)

• 1つまたは2つのリージョンの2か所から3か所の施設でデータのコピーを 3 つ保持

• ブロック BLOBのみサポート

44

地理冗長ストレージ (GRS)

• プライマリ リージョンで 3つ、セカンダリ リージョンで 3 つデータのコピーを保持するため、合計６つのデータコピーを保持

• セカンダリ リージョンには非同期でレプリケート

• プライマリ リージョンで障害が発生した場合、Azure Storage はセカンダリ リージョンにフェールオーバー

45

プライマリ リージョン

地理冗長ストレージ (GRS)

46

ストレージ

データA

データB

アプリケーション

書き込み

ストレージ

データA

データB

複製

ストレージ

データA

データB

セカンダリ リージョン

ストレージ

データA

データB

書き込み

ストレージ

データA

データB

ストレージ

データA

データB

複製応

答

成功

読み取りアクセス地理冗長ストレージ (RA-GRS)

• セカンダリリージョンにデータに対する読み取りアクセスを提供

• 開発などで使用する Azure のストレージ エミュレーターも対応

47

RA-GRSのサンプルコード

48

Azure関連の情報が豊富な「ブチザッキ」にサンプルコードが掲載されていますので、”地理冗長の読み取りアクセスを試してみる”などで検索してみてください。

詳しくは

Microsoft Azure Japan Team Blogをご覧ください。

Windows Azure ストレージの冗長オプションと読み取りアクセス地理冗長ストレージ

http://blogs.msdn.com/b/windowsazurej/archive/2013/12/19/blog-windows-azure-storage-redundancy-options-and-read-access-geo-redundant-storage.aspx

49

SQL Databaseのレプリケーション

Basic Standard Premium

標準地理レプリケーション × ○ ○アクティブ地理レプリケーション × × ○

50

• 各サービス レベルで提供されている地理レプリケーション機能

地理レプリケーションの選択

51

管理ポータル

標準地理レプリケーション

• DRペアリージョンに１つのセカンダリレプリカを作成可能

• プライマリからセカンダリへの地理レプリケーションは非同期

• データセンターで障害が発生し、フェールオーバー処理が完了するまで直接接続することはできない

• フェールオーバーはインシデント発生から1時間経過で有効。24 時間以内に復旧しなかった場合、自動的にフェールオーバーが開始

52

アクティブ地理レプリケーション

• 同じ、または異なるリージョンで最大 4 つ読み取り可能なセカンダリ レプリカを作成可能

• プライマリからセカンダリへの地理レプリケーションは非同期

• データセンターで障害が発生し、プライマリに影響がある場合も、フェールオーバーは手動

53

同期グループオンプレミス

SQLデータ同期プレビュー

複数の SQL Server および SQL Database間で、選択したデータを同期できるようにする サービス

54

ハブ データベース

SQL Database

SQL ServerSQL Database

SQLデータ同期プレビュー

55

同期グループオンプレミス

ハブ データベース

SQL Database

SQL ServerSQL Database

複数の SQL Server および SQL Database間で、選択したデータを同期できるようにする サービス

SQLデータ同期プレビューの設定

小澤さんのSEの雑記で書かれていましたので、「 SEの雑記 SQLデータ同期プレビュー」などで検索してみてください。

56

関連情報

57

関連するパターンとガイダンス

• Caching ガイダンス– 次回予定

• Multiple Datacenter Deployment ガイダンス– 第3回 クラウドデザインパターン勉強会

浅見 城輝さん/株式会社 pnop （終了）Data Consistency 入門

• Data Partitioning ガイダンス– 第3回 クラウドデザインパターン勉強会

小澤真之さん（終了）

58

今後の予定

• 第5 回クラウドデザインパターン勉強会

– Caching ガイダンス

– Instrumentation and Telemetry、Service Metering ガイダンス

59

もう1回、イベント告知

60

http://r.jazug.jp/