NetOpsに最小実行可能な導入形態はあるのか？

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

ネットワーク自動化は、本当に「すべてかゼロか」なのでしょうか？

ネットワーク自動化（本番環境へのデプロイパイプラインにDevOpsを適用する取り組み）は、すでに多くの組織で導入されています。全面的に導入している組織はごくわずかですが、大半（F5の最新の「State of Application Delivery」によると77%）は、本番環境で自動化を試験導入しているか、一部で利用しています。

DevOpsと密接に関連し、そのためNetOpsとも関連付けられることが多い概念の1つが、実用最小限の製品（MVP）です。

これはアジャイル手法の一部であり、開発サイクルを短縮し、ソリューションをより迅速に市場へ投入するために活用されます。まさに「ネットワーク」に切実に求められているものです。以前のブログで取り上げたAppianの調査を覚えているでしょうか。その調査では、回答者の72%が、ビジネスニーズに応じて拡張するIT部門の能力に確信を持てないと回答しており、厳しい現実を突きつけられました。

これは痛い結果です。ITでは自動化がかなり広く活用されているにもかかわらず、開発者やビジネス部門のステークホルダーは、ITが仕事をやり遂げる能力に依然として確信を持てていません。

したがって、DevOpsのツール、テクノロジー、手法を取り入れ、よりスマートなスケーリングによってスピードアップを図ることは、それほど突飛な考えではありません。しかし、MVPをネットワークにどう適用するかを検討する前に、まずMVPとは何かを理解する必要があります。DevOps、アジャイル、MVPになじみのない方のために、Agile Allianceによる分かりやすい定義をご紹介します。

ここで指摘しておきたいのは、DevOps（およびそれに関連するテクノロジーや方法論）にまつわる概念の多くは、NetOpsの取り組みに適用しても、必ずしもうまく当てはまるとは限らないという点です。ネットワークへの変更について議論する際、IT部門のエンジニア、アーキテクト、経営幹部が「実験」という言葉を使うことはありません。

問題は、影響範囲です。広範囲に及び、無視できません。多くの組織が運用リスクを許容できないのには、もっともな理由があります。システム停止は実際に金銭的損失をもたらし、ときには雇用にも影響します。ネットワークは、実験に適した場所とは言えません。

しかし、だからといってNetOps向けの実用最小限のデプロイメント（MVD）が存在しないわけではありません。

NetOps向けMVDの定義

現在の本番環境のパイプラインは、スイッチ、ルーター、DNS、マルチクラウドルーティング（GSLB）などの共有リソースと、ロードバランサー、WAF、アプリケーションアクセス制御など、アプリケーションごとのアプリケーションサービスで構成されています。

興味深いことに、共有リソースの変更頻度は比較的低いことがわかります。つまり、変更されることがあまりありません。これは好都合です。共有リソースは中断に対する許容度も低いためです。一方、アプリケーション単位のリソースは変更頻度が高く、中断に対する許容度も高くなります。

結局のところ、アプリ単位のアーキテクチャには、データパスを分離することで、問題が発生した際に他のアプリが影響を受けないよう保護できるというメリットがあります。

F5の調査によると、そのデータパス上では、組織がアプリケーションの配信とセキュリティ確保に平均16種類の異なるアプリケーションサービスを使用しています。そのうち、ネットワークファイアウォールやDNSなどは共有リソースです。一方、共有されていないものや、少なくとも共有する必要がないものもあります。現在は共有プラットフォームに導入されている場合でも、妥当な理由があれば、独自のデータパスを持つように設計できます。

もちろん、ここからはその理由をご説明します。

これが妥当な理由は、アプリケーションに密接に結び付いたアプリケーションサービスにアプリ単位のアーキテクチャを採用すれば、そのアプリケーションのMVDを効果的に開発できるためです。そのためには、まず、アプリケーションに密接に結び付いたアプリケーションサービスに、アプリ単位のアーキテクチャを採用する必要があります。

MVPの定義が示すように、「プロダクト」（ここではアプリのデプロイ）を完全に自動化する必要はありません。リスクが最も高く、変更に対する許容度が最も低いリソースについては、引き続き手動で設定（および検証）する必要があるという前提でも、改善は可能です。ファイアウォールやDNSなどのコアサービスは変更頻度が非常に低いため、手動での対応がデプロイのスケジュールに大きな影響を及ぼすことはないと考えられます。アプリ単位のアプリケーションサービスの大部分を自動化すれば、なおさらです。運用担当者やエンジニアが必要に応じて手動で変更するための時間を確保できるからです。

コア（共有）サービスとアプリごとのアプリケーションサービスの比率を約1対3*と仮定すると、平均的な組織では、手動で管理する共有リソースが少なくとも4つ、自動化するアプリごとのリソースが12個あることになります。

アプリケーションサービスの広範なリスト（現在、30種類のサービスを追跡しています）を見ると、その一部は、アプリケーションの配信やセキュリティ確保（DDoS、WAF、拡張性を高める負荷分散、アプリケーションアクセス）に不可欠である一方、その他は、いわば機能強化に当たります。たとえば、パフォーマンスを向上させる高速化オプションや、生産性を高めるシングルサインオン（SSO）などのアプリケーションサービスです。

そこで、MVDの実装を検討する場合は、アジャイルなアプローチを採用し、初日からアプリケーションのデリバリとセキュリティに不可欠なアプリケーションサービスに重点を置くことが考えられます。これは拡張機能を無視するという意味ではなく、まず不可欠なサービスに注力し、その自動化を優先するということです。生産性やパフォーマンスを向上させるサービスは引き続き手動で管理できますが、MVDでは利益に影響するサービスに焦点を絞ります。

アジャイルネットワークに向けたMVDアプローチ

MVDの定義と提供を目指して自動化に取り組むことで、より迅速に（よりアジャイルに）進められるようになります。また、四半期単位ではなく週単位の各スプリントで自動化を反復的に改善・拡張し、堅牢で持続可能な成果物（自動デプロイ）へと発展させることができます。

自動化にMVDベースの戦略を採用するには、アーキテクチャだけでなく、アプリケーションを重視するアプローチと姿勢にも取り組む必要があります。このようなアプローチでは、運用とビジネスの両面から、アプリケーションとそのニーズを理解する必要があるためです。あるアプリケーションのMVDが、別のアプリケーションのMVDと一致するとは限りません。固定的な手動ネットワークからアジャイルな（自動化された）パイプラインへ移行する際に、アプリケーション単位のアーキテクチャが極めて重要な要素となる理由の1つがここにあります。

つまり、NetOpsにも実用最小限のデプロイメントが存在します。これは、ネットワーク自動化にアジャイルなアプローチを採用できるということです。アジャイルネットワークの取り組みの一環としてアプリケーション単位のアーキテクチャに移行すれば、そのアプローチは飛躍的に高速化し、より安全になります。

ネットワークに関する（ほぼ）すべてを自動化。

*これは、リストと私の経験、そして私の（強い）意見に基づく、まったくの概算です。実際の結果や定義は異なる場合があります。

著者について

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

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

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