私たちの行く先にダウンタイムは必要ない

計画的ダウンタイムは、すべてのIT担当者にとって悩みの種です。ほとんどの組織では、ダウンタイムにより、CxO以下、変更を導入するプロセスにおいてお役所仕事的対応を超えた状況が発生しています。このプロセスにより、米国議会でのほとんどの日は、問題なく過ぎていくように見えます。

ダウンタイムの問題の多くは、変更や更新自体に基づくものではなく、24時間365日稼働するビジネスへの影響を制限することです。ヘルスケアはその完璧な例です。私たちは人為的ミスを避けているのではなく、不便さをなくそうとしているのです。

システムのメンテナンスのコストは莫大です。私たちはシステムの運用とセキュリティを維持するためにダウンタイムが必要という困難な状況に陥っていますが、ダウンタイム発生させることはビジネスにおいて好ましくありません。「ゼロダウンタイム」のアイデアを実現するために、組織はホットスタンバイシステムを実装し、システムがオフラインにならないようにハードウェアとサポートインフラストラクチャに2倍の取り組みを実施します。この対策を行う余裕のない組織にとっては、生産性の損失としてダウンタイムを受け入れるしかありません。

クラウドが多くの組織にとって合理的であるのはこのためです。適切に構築されたクラウドは、通常、常時稼働し、常に高い信頼性があり、ほとんどの組織にとって実装可能な保証手段となっています。コスト削減目的だけでも、クラウドは多くのソリューションの実行可能な代替手段になります。

Extremeでは、例えば大規模なマルチテナント環境で100万台のデバイスを管理している場合、ダウンタイムは到底許容されないものであることを認識しています。このため、ここ数カ月間で、当社では第4世代のクラウド技術の開発と導入に加えて、メンテナンスのダウンタイムを無くすための目覚ましい進歩を遂げました。

ExtremeCloud IQのQ1r3リリースに始まり、アプリケーションをオフラインにすることなく、本番環境を更新する新しい方法を実装しました！これを実現するために、アーキテクチャ内および開発分野内でいくつかの作業を実施することになりました。このことについてこれから説明させてください。

ExtremeCloud IQは100%アジャイルの開発プロジェクトです。私たちはアジャイルスプリントでコード化し、時間の経過とともに製品に多くの漸進的な更新を加えます。このような更新にはデータベーススキーマの変更が必要な場合があり、以前はそうしたスキーマ更新が定期メンテナンスの原因となっていました。クラウドのスピードで変更を行っている場合、上記の変更により、スケジュールに基づいて不要なシステムの中断まで発生する可能性があります。

ゼロダウンタイムの設計

ExtremeCloud IQでは、2種類の主要DBMSシステムを利用しています。 私たちは、使用するすべての構造化データについて、多くのユーザーの皆様が精通している、実績のあるSQLベースのソリューションを利用しています。この構造化データは、認証情報、構成オブジェクト、または管理対象デバイスのインベントリリストなどの要素で構成されています。私たちが処理する他のほとんどのデータは、監視統計、イベント、アラーム、AI（人工知能）/ML（機械学習）などの非構造化データのカテゴリに分類されます。この非構造化データはすべて、Elasticsearchを使用して保存されます。

Elasticsearchはインデックス内にデータを格納し、それらのインデックスをいつでも新しいフィールドで拡張できるという点で優れています。アプリケーションは、何か削除しない限り、Elasticsearchインデックスへの操作を気にしません。

SQLデータベーススキーマは、運用に細心の注意が必要です。アプリケーションとアプリケーションが行うクエリがデータベーススキーマ内の違いを正しく処理できる場合を除いて、データベーススキーマの変更は適切なイベントではありません。7つのフィールドが返されることを期待してクエリを1つ作成したが、10のフフィールドが返された、またはフィールドが「X」の長さであることが期待されますが、実際は「Y」の長さになったと想像してみましょう。これらの変更により、標準のアプリケーションでかなりの混乱が生じる可能性があるため、以前はデータベースの更新を適用する前にアプリケーションをシャットダウンしていました。このプロセスは熟知され、プロセス自体は大幅に自動化されていますが、それでも完了するまでに30分かかりました。これでは、お客様が30分間不便を感じることになります。

第4世代クラウドの登場により、やり方を少し変えてみることにした

手始めに、ISO 27001認証に従い、開発者がスキーマの提案された変更を文書化することを要求する数百ページの運用ドキュメントとプロセスを蓄積しました。特定のリリーススプリントに対して提案されたスキーマの変更は、Cloud Operations Distinguished Engineerを含む数人の担当者によって吟味されます。明示的な審査と承認がなければ、データベースの変更は行われません。

次に、ExtremeCloud IQを前方互換性と後方互換性を持つように設計しました。これは実際にはかなりの偉業です。データベース接続と対話するアプリケーションのすべてのコード行は、それが新しいスキーマとインターフェース接続し、それを適切に処理する必要があることを予期する必要があります。また、アップグレードプロセス中にレガシーアプリケーションが引き続き機能できるように、関連するデータベースには後方互換性が必要です。これは、ゼロダウンタイムの更新という状況を作成するために一緒に来るコード、条件付き処理、および操作プロセスのバレエのようなものです。

ゼロダウンタイムの更新の実現方法

下の図では、左側からExtremeCloud IQアプリケーションとサポートデータベースが正常に動作しています。最初のステップでは、私たちのクラウド運用チームが完全に吟味、承認されたDBスキーマの更新をアクティブなデータベースに適用し、「N+1」のDBバージョンを作成します。その間、アプリケーションに組み込んだ前方互換性を利用して、古いバージョンのExtremeCloud IQは新しいデータベーススキーマを使用して実行を続けます。  新しい「N+1」DBスキーマの後方互換性により、レガシーアプリケーション形式からの新しいトランザクションを受け入れて処理できます。

次に、ExtremeCloud IQアプリケーション自体に更新を適用します。第4世代のクラウドでは、この更新には、Kubernetesインフラストラクチャを介して調整される新しいコンテナの起動と交換が含まれます。これは正常に行われ、稼働中のKubernetesポッドの一部が置き換えられ、アップグレードされたインスタンスへのアクティブな接続が失敗します。次に、残りのポッドをアップグレードして、新しいサポートDBスキーマに接続されるアプリケーションバージョン「N+1」を作成します。

最後に、DBクリーンアップとハウスキーピングルーチンを適用して、アプリケーションとデータベースの両方に新しい標準を設定します。

ExtremeCloud IQと同じくらい大規模で複雑なアプリケーションでは、動作する部分がたくさんあり、先ほど説明したこのプロセスは非常に単純化されています。ただし、これらの部分がうまく調整された方法で動作する場合、ゼロダウンタイムのアップグレードを実現できます。最近リリースされたQ1r3リリース（2020年4月13日の週にリリース）から始まり、この方法論を使用して最初の製品の導入を達成しました。

クラウド運用の友好的なスタッフが提供する、ダウンタイムのない未来はすぐそこです。第5世代のクラウドがどのようなものか想像してみませんか？  #cloudspeed #extremecloudiq