SE の雑記

SQL Database Managed Instance の各種情報を集めてみる ? その 1 ? の続きです。

前回は、SQL Database Managed Instance (MI) の特徴をざっくりとまとめてみました。
従来から提供されている、SQL Database (SQL DB) は「Managed Database」となっています。
SQL Server のインスタンスではなく、各データベースをリソース制御の境界とした、「データベース利用」の PaaS のサービスとなり、各データベースは独立して管理されており、一つの論理サーバー配下に複数のデータベースを作成した場合、独立した環境となっているのが特徴でした。
MI は「Managed Instance」となっています。
SQL Server のインスタンスをリソース制御の境界とした、「インスタンス利用」の PaaS のサービスとなり、インスタンス全体を利用することができるため、一つのインスタンス配下に複数のデータベースを作成した場合、同一の管理境界内に配置され、相互に利用が可能となっていることが特徴でした。
RDS for SQL Server や、Azure Database for MySQL / Azure Database for PostgreSQL に近い管理モデルとなっている形ですね。

MI は、既存の SQL Server からの「Lift & Shift」(既存の環境を変更なくクラウドに移行) を強く意識された環境であるため、SQL DB よりサポートされている機能が多いのも特徴の一つです。
Feature comparison: Azure SQL Database versus SQL Server
それでは、前回はまとめられなかった点についてもまとめていきたいと思います。

製品のパフォーマンスレベル

SQL Database
SQL DB は DTU という単位で製品のパフォーマンスレベルが決まるような体系となっていました。
データベース トランザクション ユニット (DTU) とエラスティック データベース トランザクション ユニット (eDTU)
DTU はデータベース単位で変更することができ、サイズによって次のようなリソース制御が変わってきます。

• データベースの最大サイズ
• ログイン / セッション / ワーカースレッドの最大数
• CPU / データファイル I/O / ログファイル I/O / メモリのリソース割り当て

DTU は、相対値としての比較材料となっており、何 CPU コア / 何 IOPS というような具体的なリソース制御がどのようになっているかは、情報として提供されていませんでした。
 
サービス階層としては、

• Basic / Standard / Premium

の 3 種類が提供されており、現時点では、Premium の場合のみ、次の機能が提供されています。

• 列ストアインデックス
• インメモリ OLTP
• DMV に対しての詳細な権限設定

 
Managed Instance
MI の場合は、DTU という単位でパフォーマンスレベルは設定されていません。
https://azure.microsoft.com/ja-jp/pricing/details/sql-database/managed/ に記載されていますが、サービス階層としては、次の 2 種類が提供されています。

• General Purpose
  • 汎用ワークロードでの利用を想定した、一般的なワークロードを提供
• Business Critical (今後提供予定)
  • 高速な I/O と高可用性を要件とした、ハイパフォーマンスなコンピューターおよびストレージオプションを提供

現時点では General Purpose のみが提供されており、BUsiness Critical については、今後の提供予定となっているため、まだ情報が公開されていないようですね。
現状は、次のようなリソースの制限が明記されていますが、基本的には General Purpose に適用されるものとなるため、Business Critical については情報の公開待ちです。

• CPU
  • 各サービス階層では、8 / 16 / 24 コアの CPU を選択できるようになっています。
  • 次の画像は、Create a Managed Instance から引用したものですが、このような GUI で作成時にインスタンスサイズを指定できるようになっているようです。
    

    

  • 料金ページ にも記載されているのですが、CPU の世代としては、Haswell と、Broadwell のモデルが用意されているようですが、明示的な指定はできないようですね。
    CPU コア数か、General Purpose / Business Critical のどちらを使用するかによって変わるのでしょうかね。

  仮想コアとは何ですか?

  仮想コア (vCore) は、ハードウェアの世代の選択が可能な、サーバーで使用できる論理 CPU を表します。Gen4 仮想コアを使用して作成されたサーバーの場合、仮想コアは Intel E5-2673 v3 (Haswell) 2.4 GHz プロセッサをベースにしています。Gen5 仮想コアを使用して作成されたサーバーの場合、仮想コアは Intel E5-2673 v4 (Broadwell) 2.3 GHz プロセッサをベースにしています。

• ストレージ
  • 32GB までのストレージが標準で含まれているようです。
    • General Purpose については、最大ストレージサイズは 8TB となっています。
    • 32GB 単位で追加課金が発生します。
  • General Purpose のストレージについては、Premium Storage を使用しているため、データファイル毎に 500 ～ 7,500 IOPS の制限があるようです。
    • データファイル
      • 32GB 単位での追加となるようなので、P4 の最小ディスクサイズに合わせているのでしょうが、P4 の場合、ディスク当たりの IOPS が 120 なので、標準搭載されている 32 GB のディスクが、Premium ストレージのどのレベルが使われているのかが不明ですね。
      • データファイルについては複数ファイルがサポートされているため、7,500 IOPS の上限については、複数のデータファイルを使用することで単一ファイルの IOPS の制限は緩和できるかと
        複数のデータファイルを有効に活用するのが、General Purpose の環境でのストレージ性能を向上させるポイントとなりそうです。
    • ログファイル
      • ログファイルについては、シングルファイルのみのサポートとなっており、ログファイル自体はもともと各ファイル内でシーケンシャル書き込みですので、これについては性能上限を緩和させることは難しそうですね。
• メモリ
  • 現時点ではメモリについてはリソースの上限が記載されていませんので、どの程度データキャッシュにメモリが利用できるかは要調査ですね。

 
Public Preview が触れていないので、CPU コア数と、ストレージサイズの動的な変更については、どのようになるかの情報が見つかっていませんが、PaaS 型のサービスですので、柔軟に変更はできるのではないでしょうか。
Create a Managed Instance には、次のような記載がありますので、現状の初期展開についてはかなり時間がかかりそうです。

Important

For the first instance in a subnet, deployment time is typically much longer than in case of the subsequent instances – sometimes more than 24 hours to complete. Do not cancel deployment operation because it lasts longer than you expected. This length of time to deploy your first instance is a temporary situation. Expect a significant reduction of deployment time shortly after the beginning of the public preview.

料金

SQL Database
SQL Database の場合、料金はシンプルな体系となっています。
https://azure.microsoft.com/ja-jp/pricing/details/sql-database/single/
基本的な課金は次のものになります。

• DTU に応じた時間単位の課金
  • 付属ストレージについては、時間単位の基本課金に含まれている

追加課金として発生するものがあるのは次のようなものでしょうか。

• 追加ストレージを利用する場合、GB 単位の追加課金
• 脅威検出機能を利用する場合のノード単位の追加課金
• アクティブ Geo レプリケーションを使用する場合の、オンラインセカンダリの追加課金
• バックアップストレージが追加で使用される場合の追加課金
• 長期保有バックアップを使用する場合の Azure Recovery Service コンテナーの課金
• 監査ログ / 拡張イベントを出力する場合の Azure BLOB ストレージの追加課金

一般的な利用であれば、DTU の料金とログ保存のストレージの領域ぐらいの課金で賄えているのではないでしょうか。
2018/3/11 時点の、東日本の月単位の課金については、次のようになっています。
Standard と Premium を対象と考えると、月額 2,000 円程度 ～ 200 万程度まで、様々な価格帯が用意されているのが特徴的ですね。(Basic ですと、月額620 円程度で利用することも可能です)
Azure ストレージの利用料は大きくならないでしょうから、基本的には上記の額の範囲で収まるのではないでしょうか。
Standard

Premium

Managed Instance
Managed Instance については、通常の利用時でも SQL Database と比較して、様々な構成要素で課金が発生することになります。
https://azure.microsoft.com/ja-jp/pricing/details/sql-database/managed/
現状、Preview 価格ですので、 50% OFF の価格となっているはずですので、一般提供開始後には倍の価格になるかと。
2018/3/11 時点の、東日本の月単位の課金については、次のようになっています。

現状、General Puropose の料金しか公開されていませんが、月額で考えた場合、仮想コア数に応じて、92,000 ～ 275,000 円程度の利用料が発生することになります。
(GA 後は 183,000 ～ 549,000 程度でしょうか)
標準ストレージに 32 GB で足りればよいですが、それでは足りないケースがほとんどでしょうから、1TB 程度のストレージ料金も結果として必要になるのではないでしょうか。

1TB を 1024 GB で計算した場合、「32 GB + 992 GB」(最初の 32 GB は標準課金に含まれる) 発生しますので、プレビュー期間中で、月額 7,700 円程度 (GA 後は 15,400 円程度) のストレージの、追加課金が発生するかと。
下の画像は、SQL Database の超過ストレージの GB 単価になります。
両方ともプレビュー料金なのですが、Managed Instance の方が超過ストレージの単価は安いですね。

ストレージの IOPS については、100 万 IO 単位ですので、一般的なシステムであれば、IOPS の課金はそれほど跳ね上がらない気がしますね。

 
ざっと比較表にしてみると次のようになるのでしょうか。

 
SQL Database の場合は、上記の課金が DB 単位で発生することになりますが、Managed Instance については、一つのインスタンス上に複数の DB を作成することができ、ストレージについてはインスタンス内の共有リソースとなるため、データベースを増やしても、既に割り当てているストレージのサイズ内に収まるのであれば追加の課金は必要ありませんので、「システムとして何データベースが必要となるか」というのも、料金比較をする際に考慮しておきたいポイントですね。
8core + 250 GB のストレージを持つ環境として使用する場合、「\182,712.02 + \1,635.2 = \18,4347.22/月」になりますので、S3 と変わらない金額で複数の DB をホストできる環境を利用することができそうです。
(Managed Instance、もうちょい高いと思っていたので、計算が合っているのか心配になってきますが…。)
SQL Database の場合、Elastic Pool を使用することでコストを抑えることができますので、複数 DB を利用する場合は、Single Database ではなく、Elastic Pool の方と比較を検討する必要もあるかと。
 
Azure Database for MySQL / Azure Database for PostgreSQL の General Purpose と比較すると次のようになります。
MySQL / PostgreSQL の方が、コア数の選択肢が多いですが、Managed Instance と同コア数の料金比較とし、Preview 価格での比較です。

 
基本的な金額については SQL Server の製品のライセンスがあるからかと思いますが、Managed Instance の方が高くなっていますね。
その他の課金の考えについては、同様となっており、プレビュー中は課金なしとなっているものが、Managed Instance の方では明確な金額が公開されているようですね。
 
性能面については実際に評価してみないとわからないところがいくつかありますが、Azure Database for MySQL / PostgreSQL と同様の価格の考えとなっており、SQL DB の S3 クラスと同程度のコストで初期利用ができそうな感じではありますね。

SQL Database Managed Instance の各種情報を集めてみる – その 1 – の続きです。

前回は、SQL Database Managed Instance (MI) の特徴をざっくりとまとめてみました。

従来から提供されている、SQL Database (SQL DB) は「Managed Database」となっています。
SQL Server のインスタンスではなく、各データベースをリソース制御の境界とした、「データベース利用」の PaaS のサービスとなり、各データベースは独立して管理されており、一つの論理サーバー配下に複数のデータベースを作成した場合、独立した環境となっているのが特徴でした。

MI は「Managed Instance」となっています。
SQL Server のインスタンスをリソース制御の境界とした、「インスタンス利用」の PaaS のサービスとなり、インスタンス全体を利用することができるため、一つのインスタンス配下に複数のデータベースを作成した場合、同一の管理境界内に配置され、相互に利用が可能となっていることが特徴でした。
RDS for SQL Server や、Azure Database for MySQL / Azure Database for PostgreSQL に近い管理モデルとなっている形ですね。

MI は、既存の SQL Server からの「Lift & Shift」(既存の環境を変更なくクラウドに移行) を強く意識された環境であるため、SQL DB よりサポートされている機能が多いのも特徴の一つです。
Feature comparison: Azure SQL Database versus SQL Server

それでは、前回はまとめられなかった点についてもまとめていきたいと思います。

Read the rest of this entry »

SQL Database Managed Instance の各種情報を集めてみる ? その 1 ? の続きです。

前回は、SQL Database Managed Instance (MI) の特徴をざっくりとまとめてみました。

従来から提供されている、SQL Database (SQL DB) は「Managed Database」となっています。
SQL Server のインスタンスではなく、各データベースをリソース制御の境界とした、「データベース利用」の PaaS のサービスとなり、各データベースは独立して管理されており、一つの論理サーバー配下に複数のデータベースを作成した場合、独立した環境となっているのが特徴でした。

MI は「Managed Instance」となっています。
SQL Server のインスタンスをリソース制御の境界とした、「インスタンス利用」の PaaS のサービスとなり、インスタンス全体を利用することができるため、一つのインスタンス配下に複数のデータベースを作成した場合、同一の管理境界内に配置され、相互に利用が可能となっていることが特徴でした。
RDS for SQL Server や、Azure Database for MySQL / Azure Database for PostgreSQL に近い管理モデルとなっている形ですね。

MI は、既存の SQL Server からの「Lift & Shift」(既存の環境を変更なくクラウドに移行) を強く意識された環境であるため、SQL DB よりサポートされている機能が多いのも特徴の一つです。
Feature comparison: Azure SQL Database versus SQL Server

それでは、前回はまとめられなかった点についてもまとめていきたいと思います。

Read the rest of this entry »