sql >> データベース >  >> RDS >> Sqlserver

Azure SQLデータベースのDTUとは何か、必要な量を把握する方法

    Microsoft Azureは、AzureSQLデータベースプラットフォームを介してPlatformasa Service(PaaS)データベースエンジンを提供しているため、このデータベースをクラウドベースのアプリケーションに使用できます。 Azure SQL Databaseの主な利点は、ダウンタイムなしで簡単にスケーリングできることであり、バージョンのアップグレードやパッチ適用プロセスを必要としません。また、ハードウェアの問題について心配する必要はありません。

    ただし、Azure SQLデータベースの重要な考慮事項は、最小コストに対してデプロイされたデータベースのパフォーマンス要件を満たすことです。間違いなく、使用していない、または使用する予定のない冗長なリソースや機能にお金を払いたくない人はいないでしょう。

    この時点で、Microsoft Azureは、コスト効率を高めるために2つの異なる購入モデルを提供しています。

    • データベーストランザクションユニット(DTU)ベースの購入モデル。
    • 仮想コア(vCore)ベースの購入モデル

    購入モデルの決定は、データベースのパフォーマンスと請求額の合計に直接影響します。私の考えでは、デプロイされたデータベースがあまり多くのリソースを消費しない場合は、DTUベースの購入モデルの方が適しています。

    次に、これら2つの購入モデルの詳細について次のセクションで説明します。

    データベーストランザクションユニット(DTU)ベースの購入モデル

    DTUベースの購入モデルをより明確に理解するには、AzureSQLDatabaseでDTUが意味をなすものを明確にする必要があります。 DTUは、「データベーストランザクションユニット」の略語であり、AzureSQLデータベースのパフォーマンスユニットメトリックを表します。データベースのパフォーマンスに直接影響するため、DTUを車の馬力に合わせることができます。 DTUは、AzureSQLデータベースの単一のパフォーマンスユニットとして次のパフォーマンスメトリックの混合を表します。

    • CPU
    • メモリ
    • データI/OとログI/O

    DTUの概念の主なアイデアは、事前構成されたリソース構成をクライアントに提供して、単一のメトリックでのパフォーマンスのスケーリングを簡素化することです。たとえば、パフォーマンスを向上させる必要がある場合は、バーをスライドさせて、AzureSQLデータベースのDTUの数を増やすことができます。

    DTUベースの購入モデルには3つの異なるサービス層が含まれており、これらのサービス層は異なるDTUと機能オプションを提供します。次の表は、DTUベースの購入モデルに参加したサービス層を示しています。

    基本

    標準

    プレミアム

    ターゲットワークロード

    開発と生産

    開発と生産

    開発と生産

    稼働時間SLA

    99.99%

    99.99%

    99.99%

    最大のバックアップ保持

    7日

    35日

    35日

    CPU

    低、中、高

    中、高

    IOスループット(概算)

    DTUあたり1〜5 IOPS

    DTUあたり1〜5 IOPS

    DTUあたり25IOPS

    IOレイテンシ(概算)

    5ミリ秒(読み取り)、10ミリ秒(書き込み)

    5ミリ秒(読み取り)、10ミリ秒(書き込み)

    2ミリ秒(読み取り/書き込み)

    列ストアのインデックス作成

    該当なし

    S3以降

    サポートされています

    インメモリOLTP

    該当なし

    該当なし

    サポートされています

    最大DTU

    5

    3000(S12)

    4000(P15)

    最大ストレージサイズ

    2 GB

    250 GB

    1 TB

    ご覧のとおり、最大DTUと機能はサービス層によって異なります。また、サービス階層に関連して料金モデルが変更されます。たとえば、DTUベースの購入モデルの単一データベースの次の構成は月額$584.00になります。

    弾性プール

    簡単に言うと、Elastic Poolは、共有リソースプールに対する予測不可能で変化するリソース要求を持つ複数のデータベースを自動的に管理およびスケーリングするのに役立ちます。 Elastic Poolを通じて、リソース需要の変動に対してデータベースを継続的に拡張する必要はありません。プールに参加するデータベースは、必要なときにElastic Poolリソースを消費しますが、Elastic Poolリソースの制限を超えることはできないため、費用対効果の高いソリューションを提供します。

    AzureSQLデータベースのDTUの適切な見積もり

    DTUベースの購入モデルを使用することを決定した後、論理的な理由で次の質問と回答を見つける必要があります。

    • Azure SQLに移行するときに、ワークロードに必要なサービス層とDTUの量はどれですか?

    DTU Calculatorは、オンプレミスデータベースをAzureSQLDatabaseに移行するときにDTU要件を見積もるための主要なソリューションになります。このツールの主なアイデアは、DTUに影響を与える既存のSQL Serverからさまざまなメトリック使用率をキャプチャし、収集されたパフォーマンス使用率に照らしておおよそのDTUとサービス層を推定しようとすることです。 DTU計算機は、コマンドラインユーティリティまたはPowerShellスクリプトを介して次のメトリックを収集し、これらのメトリックをCSVファイルに保存します。

    • プロセッサ-%プロセッサ時間
    • 論理ディスク-ディスク読み取り/秒
    • 論理ディスク-ディスク書き込み/秒
    • データベース-フラッシュされたログバイト/秒

    この記事では、このオープンソースプロジェクトとコードがGitHubでホストされているため、コマンドラインユーティリティの使用法について学習します。したがって、必要に応じて簡単に変更を加えることができます。コマンドラインユーティリティをダウンロードして解凍した後 2つのファイルが目の前に表示されます。

    SqlDtuPerfmon.exe.configは、コマンドラインユーティリティのいくつかのパラメータを決定するのに役立ちます:

    CsvPathは、収集されたメトリックが保存されるCSVファイルパスを指定します。

    SampleIntervalは、サンプルが収集される秒間隔を指定します

    MaxSamplesは、収集されるサンプルの最大数を指定します。

    この時点で、DTUCalculatorに関するいくつかの考慮事項を考慮する必要があります。 DTU Calculatorは、コンピューター上のメトリックの合計使用率を収集します。このため、CPU、メモリ、およびディスクの消費に影響を与える他のプロセスを停止する必要があります。そうしないと、正確なDTUの見積もりを行うことが困難になります。もう1つの問題は、可能な限り、ワークロードのピーク時間間隔をカバーするメトリックの使用率を収集する必要があることです。このようにして、DTU Calculatorは最良の推奨事項を提供し、より概算の見積もりで最大DTU要件を見つけます。次に、SqlDtuPerfmon.exeを実行すると、リソース使用率の収集が直接開始され、指定されたCSVファイルが保存されます。

    リソース使用率の収集が完了したら、コアの数を入力し、CSVファイルをDTUCalculatorWebサイトにアップロードします。

    [計算]ボタンをクリックすると、最初にサービス層/パフォーマンスレベルの円グラフが画面に表示され、推定されたサービス層の提案がパーセンテージの詳細とともにスライスに分割されて表示されます。 DTU Calculatorによると、Standard-S6層は、このワークロードに満足のいくパフォーマンスを提供します。

    このチャートのすぐ下に、DTUの経時変化チャートが表示され、このチャートは、期間に対して変化するDTUを表します。このグラフを評価する前に、より簡単に解釈できるように、いくつかの情報を追加することができます。

    ご覧のとおり、折れ線グラフは不安定なワークロードを表していますが、情報メモを追加した方が理にかなっています。私の考えでは、このチャートは、ワークロードの変更とDTUの間の相互作用を理解するのに非常に役立ちます。したがって、必要なDTUをより適切に見積もることができます。記事の冒頭で述べたように、私たちの主な目標は、ワークロードの費用対効果の高いソリューションを見つけることです。

    ただし、これらの提案は、AzureSQLのDTUの正確な要件を表すものではありません。このため、データベースをAzure SQLに展開した後、サービス層または購入モデルを変更する必要がある場合があります。

    [詳細を表示]をクリックすると、いくつかの追加のレポートが表示されます。これらのレポートは、CPU、IOPS、およびログリソースの使用率に関する個々の推奨事項を表しています。特にこれらの使用法を理解するのに非常に役立ちます。

    仮想コア(vCore)ベースの購入モデル

    この概念は、データベースの各リソースを決定できるため、従来のアプローチに似ています。このモデルでは、VCoreと最大データサイズのオプションを手動で調整できます。ただし、メモリリソースを特定することはできません。各VCoreには専用メモリが付属しており、メモリの専用値はVCoreの世代によって異なります。

    最後に、このモデルでは、次のサービス層を選択できます。

    • 汎用。
    • ビジネスクリティカル。
    • ハイパースケール

    結論

    この記事では、Azure SQLデータベースの購入モデルについて説明し、オンプレミスデータベースに必要なAzure SQLのDTUを見積もるために、DTUCalculatorの使用方法を説明しました。


    1. EM12cデータベースの待機アラートの使用時間

    2. codeigniterアクティブレコードにクエリを挿入した後に最後の挿入IDを取得する方法

    3. MySQLデータベースのパフォーマンスを提供するためのヒント-パート1-

    4. PostgreSQLのDROPTABLEIFEXISTSの例