ブログ

NetOpsのDevOpsはスケールが重要

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2016 年 11 月 7 日公開
数学の問題

そして規模はスピードにつながります。 そしてスピードが成功につながります。

1 人のエンジニアが 2 時間で変更要求を処理できるとします。 別のエンジニアがその変更要求を 1.5 時間で処理できるとします。 彼らが協力して作業する場合、200 件の変更要求を処理するのにどれくらいの時間がかかりますか?

はい、答えは明らかにビールです。  

おそらく誰もが、分数の関係を教えるために数学の授業で出された悪名高い「電車」や「絵画」の文章題を(少なからぬ恐怖と嫌悪感をもって)覚えているでしょう。 実際、私たちの多くが彼らから得たのは絵画と鉄道旅行に対する嫌悪感だったが、それが彼らの意図だったのだ。 そしてミームもたくさん。 ミームを忘れないようにしましょう。

重要なのは、このような定型的な測定がデータ センター、特にネットワークで必須になりつつあるということです。 それは予算が限られているからです(わかっていますよね? なんておかしいことでしょうか?)、Y の作業を行うために X のエンジニアしか雇えません。 高速かつ頻繁なリリース サイクルが重要視されるアプリケーションの世界では、タイムリーなリリースを実現するために雇用できる「X」の数は限られています。

これが、スケールがネットワークにおける「DevOps」(別名「NetOps」)の主な推進力となる理由です。 DevOps の運用原則をネットワークに適用することで、X と Y の関係が指数関数的 (平易な翻訳: 非常に不均衡) な場合でも、ネットワーク オペレーションは「X」エンジニアが「Y」の作業を時間どおりに予算の制約内で実行できるようにするために必要な運用規模を実現できると考えられています。

変更要求の問題は、現実の問題です。ネットワーク エンジニアが直面した変更要求 (アプリケーションのロード バランサ エンドポイントを作成し、それを DNS に追加し、アクセスを許可するファイアウォール ルールを作成するなど) の増加により、最終的には利用可能なスタッフが圧倒される恐れがあり、同時に完了までの時間も長くなるという状況でした。

答えは、もちろん自動化にあり、DevOps の原則を適用し、他のエンジニアがリクエストを行えるセルフサービス インターフェイスを提供することで見つかりました。リクエストはチケット システムに記録され、さまざまなネットワークおよびアプリケーション サービス API を介して実行されます。

この自動化(およびオーケストレーション。プロセス全体も実際に自動化されるため)の導入により、既存のエンジニアが運用規模を拡大できるだけでなく、プロセスも高速化されます。 変更要求の処理に最大 2 時間かかっていたものが、わずか 5 分で処理できるようになりました。

はい、その通りです。 最大 2 時間ではなく 5 分。

これは、自動化とオーケストレーションによる拡張性によって生じる速度の大幅な向上です。 これは野心的な「データセンター全体」のプロジェクトではありませんが、エンジニアとアプリケーション所有者の両方が頻繁に経験する特定の問題点に対処します。 この場合、1週間に最大200回になるようです。

これはまさに、ネットオペレーションが実稼働ネットワーク内で自動化とオーケストレーションに取り組むべき方法です。 繰り返し可能で、変更レビュー委員会によって簡単であるとみなされるタスク (つまり、中断がないことが証明されており、ほとんどのエンジニアが寝ている間に実行できるタスク) を見つけることで、ビジネス所有者とアプリケーション所有者の両方からネットワークで達成する必要があると指示されている速度にスケーリングする大きな機会が得られます。

中断のリスクを可能な限り少なくして自動化できる重要な情報を掘り出すことで、エンジニアは自動化に適していないと見なされるタスクに集中できるようになります。 この重点により、単純で反復可能なタスクに過度の時間を費やす必要がなくなり、他のサービスの実装にかかる時間も短縮されます。

ネットワーク自動化に CPR アプローチを採用することがいかに重要であるかは、いくら強調してもしすぎることはありません。一貫性があり、予測可能で、繰り返し可能な自動化により、より効率的な拡張とより迅速な配信が可能になり、エラーによる中断のリスクが軽減されます。 これは、信頼性と安定性が優先されるものの、俊敏性が依然として求められる、いわゆる「モード 1」と「モード 2」の運用モデルを組み合わせたものです。 ネットワークの自動化とオーケストレーションに CPR アプローチを有効にすることで、組織は、多数の (平均で約 200 個) 他のアプリケーションを配信するネットワークの信頼性を損なうリスクを大幅に低減しながら、俊敏性を向上させることができます。

データ センター ネットワークは、レガシー テクノロジーと新興テクノロジーで構成されており、多くの場合、風船ガムと釣り糸を必要とするマクガイバーのような手法で統合されています。 これらのネットワークは、50 年近くにわたって運用されてきたアプリケーション (メインフレームはまだ存在しています) と、まだ新しいテクノロジー (コンテナーなど) に基づいて構築された新しいアプリケーションを同時にサポートする必要があります。 すべてのアプリケーションを、確実かつ安全に配信する必要があります。 より新しく、より優れたアプリケーションに必要な速度と周波数を優先して、これらの標準を無視することはできません。

しかし、変更管理やその他の承認者によってチェックボックス タスクとみなされ、中断を伴わないタスクとサービス提供オプションを識別し、その後自動化できれば、ネットオペレーションは、両者の共存を可能にするバランスを実現できます。

結局のところ、家の塗装にかかる時間を決定するための私たちのお気に入りの方程式は、塗装業者に手動のブラシではなく自動ペイントローラーが渡されると劇的に変わります。

ネットワークの変更についてはあまり心配せず、方程式を変更するだけです。