そして、スケールがスピードを生み、スピードが成功をもたらします。
1人のエンジニアが1件の変更リクエストを2時間で処理でき、別のエンジニアが同じ変更リクエストを1.5時間で処理できるとします。2人で協力して200件の変更リクエストを処理する場合、どのくらいの時間がかかるでしょうか。
はい、答えはもちろんビールです。
数学の授業で、分数の関係を教えるために作られた、悪名高い「列車」や「ペンキ塗り」の文章問題を、誰もが少なからぬ恐怖と嫌悪とともに覚えていることでしょう。本来の狙いは確かにそこにありましたが、多くの人に残ったのは、ペンキ塗りと列車での移動への苦手意識でした。そして、たくさんのミームも。ミームのことも忘れてはいけません。
要するに、この種の数式に基づく測定が、データセンター、特にネットワークで必要になりつつあるということです。予算には限りがあり（そんなの当たり前？ まさか、ですよね）、Yの作業をこなすために雇えるエンジニアはX人に限られます。迅速かつ頻繁なリリースサイクルが当たり前となったアプリケーションの世界では、予定どおりにリリースするために雇える「X」の人数にも限りがあります。
このため、ネットワークにおける「devops」、別名「netops」を推進する主な要因は、スケールです。DevOpsの運用原則をネットワークに適用することで、XとYの関係が指数関数的であっても（平たく言えば、極端に不均衡であっても）、「X」人のエンジニアが予算の制約内で期限どおりに「Y」の作業をこなすために必要な運用規模を、netopsによって実現できると考えられています。
変更リクエストの問題は現実に起きています。あるネットワークエンジニアは、増え続ける変更リクエスト（アプリケーション用のロードバランサーエンドポイントを作成してDNSに追加し、アクセスを許可するファイアウォールルールを作成する作業）に直面し、対応に要する時間が長くなる一方で、最終的には対応可能なスタッフの処理能力を超えかねない状況に陥りました。
もちろん、その解決策は自動化にありました。DevOpsの原則を適用し、他のエンジニアがリクエストを送信できるセルフサービスインターフェースを提供することで、リクエストはチケットシステムに記録され、各種ネットワークAPIおよびアプリケーションサービスAPIを介して実行されるようになりました。
この自動化（プロセス全体も自動化されるため、オーケストレーションも含みます）の導入により、既存のエンジニアで運用規模を拡大できるだけでなく、プロセスも高速化しました。変更リクエストの処理に最長2時間かかることはなくなり、現在では最短5分で完了します。
<p>そう、読み間違いではありません。最大2時間かかっていた処理が、わずか5分になりました。</p>
これは、オートメーションとオーケストレーションによってスピードを大幅に向上させ、拡張できるようになった成果です。意欲的な「データセンター全体」のプロジェクトではありませんが、エンジニアとアプリケーション所有者の双方が頻繁に直面していた特定の課題に対処しています。このケースでは、週に最大200回も発生していたようです。
本番ネットワークにおける自動化とオーケストレーションに、ネットワーク運用担当者が取り組む際は、まさにこのようなアプローチが求められます。反復可能で、変更審査委員会が単純と判断するタスク（つまり、サービスに影響を与えないことが実証済みで、ほとんどのエンジニアが難なく実行できるタスク）を見つけることで、大きなスケーリングの機会が生まれます。その結果、ビジネス部門とアプリケーション所有者の双方がネットワークに求めるスピードを実現できます。
業務への影響を最小限に抑えながら自動化できる作業を見つけ出すことで、エンジニアは自動化に適さないと判断されたタスクに集中できるようになります。また、単純な反復作業に過度な時間を費やす必要がなくなるため、その他のサービスの導入も迅速化できます。
ネットワーク自動化にCPRアプローチを採用することがいかに重要かは、いくら強調してもしすぎることはありません。一貫性、予測可能性、再現性のある自動化により、エラーによる中断のリスクを抑えながら、より効率的なスケーリングと提供期間の短縮が可能になります。これは、信頼性と安定性を最優先しつつ、アジリティも求める、いわゆる「モード1」と「モード2」の運用モデルを融合したものです。ネットワークの自動化とオーケストレーションにCPRアプローチを導入することで、組織は、数多く（平均で約200）の他のアプリケーションを配信するネットワークの信頼性を損なうリスクを大幅に抑えながら、アジリティを向上できます。
データセンターネットワークは、レガシーテクノロジーと新興テクノロジーで構成され、多くの場合、ガムと釣り糸を使うような即席の工夫でどうにかつなぎ合わされています。こうしたネットワークは、50年近く本番環境で稼働しているアプリケーション（メインフレームは今も存在します）と、登場して間もないテクノロジー（コンテナなど）で構築された新しいアプリケーションを同時にサポートしなければなりません。また、すべてのアプリケーションを、信頼性とセキュリティを確保しながら配信する必要があります。より新しく魅力的なアプリケーションに求められるスピードと頻度を優先するために、こうした基準を軽視することはできません。
しかし、ネットワーク運用チームは、中断を伴わず、変更管理担当者やその他の承認者が定型的な確認事項と見なすタスクやサービス提供オプションを特定し、徹底的に自動化することで、両方を共存させるバランスを実現できます。
結局のところ、家の塗装にかかる時間を算出するおなじみの方程式も、塗装作業者が手動の刷毛ではなく自動ペイントローラーを使えば、結果は大きく変わります。
ネットワークの変更に頭を悩ませるより、方程式を変えましょう。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。