蒼の王座 
Azure SQL Database 入門 
http://sqlazure.jp/b/ 
大和屋貴仁
蒼の王座 
http://sqlazure.jp/b/ 
大和屋貴仁 
インフラエンジニア 
Microsoft MVP for Windows Azure 
@t_yamatoya 
http://sqlazure.jp/b/
蒼の王座 
Azure SQL Database 
マイクロソフトがデータベース管理の 
大部分を引き受けたマネージドサービスです 
http://sqlazure.jp/b/ 
SQL Server相当のデータベースを 
すぐに使い始められ 
バックアップなどの自動的に実施される
蒼の王座 
http://sqlazure.jp/b/ 
ハードウェア用意して、 
OSインストールして、 
SQL Serverインストールして、 
データベースの物理設計して、 
バックアップ設計して、 
データベースの論理設計して・・・ 
そんな作業をマイクロソフトがベストな状態で 
提供するのが、Azure SQL Databaseですよね
蒼の王座 
論理的概念、エンドポイント 
事実上、無限にデータベースを作成できる 
http://sqlazure.jp/b/ 
Azure SQL Databaseサーバー 
サーバー 
• サーバーのリソースを気にしなくて良い 
Azure SQL ゲートウェイサービス 
スケーラビリティ&アベイラビリティ:ファブリック、フェイルオーバー、ロードバランス
蒼の王座 
http://sqlazure.jp/b/ 
xxxxx.database.windows.net 
一昔前までは、 
サーバー名はランダムな文字列でした。 
8月ぐらいから、任意の文字列を指定できるようになりました。
蒼の王座 
http://sqlazure.jp/b/ 
データベースとサーバー 
サーバー:論理的な括り 
データベース:物理サーバーにホストされる 
同じサーバー上のDBでも、 
稼働している物理サーバーは異なる。 
DB相互でのアクセスは不可能 
test1.dbo.human 
test2.dbo.div 
一つのクエリで同時に使用できない 
USE句etc
蒼の王座 
http://sqlazure.jp/b/ 
データベースの冗長化 
デフォルトで3冗長化(プライマリと2つのセカンダリ)される 
DB 
ロジカルデータベース 
Ack 
Value Read Write 
P 
Ack Ack 
S Write Write S 
Read:プライマリで完結 
Write:セカンダリにレプリケートされる
蒼の王座 
http://sqlazure.jp/b/ 
クラスター化インデックス 
Azure SQL Databaseのレプリケーションは 
独自実装。 
クラスター化インデックスが必須の仕組み。 
クラスター化インデックスが無いと 
テーブルにデータを挿入できない
蒼の王座 
http://sqlazure.jp/b/ 
Firewall 
Services Layer 
Internet 
Services Layer 
IP アドレスによるアクセス制御 
デフォルトでは全ての接続を拒否 
サーバー単位、データベース単位で設定可能 
ポータル、SQL、APIで設定可能
新しいサービスレベル 
SQL Database service tiers
蒼の王座 
http://sqlazure.jp/b/ 
価格体系 
データ容量課金から 
パフォーマンスレベルと時間単位での課金 
3種類のサービスクラスとパフォーマンスレベル 
• Basic 
• Standard 
S0、S1、S2 
• Premium 
P1、P2、P3 
パフォーマンスレベルはどうやって定義されるか? 
マイクロソフトが開発したAzure SQL Database Benchmarkを活用し、 
データベーススループットユニット(DTU)で表現する
蒼の王座 
http://sqlazure.jp/b/ 
提供機能差異 
Basic 
• DB最大サイズ:2GB 
• ポイントインタイム復元:7日 
• 地理リストア 
Standard 
• DB最大サイズ:250GB 
• ポイントインタイム復元:14日 
• 標準の地理レプリケーション 
Premium 
• DB最大サイズ:500GB 
• ポイントインタイム復元:35日 
• アクティブ地理レプリケーション
ポイントインタイム復元 
Point-in-time restore
蒼の王座 
http://sqlazure.jp/b/ 
Azure SQLの組み込み自動バックアップ 
完全バックアップ:1週間に1回 
差分バックアップ:1日に1回 
トランザクションログバックアップ:5分に1回 
完全バックアップと差分バックアップは 
地域間で一日一回レプリケートされる
蒼の王座 
http://sqlazure.jp/b/ 
同一論理サーバー内に 
対象のデータベースの 
特定時点の状態を 
新しいデータベースとして 
復元することができる 
削除したデータベースも 
復元できる 
Basic:7日以内 
Standard:14日以内 
Premium:35日以内 
sabcp01bl21 
sabcp02bl21 
sabcp03bl21 
新しいデータベースに 
リストア 
Copy backups to Azure Storage 
LS XYZ 
DB 
DB1
蒼の王座 
http://sqlazure.jp/b/ 
ポイントインタイム復元画面
地理リストア 
Geo-Restore
蒼の王座 
http://sqlazure.jp/b/ 
地理リストア 
完全バックアップと差分バックアップが 
自動的にBlobに格納される 
そのBlobは地理レプリケーションが 
有効になっている 
地理レプリケーションで作成された 
日次バックアップからデータベースを復元する 
24時間以内の復旧、最大24時間のデータロストが発生しうる
蒼の王座 
http://sqlazure.jp/b/ 
地理リストア画面 
地理リストアに利用可能なバックアップが 
表示される
蒼の王座 
http://sqlazure.jp/b/ 
地理リストア画面 
地理リストアに利用可能なバックアップが 
表示される
標準地理レプリケーション 
Standard Geo-Replication
蒼の王座 
http://sqlazure.jp/b/ 
Standard Geo-Replication 
プライマリデータベースのコミットされたトランザクション 
を非同期で複製する 
• セカンダリデータベースはMS指定の 
DRペアリージョンに配置される 
• オフラインセカンダリ 
• データセンターがダウンした時(1時間後)のみフェールオー 
バーできる 
• インシデント24時間経過すると自動的に 
フェールオーバーする 
2時間以内の復旧、30分のデータロストが発生しうる
アクティブ地理レプリケーション 
Active Geo-Replication
Active Geo-Replication 
最大4つの読み取り専用セカンダリを 
作成できる 
トランザクションは非同期でレプリケートされる 
レプリケーションは手動で管理可能 
蒼の王座 
• リレーションシップをきると通常のデータベース 
http://sqlazure.jp/b/ 
1時間以内の復旧、5分以内のデータロストが 
発生しうる
蒼の王座 
http://sqlazure.jp/b/ 
Active Geo-Replication
監査ログ 
Auditing
監査ログ 
SQL Database 
Auditing 
Audit 
log 
Application data 
Azure Storage
蒼の王座 
http://sqlazure.jp/b/ 
監査ログ 
接続先 
<server name>.database.secure.windows.net 
記録先 
Azure Table 
記録対象 
• データへのアクセス 
• スキーマ変更 
• データの変更 
• アカウント、ロール、権限 
• セキュリティ例外 
ツール 
• Azure ストレージ用のツール 
• Excelテンプレートと定義済みのダッシュボードとレポート
蒼の王座 
http://sqlazure.jp/b/ 
ポータルでのレポート 
直近24時間のイベント 
最短で15分毎に更新される
リアルタイム性能情報の確認 
Sys.dm_db_resource_stats
Sys.dm_db_resource_stats 
リソース使用状況のデータを細かく 
リアルタイムに確認するための動的管理ビュー 
蒼の王座 
15秒毎に記録され、直近1時間分のデータ 
サービス層で提供されるリソースの 
何%を使用したかの記録 
CPU、IO、メモリ、ログ 
http://sqlazure.jp/b/
蒼の王座 
http://sqlazure.jp/b/ 
sys.resource_stats 
5分間隔の平均という精度で 
14日分のデータが格納される 
Web、Businessエディションの場合、 
S2レベル(DTU50)のリソースを基準に 
DTUの使用状況を%表示してくれる 
マイグレーション指標に使用できる 
300%の場合、S2の3倍のリソースが必要なので 
P2という選択となる
サーバー容量ポリシー 
Server Quota Policy
蒼の王座 
http://sqlazure.jp/b/ 
サーバー毎に1600DTUの 
制限が入りました 
カスタマサポートに 
連絡すれば制限を緩和可能 
Web、Businessエディションは 
上限150個
Azure SQL Database 
Elastic Scale
Azure SQL Database Elastic Scaleでは、 
クライアントライブラリの提供と 
幾つかの代表的な 
シャーディングパターンに沿ったサービス提供 
をします。 
蒼の王座 
http://sqlazure.jp/b/
蒼の王座 
http://sqlazure.jp/b/ 
Federationとの比較 
ライブラリの提供 
複数シャードへのクエリ発行が可能 
シャーディングルールにListが追加 
シャーディングのセキュリティ強化
蒼の王座 
http://sqlazure.jp/b/ 
ライブラリの提供 
Federationでは、 
ライブラリが提供されずシャーディングに 
対応するのに中間コードを実装する必要があっ 
た 
ライブラリ 
Azure SQL Database Elastic Scale Clientが 
Nugetで提供されている
Data Dependent Routing 
ShardMap.OpenConnectionForKey
蒼の王座 
http://sqlazure.jp/b/ 
複数シャードへのクエリ発行 
Federationでは、 
アプリケーション側で、 
それぞれのシャードに個別にクエリを発行し 
取得した結果をアプリケーション側で 
マージする必要がありました。
Multi-shard Query 
MultiShardCommand、MultiShardDataReader
蒼の王座 
http://sqlazure.jp/b/ 
シャーディング用のコードを減らし、 
ビジネスロジックのコードに 
専念できるようにします。
蒼の王座 
http://sqlazure.jp/b/ 
Elastic Scaleの方向性 
クラウドコンピューティングの柔軟性を約束 
• インターネット越しに無限のキャパシティー提供 
• 随時、キャパシティーの拡張、縮退が可能 
• 従量課金モデル 
• 一般的なハードウェア利用によるコスト効率 
• 高いスケーラビリティを持つシャードデータベースデザイン 
Azure SQL Database Elastic Scale 
• ADO.NETとEntity Frameworkのようなツールを使用して、Azure SQL DBで 
シャードデータモデルのアプリケーションを簡単に開発できる 
• 必要に応じたAzure SQL DBリソースのスケール拡張、縮退 
• 多くのAzure DBデータベースに対する簡単な管理 
Azure SQL Database Elastic Scaleパブリックプレビュー開始
蒼の王座 
http://sqlazure.jp/b/ 
パブリックプレビューでできること 
.NET APIクライアント管理サービス 
シャードマップ管理 
• シャードグループの定義 
• シャードのルーティングキーのマッ 
プ管理 
Data dependent routing 
• シャードに接続するためのリクエス 
トルーティング 
• ルーティング情報のキャッシュ 
複数シャードへのクエリ発行 
• 複数シャードへのクエリ発行 
• 全てのシャードにUNION ALLを使用 
した同一ステートメントの実行 
スプリット/マージサービス 
• スケールユニットの追加、削除によるキャパ 
シティーの拡張、縮退 
• スケールユニットの動的変更 
• ポリシーによる動的トリガー 
ツールとサンプル 
Federation Migration Utility 
• FederationからElastic Scaleへの移行 
Shard Elasticity 
• Azure Automationを利用したポリシーベース 
の分割 
Entity Framework 
• Elastic Scaleのガイドライン
Azure sql database 入門 2014年10月版

Azure sql database 入門 2014年10月版