クラウド データベース サービスの世界で、お客様にとってデータへの継続的なアクセスよりも重要なことはそうないと言えるでしょう。オンライン ゲームや金融サービスといったトランザクション レートの高い業界では、ほんのわずかな中断でさえエンド ユーザーの体験に影響を及ぼす可能性があるほどです。Azure SQL Database はいつでも最新の状態なので、常に最新バージョンの SQL エンジンを備えていますが、この最新状態の維持にはサービスの更新が定期的に必要になることから、データベースが一瞬オフラインになることがあります。そのため、マイクロソフトのエンジニアリング チームは、ワークロードの中断を減らす革新的なテクノロジの向上に絶えず取り組んでいます。

この記事では、Visual C++ Compiler チームと連携して、当社がワークロードに一切影響を及ぼさずに SQL Server エンジンにパッチを適用する方法について説明します。

図 1 - ホット パッチの隠れたしくみ。もう少し詳しくお知りになりたい場合は、こちらの技術的なブログ記事 (英語) をご覧ください。

課題

マイクロソフトが Azure SQL Database で実行している SQL エンジンは、お客様が独自のサーバーで実行されているものと同じエンジンの最新バージョンですが、前者の違いはマイクロソフトがその管理と更新を行うという点です。当社では、SQL Server または基盤のインフラストラクチャ (Azure Service Fabric やオペレーティング システム) を更新する際に、SQL Server のプロセスを停止する必要があります。そのプロセスでプライマリ データベース レプリカをホストしている場合、レプリカを別のマシンに移動させるため、フェールオーバーが必要になります。

フェールオーバー時には、データベースが一瞬オフラインになる可能性がありますが、それでも当社の 99.995% の SLA は保証されます。ただし、プライマリ レプリカのフェールオーバーによって実行中のクエリやトランザクションが中止されることから、ワークロードに影響が及びます。当社ではそうした状況に対処するため、再開可能なインデックスの (再) 構築や高速データベース復旧といった機能を用意しましたが、実行中のすべての処理が自動的に再開されるわけではありません。アップグレードによって中止された複雑なクエリやトランザクションをやり直すにはコストがかかることがあるからです。そのため、フェールオーバーは即座に実行できるとはいえ、当社では避けたいと考えています。

エンジニアリング チームは、SQL Server だけでなく Azure プラットフォーム全体に対して、プラットフォームの可用性と信頼性の向上に向けて並々ならぬ努力を傾注しています。たとえば SQL Database では、データベースごとに複数のレプリカを用意し、アップグレード時には、直ちに引き継げるようにホット スタンバイを利用できるようにしています。

我々は Azure や Service Fabric を担当する幅広いチームと緊密に連携を取りながら、フェールオーバーの数を最小限に抑えるべく取り組んできました。まずアップグレードのためにデータベースのフェールオーバーを行うことを決定したら、スタック内のすべてのコンポーネント (OS、Service Fabric、および SQL Server) に対して同時に更新プログラムを適用します。 各 Azure リージョンの主な営業時間にかち合わないように、自動スケジューリングを採用しています。フェールオーバーの直前には、アクティブなトランザクションをなくして、途中で中止せずに済むようにします。さらに、データベース ワークロードのパターンを活かして、ワークロードにとって最適なタイミングでフェールオーバーが行われるようにもしています。

これらすべてをもってしても、SQL エンジンを最新バージョンに更新する際には、プロセスをやり直して、データベースのプライマリ レプリカのフェールオーバーを少なくとも 1 回は行う必要があるという事実は避けられません。それとも、避ける方法はあるのでしょうか。

ホット パッチとその効果

ホット パッチ (英語) とは、実行中のプロセスでメモリ内のコードを変更するもので、プロセスをやり直す必要がありません。当社の場合、ホット パッチを採用することで、sqlservr.exe をやり直さずに SQL エンジン内の C++ コードを変更できるようになりました。やり直すことがないので、プライマリ レプリカのフェールオーバーを行うことによってワークロードを中断させずに済みます。パッチの適用時に SQL Server の動作を一時停止する必要さえありません。ホット パッチは、もちろんパッチのペイロード以外にユーザーのワークロードでも気付かれることはありません。

ホットパッチは従来のやり直しを伴うアップグレードに代わるものではなく、それらを補完するものです。現在のところホットパッチには制約があるため、重要な新機能が導入される場合など、多数の変更が行われる場合には適していませんが、対象を絞った小規模な変更には最適です。一般的な SQL のバグ修正の 80% 以上がホット パッチ可能です。ホット パッチには以下のようなメリットがあります。

• ワークロードの中断の減少 - やり直す必要がないので、データベースのフェールオーバーを行わずに済み、ワークロードに影響が及ぶことがなくなります。
• バグ修正の迅速化 - 当社では以前、バグ修正の実施によるお客様のワークロードへの影響よりも、バグ修正の緊急性に重きを置いていましたが、ワークロードへの影響を考えると、世界規模でロールアウトするほどバグ修正が重要でないように思われることもありました。ホット パッチを採用することで、今では即座に世界規模でバグ修正を実施できるようになりました。
• 機能提供までの期間の短縮 - 新機能を開発するたびに 50 万回を超える機能テストを 1 日に何度も実施し、徹底した検査を行っていても、お客様への新機能の提供を開始した後で問題を発見することがあります。そのような場合には、その機能を無効化したり、次回予定のフル アップグレードまで提供開始を遅らせたりしなければならないこともあります。しかしホット パッチなら、問題を修正して、その機能の提供を早めることができます。

当社が初めて実稼働環境でホット パッチを実施したのは 2018 年のことですが、それ以来、毎月何百万もの SQL Server にホット パッチを行ってきました。ホット パッチによって、SQL Database の出荷速度が 50% アップすると同時に、可用性が向上しています。

ホット パッチのしくみ

技術的な内容をお知りになりたい場合は、こちらの技術的なブログ記事 (英語) でホット パッチの隠れたしくみについて詳しい説明をご確認いただけます。セクション 3 からお読みください。

まとめと次のステップ

この機能を採用したことで、当社は現在、短い所要時間でより多くの変更をホット パッチできるようにするためにツールの向上と制約の解消に取り組んでいます。現在のところホット パッチは Azure SQL Database でしか利用できませんが、今後 SQL Server でも利用できるようになるかもしれません。このことについてご関心をお持ちのお客様は、SQLDBArchitects@microsoft.com からご連絡ください。

当社が取り組んでいる素晴らしいテクノロジについてより詳しい情報をお探しの場合は、以下にコメントやご質問をお寄せいただくか、上記の電子メールでお問い合わせください。