SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Ignite 2018 で発表された SQL Database の Hyperscale サービス層の情報

leave a comment

Ignite 2018 で SQL Database の新しいサービス層である Hyperscale が発表されました。
2018/10/1 の Public Preview の開始前にいろいろと情報が公開されていますので、メモとして。

Hyperscale は SQL Database を VLDB (現状は 100 TB 想定で、1TB のチャンクで最大 100TB まで自動インク連とされる構成だが、実質的にはそれ以上に対応できる) に対応させ、コンピューティングレイヤーとストレージレイヤーを完全に分離させたことにより、瞬時に柔軟にスケールさせることができる新しいアーキテクチャとなっています。

ストレージレイヤーが独立していることで、コンピューティングレイヤーを持たない、Geo レプリカの展開も可能となり、コンピューティングデプロイされない分、コストを抑えて遠隔地にデータを退避させることができるようです。
(ゾーン冗長ストレージ (ZRS) もサポートされているようです)

上記のような構成がとられており、コンピューティングにはデータを持たない構成のため、読み取りセカンダリのデプロイについても、プライマリに負荷をかけることなく、高速にセカンダリをデプロイすることも可能となっています。

SQL Server のエンジン実行されるコンピューティングレイヤーについては、ステートレスでありこの部分には、永続データは保持せず、永続データはストレージまたはログサービスに保持することになり、コンピューティングレイヤーはデータのキャッシュ層となるようです。
SQL Server 2016 で実装された、Buffer Pool Extension というメモリに保持しきれないデータを、単純にキャッシュアウトするのではなく、ローカルの SSD ストレージにキャッシュアウトさせるテクノロジーを最新にした、回復力のある Buffer Pool Extension が採用されているようです。
メモリに保持しきれないデータのアクセスについても高速に実施ができるようなアーキテクチャがコンピュートとページサーバーのノードで使用されており、永続データとして格納されているストレージ層へのアクセスを極力なくすようなアーキテクチャが採用されています。

ストレージレイヤーについては、「ページサーバーノード」「ログサービスノード」「Azure Storage ノード」の 3 層で構成されています。

  • ページサーバーノード
    • 各ページサーバーには 1TB のデータをキャッシュできるようになっており、データページをコンピュートノードに提供する
      • ストレージが 1TB でチャンクしているということなので、1TB 分割されたデータファイルの内容を 1 台のページサーバーですべてキャッシュできるような対応となっているのでしょうね。
        • 従来の 1 データファイルが、1 ページサーバーのような考えなのかなと。
        • ページサーバーも冗長化されており、耐障害性と回復性が確保されているようです。
      • コンピュートノードに存在しないデータページについては、ページサーバーから取得を行う
    • ログサービスと連携して、トランザクションログのレコードを再生し、データの最新化を行う
    • データベースファイルをマウントしているわけではないので、セカンダリもプライマリと同一のページサーバーノードを共有するのではないでしょうか (たぶん)
  • ログサービスノード
    • トランザクションログの役割を担うノード
    • 変更のログレコードは高速な Azure Premium Storage に連携される。
    • データの変更をページサーバーノードに反映し、他のセカンダリノードのキャッシュのデータにも反映させることで、データの最新化を行う
    • ログレコードの最終到達点として、Standard Storage に永続化データとして保存を行う
  • Azure Storage ノード
    • データページの最終到達点として、Standard Storage に永続化データとして保存を行う
    • バックアップをデータファイルのスナップショットにより取得を行う

永続化するデータについては、Standard Storage に最終的に連携を行い、コンピューティングレイヤーとの連携については、高速な領域を使用するという構成を思い浮かべるとよさそうです。

バックアップについてはストレージレイヤーのスナップショットによって実施され、高速に取得が可能であり、バックアップの実行時のハードウェアリソースの消費を抑えることができるため、クエリ実行に影響を与えることなく取得が可能となっています。
リストアについてもデモでは、50TB の DB のリストアが秒単位で実施できていました。

基本性能については、デモで、現状の DTU モデルの最高レベルである P15 との比較が実施されていましたが、Hyperscale の方が短時間で処理を完了させることができており、ストレージのスケーラビリティだけでなく、性能面でも高い値を示していました。

コンポーネントが分かれていた SQL Server というと、SQL Datawarehouse を思い浮かべるかもしれませんが、Hyperscale は SQL Database の用途をスケール可能としたものですので、今後も用途によって SQL DB と SQL DW を使い分けることは変わらないかと。

DMV で様々な構成が見れるのではと思いますので、実際に使えるようになったら、情報を見ながら構成を改めて確認してみたいと思います。

 

アナウンス

ドキュメント

  • What is the Hyperscale service tier (preview) in Azure SQL Database?
    • Hyperscale サービス層の基本情報が記載されたドキュメントとなります。
  • Azure SQL Database vCore-based purchasing model limits for a single database
    • リソース上限の情報に Hyperscale が追加されています。
    • vCore モデルがベースとなっているため、CPU コアやメモリサイズについては情報が公開されていますね。
      • ディスク IO については後日の確定となるようで、具体的な値は現時点では記載されていません。
      • Ignite のデモで表示されていたポータルでは、次のような記載がありました。
        データ部分の性能については、ビジネスクリティカルの Gen 5 : 80 コア相当なのかもしれないですね
        • データ : 200,000 IOPS : 1,2 ms のレイテンシー
        • ログ : 7,000 IOPS : 5,10 ms のレイテンシー
          • トランザクションのコミット待ちは、初期のプレビューで数ミリ秒、最終的にはサブミリ秒となるそうです。
          • 現状サポートされているログ生成のスループットは約 100MB/sec とのこと。
  • Scale database resources
    • vCore モデルの汎用目的 / ビジネスクリティカルの他に Hyperscale が追加されることが記載されました。
    • 汎用目的 / ビジネスクリティカルから Hyperscale に変更することはできないとのことなので、既存環境の移行については考慮する必要があるかと。
      • Ignite の資料では Hyperscale に移動はポータルのスライダーを移動するのと同じくらいにシンプルということが記載されており、マイグレーションも高速にできるような記載があったので、この辺は今後も情報を精査する必要がありそうですが。
      • Hyperscale から、非 Hyperscale への変更はサポートされていないようでもありますので、この辺はきちんと把握しておく必要があるかと。

Ignite 2018 のセッション

Written by masayuki.ozawa

9月 30th, 2018 at 2:57 pm

Posted in SQL Database

Tagged with ,

Leave a Reply

*