Azure SQL ServerとAzure SQL database 違いと設計ポイント（1/2）

二回に分けてAzure SQL ServerとAzure SQL databaseの違いや仕様について説明する。これら二つのサービスは多くをAzureが管理をしてくれるため、オンプレのデータベース管理を経験した人ならその便利さを理解し、すぐ使ってみたくなるはずだ。まずは二つの違いについて説明する。

Azure SQL Serverとは

Azure SQL Serverとは、Azure管理のSQL Serverだ。

注意ポイント

これはVMにインストールされたSQL Serverとは違うという点に注意してほしい。

画像のように、Azureサービスの中に存在するSQL Serverだ。

特徴は、簡単なボタン操作でSQL Serverが立ち上がるということだ。そして、そのSQL Serverの管理は、Azureがやってくれる。このAzure SQL Serverは構築時に論理サーバのみとして画像のように明示されているからVMとは違うのだなとイメージしやすい。

もちろん、耐障害性でお世話になる冗長性の仕組みも搭載されている。

Azure SQL databaseを使う場合は、このSQL Serverが必須となる。そのため、両方のサービスを覚えておいてほしい。

フェールオーバーグループ

私がなぜ、Azure SQL Serverをお勧めするか。それは、この機能があるからだ。フェールオーバーグループとは、オンプレのSQL Serverでもお世話になったSQL Server Always Onのような機能だ。（というか多分その仕組みを使ってる。）Azureの論理SQL Server同士をフェールオーバーグループとしてまとめて、片方に障害が発生した時に、もう片方のSQL Serverにフェールおーばしてくれる機能だ。

今まで、オンプレでこの機能を装備させようと考えたら、SQL Serverをもう一台立てて、ソフトウェアを入れて設定して、テストして・・・という作業が必要であった。しかし、便利な世の中になった。数回のボタンクリックと名前入力だけでそれができるのだ。所要時間は10分程度で、SQL Serverの冗長性を担保できるようになったのだ。これはお勧めしたい。というか、次の仕事ではこれを使いたい。工数が減る。

画像を見てもわかるように視覚的にもわかりやすい。画像の例だと、日本の中、東日本リージョンと西日本リージョンでクラスタを組んでいるということがわかる。

そして、読み取り/書き込みのリスナーエンドポイントという名前からも察しがつくように、フェールオーバーグループを作るとエンドポイントが自動的に作成される。このエンドポイントめがけてアプリケーションが接続をしている場合、SQL Serverに障害が発生したとしても、エンドポイントが待機系のSQL Serverに移動するため、アプリケーション側は障害にはならないのだ。

そして、Azure SQL Server側の障害は、Azureが直してくれる。ユーザ側は何もしなくて良いのだ。

バックアップ

別で説明するSQL databaseのバックアップもここで設定する。SQL Serverの方でバックアップを設定するのだ。よく混乱する二種類についてまとめる。

PITR（Point in time recovery）

Point in time recoveryの略。

ポイント

Azure SQL ServerにSQL databaseを構築した後、大体30分程度してから自動でバックアップがとられる。

PITRのバックアップタイミングについては、下記ドキュメントを参照。

引用：https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-automated-backups

SQL Database では、完全バックアップ、差分バックアップ、トランザクションログバックアップを自動的に作成して、ポイントインタイムリストア (PITR) のセルフサービスをサポートします。完全データベースバックアップは毎週、差分データベースバックアップは一般的に 12 時間ごとに、トランザクションログバックアップは通常、5 - 10 分ごとに作成されます。頻度は、コンピューティングサイズとデータベースアクティビティの量に基づきます。初回の完全バックアップは、データベースの作成直後にスケジュールされます。通常この操作は 30 分以内に終了しますが、データベースのサイズが大きい場合はそれ以上かかることがあります。

下記画像が実機の例だ。画像のように設定できる。

LTR（Long-term-retention）

long-term-retentionの略。長期間”完全バックアップを”バックアップを保持しておきたい場合に使用する。これはポイントがあるため、説明する。

引用：https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-long-term-retention

注意ポイント

このLTRバックアップは設定しないと取得されない=リストに出てこない。そして、PITRと混合しやすいため注意してほしい。

下記画像を見ると、使用可能な可能なバックアップの一覧にバックアップが存在しないことがわかる。これをPITRと混乱すると自動バックアップされていないじゃないかと思うかもしれないが、そうではない。二枚目の画像のように、LTRを設定しないと取得されない。一週間前のバックアップを保持ならそのタイミングを過ぎて初めてLTRバックアップが保持される。

これは、PITRで取得される完全バックアップをLTRとして別ストレージに退避する理解で問題ない。