マズローの自動化ニーズ階層説

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

今、コンテナ以上に注目を集めているものがあるとすれば、おそらくサーバーレスのようなコンテナベースのテクノロジーでしょう。現在の「注目株」であるだけでなく、モダンアプリケーションにとって自動化とオーケストレーション*がいかに重要かを示す中心的なテーマでもあります。

コンテナアーキテクチャには、ほぼ毎日のように新たなコンポーネントが登場し、それに応じたレベルの自動化も進んでいます。コンテナの世界では、自動化できるものはすべて自動化されていきます。豊富なAPIと、構成／テンプレートベースのアーティファクトへの依存が、コンテナベース環境における自動化の絶え間ない進化を促しています。APIエコノミーがビジネスのデジタルトランスフォーメーションにとって重要であるなら、もう1つのAPIエコノミーはITのデジタルトランスフォーメーションに不可欠です。

コンテナ環境も例外ではありません。コンテナ環境の本番導入が進むにつれ、アップストリーム（N-S）サービスには、変化の激しい環境内でスケーリングされ提供されるアプリケーションを配信するだけでなく、自動化およびオーケストレーションのレイヤーでコンテナ環境と統合できることが、ますます重要になります。

これは、このテクノロジー「スタック」を構成するレイヤーの中に、他よりも変動の激しいものがあるためです。たとえば、コンテナの作成と破棄は、クラスター全体の作成や破棄よりもはるかに頻繁に行われます。実際、Data Dog HQのDocker導入状況レポートによると、「2017年3月時点で、Dockerを実行しているDatadogのお客さまの約40%が、Kubernetes、Mesos、Amazon ECS、Google Container Engine、またはその他のオーケストレーターも実行していました」。自動化とオーケストレーションは、コンテナを効果的に活用するうえで、特にその中核において不可欠です。つまり、取り組みを進めるにあたり、一部の自動化要件には可能な限り迅速かつ十分に対応する必要があります。それらがほかのすべての基盤となるためです。

これはクラウド環境にも当てはまります。自動化とオーケストレーションが必要とされる理由は、変動性だけでなく、アジリティにもあります。クラウドコンピューティングに伴う複雑な「セルフサービス」モデルでは、ユーティリティコンピューティングモデルの中で、クラウドコンピューティングの伸縮自在なオンデマンド型アーキテクチャという概念を支える自動化が求められます。クラウドとコンテナには共通する一連の自動化ニーズが明確に存在し、それらが自動化のビジネス価値を理解するための基盤となります。

自動化ニーズの階層は、マズローの欲求階層説と同様に、成長を可能にする高次のニーズへと進むには、まず満たすべき「欠乏」ニーズがあるという前提に基づいています。

より高次の成長欲求を満たす段階へ進むには、まず低次の欠乏欲求を満たす必要があります。欠乏欲求が満たされると、その欲求は消失し、まだ満たされていない次の欲求を満たすことへと、習慣的に行動が向けられるようになります。そして、それらが顕在的な欲求となります。一方、成長欲求は感じ続けられ、いったん追求し始めると、さらに強まることさえあります。こうした成長欲求が十分に満たされると、自己実現と呼ばれる最高段階に到達できる可能性があります。-- https://www.simplypsychology.org/maslow.html

この「自動化ニーズの階層」は、アプリケーションとそれを構成するサービスのスケーリングに関する基礎的なニーズに重点を置いています。この概念を最初に提唱した優秀なF5エンジニアは、次のように説明しています。「階層の下位にある自動化は、最も頻繁に実行され、アプリケーションの稼働を維持するうえで不可欠なため、最も価値があります。階層の上位にある自動化は、実行頻度が低く（場合によっては『1回』だけ）、すでに多くの担当者が手作業を行っているのと同じタイミングで実行されるため、価値は最も低くなります。」

コンテナ、仮想マシン、アプリの作成と破棄を自動化することは「基本的」なニーズであり、スケーリングだけでなく、スケーリングの効率性を確保するうえでも不可欠です。この効率性は、コストを抑え、従来は（高コストな）手作業に委ねられていたスケーリングの負担を軽減するために重要です。現在、このような処理が大量かつ頻繁に発生していることを考えると、自動化は「あればよいもの」ではなく必須要件です。これは欠乏ニーズであり、これが満たされなければ、より高次で発生頻度の低い自動化を検討しても、ほとんど意味がありません。

これは特にコンテナに当てはまります。Data Dogが「コンテナの平均稼働期間は2.5日であるのに対し、全企業における従来型VMとクラウドベースVMの平均稼働期間は23日です」と指摘していることからも、改めて裏付けられているようです。この違いには、自動化が影響していると考えられます。「オーケストレーターを使用してDockerを運用している組織では、一般的なコンテナの稼働期間は1日未満です。Dockerをオーケストレーションなしで運用している組織では、コンテナの平均稼働期間は5.5日です」

コンテナ、ひいてはアプリの作成と破棄を自動化する機能は、従来型環境とクラウドベース環境の両方で組織がコンテナのメリットを享受するために必要な、スピードと俊敏なスケーリングを実現するうえで不可欠です。

より高度な自動化のニーズは、そのほとんどがルーティングに関するものであり、いわゆる成長欲求に該当します。成長欲求が求められるのは、基本的欲求（欠乏欲求）が満たされた後です。クラスターの作成や破棄、ルーティングの変更は頻繁には行われず、アプリが導入され、スケールできるようになって初めて価値を持ちます。開発／テスト環境から本番環境へ移行し、アプリケーションの提供を通じてビジネス価値を生み出すことが求められるようになると、これらは不可欠になります。応答できないアプリへのルーティングは、空腹の人を抱きしめるようなものです。温かい気持ちにはなっても、食べ物という基本的欲求は満たせません。Mesosphereが2016年にユーザーを対象に実施した調査では、回答者の62%がすでに本番環境でコンテナを使用していることが明らかになりました。また、コンテナに特化したカンファレンスDockerConでPortworxが2017年に実施した調査では、回答者の67.2%が本番環境でコンテナを使用していました。つまり、少なくともコンテナを導入している組織にとって、ルーティングのニーズは急速に重要性を増しています。

ビジネスの自己実現における究極の目標である「成長」は、階層全体のニーズが満たされるまで、つまり「スタック」全体が自動化され、オーケストレーションされるまでは達成できません。そのため、主にN-Sデータプレーンを扱う担当者が、まず環境のスケーリング要件に対応し、次にN-SトラフィックからE-Wトラフィックへの移行が行われるルーティング要件へと、ボトムアップでオーケストレーションを進めるのは当然といえます。これは、Kubernetesなどのコンテナオーケストレーターを中心に、より密接に連携するエコシステムの開発が継続していることからも明らかです。比較的最近の開発では、レイヤー7（URI／API）でルーティングするIngress Controllerを導入し、N-SトラフィックからE-Wサービスへの移行をシームレスに行えるようにするという「ルーティング」要件に重点が置かれています。このコンポーネントも最終的には統合（自動化）し、ルーティング要件を満たす必要があります。これにより、組織は階層をさらに上へ進み、成長を実現できます。

これをコンテナ固有の構成要素に置き換えることで、成長の実現に必要なコンテナ環境のスケーリングを支えるネットワークサービスと、その環境の自動化ニーズを対応付けることができます。コンテナとネットワーク／アプリケーションサービスの構成要素は、いずれも自動化が必要です。アプリケーションをスケールするために100個のコンテナを作成しても、デリバリー時にそれらを管理するサービスを同時に自動化しなければ、ニーズを満たすことはできません。こうしたネットワーク構成要素には、コンテナネイティブな構成要素を使用することも、既存のアプリケーションサービスをコンテナ環境にネイティブに適合するよう調整して使用することもできます。実装の詳細はアーキテクチャと運用要件によって異なりますが、成功を実現するには、基本的なニーズ（スケール）と成長のニーズ（ルーティング）を満たす両方の構成要素が必要です。

いずれの場合も、コンテナとクラウドの成功は、そのエコシステムに大きく依存します。つまり、デジタルトランスフォーメーションの取り組みを通じたビジネス成長に不可欠な自動化とオーケストレーションを実現するには、Other APIエコノミーに頼る必要があります。

* コンテナの世界では、自動化とオーケストレーションの概念が混同され、一方が他方と同じ意味で使われているように見えるのが、どうにももどかしく感じます。とはいえ、今はその点には目をつぶり、細かいことにこだわる自分は本来いるべき場所に押し込めておきます。頭の中です。必死に叫んでいます。

著者について

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

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

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