Azure に SQL Server をデプロイするための PaaS オプションについて説明する
サービスとしてのプラットフォーム (PaaS) は、シンプルなクラウドベースのアプリケーションや高度なエンタープライズ アプリケーションに使用できる、クラウド内の完全な開発およびデプロイ環境を提供します。
Azure SQL Database と Azure SQL Managed Instance は、Azure SQL の PaaS オファリングの一部です。
Azure SQL Database – クラウド内の SQL Server エンジンに基づいて構築された製品ファミリの一部。 これにより、開発者は新しいアプリケーション サービスを構築する際の柔軟性が大幅に向上し、大規模な詳細なデプロイ オプションが提供されます。 SQL Database は、特定のワークロードに最適なオプションになる可能性のある、低メンテナンス ソリューションを提供します。
Azure SQL Managed Instance– フル マネージドのサービスと機能を提供するため、クラウドへのほとんどの移行シナリオに最適です。
各オファリングは、コスト効率の程度によって、インフラストラクチャに対する一定のレベルの管理を提供します。
デプロイ モデル
Azure SQL Database は、次の 2 つの異なるデプロイ モデルで使用できます。
単一データベース – データベース単位レベルで課金および管理される単一データベース。 各データベースは、スケールとデータ サイズの観点から個別に管理します。 このモデルにデプロイされた各データベースには、同じ論理サーバーにデプロイされている場合でも、独自の専用リソースがあります。
エラスティック プール – 一緒に管理され、共通のリソース セットを共有するデータベースのグループ。 エラスティック プールは、すべてのデータベース間でリソースが共有されるため、サービスとしてのソフトウェア アプリケーション モデルにコスト効率の高いソリューションを提供します。 DTU ベースの購入モデルまたは仮想コアベースの購入モデルに基づいてリソースを構成できます。
購入モデル
Azure では、すべてのサービスが物理ハードウェアをサポートしており、2 つの異なる購入モデルから柔軟に選択できます。
データベース トランザクション ユニット (DTU)
DTU ベースの購入モデル は、コンピューティング、ストレージ、および I/O リソースを組み合わせた数式に基づいて計算されます。 これは、構成済みのシンプルなリソース オプションが必要なお客様に適しています。
DTU 購入モデルには、Basic、Standard、Premium など、いくつかの異なるサービス レベルがあります。 各レベルにはさまざまな機能があり、このプラットフォームを選択する際にさまざまなオプションが提供されます。
パフォーマンスの面では、Basic レベルは要求の厳しいワークロードに使用され、Premium レベルは負荷の高いワークロード要件に使用されます。
コンピューティング リソースとストレージ リソースは DTU レベルに依存し、固定ストレージ制限、バックアップリテンション期間、コストでさまざまなパフォーマンス機能を提供します。
DTU 購入モデルの詳細については、 DTU ベースの購入モデルの概要を参照してください。
仮想コア
仮想コアベースの購入モデルを使用すると、特定のワークロードに基づいて、指定した数の仮想コアを購入できます。 仮想コアは、Azure SQL Database リソースを購入するときの既定の購入モデルです。 仮想コア データベースには、コアの数と、データベースに提供されるメモリとストレージの量との間に特定の関係があります。 仮想コア購入モデルは、Azure SQL Database と Azure SQL Managed Instance の両方でサポートされています。
仮想コア データベースは、次の 3 つの異なるサービス レベルで購入することもできます。
| サービス レベル | 最適な対象者 | ストレージの種類 | 遅延 | コンピューティング レベル | 回復性の機能 | 最大データベース サイズ |
|---|---|---|---|---|---|---|
| General Purpose | 汎用ワークロード | Azure Premium Storage | BC より高い | プロビジョニング済み、サーバーレス | なし | 4テラバイト (4 TB) |
| Business Critical | 高パフォーマンスのワークロード | ローカル SSD | 最低 | プロビジョニング済み | 組み込みの読み取り専用レプリカ、障害に対する最も高い回復性 | 4テラバイト (4 TB) |
| Hyperscale | 大規模なデータベース | Azure Premium Storage | 場合により異なる | プロビジョニング済み | スケーリングのための独自のアーキテクチャ | 100 TB |
General Purpose サービス レベルには、プロビジョニングとサーバーレスの 2 つのコンピューティング オプションが用意されています。 プロビジョニングされたリソースは、構成された仮想コアに基づいて事前に割り当てられ、1 時間ごとに課金されます。一貫性のあるワークロードに最適です。 サーバーレス リソースは需要に基づいて自動スケーリングされ、1 秒あたりに課金されるため、変動するワークロードではコスト効率が高くなります。
サーバーレス
"サーバーレス" という用語は、接続のために Azure SQL Database を論理サーバーにデプロイしているため、誤解を招く可能性があります。 サーバーレス は、ワークロードの需要に基づいてリソースを自動的にスケールアップまたはスケールダウンするコンピューティング レベルです。 ワークロードにコンピューティング リソースが不要になった場合、データベースは一時停止され、非アクティブ期間中はストレージのみが課金されます。 接続が試行されると、データベースが再開され、使用可能になります。
一時停止を制御する設定は自動一時停止遅延と呼ばれ、最小値は 60 分、最大値は 7 日間です。 その期間、データベースがアイドル状態のままである場合は、一時停止します。
指定した時間、データベースが非アクティブになると、後続の接続が試行されるまで一時停止します。 コンピューティングの自動スケール範囲と自動一時停止の遅延を構成すると、データベースのパフォーマンスとコンピューティング コストに影響します。
サーバーレスを使用するアプリケーションは、接続エラーを処理し、再試行ロジックを含むように構成する必要があります。一時停止しているデータベースに接続すると接続エラーが発生するためです。
サーバーレスと Azure SQL Database の標準仮想コア モデルのもう 1 つの違いは、サーバーレスでは仮想コアの最小数と最大数を指定できることです。 メモリと I/O の制限は、指定された範囲に比例します。
この画像は、Azure portal のサーバーレス データベースの構成画面を示しています。 仮想コアの半分の最小値と最大 16 個の仮想コアを選択できます。
サーバーレスは、Azure SQL Database のすべての機能と完全に互換性があるわけではありません。一部の機能では、次のようなバックグラウンド プロセスを常に実行する必要があるためです。
- ジオレプリケーション
- 長期のバックアップ保存期間
- エラスティック ジョブのジョブ データベース
- SQL データ同期の同期データベース (データ同期は、データベースのグループ間でデータをレプリケートするサービスです)
注
サーバーレスは現在、仮想コア購入モデルの General Purpose レベルでのみサポートされています。
バックアップ
サービスとしてのプラットフォームオファリングの最も重要な機能の 1 つはバックアップです。 この場合、システムはユーザーの介入なしにバックアップを自動的に実行します。 Azure BLOB geo 冗長ストレージにはこれらのバックアップが格納されます。既定では、データベースのサービス レベルに応じて 7 日から 35 日間保持されます。 Basic データベースと仮想コア データベースの既定のリテンション期間は 7 日間であり、管理者は仮想コア データベースに対してこの値を調整できます。 長期リテンション期間 (LTR) を構成することでリテンション期間を延長できます。これにより、バックアップを最大 10 年間保持できます。
冗長性を提供するために、読み取りアクセス可能な geo 冗長 BLOB ストレージを使用することもできます。 このストレージは、データベース バックアップを好みのセカンダリ リージョンにレプリケートします。 必要に応じて、そのセカンダリ リージョンから読み取ることもできます。 データベースの手動バックアップはサポートされておらず、プラットフォームは要求を拒否します。
データベース バックアップは、特定のスケジュールに従って実行されます。
- 完全 - 週に 1 回
- 差分 - 12 時間ごと
- 丸太– トランザクション ログ アクティビティに応じて 5 分から 10 分ごと
このバックアップ スケジュールは、ほとんどの復旧ポイント/時間目標 (RPO/RTO) のニーズを満たしている必要があります。ただし、各顧客は、ビジネス要件を満たしているかどうかを評価する必要があります。
データベースを復元するには、いくつかのオプションがあります。 サービスとしてのプラットフォームの性質上、T-SQL コマンド RESTORE DATABASEの発行など、従来の方法を使用してデータベースを手動で復元することはできません。
実装されている復元方法に関係なく、既存のデータベースに対して復元することはできません。 データベースを復元する必要がある場合は、復元プロセスを開始する前に、既存のデータベースを削除または名前変更する必要があります。 さらに、プラットフォームのサービス レベルによっては、復元時間は保証されず、変動する可能性があることに注意してください。 復元プロセスをテストして、復元にかかる時間に関するベースライン メトリックを取得することをお勧めします。
Azure portal を使用した復元 – Azure portal を使用すると、Azure SQL Database の同じ論理サーバーにデータベースを復元することも、復元を使用して任意の Azure リージョンの新しいサーバーに新しいデータベースを作成することもできます。
スクリプト言語を使用した復元 – PowerShell と Azure CLI の両方を使用して、データベースを復元できます。
注
Azure blob storage へのコピーのみのバックアップは、SQL Managed Instance で使用できます。 SQL Database では、この機能はサポートされていません。
自動バックアップの詳細については、「 自動バックアップ - Azure SQL Database と Azure SQL Managed Instance」を参照してください。
アクティブ geo レプリケーション
geo レプリケーション は、データベースを最大 4 つのセカンダリ レプリカに非同期的にレプリケートするビジネス継続性機能です。 トランザクションがプライマリ (および同じリージョン内のレプリカ) にコミットされると、トランザクションは再生されるセカンダリに送信されます。 この通信は非同期的に行われるので、呼び出し元アプリケーションは、SQL Server が呼び出し元に制御を返す前に、セカンダリ レプリカがトランザクションをコミットするのを待機する必要はありません。
セカンダリ データベースは読み取り可能であり、読み取り専用ワークロードをオフロードするために使用できるため、プライマリ上のトランザクション ワークロードのリソースを解放したり、エンド ユーザーに近いデータを配置したりできます。 さらに、セカンダリ データベースは、プライマリリージョンと同じリージョンに配置することも、別の Azure リージョンに配置することもできます。
フェールオーバーは、ユーザーが手動で開始するか、アプリケーションによってプログラムで開始できます。 フェールオーバーが発生した場合は、アプリケーション接続文字列を更新して、現在のプライマリ データベースの新しいエンドポイントを反映させることができます。
フェールオーバー グループ
フェールオーバー グループ は、geo レプリケーションで使用されるテクノロジに基づいて構築されますが、接続用の単一のエンドポイントを提供します。 フェールオーバー グループを使用する主な理由は、トラフィックを適切なレプリカにルーティングするために使用できるエンドポイントを提供するためです。 その後、接続文字列を変更せずに、フェールオーバー後にアプリケーションを接続できます。