仮想化から学ぶスケーリング

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

仮想化が普及し始めると、その成果を測定するためのさまざまな指標が提案されました。なかでも、統合率、仮想マシン数に対する管理者数の比率、プロビジョニングに要する時間、仮想化されたサーバーの割合は、仮想化プロジェクトの成果を測定・評価する指標として広く使用されていました。

現在、DevOpsが普及し始める中、その成功を測るために同様の指標が提案されています。DevOpsを定義するCAMS（文化、自動化、測定、共有）の「M」に注目すると、市場投入までの時間、平均復旧時間、変更のリードタイム、デプロイ頻度などが、よく取り上げられる指標です。

これらは有用かつ必要な指標ですが、DevOpsには、あまり語られることがないものの、同じくらい重要なメリット、いわばユースケースがあります。それが運用のスケーラビリティです。

これは、SDNが運用化によって「ネットワーク内」で解決しようとしている問題と同じです。モバイルアプリケーションやWebアプリケーションの急速な普及により、企業が望み、実際に経験している成長のペースに対応できるよう、テクノロジーを活用してチームの運用規模を拡大するという課題です。これは典型的な「30/30/3」の問題です。データ量の増加によって転送、処理、保存にかかるITコストが上昇する一方、収益はわずかしか増えません。この問題を解決するには、この関係式の中で制御できる唯一の要素、すなわちITコストの上昇に焦点を当てる必要があります。SDNと呼んでも、DevOps for the Networkと呼んでも、SDDCと呼んでも構いません。お好みなら、クラウドと呼ぶこともできます。いずれにも共通する前提があります。それは、成長には運用規模を迅速に拡大することが不可欠だという点です。

重要なのは、ハードウェアとソフトウェアのリソースだけではありません。それらのリソースをどのようにプロビジョニングし、管理するかも重要です。アプリケーションのデプロイと提供に必要なハードウェアおよびソフトウェアのリソース一式を管理する労力を削減する必要があります。

そこで効果を発揮するのが、「Automation（自動化）」の「A」です。成長の方程式を変えるために必要なITコストを削減し、事業のさらなる成長を支える規模への拡張を可能にします。

しかし、必要なのは表面的な自動化だけではありません。サービスやアプリのデプロイに必要なプロビジョニング、管理、運用プロセスをスクリプトとオーケストレーションによって自動化することは重要ですが、「Infrastructure as Code」が果たす極めて重要な役割も忘れてはなりません。

そのためのヒントは、過去を振り返り、コンピューティングリソースの管理を拡張するうえで仮想化が成功した理由を探ることで得られます。その成功には、インフラストラクチャを「コードとして」扱ったことが大きく貢献しています。

確かに、厳密には、コードではありませんでした。スクリプトでも構成ファイルでもなく、「コード」らしいものではなかったからです。しかし、集中管理された「ゴールデンイメージ」のリポジトリを使用し、そこからサーバーを迅速にプロビジョニングして構成するという意味では、「コードとして」扱われていました。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倍にするだけでも、事業拡大に伴うコストを削減すると同時に、ネットワーク全体の拡張性を高められます。そのためには、仮想化の成功にならう必要があります。必ずしも仮想化そのものを使用するのではなく、管理者1人で驚くほど多くのサーバーを管理できるようにした概念、すなわちInfrastructure as Codeと自動化を活用するのです。

スイッチやロードバランサーに加え、組織がアプリケーションの配信とセキュリティ確保に利用していることがわかっている20種類以上のL4～7アプリケーションサービスについて、単純にゴールデンイメージを作成できないのは、構成がそれぞれ異なり、アプリケーション中心だからです。つまり、これらのサービスをソフトウェア化（仮想化）し、ゴールデンベースイメージをデプロイすることは可能ですが、それでも構成を行う担当者が必要です。しかも、その構成は単純ではありません。

Exchange向けに複数のアプリケーションサービスを構成する場合、必要な可用性、パフォーマンス、セキュリティを確保するには、80を超えるさまざまなオブジェクトを作成、構成し、正しく関連付ける必要があります。

まさにここで、「ネットワーク内」の作業に時間（およびそれに伴うコスト）がかかります。

だからこそ、そこでスケールさせる必要があります。インフラストラクチャを「コードとして」扱う必要があるのです。

このため、テンプレート化はDevOpsの「A」、すなわちAutomation（自動化）の要素に含まれています。テンプレート化により、ネットワーク運用（およびセキュリティ運用）では、一般的な構成を一元管理されたリポジトリで管理可能な「コード」として扱えるようになります。テンプレートは、アプリケーションサービスのプロビジョニングと構成の基になる「ゴールデンイメージ」として機能します。このアプローチにより、仮想マシンのプロビジョニングと同様の自動化とオーケストレーションが可能になり、組織がビジネスの成長を支えるために必要とする運用上のスケーラビリティの基盤が整います。

DevOps、SDN、SDDC、さらにはクラウドも、市場投入までの時間短縮や運用コストの削減だけを目的とするものではありません。ビジネスの成長を妨げるのではなく後押しする、効率的なスケーリングの鍵でもあります。データセンター全体（コンピューティング、ネットワーク、セキュリティ、ストレージ）で増え続けるリソースを管理するために、オペレーターやエンジニアを増員し続ければ、そのコストがスケーリングによって得られる成長を食い尽くしてしまいます。自動化を活用して効率的にスケーリングし、インフラストラクチャを「コードとして」扱うことは、ビジネスが目指す成長を支えるために必要な規模を管理する方法の1つとなり得ます。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事