vimdiffに固執する1人を除き、GitHubを導入するNetOps

F5エコシステム | 2017年1月16日

さらに、NetDevOps 2016年秋季調査(NetworkToCodeコミュニティ実施)から得られたその他の知見

NetworkToCodeコミュニティには、ネットワークとコードに情熱を注ぐ人々が集まっています。ありきたりな表現かもしれませんが、ネットワークの自動化が注目を集め、経営上の必須事項となる以前から、こうした人々は自動化に取り組んできました。

2016年秋、コミュニティはネットワークとコードを中心に、幅広い項目についてアンケート調査を実施しました。生の調査結果(上記リンク)は一般公開されています。オンラインアンケートツールで得られるデータセットは、データを正規化しないと分析が難しい場合がありますが、その作業には手間がかかります。幸い、その作業は筆者が済ませているため、より視覚的で色彩豊かな形で知見をご紹介できます。

DevOpsに対するNetOpsの見解

鋭い読者の方ならお気づきのとおり、私は以前から、一般に「DevOps」の原則をネットワークに適用することを提唱してきました。そのため、このデータを掘り下げる際に、そこへ多くの労力を注いだのも当然のことです。

コードとネットワーキングに重点を置くグループで、DevOpsに対する見方が少なくともおおむね肯定的だったことは、驚くにはあたりません。DevOpsに「関心がない」と回答したのはわずか6.75%で、25.74%はすでに本番環境で導入済みと回答しました。その他の大半は、評価中(28.27%)ではないにしても、少なくとも検討中(39.24%)でした。

この調査の優れた実施者は、このトピックについて、Infrastructure as Codeに対するNetOpsの見解など、かなり踏み込んだ質問をしています。こちらはやや関心が低く、10%近くが「関心なし」と回答しました。興味深いことに、Infrastructure as Codeが「すでに本番環境で稼働中」と回答したのはわずか19.35%でしたが、回答者の実に54%が構成のデプロイに自動化を利用し、さらに66%が構成のアーカイブを自動化していました。構成管理を自動化しているNetOps担当者は、ちょうど1人だけです(しかも、構成変更の管理にvimdiffを誇らしげに使っているあのNetOps担当者ではないと、私はほぼ確信しています)。

まず頭に浮かぶのは、「そもそもInfrastructure as Codeとは何か」という疑問でしょう。これが、「評価中」または「検討中」と回答した人が大半であるにもかかわらず、実際にははるかに多くの人が「実践している」理由なのかもしれません。 皆さん、定義疲れは現実に起きています。最近は明確な定義が示されていないため、次々と移り変わる用語について結論を導き出すのは困難です(とはいえ、結局は結論を出します。それが私たちの仕事ですからね)。

では、NetOpsは何を自動化しているのでしょうか。デジタルトランスフォーメーションを滞りなく進めるには自動化が必要だと、私たちは繰り返し伝えてきました。しかし、特に企業ネットワークは、自動化を気軽に試せるような環境ではないことも承知しています。今や事業全体を支える、極めて重要なネットワークだからです。実際のところ、NetOpsはかなり多くの作業を自動化しています。

ネットワーク自動化 2016

現在、自動化が最も進んでいる3つの運用は、構成の生成、アーカイブ、デプロイです。データ収集とレポート作成の自動化も進展しているようです。

実際、構成管理(そして、果敢に取り組むNetOps担当者が1人)を除けば、回答者の組織のうち相当数で、あらゆる運用が自動化されているようです。

しかし当然ながら、構成関連タスクの自動化については、そもそもそのタスクをどの程度の頻度で実行するのか、そして自動化するだけの価値があるのか、という疑問が生じます。おそらく現在の一般的な見解には反しますが、本番環境への変更のデプロイ頻度が低いほど、実は自動化の価値は高まると私は考えます。確かに、自転車の乗り方を「忘れる」ことはありません。しかし、数か月、あるいは数年ぶりに再び自転車に乗るとなれば、いわば最初のひと漕ぎは苦痛を伴い、ミスも起こりがちです。デプロイについても同じことが言えます。ただし、これはまた別の機会に取り上げます。

実際、NetOpsはかなり定期的にデプロイを行っています。ほぼ半数(50.92%)が本番環境に1日複数回、小規模な変更をデプロイし、37.59%が月に1~5回、大規模な変更をデプロイしています。Webネイティブで、主に単一のアプリを支えるテクノロジープロバイダー(Netflix、PayPal、Facebookなど)が掲げる驚異的な「1日200回」には遠く及びません。それでも、F5の「State of Application Delivery」調査によると、平均200以上のアプリケーションを支える企業としては、かなり速いペースでアプリを展開しています。

本番環境での変更頻度

最後に、これほど多くの変更をどのように管理しているのか、気になるところです。タイトルにもあるとおり、変更管理にはvimdiffしか使わないと胸を張るNetOps担当者が、実際に1人だけいました。データの構造上、この回答と本番環境での変更頻度を関連付けるのは困難です。それでも、外部からどれほど圧力を受けても、自分にとって有効な方法を誇りを持って使い続けるこの担当者は私のヒーローなので、ぜひ話を聞いてみたいと思います。

では、ほかのNetOpsは何を利用しているのでしょうか。実に多くのNetOpsがGithubを使用しており、その割合は47%です。また、別の大きなグループ(39%)はRancid/Oxidizedを使用しています。Rancid(1991年にカリフォルニア州バークレーで結成された米国のパンクロックバンドとは別物です)は、構成のバックアップを管理するネットワークツールです。Oxidizedも構成のバックアップを管理するネットワークツールで、RANCIDの代替としてよく紹介されています。さらに詳しく知りたくなったら、それぞれ専用のsubredditもあります。

驚くべきことに、8%は構成変更をまったく追跡していません。私も以前ラボで同じことをして、ネットワーク間リンクが一方向では100 Mbps、反対方向では1.5 Mbpsという、ひどく非対称な状態になったことがあります。そう、11年近く前、グリーンベイのラボで現代のケーブルブロードバンドモデルを偶然再現してしまったのです。残念ながらロイヤリティーはもらっていませんが、幸い苦情のメールも届きません。繰り返しになりますが、組織規模とのクロス集計ができなければ、その理由を理解するのは困難です。興味深いことに、11.91%が管理しているネットワークデバイスは0~50台です。そのため、先ほどの8%は管理可能な台数のデバイスを担当しており、問題なく運用できていると推測することもできます。NetOpsで最も多い層(38.63%)は1,000台を超えるデバイスを管理しており、さらに28.23%が251~1,000台を管理しています。したがって、NetOpsの大半は多数のデバイス(ほぼ間違いなく異種混在環境)を担当していると言えます。そのため、構成変更の追跡は、ネットワークを継続的に健全な状態に保つためだけでなく、運用担当者の平静を保つためにも欠かせません。

GitHubを導入するNetOps

総じて、彼らが自ら「NetDevOps」と呼ぶ世界を掘り下げ、使用しているもの、重視していること、そして業務環境の概要を大局的に把握できたことは、非常に興味深い体験でした。

NetOpsはIT組織を支える屋台骨です。企業がデジタルトランスフォーメーションを進める中、ネットワークとその安全な運用を担うオペレーターの負担増が見込まれており、NetOpsにはあらゆるシステムを安定稼働させる責任がますます求められています。

ネットワーク運用を従来型モデルから、よりアジャイルでDevOpsに近いモデルへ一挙に全面刷新することは不可能だと考えています。ビジネスのデジタルトランスフォーメーションと同様に、ITのデジタルトランスフォーメーションも、事業の進行を妨げかねない既存プロセスを中断させないよう配慮しながら、段階的に進められます。この調査からは、明らかに変革が進んでいることがわかります。それは「DevOps」と呼ばれていないかもしれず、DevOpsのあるべき姿に関する純粋主義者の考えを完全には満たしていないかもしれません。それでも、企業ネットワークを独自のデジタルトランスフォーメーションの道のりにおいて、確実に前進させています。

共有
タグ: DevOps, 2017

著者について

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

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エコシステム | 2025/04/15

F5 Application Study Tool:OpenTelemetryによるF5 BIG-IP環境の監視

F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。

F5 BIG-IPでAI防御を実現
F5エコシステム | 2024/11/13

F5 BIG-IPでAI防御を実現

F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。

F5 Advanced WAFによるGraphQL APIの保護
F5エコシステム | 2021/08/31

F5 Advanced WAFによるGraphQL APIの保護

ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。

アプリケーションサービスの現状 通信業界版:リーダーとしての台頭
F5エコシステム | 2019/02/19

アプリケーションサービスの現状 通信業界版:リーダーとしての台頭

通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。

デジタルトランスフォーメーションは、単なるペーパーレス化ではない
F5エコシステム | 2017/07/10

デジタルトランスフォーメーションは、単なるペーパーレス化ではない

デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。

やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
F5エコシステム | 2016/09/19

やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。

もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。