Azure

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

投稿日:2019年5月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として別ストレージに退避する理解で問題ない。

 

 

次回に続く

 

おすすめ記事

1

敬愛してやまない大芸人であるコウメ太夫様が毎日実施されているツイート(#まいにちチクショー)を元に、機械学習初心者がPythonのプログラミングでデータ収集と学習を行い、コウメ太夫様っぽい文章を自動生 ...

2

正直私も最初はUdemyなんて聞いたことないし怪しいなと思いました。でも、今では実際に25講座ほど購入済みです。そんな私がUdemyの評判やお得な講座購入方法について書いていきます。   目次 Ude ...

3

先日AWSソリューションアーキテクトアソシエイト(AWS SAA)に一発で合格しました。スコアは800点台の後半でした。 世の中にはたくさんAWS SAAの合格体験記がありますが、私もこのサイトに合格 ...

4

この記事は、技術系ブログ運営の実情と運営するメリットについて詳しく書いていく。これから技術系ブログを始めたいと思っている人は、よく読んで参考にしていってください。そして、この記事を参考に技術系ブログを ...

-Azure

Copyright© CLOUD IT FUTURE , 2020 All Rights Reserved.