クラウドのスピードが、どのようにSQL Server DBAの役に立つのか (How cloud speed helps SQL Server DBAs)

Posted: 2017/12/28 カテゴリー: Uncategorized
タグ:, , , , , ,

image


Conor Cunningham (Partner Architect, SQL)

数年前、Microsoft SQL Server製品チームは、SQL Serverコード ベースを共有している新しいクラウドPaaS (Platoform as a Service) である、Azure SQL Databaseを発表しました。クラウド ファースト サービスの稼働は、完全に対応するために数年の投資を費やした、レガシー SQL Serverエンジニアリング モデルの大幅な変更を必要としました。このエンジニアリング モデルの変更によって、Azure SQL Database、SQL Serverの両方に良い影響を与えた大きな利点がありました。

たとえ、あなたが現在、Azure SQL Databaseを使っていないSQL Server DBA (データベース管理者) だとしても、やはりMicrosoftのクラウドへの投資からの利点を確認できるでしょう。このブログ ポストは、クラウドの要求によって主導されたエンジニアリング モデルの変革が、我々がSQL Serverを構築、出荷、サービス提供する方法におけるいくつかの改善をどのようにしてもたらしたかを、概観します。

機能をより早く提供

SQL Serverの初期 (2005-2012) には、SQL Serverは、およそ3年間のエンジニアリング サイクルを持っていました。SQL Serverの計画された各リリースに対して、異なるチーム間で調整されたウォーターフォールに似たソフトウェア開発プロセスを使って、事前の設計としてかなりの量の計画が行われていました。これには、プログラム マネージャーによる機能仕様書、開発者による設計仕様書、テスターが開発する自動テスト コードが含まれていました。

SQL Serverが最終的に出荷されてから、お客様がアップグレードし、関連する新機能を採用するまでに、数年間かかることもありました。このレガシー エンジニアリング モデルと、元々の計画と実際のお客様の採用との間の期間の長さによって、機能が適切に「リリース」され、元々意図されていたシナリオのニーズを満たしていたかどうかを理解するのに、全体として何年もかかっていました。SQL Serverエンジニアリング チームは、議論されるあらゆる新機能について、市場の数年先を考えなければなりませんでした。

PaaS (Platoform as a Service) のAzure SQL Databaseの開発は、SQL Serverエンジニアリング チームの焦点を、大幅に短い時間枠での作業に移しました。SQL Serverエンジニアリング チームは、これを実現させるために、いくつかの主要な変更を行いました。

  • SQL Serverのビルド、テストのループは、並列にテストを実行するために、数千台のマシンを使って自動化されました。テストは、絶えず実行されています。これによって、ビルド/テスト プロセスは、レガシー エンジニアリング モデルでの数週間から、新モデルの平均的な場合での数時間にまで短くなりました。
  • SQL Serverエンジニアリング チームは、元々のSQL Serverコードが非常に巨大なため、モノリシックな状態でデプロイするのが難しいことに気付きました。そのため、チームは、アーキテクチャを可能な限り全面的により小さいマイクロサービスに分解する方法を探しました。このアーキテクチャの変更によって、各コンポーネントごとの別個のデプロイ、サービス提供が可能になりました。

  • より漸進的に機能を構築し、月次のコミュニティ テクニカル プレビュー (CTP) で機能をリリースすることが、求められるようになりました。

この変更によって、リリース サイクルを短くし、かつてないほどに早く、Azure SQL Database、SQL Serverに機能を追加できるようになりました。最近、SQL Serverエンジニアリング チームは、SQL Server 2016リリースのわずか15か月後に、新しいクロス プラットフォーム サポートを備えたSQL Server 2017を何とか出荷しました。これを、過去の3-5年のSQL Server出荷サイクルと対比してください。

機能がより早くテストされ、お客様による検証が必要

Microsoftは、SQL Server 2017のGA (一般提供) につながる、新機能のテストへの早期で継続的なアクセスをパブリックに提供する、月次のコミュニティ テクニカル プレビュー (CTP) を提供しました。製品品質のビルドを提供できる能力は、現在、Azure SQL Databaseで使われている継続的リリース プロセスによって大いに主導されました。また、この新機能への早期アクセスは、お客様からの早期のフィードバックをもたらし、SQL Serverエンジニアリング チームが、即座にこのフィードバックを使いました。SQL Serverエンジニアリング チームは、機能の完成を宣言する前に機能が正しく動作しているかどうかを評価するために、エンジニアリング サイクル中のお客様による機能のテストを必要としています。

準備ができた時に、機能を出荷

SQL Serverの以前のバージョンでは、いくつかの改善が、出荷前にSQL Serverリリースに「押し込まれる」危険がありました。これは、出荷ウィンドウを逃すと、次の3年間、その機能が製品に含まれなくなる可能性があるからでした。SQL Serverエンジニアリング チームが製品品質のリリースを頻繁に出荷できる能力を備えるようになったので、これはもはや問題(または誘惑)ではありません。機能の準備ができていない場合は、問題が解決されるまで機能のリリースを控え、それから、後の月次リリースにその機能を含めます。

機能開発は反復型

計画は依然としてエンジニアリング プロセスの重要な部分ですが、SQL Serverエンジニアリング チームは、少し違ったやり方でそれを行うようになりました。新機能のアイデアに対して、チームのアーキテクト、プログラム マネージャー、エンジニアリング マネージャーが問題領域を検討し、妥当な時間枠内で出荷可能な基本的な解決策を探索します。提案されるあらゆる機能には、取り組みとエンジニアリングの財源を正当化するのを助けるために、関連する主要なお客様がいなければなりません。それから、SQL Serverエンジニアリング チームは、お客様のニーズを反復し、機能が完成して出荷の準備ができるまで、機能のバージョンをリリースします。

この一例が、プランのリグレッションを識別し、以前の正常なプランを適用することでリグレッションを修正する、SQL Server 2017の新しい自動チューニング機能である自動プラン修正機能です。この機能は、まずAzure SQL Databaseにデプロイされ、社内ユーザー、オプトインしたプライベート プレビューのお客様による大量の現実世界のテストが行われました。これは、大量のフィードバックをもたらし、この機能がSQL Server 2017で現在の形式で最終的に出荷される前に、いくつかの変更が行われました。

MVP (Minimum Viable Product、実用最小限の製品) の早期バージョンに対するフィードバックは、構築されたものを改良 (またはリセット) するために使われます。お客様からのフィードバックは、エンジニアリング サイクルの間中ずっと使われ、新機能や既存機能への変更を正当化するために使われます。我々は、よりアジャイルになったことで、斬新的な価値を提供する大小さまざまな機能をリリースできるようになり、「マーケティング」のための機能に集中するだけではありません。

スムーズなアップグレード

Azure SQL Databaseは、継続的にアップグレードされています。修正は時間とともにブランチにわたって適用され、このアップグレードにはバグ修正と新しい改善を含めることができます。この継続的な変更によって、自動アップグレードをできる限りシームレスでスムーズなものにする、という要求がありました。結果として、SQL Serverエンジニアリング チームは、ほとんどの機能を非推奨にして削除することをやめ、代わりに、シームレスで静かなアップグレードを可能にするために、後方互換性を維持するポリシーに移行しました。この非推奨ポリシーは、SQL Server、Azure SQL Databaseの両方に適用されます。

SQL Serverエンジニアリング チームは、強い目標として後方互換性を維持しようとしているので、サービスは透過的にアップグレードできます。(サービスのセキュリティを維持するために変更が必要となる、など) 互換性が破壊される場合は、エンジニアリングは影響を受けるお客様に事前に連絡し、お客様とともに回避策を探すか、または、お客様が自分のアプリケーションを十分にテストし、準備ができたときに新しいコードにオプトインするために、互換性レベルを使います。

互換性レベルについては、クエリ実行プランに影響を与えるあらゆる新機能や修正は、次のデータベース互換性レベルで現れます。その意図は、リグレッションの危険性を最小化することです。たとえば、SQL Server 2017で導入された新しいアダプティブ クエリ処理機能ファミリーは、140以上の互換性レベルを必要とします。SQL Server 2017へのアップグレードでは、明示的に既存のユーザー データベースの互換性レベルを変更するまで、互換性レベルは維持されます。(たとえば、SQLグラフなど) エンジン機能がプランに影響を与えない場合は、我々はその機能を互換性レベルに結びつけません。その機能は、明示的に有効化される必要なしに、利用可能な機能として自動的に現れます。

加えて、自動プラン修正クエリ ストアといった機能が、アップグレード後の逆転防止装置、保険証券として機能でき、リグレッションに対処する迅速で効率的な方法を可能にします。

テレメトリが品質を改善

SQL Serverエンジニアリング チームは、次の目的のためにテレメトリを利用しています。

  1. 今後の改善のためのシナリオ候補を識別する
  2. 機能の採用状況を評価する
  3. より迅速に問題を表面化させることで、製品品質を改善する

すべてのテレメトリ データは、お客様のデータを保護するために一般化、修正され、それから、大規模にサービスを管理するために、このテレメトリが使われます。数百万のデータベースが稼働しており。運用スタッフやDBAが1人もいないAzure SQL Databaseでは、1日あたり約600 TBのテレメトリがAzure SQL Databaseから収集されており、SQL Serverエンジニアリング チームが自動アラート/SLAインフラストラクチャを稼働させるのを助けています。

加えて、SQL Serverエンジニアリング チームは、Azure SQL Databaseで実行されている数百万のデータベースからのすべてのクラッシュ ダンプを監視、調査しています。

Azure SQL Databaseのサービス提供からの学びは、次のような形でSQL Serverの品質に現れています。

  • SQL Serverエンジニアリング チームは、積極的に修正し、Azure SQL Database、SQL Serverの販売中バージョン、SQL Serverの今後の開発中バージョンに、その修正をデプロイします。
  • 修正は、過去よりもずっと積極的に、SQL Serverの累積的な更新プログラム (Cumulative Update、CU) に追加されます。

  • このエンジニアリング モデルへの投資のため、SQL Serverエンジニアリング チームは、SQL Server 2016以降では、最新のCUを適用することを推奨しています。お客様は、過去であれば修正プログラム (hotfix) としてリクエストする (それから、エンジニアリング チームが急いで修正するのを待つ) 必要があった修正を、入手できるようになりました。積極的に、サポート チケットを作成することなしに、こういった修正が行われるようになりました。

    SQL Server DBAの観点から見ると、最新CUに遅れずについていくことは、既知の問題が発生することの回避に役立ち、また、SQL Server環境のパフォーマンス、可用性、全体的な正常性にも役立ちます。

    SP1の必要性を不要に

    Azure SQL Databaseでは、数百万のデータベースにわたって漸進的にコード変更を行うことで、ほとんどの機能とバグ修正を最初に適用されます。また、SQL Serverエンジニアリング チームは、より高速かつ頻繁にテストを実行するために、多数の並列マシンを活用しています。その結果、リグレッションやバグは、エンジニアリング サイクル内でずっと早く捕捉、修正されます。こういった修正は、今後の累積的な更新プログラム (CU) を介して、SQL Serverに展開されます。

    徹底的なテストとリリースの準備ができているビルドが、現代的なサービス モデル (Modern Servicing Model) のブログ ポストで説明されている変更の発表につながりました。SQL Server 2017から、ローカライズされた累積的な更新プログラム (CU) が、修正の主要な配信方法になります。CUは、SQL Server 2017のリリース後、最初の12か月の間は毎月配信され、それから、5年間のメインストリーム サポート サイクルのうちの残りの4年間は、毎四半期に配信されます。累積的な更新プログラム (CU) はリリースの準備ができており、過去のサービス パック リリースと同様に十分テストされているので、SQL Server 2017から、年次のサービス パックはもはや発行されません。SQL Server 2017にアップグレードするために、SP1まで待つ必要はありません!

    2つの世界、1つのエンジニアリング モデル

    Azure SQL Databaseを稼働させることが、SQL Serverのエンジニアリング モデルを大幅に変革しており、その進化は続いています。ビルド/出荷プロセスは合理化、改善され続けているので、我々の目標は、Azure SQL Database、SQL Server両方のお客様に継続的な価値と革新を提供することです。クラウドの変革がSQL Serverを強化しているので、我々は、SQL Serverが、皆さんの次のオンプレミス データ層とアプリケーションを構築するのに最適な場所だと信じています。

    Microsoftのエンジニアリング モデルやここで説明した改善に関する共有すべきフィードバックがある場合は、我々は話を聞きたいと思っています。フィードバックや本件のコメントに関して、SQL Serverエンジニアリング チームに連絡するには、SQLDBArchitects@microsoft.com に電子メールを送ってください。

    広告

    コメントを残す

    以下に詳細を記入するか、アイコンをクリックしてログインしてください。

    WordPress.com ロゴ

    WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

    Twitter 画像

    Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

    Facebook の写真

    Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

    Google+ フォト

    Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

    %s と連携中