まずはSQL Database Single DBから始めよう

Azure SQLにはたくさんの種類があります。新規アプリケーションの構築の場合（アプリケーションの再設計が可能な場合）はまずSQL Database Single DBから検討をしてみましょう。
すでにSQL Serverを利用している場合は、SQL Server AgentやSQL Serverと同じマシンで動くことを前提にしたバッチなどが存在しているかもしれません。前者の場合はManaged Instanceを、後者も考慮しないといけない場合はSQL Server on Virtual Machinesを検討することになると思います。

PaaSのSQL Server

PaaSのSQL ServerにはIaaSにはない、運用コストを大幅に削減できるメリットがあります。

• 自動バージョンアップ
• 自動バックアップ
• 柔軟なスケールアップ、スケールダウン
• 仮想マシンレベルのセキュリティ対策が実施済
• ベストプラクティスが適用済 例：TempDBをCPU数分設けるなど

PaaSでは常に最新のSQL Serverを利用することができます。以下は2021-07-03に実施した結果です。表示される情報はSQL Serverのいずれかのバージョンと完全に対応するものではないとされています。

SELECT @@VERSION

バージョンが自動であがると書きましたが、オプティマイザの挙動などに関わる、compatibility_levelは変更されません。compatibility_levelは以下で確認できます。

SELECT name, compatibility_level FROM sys.databases;

SQL Database Single DB

SQL DatabaseにはBusiness CriticalとGeneral Purposeという二つのサービスレベルがあります。
一般的なワークロードであればGeneral Purposeでも耐えられるかもしれませんが、性能要件が厳しい場合はBusiness Criticalを使うことになると思います。

EngineEditionの確認結果です。それぞれ以下の意味です。※以降は省略します。

1 = Personal または Desktop Engine
2 = Standard
3 = Enterprise
4 = Express
5 = SQL Database
6 = SQL Data Warehouse
8 = SQL Managed Instance

SELECT SERVERPROPERTY('EngineEdition') AS EngineEdition;

SQL Databaseではmsdb、tempdb、および modelは表示されません。Azure SQL Managed Instance では表示されます。

SELECT * FROM sys.databases;

利用できるリソースを確認します。SQL Databaseでは通常、この時に使うsys.dm_process_memoryを利用することができず、sys.dm_user_db_resource_governanceを使います。Azure SQL Managed Instance ではsys.dm_instance_resource_governanceを使います。

SELECT * FROM sys.dm_user_db_resource_governance;

トランザクション ログはの最大サイズは、常に データの最大サイズ の 30% です。 データの最大サイズ が 1 TB の場合、最大トランザクション ログ サイズは 0.3 TB です。

SQL Database Elastic Pool

各データベースのピーク時の使用量と、平均使用量に大きな差があるときに、DBをまとめることができます。マルチテナントのサービスの新規アプリケーションの構築時で利用者ごとのピーク時間が重複しない場合に使えると思います。

SQL Database Hyperscale

Hyperscaleの一番の特徴は容量です。ディスク容量の考え方が最初に 40 GB のデータベースが作成され、100 TB の上限サイズまで自動的に拡大されます。トランザクション ログはの最大サイズも1 TB に固定されています。

Hyperscale サービス レベルは Azure SQL Database でのみ使用できます。 このサービス レベルでは、キャッシュとページ サーバーの階層化された層を使用して、データ ファイルに直接アクセスせずにデータベース ページにすばやくアクセスするように機能が拡張されているため、このレベルには固有のアーキテクチャがあります。

Hyperscaleの内部構造を図にしたものが以下です。

Hyperscaleでは計算ノード、ページサーバ、ログサービスという3つの役割を持ったノードが別々に存在しています。ページサーバは水平にスケールされ、すべてのデータがキャッシュ レイヤーに格納されます。ログ サービスは、レプリカとページ サーバーにデータを書き込む役割を担っています。通常のトランザクションログの場合と同じで、ログ サービスでランディング ゾーンに書き込みを行うとトランザクションはコミットできます。

Hyperscaleにはない様々な制限があります。

• Geoレプリケーションがまだプレビューです。
• 既存のDBをHyperscaleに変更することはできますが、Hyperscaleから他に変更することはできません。

SQL Database Serverless

オートスケールが可能でCPUを利用している時間、秒単位で課金されます。
一定期間アクセスがないと停止され、ストレージのみに課金される状態になります。

実行計画が消えたり、レスポンスが安定しなかったりするので、本番環境で利用するのはかなり勇気がいると思いますが、開発環境で特に性能をテストしているわけでない場合はServerlessが使えると思います。

Azure SQL Managed Instance

Managed InstanceではSQL Databaseでは封印されてしまったSQL Serverの多くの機能を利用することができます。個人的には肥大化していたSQL Serverの機能がスリムになってSQL Databaseとして提供されていることは良いことだと思いますが、以下の機能はSQL Databaseにも必要だと思います。

1. Resource Governorのカスタムリソースプール
2. トランザクションレプリケーションのPublisher
3. SQL Server Agent　※elastic jobsがプレビューになりました

中でもリソースの上限をコントロールできるResource Governorのカスタムリソースプールは別格というか、なんで使わせてくれないのか不思議です。これが使えればINSERT BULKとかIndexのRebuildとか重いバッチ処理がオンライン処理に影響を及ぼさないように、より簡単に制御できるのですが…

いずれにしてもManaged Instanceはこれらの機能の他、SQL Serverのほとんどの機能を利用できます。SQL Serverとの主な違いは以下です。

• 自動バックアップおよびポイントインタイム リストアのみが利用できる
• 完全な物理パスは指定できないため、BULK INSERT は Azure BLOBのみになる
• Windows 認証に代わりAzure AD 認証がサポートされる

IaaSのSQL Server

SQL Server on Virtual Machines

この方法では仮想マシンでSQL Serverを動かしている状態になります。仮想サーバにSQL Serverをインストールして利用している状態とほぼ同じですが、SQL Server IaaS エージェント拡張機能を利用することでバックアップとセキュリティ修正プログラムの適用を自動化することができます。

SQL Serverのインストールは自分でやる方法と、Azure ギャラリーのイメージからOSとセットで選択する方法の二つがあります。手軽なのは後者ですが、オンプレからの移行方法によっては結果として自分でインストールしたのと同じ状態になると思います。

シリーズAzure SQLの基礎

• Azure SQLの基礎 第1回 種類と使い分け - Qiita
• Azure SQLの基礎 第2回 SQL Databaseの冗長構成 - Qiita
• Azure SQLの基礎 第3回 認証 - Qiita