「2018年版 アプリケーションデリバリの状況」調査結果：ネットワーク管理者（NetOps）にもオートメーションが浸透
私はプロトコルやワイヤキャプチャと同じくらい、プログラミング言語を好むIT博学者を自負しています。その私を最近困惑させているのが、オートメーションとオーケストレーションに要求されていることの違いが、曖昧になっていることです。
「アプリケーションデリバリの状況」調査では、API対応のインフラとそれに関連するテクノロジーが回答者によってどのように認識されているのか、4年間にわたって追跡してきました。この間に、インフラのプログラマビリティが重要である（5段階評価で4または5）とした回答者の割合は、2倍近くに増加しました。2015年版では「これが重要である」と回答した割合は半数に満たない40%でしたが、2018年版では74%に達しているのです。
2017年に行った調査の結果を踏まえれば、この結果は驚くべきことではないかもしれません。この調査ではDevOpsとNetOpsの両方の考え方が検証されていますが、アプリケーションリリースのための一連のパイプラインにおいて、オートメーション化が重要であるという点では認識が一致しています。
しかし、認識とは意見にすぎません。実際の利用状況はまた別の問題です。
今年の調査でわかったのは、地域や産業、また企業の規模にかかわらず、オートメーションが浸透していることでした。100%オートメーションを達成している企業や組織はまだ存在しませんが（おそらく今後も登場しないでしょう）、オートメーションは人々が考えるよりもはるかに進んでいます。
実際に回答者の25％は、アプリケーションのメジャーリリースでは、常にオートメーションを利用すると述べています。60％はマイナーリリースでも、時々オートメーションを利用すると回答しました。インシデント対応と比較すると、アプリケーションリリースでオートメーションが利用されるケースの方が多いこともわかっています。4分の1以上（26%）はインシデント対応にオートメーションを利用することはまったくないと回答しており、常に利用するとの回答は22％にすぎないのです。インシデントは予測不可能なことへの対処が求められることが多いため、この結果は驚くべきことではありません。オートメーションの少なくともその一部は、明確に定義されたタスクとステップのセットをひとつの運用プロセスへとまとめあげることに意義があります。メジャーかマイナーかにかかわらず、アプリケーションリリースといったプロセスは、このような「コード化」に適しています。逆にインシデント対応は、それほど適しているとは言えません。
実際、あらゆる形態、規模、産業のデータセンターにおいて、驚くほど多くのオートメーション化が進められているようです。
このオートメーション導入にあたり、何が使用されているかを知りたい人もいると思います。かつては数々のツール、ツールセット、およびフレームワークを挙げてもらうことが、その答えを知るための質問になり得ました。しかしこれはもはや、適切なアプローチとはいえません。オートメーションには以下のようにさまざまな側面があり、それらを理解することなしにオートメーションの状況を把握することは不可能になっています。
- 言語とツールセット
ネットワーク管理者とIT担当者は、言語とツールセットをオートメーションに対するコマンドとコントロールの手段として使用しています。これには、Ansible（20%）やVagrant（5%）などのツールとともに、Puppet（19%）やChef（16%）のようなフレームワークが含まれます。最も使用されているのは昔ながらのPythonスクリプトで、回答者の39%が自ら作成したスクリプトをITオートメーションに使用しています。 - ネットワークオートメーション
アプリケーション提供のためのネットワークの中には、平均で16種類のアプリケーションサービスが存在しており、アプリケーションの安全性とスケーラビリティを支えるために、適切な配置と設定、管理を必要としています。このような状況の中、ほとんどの企業や組織は、Cisco ACI（48%）, VMware（65%）、OpenStack（26%）といったシステムへの移行を進めています。これらの3つのシステムは、いずれも昨年度から利用者が大きく増えています。デジタルトランスフォーメーションへの取り組みの結果として、企業の55％がオートメーションとオーケストレーションを導入していることを踏まえれば、これは驚くべき結果ではありません。 - コンテナオーケストレーション環境（COE）
このような最新テクノロジーが、現在急速な勢いで台頭しています。これを活用し、コンテナ化されたアプリケーションを拡大していこうという動きは、必然的なものだといえます。回答者が一番多く使用していたのはDocker Swarm（27%）で、Red Hat OpenShift（21%）とKubernetes（16%）がこれに続きました。現時点でどれも使用していないとの回答は48%でした。
各企業が利用するこれらのツールとフレームワークの数は減少していますが、これは驚くべきことではありません。これは標準化への戦略的な取り組みの中で、慎重な検討に基づいてオートメーションのためのツールとツールセットが選択されていることを意味します。アプリケーション開発者は長年にわたって古いテクノロジーやアーキテクチャの「負の遺産」に悩まされ続けてきましたが、これと同様の悩みにIT組織が屈服し混乱が支配する前に、いち早く対応することこそが最善の策となります。実際には、回答者の50%はネットワークオートメーションに一つのフレームワークを使用していました。このうちCisco ACIは8%、OpenStackは5%、VMwareは19%でした。
これをムーブメントではなくマーケットと呼ぶのであれば、現在も依然として非常に流動的であり、進化の真っ只中にあるマーケットだといえます。DevOps的なアプローチの導入と、ビジネス面からのプレッシャーにより、IT担当者はさらに迅速に動くことを強いられています。オートメーションの採用は、NetOpsでも全面的に進んでいくでしょう。オートメーションの適用領域を拡大し、IT組織が自らデジタルトランスフォーメーションを達成することで、ビジネスにも強固なデジタル基盤を提供できるようになります。そしてこのような基盤の確立こそが、新たなアプリケーションの構築と、それによる新たなビジネスチャンス獲得を可能にするのです。
デジタルトランスフォーメーション、マルチクラウド、アプリケーションサービス、セキュリティ、および継続するNetOps変革の詳細については「2018年版 アプリケーションデリバリの状況」調査レポートをご覧ください。Twitter（@F5Japan）やハッシュタグ#soad18もご利用ください。またレポートでは示されていないデータや見解の入ったブログ記事も今後投稿する予定です。