Skip to content

MS_AzureSQLDatabase

nishi_74322014 edited this page Aug 19, 2026 · 1 revision

Azure SQL Database

概要

  • Azure 上にある SQL Server の PaaS 的データベース
  • SQL Server on Azure ではない(IaaS)。

補足(この一行が最も重要な区別): 「SQL Server on Azure ではない」という
注記が示すとおり、Azure で SQL Server を使う方法は3 つあり、
まずどれを選ぶかを決める必要がある。

方式 実体 管理範囲 互換性
SQL Server on Azure VM IaaS。VM に SQL Server を入れる OS も SQL も自分で 100%
SQL Managed Instance PaaS(インスタンス単位) SQL の運用はほぼ Azure ほぼ 100%
Azure SQL Database PaaS(DB 単位) Azure が全部 一部制限あり

右に行くほど楽になるが、使えない機能が増える
Azure SQL Database で使えない主なものは、

  • SQL Server エージェント(ジョブは Elastic Job / Logic Apps 等で代替)
  • クロス DB クエリ(3 部・4 部名称。Elastic Query で一部代替)
  • CLR 統合、Service Broker、ファイル ストリーム
  • USE 文(DB を跨げない)
  • MSDTC による分散トランザクションMSDTC

既存システムの移行では、この非互換が移行可否を決める
**Data Migration Assistant(DMA)**で事前に評価するのが定石である
SQL Server のアップグレードと移行)。

詳細

以下のような建付けになっている。

SQL データベース

Single Database

フル マネージドの分離されたデータベース

エラスティック プール

Elastic Scale, Elastic Database Pool

  • Single Databaseのコレクション。
  • Single Database は Elastic Scale, Elastic Database Pool の内外に移動できる。

補足(エラスティック プールが効く場面): プールの本質は
**「リソースを複数の DB で融通し合う」**ことにある。

【Single Database × 10】 各 DB に個別に性能を確保 → 使っていない分も課金
  DB1[■□□□] DB2[■□□□] ... DB10[■□□□]   ← 合計 10 個分の費用

【エラスティック プール】 プール全体で性能を共有
  Pool[■■■■□□□□] ← DB1〜10 が必要な時に使う  ← 合計 4 個分程度の費用

つまり、**「多数の DB があり、ピークがずれる」**場合に効く。
典型例はマルチテナント SaaS で、
テナントごとに DB を分ける構成である
SQL Server の Elastic Scale とプール)。

逆に、全 DB が同時にピークを迎える場合は効果が無い
(むしろ互いに食い合う)。

データベース サーバー

中央管理ポイントとして機能する論理構築物
(と言う事で、これダケ、デプロイモデルに含まれない)

  • 複数の単一データベースまたはプールされたデータベース
  • ログイン、ファイアウォール規則、監査規則、
    脅威検出ポリシー、フェイル・オーバー グループ

補足(「論理構築物」の意味): xxx.database.windows.net という
サーバは、物理的なサーバではない
オンプレミスの SQL Server インスタンスとの違いは決定的である。

オンプレのインスタンス Azure SQL の論理サーバー
実体 プロセス(sqlservr.exe) 管理と接続の窓口だけ
リソース インスタンス内の DB が共有 DB ごとに独立(共有しない)
DB を跨ぐクエリ できる できない
master DB 実体がある 中身はほぼ空(メタデータのみ)

「同じサーバーに置いたから速く連携できる」ということは無く、
DB 同士は完全に独立している
この点を誤解すると、移行時に
「同じサーバーに移したのにクロス DB クエリが動かない」
という問題に直面する。

論理サーバーが実際に担うのは、

  • 接続のエンドポイント(FQDN)
  • ファイアウォール規則(送信元 IP の許可)
  • Microsoft Entra ID 管理者の設定
  • 監査・脅威検知の設定
  • フェイル オーバー グループ(後述)

といった管理面の共通設定である。

SQL マネージド インスタンス

SQL Server データベース エンジンのフル マネージド インスタンス

マネージド インスタンス

最新の SQL Server データベース エンジンとの 100% 近い互換性

インスタンス プール

  • 小規模な SQL インスタンスを大規模にクラウドに移行するために便利
  • マネージド インスタンス用のインスタンス プール?

補足(Managed Instance が「移行の本命」である理由): 前掲の非互換一覧のうち、
Managed Instance では多くが使える

機能 SQL Database Managed Instance
SQL Server エージェント 不可
クロス DB クエリ 不可
CLR 統合 不可
Service Broker 不可
リンク サーバー 不可 SQL Server のリンクサーバ
ネイティブ バックアップ/復元 不可 .bak から復元できる)
VNET 内への配置 Private Endpoint 既定で VNET 内

つまり、既存のオンプレ DB を「そのまま」持ち上げるなら
Managed Instance が第一候補になる。

一方、

  • 費用が高い(最小構成でも相応の規模になる)、
  • VNET のサブネットを専有する(専用サブネットが必要)、
  • デプロイに時間がかかる(数時間)

といった制約があるため、
新規開発なら SQL Database、既存移行なら Managed Instance
というのが基本的な使い分けになる。

冗長オプション

Standard/GP

Premium/GP

Geo Replication

補足: この 3 段階はAzureの冗長化の表の
4 行目に対応する(ラック分散 / DC 分散 / 地理分散)。
要点を補っておく。

購入モデル/レベル 冗長性 内容
Standard / General Purpose ラック分散相当 コンピューティングとストレージが分離。障害時は別ノードで再接続(数十秒)
Premium / Business Critical DC 分散相当 ローカルの SSD 上に 4 つのレプリカ(AlwaysOn 相当)。フェイル オーバーが速く、読み取りレプリカも使える
ゾーン冗長オプション AZ 分散 上記のレプリカを可用性ゾーンに分散(Premium / BC、および GP でも選択可)
Geo Replication / フェイル オーバー グループ 地理分散 別リージョンに非同期で複製。読み取り可能

実務上の要点は 2 つある。

  1. General Purpose を選ぶと、ゾーン冗長は明示的に有効化しないと付かない
    アプリ層だけ AZ 冗長にしてもデータ層が単一 DC、という
    片手落ちが起きやすい(Azureの冗長化)。
  2. Geo Replication は非同期である。
    フェイル オーバー時に直近のトランザクションが失われ得る(RPO > 0)。
    ゼロを求めるなら地理分散ではなくゾーン冗長を使う。

なお、フェイル オーバー グループを使うと
接続文字列をリスナー名xxx.database.windows.net)のままにでき、
切り替え時にアプリ側の設定変更が不要になる。

補足: 既定では Azure SQL Database は
パブリック エンドポイントを持ち、ファイアウォール規則で
送信元 IP を制限する形になっている。
閉域化するには Private Endpoint を使い、
パブリック アクセスを無効化する
Azure Private Endpoint)。

注意点として、

  • ファイアウォール規則の**「Azure サービスへのアクセスを許可」を
    有効にすると、他テナントを含む全 Azure から到達できる**
    (このチェックは実質「全 Azure 許可」であり、閉域化とは相容れない)、
  • Private Endpoint 化するとDNS の解決先が変わるため、
    プライベート DNS ゾーンの構成が必要になる
    AzureのDNS

という 2 点が要注意である。

参考

@IT

Microsoft Docs


Tags: 移行, クラウド, Azure, データアクセス, SQL Server

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

(未着手)

開発基盤部会 Wiki

移行管理: DONETODO

Clone this wiki locally