コンテナとか何とか……使えばそれでクラウドネイティブじゃない？：DXに悩むITマネジャーに捧ぐ！ クラウドネイティブ講座（3）
この連載では、「クラウドネイティブ思考」を紹介してきました。 今回はより具体的な話に移りますが、技術は目的でなく手段です。これを踏まえて、コンテナをクラウドネイティブ思考の観点から見てみましょう。
DXに悩むITマネジャーにささげる！ クラウドネイティブ講座、第3回です。今回は、クラウドネイティブ思考に基づいて、既存のクラウドネイティブ技術を見ていきたいと思います。
本題に入る前に、まずは前提を再確認しましょう。クラウドネイティブ思考で大事なことは「コンピューターの力でコンピューターを動かす」「人間の関与をなくしていく」の2点です。
本連載では、この2点をしつこいほど繰り返します。なぜかというと、人には「ある特定のものを意識し始めると、自然にその対象に対する情報が入りやすくなる」という心理現象があるからです。例えば、「今日のラッキーカラーは赤です」と言われると、その一日、自然と赤に関する情報が目に付くようになります。日本では「カラーバス効果」という名前で解説されていることもあります。
これを応用すると、「コンピューターの力でコンピューターを動かす」「人間の関与をなくしていく」と普段から意識することによって、日常の業務で足りないところが自然と目に付きやすくなるのではないか。そんな期待を持ってこの記事を書いています。
クラウドネイティブ思考で見るクラウドネイティブ技術
第1回では「いったん忘れてください」と言った、CNCFによるクラウドネイティブの定義を再度見てみましょう。なお、CNCFというのは「Cloud Native Software Foundation」の略で、オープンソースのクラウドネイティブ技術の開発と推進を担っている非営利団体です。
クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。（https://github.com/cncf/toc/blob/main/DEFINITION.mdより引用。強調は筆者による）
これをクラウドネイティブ思考に当てはめると、重要なのは太字で強調している2点です。
「近代的でダイナミックな環境」とは、APIが提供されており、プログラムで動的な設定が行える環境であることを意味しています。 AWS（Amazon Web Services）やMicrosoft Azureのような有名クラウドはもちろん、自社内で運用するプライベートクラウドもこれに当たります。「スケーラブル」とは、拡大・縮小が可能なシステムであることを指しています。
この2点が組み合わさることによって、全体の文脈としては「APIを活用してプログラムから動的にシステムを拡大・縮小させられる」ことを意味します。これはまさに「コンピューターの力でコンピューターを動かす」という話であり、その実現を助けるのがクラウドネイティブ技術だと言っているわけですね。
数あるクラウドネイティブ技術と、よくある勘違い
CNCFによるクラウドネイティブの定義によると、クラウドネイティブ技術とされるものには以下のようなものがあるとされています。
このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。（https://github.com/cncf/toc/blob/main/DEFINITION.mdより引用）
CNCFが提供しているCloud Native Landscapeでは、カテゴリごとに整理されたオープンソース（OSS）プロジェクトやプロダクトの一覧を確認することができます。ここに記載されているものについては、クラウドネイティブ技術であると考えて良いでしょう。
しかし、注意しなければいけないのは、「ここに掲載されているプロダクトを採用したからといって、クラウドネイティブを実践していることにはならない」という点です。
例えば、ワークフローの一部をクラウドネイティブ技術で自動化をしたとしても、他の部分で人間の関与が多く残ってしまっていては、スループットの改善はできません。第1回で解説した制約条件理論（TOC）に当てはめて考えてみましょう。ワークフロー全体において改善を図っていかないと、単にボトルネックが移動するだけで終わってしまいます。これでは、クラウドネイティブを実践できているとは言えませんよね。
逆に、Cloud Native Landscapeに掲載されているプロダクトを利用しなくとも、コンピューターでコンピューターを動かし、全体最適を図れているのであれば、それはクラウドネイティブを実践できていると言えるでしょう。各クラウドベンダーが用意しているサービスを活用して実現することもできますし、その気になれば従来の仮想マシンを使ったアーキテクチャでも実現可能です。
単にプロダクトを導入するだけではなく、クラウドネイティブ思考をもとに全体を俯瞰（ふかん）して最適化を考えていくべきです。
クラウドネイティブ技術の代表、コンテナ
CNCFは、Cloud Native Trail Mapという、企業がクラウドネイティブを実践していくに当たっての道しるべとなる10のステップを紹介しています。このTrail Mapは、10ステップ全てを実践しないとダメというものではありませんし、順番は前後しても問題ありません。
- コンテナ化
- CI/CD
- オーケストレーション＆アプリケーション定義
- 可観測性と分析
- サービスプロキシ、ディスカバリ＆メッシュ
- ネットワーク＆ポリシー
- 分散データベース／分散ストレージ
- ストリーミング＆メッセージング
- コンテナレジストリ＆ランタイム
- ソフトウェアディストリビューション
まずは1番のコンテナ化を見てみましょう。
「Dockerを代表とするコンテナ技術を使って、アプリケーションとその実行環境をひとまとめにして動かせるようにしましょう」というのがこの項目で述べられていることです。
コンテナ技術で実現可能な利点は大きく分けると2つ。一つ目は「アプリケーションをOS内の異なる空間で実行可能にする」。これにより同一OS上で複数のアプリケーションを動かしやすくなります。通常OS内で複数のアプリケーションを動かす場合、ファイルシステムの利用やCPU、メモリの配分などで相互に影響を及ぼす可能性があります。そこで、OSの持つ名前空間分離機能を活用することで、お互いの影響を最小限にすることができます。計算機リソースそのものを仮想化して分離するVM（Virtual Machine：仮想マシン）とは異なり、言ってしまえばアプリケーションを立ち上げるパラメータを変えてしまうだけなので、極めて高速に立ち上げることができます。この特性はクラウドネイティブ思考的にも好都合です。
2つめが「アプリケーションとその実行環境をイメージにまとめられる」。通常アプリケーションを動かす際には、アプリケーション本体だけでなく各種ミドルウェアが必要となります。従来は、このアプリケーションとミドルウェアの配置作業をサーバエンジニアが行っていましたが、地味に手間がかかる作業であり、サーバが複数あればそれぞれに対して同じ作業を行う必要がありました。これを、あらかじめコンテナイメージという形でひとまとめにしておき、実行する際に展開し、先に述べた分離された空間で実行する。こうすることで、さまざまな環境で同じ構成のアプリケーションを簡単に実行できるようになりました。アプリケーションの可搬性（ポータビリティ）が格段に高まったのです。
物流の革命から考える、ITのコンテナ化
ところで、「コンテナ化」という単語ですが、これを英語でいうと「Containerization（コンテナリゼーション）」となります。では、「コンテナリゼーション」を検索エンジンで調べてみてください。Dockerではなく、港でよく見かける四角い輸送用コンテナが積み上げられている写真がたくさん出てくると思います。
もともとコンテナリゼーションとは、物流業界で使われる単語でした。いまでは世界的に使われている、あの輸送用コンテナを共通規格として普及させていく。これをコンテナリゼーションと呼んでいます。実現したのは比較的最近で、1960年代のことです。
コンテナリゼーション以前は、特に決まった梱包は行わない、ばら積みと呼ばれる形態が一般的でした。港では、港湾労働者たちが荷物を船に積み込み、運ばれた先ではまた別の労働者が荷物を運び出す。そうして運び出された荷物は個別に分類され、配送先に運ばれるという流れになっていました。
これはとても効率の悪いやり方でした。それぞれのフェーズで多くの人間が関与している上に、荷物の追跡も難しい。安全性も低く、港での盗難は日常茶飯事だったといいます。
それでは、コンテナリゼーションによってどのようなメリットがもたらされたのでしょう。まず、工場は生産した商品をコンテナに積み込みます。コンテナは鉄道やトラックなどで港に運ばれ、そのままクレーンで船に積み込まれます。船で運ばれた後は、到着先の港で再びクレーンで下ろされ、トラックないしは電車で必要な先へ運ばれていくわけです。
輸送の過程で、コンテナの中身を開いて積み替えるという作業は一度も行われていません。トラックもバスも、港のクレーンも、船も、コンテナをコンテナのまま扱う。そうすることで、一連のプロセスの中から人の関与を減らすことができ、時間の削減や盗難・破損のリスクを大きく下げることが可能となるのです。また、コンテナの中身が何であろうとも同じ方法で輸送ができるので、荷物ごとの特別な対処がいらない。これもコストを下げられる大きな要因となります。
この仕組みを実現するのに一番重要な要素は何でしょう？ それは、コンテナの仕様が規格として標準化されていること、そしてコンテナを扱うシステム（今回のケースではトラック、鉄道、船、クレーン）がその標準規格に対応していることです。コンテナだけを見てしまうと、それはただの金属の箱でしかありません。しかし、システム全体が規格化されたコンテナに対応することで、物流に革命を起こす存在となったのです。
クラウドネイティブにおけるコンテナも、目指している先はまさにこれなのです。コンテナをリードしたプロダクトの名前がDocker（英語で港湾労働者）であることや、Kubernetes（ギリシャ語で操舵（そうだ）手や水先案内人）をはじめとしたコンテナ関連プロダクトが海運に関連する名称なのも、物流のコンテナリゼーションを意識しているからなのです。
コンテナを利用したアプリケーション開発の流れ
コンテナを活用した開発の流れはこうです。まずアプリケーション開発者は、工場で商品をコンテナに詰めるかのごとく、開発したアプリケーションのコンテナイメージを作成します。そしてそれを出荷するわけですが、コンテナイメージをレジストリという保存先にアップロード（プッシュ）する形で行います。
サーバでは、レジストリからコンテナイメージをダウンロード（プル）し、コンテナ実行環境で実行します。動かす先のサーバにアプリケーションごとの実行環境を用意する必要はありません。必要なのは、コンテナを動かす実行環境のみです。
開発側でコンテナイメージの作成が終わっていれば、そこから先の操作はどんな言語で開発されていても同じ操作で運用が行えます。まさに、物流のコンテナリゼーションと同じメリットが得られるわけです。
コンテナイメージおよび実行環境に関する仕様はOCI（Open Container Initiative）によって標準化されています。ですので、この仕様に対応しているシステムであれば、どのベンダーであってもそのまま実行が可能です。
その利便性の良さから、いまでは多くのシステムがこのOCI準拠のコンテナを動かせるようになっています。コンテナ対応を明示的に謳（うた）っているシステムはもちろん、そうでないシステムやサービスにおいても、裏側ではコンテナが使われているというのが一般的になりつつあります。
前半にも述べたように、コンテナを使わなくともクラウドネイティブの実践は可能です。コンテナでなければクラウドネイティブではないと言うつもりはありません。しかしながら、コンテナ技術がクラウドネイティブ思考、すなわちコンピューターでコンピューターを動かし、人の関与を減らしていく仕組み作りに適した特性を備えているのも、また事実です。今後多くのシステムがOCI準拠のコンテナを明示的、もしくは暗黙的に利用することを考えると、ぜひとも押さえておきたい技術であると言えるでしょう。
特集：マネージャーこそ知りたい「クラウドネイティブ」大注目のワケ
人々とビジネスをつなげる「アプリケーション」は企業価値の源泉といっても過言ではない。ITを通じたビジネス提供が常識となる中で、 なぜ「クラウドネイティブ」は注目されているのか。本特集は“マネージャーこそ知りたい”と題し、クラウドネイティブの基本と本質に立ち返る。
Copyright © ITmedia, Inc. All Rights Reserved.