仮想化からスケールについて学べること

仮想化が普及し始めると、成功を測定するためのさまざまな指標が提案されました。 統合率、管理者対仮想マシンの比率、プロビジョニングにかかる​​時間、仮想化されたサーバーの割合は、仮想化プロジェクトの成功を測定および評価するために最も一般的に使用されていました。

今日、私たちは DevOps が急成長し始め、その成功を測定するために同様の指標が提案されているのを見ています。 市場投入までの時間、平均復旧時間、変更のリードタイム、展開頻度などは、DevOps の CAMS (文化、自動化、測定、共有) 定義の「M」に焦点を当てるときによく使われる測定基準の一部です。

これらは良いことであり、必要なものですが、DevOps には、ほとんど議論されることはありませんが、同様に重要な利点 (ユースケースとも言えます) があります。それは、運用の規模です。

これは、SDN が運用化を通じて「ネットワーク内」で解決しようとしている問題と同じです。つまり、モバイル アプリケーションや Webapplicationsの急速な成長により、企業が望んでいる成長率や経験している成長率に合わせて、テクノロジーを通じてチームの規模を調整します。 これは、データの増加により IT コスト（転送、処理、保存）が上昇し、収益はわずかにしか増加しないことから生じる典型的な「30/30/3」問題です。 この問題を解決するには、私たちが制御できる唯一の要素、つまり IT コストの上昇に焦点を当てる必要があります。 したがって、SDN と呼びたい場合は、どうぞご自由に。 これをネットワーク向け DevOps と呼びたいのであれば、どうぞ。 SDDC と呼びたいなら、そうしてもいいでしょう。 それがお好みなら、クラウドとも呼んでください。 これらすべてに共通する前提は、急速な事業拡大が成長に不可欠であるということです。

それはハードウェアとソフトウェアのリソースだけの問題ではなく、それらのリソースをどのようにプロビジョニングし管理するかということも重要です。 applicationの展開と配信に必要な一連のリソース (ハードウェアとソフトウェア) の管理に必要な労力を削減する必要があります。

ここで、「自動化」の「A」が、成長方程式を変更するために必要な IT コストを削減し、より大きなビジネス成長をサポートできる規模を実現する上で役立ちます。 

しかし、私たちが必要としているのは、自動化の表面的な見方だけではありません。 自動化（スクリプトとオーケストレーションを使用してプロビジョニングと管理を推進し、サービスとアプリを展開するために必要な運用プロセスを実行する）は重要ですが、「コードとしてのインフラストラクチャ」が果たす重要な役割を忘れてはなりません。

ウェイバック マシンを使って仮想化のコンピューティング リソース管理のスケーリングの成功を覗いてみると、そのインフラストラクチャを「コードとして」扱うことによるところが大きいことがわかります。

わかっています、わかっています。それはスクリプトでも構成ファイルでも「コード」のように見えるものでもなかったという意味で、本当のコードではありませんでした。 しかし、サーバーを迅速にプロビジョニングおよび構成するための「ゴールデン イメージ」の集中リポジトリを使用するという意味で、これは「コードとして」扱われました。 Web サーバー、アプリケーション サーバー、データ サーバー。 さまざまな種類のサーバーが、オペレーターが拡張できるように事前に定義された「イメージ」によって理想化されました。

スケールと言うとき、私はスケールを意味します。 さまざまな数字が飛び交っていますが、2011 年当時は、管理者と仮想サーバの比率が 1:350 の組織も珍しくありませんでした。 1:500 から 1:1000 までと主張する人もいましたが、組織の規模が理由で 1:100 や 1:150 しか主張できない人もいました。 複数のITベンチマークレポートのデータを分析した2012年のレポートでは、管理者とサーバーの比率は1であると報告されています。 物理サーバーの場合は 50 ～ 75、仮想サーバーの場合は 1:185 ～ 450。

規模で言えばすごいですね。 これにより、通常は付随的に発生する IT コストの増加なしに成長が可能になります。

ここで、あらゆる規模の企業におけるエンジニアとデバイスの比率の中央値は約 1:36 であると考えてみましょう。 それ自体が興味深いと思いませんか？ ビジネスが成長してもこの比率は変化しないようです。 これは一種の悪いことであり、30/30/3 問題の一因となるだけです。

しかし、これを何らかの方法で変更できれば、エンジニア 1 人あたりのデバイス数を 2 倍にするだけでも、成長コストを削減し、ネットワーク全体の拡張性を高めることができます。  そのためには、仮想化の成功を模倣する必要があります。 必ずしも仮想化を使用するわけではありませんが、信じられないほどの管理者対サーバーの比率をサポートできるようにする概念、つまりコードとしてのインフラストラクチャと自動化を使用します。

スイッチやロード バランサー、そして組織がapplicationsの配信とセキュリティ保護に使用していることがわかっている 20 を超えるその他の L4-7 アプリケーション サービスのゴールデン イメージを作成できない理由は、すべての構成が固有であり、アプリケーション中心であるためです。つまり、ソフトウェア (仮想) に移行してこれらのサービスのいずれかのゴールデンベースイメージを展開することはできますが、それでも構成を行う人が必要になります。 そして、それは単純な構成ではありません。

Exchange 用にいくつかのアプリ サービスを構成していますか? 必要な可用性、パフォーマンス、セキュリティを実現するには、80 を超えるさまざまなオブジェクトを作成、構成し、正しく関連付ける必要があります。

これはまさに、「ネットワーク内」で時間 (およびそれに関連するコスト) が発生する場所です。

そこがスケールする必要があるところです。 インフラストラクチャを「コードとして」扱う必要がある場合。

これが、テンプレートが DevOps の自動化コンポーネントの「A」に含まれている理由です。 テンプレートを使用すると、ネット (およびセキュリティ) オペレーションは共通の構成を「コードとして」扱い、中央リポジトリで管理できるようになります。 テンプレートは、アプリ サービスのプロビジョニングと構成の基準となる「ゴールデン イメージ」になります。 このアプローチにより、仮想マシンのプロビジョニングを模倣した自動化とオーケストレーションが可能になり、ビジネスの成長を実現するために組織が必要とする運用上のスケーラビリティの基盤が提供されます。

DevOps、SDN、SDDC、さらにはクラウドは、市場投入までの時間を短縮したり、運用コストを削減したりするだけではありません。 これらは、ビジネスの成長を妨げるのではなく、成長を可能にする効率的な規模の拡大にも重要です。 データセンター全体にわたって増加するリソース (コンピューティング、ネットワーク、セキュリティ、ストレージ) を管理するために、ますます多くのオペレーターやエンジニアを追加するコストは、その規模から生まれる成長を食い尽くすことになります。 自動化を使用してより効率的にスケーリングし、インフラストラクチャをコードとして扱うことは、ビジネスが望む成長をサポートするために必要な規模を管理する 1 つの方法です。