Azure SQLデータベースのマネージドインスタンスは2018年後半に一般提供されました。それ以来、多くの組織がマネージド環境のメリットのためにマネージドインスタンスへの移行を開始しています。組織は、管理されたバックアップ、多くの組み込みのセキュリティ機能、99.99％の稼働時間SLA、およびSQLServerやオペレーティングシステムへのパッチ適用を担当しない常に最新の環境を利用しています。
1つのサイズはありません 常にすべてに適合します。 マネージドインスタンスは、パフォーマンスのために2つの層を提供します。 汎用 ティアは、一般的なパフォーマンスとI / Oレイテンシ要件を備えたアプリケーション向けに設計されており、組み込みのHAを提供します。 ビジネスクリティカル ティアは、低いI/Oレイテンシと高いHA要件を必要とするアプリケーション向けに設計されています。 Business Criticalは、2つの読み取り不可能なセカンダリと1つの読み取り可能なセカンダリも提供します。読み取り可能なセカンダリは、プライマリからワークロードを分散するための優れた方法です。これにより、プライマリに必要なサービスティアを下げることができ、インスタンスの全体的な支出を減らすことができます。
マネージドインスタンスが最初にリリースされたとき、Gen4プロセッサとGen5プロセッサのどちらかを選択できました。 Gen4はまだドキュメントに記載されていますが、このオプションは現在ほとんど利用できません。この記事では、Gen5プロセッサを使用した構成についてのみ説明します。
各サービス層は、4〜80個の論理CPU（仮想コア、またはvCoreとも呼ばれます）をサポートします。メモリは、vCoreあたり約5.1GBで割り当てられます。汎用は最大8TBの高性能AzureBlobストレージを提供し、BusinessCriticalは最大4TBの超高速ローカルSSDストレージを提供します。
メモリ
vCoreあたり5.1GBのメモリしかないため、vCoreの数が少ないインスタンスは問題が発生する可能性があります。 vCore構成のオプションは、4、8、16、24、32、40、64、および80vCoreです。各vCoreオプションで計算を行う場合（(number of vCores) × (5.1 GB) ）、次のコア/メモリの組み合わせが得られます：
4 vCores = 20.4 GB 8 vCores = 40.8 GB 16 vCores = 81.6 GB 24 vCores = 122.4 GB 32 vCores = 163.2 GB 40 vCores = 204.0 GB 64 vCores = 326.4 GB 80 vCores = 408.0 GB
オンプレミスからマネージドインスタンスへの移行を支援してきた多くの組織では、メモリが大幅に削減されています。オンプレミスの一般的な構成は、4つのvCoreと32 GBのメモリ、または8つのvCoreと64GBです。どちらもメモリを30％以上削減します。インスタンスがすでにメモリ不足になっている場合、これにより問題が発生する可能性があります。ほとんどの場合、オンプレミスインスタンスを最適化して、マネージドインスタンスに移行する前にメモリの負荷を軽減することができましたが、場合によっては、メモリの負荷を軽減するために、より高いvCoreインスタンスを使用する必要がありました。 。
ストレージ
複数の要因を考慮する必要があるため、ストレージの計画と検討は少し難しくなります。ストレージについては、ストレージサイズとI/Oの両方のニーズに対する全体的なストレージ要件を考慮する必要があります。 SQL Serverインスタンスに必要なGBまたはTBの数と、ストレージの速度はどれくらいである必要がありますか？オンプレミスインスタンスが使用しているIOPSとスループットはいくつですか？そのためには、perfmonを使用して現在のワークロードをベースライン化し、平均および最大MB /秒をキャプチャするか、sys.dm_io_virtual_file_statsのスナップショットを取得してスループット使用率をキャプチャする必要があります。これにより、新しい環境で必要なI/Oとスループットのタイプがわかります。私が一緒に仕事をした何人かの顧客は、移行計画のこの重要な部分を見逃し、ワークロードをサポートしていないインスタンスレベルを選択したためにパフォーマンスの問題に遭遇しました。
オンプレミスサーバーでは、高スループット機能を備えた超高速SANからより小さなサイズの仮想マシンにストレージが提供されるのが一般的であるため、これはベースラインにとって重要です。 Azureでは、IOPSとスループットの制限は、計算ノードのサイズによって決まります。インスタンスの管理の場合は、割り当てられたvCoreの数によって決まります。汎用の場合、ファイルサイズに応じて、インスタンスあたり30〜40k IOPS、またはファイルあたり500〜12,500IOPSの制限があります。ファイルあたりのスループットも、最大128GBのファイルの場合は100MiB / sから始まり、4TB以上のファイルの場合は最大480MiB/sの範囲のサイズに基づいています。ビジネスクリティカルでは、IOPSの範囲はインスタンスあたり5.5K〜110K、またはvCoreあたり1,375IOPSです。
コンシューマーは、インスタンスのログ書き込みスループットも考慮する必要があります。汎用はvCoreあたり3MB/ s、インスタンスの最大値は22MB / s、ビジネスクリティカルはvCoreあたり4 MB / s、インスタンス全体の最大値は48 MB/sです。私が顧客と協力した経験では、多くの人が書き込みスループットのこれらの制限をはるかに超えています。一部の人にとっては目を見張るものであり、他の人にとっては、システムを最適化および変更して負荷を減らすことができました。
全体的なスループットとI/O要件を知る必要があることに加えて、ストレージサイズは選択したvCoreの数にも関係しています。汎用：
4 vCores = 2 TB max
8 - 80 vCores = 8 TB max
ビジネスクリティカルの場合：
4 – 16 vCores = 1 TB
24 vCores = 2 TB
32 - 80 vCores = 4 TB
汎用の場合、8つのvCoreに到達すると、使用可能なストレージを最大限に活用できます。これは、汎用のみが必要なユーザーに適しています。しかし、ビジネスクリティカルが必要な場合、事態はさらに困難になる可能性があります。私は、4、8、16、および24個の論理プロセッサを搭載したVMに複数のTBが割り当てられている多くのお客様と協力してきました。これらのお客様の場合、コストのかかるオプションであるストレージ要件を満たすために、少なくとも32個のvCoreを上に移動する必要があります。 Azure SQL Databaseにもデータベースの最大サイズに関する同様の問題があり、Microsoftはハイパースケールオプションを考え出しました。これは、ある時点で、同様の方法でストレージ制限に対処するためのマネージドインスタンスのオプションになると予想されます。
tempdbのサイズは、vCoreの数にも相関しています。汎用層では、データファイル用にvCoreごとに24 GB（最大1,920 GB）を取得し、tempdbログファイルのサイズ制限は120GBです。ビジネスクリティカル層の場合、tempdbは現在利用可能なインスタンスストレージサイズまで大きくなる可能性があります。
インメモリOLTP
現在インメモリOLTPを利用している（または利用する予定の）人は、ビジネスクリティカルサービス層でのみサポートされていることに注意してください。インメモリテーブルに使用できるスペースの量も、vCoresによって制限されます：
4 vCores = 3.14 GB
8 vCores = 6.28 GB
16 vCores = 15.77 GB
24 vCores = 25.25 GB
32 vCores = 37.94 GB
40 vCores = 52.23 GB
64 vCores = 99.90 GB
80 vCores = 131.86 GB
結論
Azure SQLマネージドインスタンスへの移行を計画する場合、移行を決定する前に考慮すべき複数の考慮事項があります。まず、メモリ、CPU、およびストレージの要件を完全に理解する必要があります。これにより、インスタンスのサイズが決まります。同様に重要なのは、ストレージI/O要件が何であるかを知ることです。汎用層のIOPSとスループットは、vCoreとデータベースファイルのサイズに直接関係しています。ビジネスクリティカルの場合、vCoreの数に関連付けられます。 I / Oを集中的に使用するワークロードがある場合、ビジネスクリティカルは、より高いIOPSとスループットの数値を提供するため、より魅力的なサービス層です。 Business Criticalの課題は、ストレージ容量が少なく、最大16vCoreのインスタンス全体で1TBしかサポートしないことです。
適切な計画を立て、大規模なインスタンスを小規模な管理対象インスタンスに非統合化する可能性があるため、このオファリングは多くの組織にとって非常に実行可能な移行オプションになります。魅力は、管理されたバックアップ、99.99％のSLAを備えた組み込みHA、追加されたセキュリティ機能とオプション、およびOSまたはSQLServerインスタンスへのパッチ適用について心配する必要がないことの利点です。