このページはAzure SQL databaseについて説明する。前回の記事を読んでいない場合は、前記事から読み進めてほしい。
Azure SQL ServerとAzure SQL database 違いと設計ポイント（1/2）
-
-
Azure SQL ServerとAzure SQL database 違いと設計ポイント（1/2）
二回に分けてAzure SQL ServerとAzure SQL databaseの違いや仕様について説明する。これら二つのサービスは多くをAzureが管理をしてくれるため、オンプレのデータベース管理 ...
続きを見る
Azure SQL databaseとは
Azure SQL databaseとは、Azureがdatabaseを管理してくれるSaaSの一種だ。ユーザ側がＶＭを立てて、SQL Serverをインストールして、データベースを構築して・・・という作業は必要ない。数回のボタンクリックで、SQL Serverのデータベースが利用できるのだ。詳しくは下記記事を参照。
ユーザ側の意見
これほど嬉しいことはない。従来、データベースとは、システムの最も大事な部分であった。耐障害性、性能、データベースのバックアップ、リストア、保守・・・そういった細かい点を設計し、カバーしないといけなかった。
現代社会は情報が命である。情報をどうやって永久に保持し活用し続けるか。最近はリレーショナルデータベース以外にも、NoSQLが出現しさまざま種類のデータベースが登場してきた。しかし、根本は変わらない。情報をどうやって安全に活用し続けるか。ということだ。
前記事のSQL Serverと合わせて、このAzure SQL databaseを使えば、ユーザ側はその大部分の管理から解放される。HW管理、バックアップ管理、ソフトウェア保守、耐障害時の動作・・・これらはすべてAuzreが設計し管理し保証してくれるからだ。
前記事を読んだのであれば、バックアップはAzure SQL Serverの範囲であることを理解できたと思う。次からはAuzre SQL databaseの特徴的な仕組みを説明する。
Geo-Replication（Geo レプリケーション）
ポイント
Geo-Replicationとは、従来のSQL Server ログ配布に近い機能だ。
Azure SQL Serverでグループを組んでいる場合、プライマリではない、セカンダリのSQL Server上にあるデータベース側にトランザクションデータが渡され、プライマリのデータベースとセカンダリのデータベース間で同期がとられる仕組みだ。完全同期ではないが、これで、SQL ServerやSQL databaseに障害が発生した場合でも、多くの情報を失うことなく、セカンダリでシステムを継続することができる。
仕様説明
注意ポイント
前記事で説明したフェールオーバーグループと混同しないこと。
設定は画面の通り、データベースを選択し、SQL Serverを選択し、レプリケーションを組むことで完了する。この設定を忘れないようにしていただきたい。（忘れたことがある。）
DTUs
ポイント
DTUsとはDatabase Throughput Unitの略でAzure SQL database特有の新しい性能指標の概念である。
DTUはベンチマークテストにより、弊社が独自で決めており、具体的には、各サービスレベルのCPU、メモリ、およびディスクの読み書きを組み合わせた測定に基づいて算出しております。
引用：https://blogs.msdn.microsoft.com/jpsql/2017/09/06/azure-sql-database-dtu/
慣れれば簡単なのだが、「このサーバはメモリ12GB積んでいます。」と同じように「このAzure SQL databaseはDTUs100です。」という使い方になる。
CPUコアがxxで、メモリがxxGBで・・・という従来の考え方でなく、DTUsが100あります。という考え方となる。DTUsそれ自体は、CPUやメモリ、DISKIOリソースの組み合わせとなっている。
例えば、DTUsを用いたデータベースで性能試験をした場合、DTUsが100%に張り付いているならば、性能が足りないことになる。DTUsのレベルを上げる必要があるということだ。ちなみに、CPUが100%に張り付いて、メモリが0％だった場合も、DTUsは100%となる模様。（推測）
設計の進め方と設計方針
まずは費用を確認しましょう。結構高いです。しかし、バックアップの自動化等メリットははかりしれません。例えば、パッチ適用や自動フェールオーバーなど保守を考えたときに後々楽になります。
次に大事な観点としてDTUsを理解しましょう。これは、性能指標だと思ってください。オンプレであればCPU、メモリのサイズとその使用量が個別に測定できます。でもクラウドはそれらを共有しているため、測ることができません。なので、DTUというあらたな指標ができました。ポイントととしては、どのリソースが限界かはわからないことです。なので、DTUsを素直にあげましょう。もしくは、従来のオンプレと同じように細かく性能劣化の原因を確認するのもプロジェクト的には良い手かもしれません。
注意ポイント
大事なこととして、データベースの時間は変更できません。UTCになります。
なので、例えば、データベース上でSQLが実行された時間をレコードとして保持するシステムがある場合、クライアントが日本だとずれます。これはシステムの特性にもよりますが、考慮が必要です。
