効果が出るまでの時間
このブログは、「多数の Kubernetes クラスターを操作するのに適したコントロール プレーンとは」の続編です。 前回のブログでは、インフラストラクチャ サイトとapplicationsのフリートを管理するための Volterra 独自のフリート オペレーション アプローチについて説明しました。 このブログでは、多数のクラスターまたはサイトにわたって構成変更を行う際に運用チームが直面する構成ドリフトの主要な課題について説明します。 私はこの課題を「効果を出すまでの時間」と呼んでいます。
効果発現までの時間とは何ですか?
簡単に言えば、操作の意図が有効になるまでにどれくらいの時間がかかるかということです。 例:
- セキュリティ ポリシー構成がすべてのサイトで有効になるまでにどれくらい時間がかかりますか?
- applicationの最新バージョンがすべてのサイトに伝播されるまでにどれくらいの時間がかかりますか?
- 世界中に分散しているすべてのサイトでオペレーティング システムまたはインフラストラクチャ ソフトウェアをアップグレードするにはどのくらいの時間がかかりますか?
なぜそれが重要なのでしょうか?
この質問に対する答えは、実際の顧客の例をいくつか挙げることで得られます。
- Meltdown と Spectre — Meltdown/Spectre のニュースが報じられた後、すべての CISO が最も気にしていたのは、すべてのインフラストラクチャ上のオペレーティング システムに迅速にパッチを適用する方法でした。 運用チームは、意図（OS バージョンのアップグレードなど）が有効になるまでの時間を 1 時間ごとに測定されていました。
- 大学にサービス拒否攻撃を引き起こした自動販売機の群れについて聞いたことがあるでしょうか? この攻撃についてまだご存知ない方のために、要約すると、ハッカーはゼロデイ脆弱性を悪用し、他の自動販売機に接続して自動販売ボットの艦隊を作成したマルウェアをインストールしました。 その後、大量のトラフィックが送信され、大学に対してサービス拒否攻撃が発生しました。 大学は攻撃を検出すると、コマンド＆コントロール サーバーへのアクセスを防ぐために、各自動販売機にネットワーク ポリシー ルールを 1 つずつ設定する必要がありました。 彼らにとって、流出を止めるために、彼らの意図（つまり、特定の Web サイトへのアクセスをブロックする）をすべての自動販売機で直ちに有効にすることが極めて重要でした。
効果までの時間は、インフラストラクチャ ソフトウェア、applicationソフトウェア、ネットワーク ポリシー、セキュリティ ポリシーなどの複数のカテゴリにとって重要です。
課題は何ですか?
課題の深刻さは、運用チームが管理しなければならないときに最も顕著になります。
- 大規模なサイト
- 世界中に分散したサイト
- 異機種環境、つまりプライベート、パブリック、通信クラウド、エッジデバイス内のサイト
- サイト間の接続が不安定
ソフトウェアの更新と自動車の接続性の管理を担当する自動車 OEM の運用チームの好例 (以下、顧客サイトと呼びます)。 典型的な展開には、運用チームが自動車を世界規模で（または組織構造に応じて地域的に）制御するためのプライベート データ センタが含まれます。
課題を理解するために、運用チームが利用できるソリューションを見てみましょう。 ほとんどのソリューションは、大規模な分散サイトを集中管理するために、顧客のプライベート データ センタでホストされる管理ソフトウェアを提供します。 自動車 OEM がすべての自動車に適用する必要があるポリシーを構成する場合、中央管理ソフトウェアは基本的に各車両に構成スクリプトを 1 台ずつダウンロードします。 構成スクリプトは、各サイトで一連の構成コマンドを実行する Ansible プレイブックまたは Helm チャートになります。 これは、下の図に示すように視覚化できます。
問題は、効果が出るまでの時間がサイトの数に正比例することです。 集中管理ソフトウェア ベンダーは、すべての操作をリモートで自動的に実行できる限り、これが実現可能な最善の方法であると主張します。
ヴォルテッラはこれに反対しており、このブログでそれを証明することができます。 私たちは、効果が出るまでの時間を最小限に抑えるように設計された、階層型のスケールアウト アーキテクチャ アプローチを採用した分散型コントロール プレーンを構築しました。
効果までの時間を最小化するボルテラアーキテクチャ
効果が出るまでの時間を最小限に抑えるための基本的な構成要素は次のとおりです。
- 階層型ツリーベースアーキテクチャ
- 専用に構築された分散型コントロールプレーン
次に、高レベルのアーキテクチャの概要を示します。
Volterra の階層型アーキテクチャ アプローチは、構成を配布するためのノードのツリーを作成することです。 各ノードは保存と転送を実行します。つまり、構成をローカルに保存し、その子に転送します。 これは例を挙げて説明するのが一番わかりやすいでしょう。 ユーザーが Volterra コンソールでネットワーク ポリシーなどのオブジェクトを構成すると、制御および管理プレーンによってその構成が直下の子である Regional Edge (RE) に配布されます。 各 RE は構成をローカルに保存し、その子に転送します。 RE の子は、その RE に接続された顧客サイトです。
階層的なツリーベースのアーキテクチャにより、効果が出るまでの時間が最小限に抑えられます。 効果が出るまでの時間は、ツリーのレベル数とノードあたりの子の数によって制限されます。 ツリーの最大レベル数は 3 です (コントローラ → RE → 顧客サイト)。 ノードあたりの子の数は、RE に接続されているサイトの数に正比例します。 一連のサイトの構成を処理するために、RE 上にサービス インスタンスが生成されます。 Volterra のスケールアウト コントロール プレーンは、RE に接続されているサイトの数が増加すると、オンデマンドで新しいサービス インスタンスを生成します。
テストのセットアップ
効果までの時間の測定は、ニューヨーク (NY8-NYC) とパリ (PA4-PAR) にある 2 つの地域エッジに接続された大規模な顧客サイトで実施されました。 顧客サイトは、サンタクララ (カリフォルニア州)、ヒューストン (テキサス州)、マドリード (スペイン)、プラハ (チェコ共和国)、ロンドン (英国) など世界中に分散していました。 また、顧客サイトは、AWS、仮想マシン (ESXi)、Intel NUC や Fitlet2 を含むエッジ ゲートウェイなどの異機種環境にまたがっていました。
Volterra の顧客ポータルとグローバル コントロール プレーンは、Azure (ワシントン IAD) で実行されていました。 実際の運用環境を表現するために、顧客サイトは複数の名前空間とテナントに分散されていました。
障害状態は、RE 上のサービス インスタンスを強制終了し、RE と顧客サイト間の低品質の接続リンクを使用することでシミュレートされました。 図 3 に、単一の名前空間内の全艦隊のセグメントのスナップショット ビューを示します。
テスト方法
Volterra コンソールでオブジェクトが構成され、各顧客サイトで構成が適用されるたびに、タイムスタンプ付きの監査ログが Volterra システムにキャプチャされます。 伝播時間は、ポータルでの構成から顧客サイトでの構成のapplicationまでの時間差として測定されました。 次に、詳細な手順を段階的に説明します。
- 顧客ポータルでオブジェクトを構成します。
- 開始時間を、顧客ポータル (以下、Volterra Global Controller と呼びます) 上のオブジェクト作成時間として測定します。 例として図4を参照してください。
- 終了時間を顧客サイトでのオブジェクト作成時間として測定します。 例として図5を参照してください。
表示されているスクリーンショットはサンプルであり、同じ測定反復を参照するものではないことに注意してください。
構成開始時間
構成終了時間
テスト結果
伝播時間のテスト結果を図6と図7に示します。 図 6 のグラフは、ほとんどの測定サンプルの伝播時間が 0 ～ 400 ミリ秒であったことを示しています。 つまり、すべての顧客サイトが0 ～ 400 ミリ秒の間に新しい構成で更新されます。 前述のように、障害状態は、RE でサービスを再起動し、顧客サイトで接続障害/遅延を導入することによってシミュレートされました。 これらの障害条件では構成の伝播時間が長くなり、これらの特定のテストでは障害の種類に応じて 600 ミリ秒から 9 秒の範囲になりました。 たとえば、RE と顧客サイト間の接続障害が発生すると、構成が顧客サイトに到達するまでの時間が長くなります。 ただし、Volterra の分散コントロール プレーンの利点は、最終的に一貫性のある構成のパラダイムに従うことです。つまり、すべての顧客サイトでの構成が顧客が定義した意図に沿っていることを確認するために再試行を続けます。
図 7 のグラフは、85% の時間で、すべての顧客サイトが322 ミリ秒以内に新しい構成で更新されることを示しています。 障害状態が発生した場合、いくつかの顧客サイトでは伝播時間が約 3 ～ 9 秒になる可能性があります。
免責事項: これらの測定値は、シミュレートされたトポロジ、規模、展開環境、および障害状況と密接に関連しています。 起こり得るすべての障害状況やその他の環境を測定したわけではありません。 したがって、テストされていない他の状況や環境での伝播遅延については保証できません。 たとえば、Kubernetes クラスターに障害が発生した場合、システムは障害の検出、再起動、構成の再試行を待機する必要があり、伝播遅延が長くなります。