クラウドネイティブの基礎知識 ークラウドネイティブを実現するロードマップ「Cloud Native Trail Map」を読み解くために

はじめに

国内外で「クラウドネイティブ」に取り組む企業やエンジニアが増え、クラウドネイティブ関連のイベントへの参加者も活況を呈しています。一方で「クラウドネイティブとは、なんでしょうか?」という疑問を持っている方々も多くいます。さらにネイティブというと、日本では特に「ネイティブスピーカー」の略語として使われることが多く、語感としてピンとこない方もいます。

そこで本連載では、クラウドネイティブについて解説するとともに、それを支える基本的なテクノロジーやソフトウェア、そして、特にエンジニア視点として、どのように学んでいくかを紹介します。初心者向けの内容となりますので、個々のテクノロジーの詳細はThinkITをはじめ他のWebメディアや書籍を参照いただければ幸いです。

第1回目の今回は、クラウドネイティブの定義、クラウドネイティブを実現するためのロードマップとして取り上げられることも多い「Cloud Native Trail Map」を読み解くためのベースとなる、クラウドネイティブを取り巻くソフトウェアや考え方を紹介したいと思います。

クラウドネイティブとは何か

クラウドネイティブおよび、その関連語を説明するとき、ビジネス上の文脈では「デジタルトランスフォーメーション(DX)」を実現するテクノロジーとして取り上げられることもあります。DXはデジタル庁の正式発足を控え、一般メディアでも目にすることも多くなってきました。「Googleの検索エンジンでどれだけ検索されているか」というトレンドを見られる「Googleトレンド」を利用しても分かるように、DXは昨年から急増傾向にある用語です。

クラウドネイティブとDXとの関わり

では、なぜDXを説明する文脈で、クラウドネイティブの話が出てくることがあるのでしょうか。それには、まずCloud Native Computing Foundation(CNCF)による定義を見てみましょう。

素直に読んでみても、2文目と3文目は、背景となる用語を理解していないとすぐには分からないのではないでしょうか。

しかし、この定義は、とてもよくできていると考えています。なぜなら、まず、何を対象としており、組織にどのような価値をもたらすかを述べているように、テクノロジーの説明にとどまらない概念であることを示しているからです。続いて、代表的なアプローチ手法が紹介され、それを利用するとどのようなシステムが実現できるかを説明しています。つまり、クラウドネイティブを実現するとモダンなシステムを構築できるというだけでなく、組織にも影響を与えると述べているのです。

日本におけるDXの定義

一方、経済産業省ではDXを以下のように定義しています。

同じ意味ではありませんが、よく似た定義であることが分かります。

CNCFの定義では、最後にCNCFの役割を述べています。CNCFはLinux Foundationが支援するプロジェクトの1つで、2015年に創設されました。ベンダー中立の立場でクラウドネイティブテクノロジーを支えるユーザーやコミュニティのエコシステムを維持、発展をすることを支援しています。

CNCFの定義における
クラウドネイティブを支える技術群

もう少し詳細を解説していきましょう。

まず、クラウドネイティブと聞くと、パブリッククラウドでの環境を指すわけでないことが最初に書かれています。つまり、プライベートクラウドや近年導入が活発化しているハイブリッドクラウドも含む概念であるとしています。

続いて重要な概念として「スケーラブル」という単語が出てきます。拡張性が高いアプリケーションだけでなく、組織がユーザーや仕事の増大に適応できる能力が高くなるとしています。

このアプローチの代表として「コンテナ」「サービスメッシュ」「マイクロサービス」などが紹介されています。しかし「コンテナは聞いたことがあるけれど、サービスメッシュとはなんだろう?」と思った方も多いのではないでしょうか。

ここで、これらの用語について簡単に説明します。Cloud Native Trail Mapを理解するためには、これらの用語を理解する必要があります。ひとまず基礎用語として覚えておきましょう。

代表的アプローチ：コンテナ

コンテナというテクノロジーの起源は、かなり古いものです。商用UNIXなどにも搭載されていました。コンテナは単一OS上で複数の分離された空間を提供し、その分離された空間に必要とされる環境のコンポーネントや資源も少なくて済むといった特徴があります。クラウドネイティブの文脈で語られるとき、コンテナは「Docker」の登場以降で話をされることが多いです。

コンテナのフォーマットとランタイムの標準化を図るため、Open Container Project(現在のOpen Container Initiative)が発足し、Linux Foundationも、その立ち上げを支援しました。そこで、定義された仕様が、次の2つです。

• コンテナーランタイムに関する仕様(Open Container Initiative Runtime Specification)
• コンテナーイメージフォーマットに関する仕様(Open Container Initiative Image Format Specification)

Docker社は、Dockerのコンテナ管理機能を分離してCNCFに寄贈し、CNCFはそのコードをまとめて2018年に「containerd」として公開しました。そのため、Dockerは標準ではcontainerdを利用して動作するようになっています。その他のランタイムとしては他にCRI-Oやrktなどがあります。

代表的アプローチ：マイクロサービスとサービスメッシュ

アプリケーション(サービス)を複数の小規模のプログラムに分割して、開発・運用できるようにする手法をマイクロサービスと呼びます。マイクロサービスでは多数のサービスを独立して動作させますが、多くのメリットがある一方で「どのように負荷分散や通信の回復性などを行うか」といった複雑なサービス間通信の効率的な管理に課題があります。

また、マイクロサービス間の通信で利用されるソリューションの1つをサービスメッシュと呼びます。代表的なソフトウェアとして「Istio」があります。Istioはオープンソースの分散型サービスメッシュで、高度なルーティング機能を提供し、クラスター外からのトラフィックの管理・監視など、より高度な機能が提供されています。Istioは環境非依存で、複数のプラットフォームで利用可能です。

代表的アプローチ：イミュータブルインフラストラクチャ

「イミュータブルインフラストラクチャ」(Immutable Infrastructure)は、「Immutable」(不変)という言葉が示すように、いったんサーバー環境を作ったら、そのサーバー環境を構成するソフトウェアに変更を加えずに稼働させることを意味します。

この説明だけだと分かりにくいのですが、サーバーを構成する要素には、かなりの頻度でパッチやコンフグレーションの変更などが発生します。そのとき、パッチを当てたらアプリケーションがおかしくなってしまったという経験をした方や話を聞いた方も多い思います。私自身もアプリケーションをバージョンアップしたらOSのかなり低いレイヤーに影響し、システムクラッシュが発生したこともあります。このようなことを避けるためも、多くの環境でサーバーのソフトウェア構成を固定した上で運用しているのではないでしょうか。

しかし、古い環境で長年システムを運用していると“つぎはぎ”だらけになってしまいがちです。ドキュメントもない中で何とか運用しているという環境もあるかもしれません。そこで、サーバー構築後は変更を加えないインフラ環境を提供し、修正やアップデートが必要な際は古い環境を破棄して、新しく環境を構築し直せば良いという考え方が生まれました。これがイミュータブルインフラストラクチャです。

イミュータブルインフラストラクチャの実現は容易ではありません。しかし、コンテナを活用することで、アプリケーションを稼働させる環境の構築から廃棄にいたるまで、作業の負担を大きく削減できるようになりました。

代表的アプローチ：宣言型API

「宣言型API」(Declarative API)の説明に入る前に、「宣言型」について解説します。

ITにおける宣言型は「命令型」と対比される概念です。例えば、スーパーのレジに並ぼうとするとき、待っている人が少ない列を見つけたら、その列まで歩いて行き、並んで、会計をすると思います。このとき「見る」「歩く」「並ぶ」「会計する」ということを自分に「命令」します。これが命令型です。

この命令型に対し「スーパーで会計する」という結果を指示する方法が宣言型です。つまり宣言型APIとは、APIを通じて「何を達成したいか」をシステムに宣言するだけで、あとはシステムが実行してくれることを指します。

おわりに

今回は、クラウドネイティブの定義、クラウドネイティブを実現するためのロードマップとなるCloud Native Trail Mapを読み解くためのベースとなる、クラウドネイティブを取り巻くソフトウェアや考え方を紹介しました。これで、Cloud Native Trail Mapを理解するための準備が整いました。

次回は、今回解説した内容を元に、Cloud Native Trail Mapの詳細を紐解いていきます。