「クラウドネイティブ」とはなにか――「クラウドファースト」となにが違うのか？ | 東京エレクトロンデバイス

クラウドファーストの利点とは？

クラウドの普及が本格化し始めた数年前に、「クラウドファースト」という言葉は登場してきました。これはシステムを構築する際、「クラウドで動かすことを優先して検討する」という意味を指しています。

例えばオンプレミスでシステムを構築する場合、システムが稼働してからサーバーの性能を増大させたり、ストレージを高速化させたりすることは難しいため、キャパシティプランニングとしてシステムに必要な処理能力をあらかじめ予想し、その能力をある程度上回るサーバーやストレージを最初から用意する必要があります。そのうえでハードウェアを調達して構築するといったコストと手間が構築時に必要となります。

一方のクラウドは、システムが稼働したあとでも、インスタンスの能力を増やしたり、ストレージを追加したりといったことが比較的柔軟に行えます。そのため、比較的小さめのインスタンスやストレージを調達してクラウド上でシステムを稼働させたあとで、性能が必要になる場面で適切な大きさのインスタンスや高性能なストレージへ切り替えればよい、ということになります。

これにより綿密なキャパシティプランニングに時間をかけることなく、ハードウェアの調達も不要なため、迅速かつ低コストにスタートができ、万が一システムが不要になっても、ハードウェアの減価償却を待つことなく、すぐにシステムを破棄できるといったことが可能になるわけです。 以上が、一般的にクラウドファーストによる利点とされています。

クラウドネイティブの定義とは？

昨年頃から、クラウドファーストよりも「クラウドの利点を徹底的に活用するシステム」といった意味で使われ始めた言葉が「クラウドネイティブ」です。クラウドネイティブは基盤にクラウドを使うのは当然として、そのうえで実行されるアプリケーションにまで踏み込んで、クラウドに最適化することを指しています。

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミューダブルインフラストラクチャ、および宣言型APIがあります。 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

やや抽象的な表現ですが、クラウドネイティブでは仮想マシンではなく、より粒度の細かなコンテナをベースとします。それにより、よりスケーラブルで柔軟なアプリケーションが構築でき、クラウドファーストよりもさらに踏み込んだクラウドのメリットが得られるというわけです。そのうえで、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、宣言型APIなどのテクノロジーを用いると、より効率的にクラウドネイティブなシステムが構築できることが示されています。

もちろんクラウドネイティブという言葉は、さまざまな組織や団体、個人が場面に応じて、さまざまな意味で使っています。CNCFの定義はその1つでしかありませんが、概ねITエンジニアによる狭い意味でのクラウドネイティブの定義として、コンセンサスがとれつつある定義だと思います。

クラウドネイティブを構成する技術群

クラウドネイティブの定義には、「マイクロサービス」「サービスメッシュ」「宣言型API」「イミュータブルインフラストラクチャ」などの用語が登場します。

マイクロサービスとはシステムを細かい「サービス」に分解し、それぞれのサービスを連携させることでシステムを機能させるというものです。サービスに分解することで、サービスごとに負荷分散やスケーラビリティを持たせることができ、機能追加や機能変更も可能になり、万が一、あるサービスに障害が発生しても、その影響を局所的に抑えることができるといったことが可能になります。

それぞれのサービスはそれぞれのコンテナに割り当てられ、その上で稼働します。あるサービスへの負荷が高まれば、そのサービスのコンテナの数を増やします。こうした複数のコンテナを1つのシステムとして管理する仕組みがコンテナオーケストレーションツールとしてのKubernetesであり、コンテナ間の通信などを管理する仕組みがサービスメッシュであるIstioの役割です。

そして、コンテナ間の連携はサービスが公開しているAPIを介して行われるため、APIの定義を宣言するとAPIが生成される「宣言型のAPI」が用いられることになるわけです。

イミュータブルインフラストラクチャとは、直訳すると不変なインフラという意味です。これを手短に説明すると、OSなどのインフラにパッチを適用するといった変更が必要な場合、変更作業を実行するのではなく、変更後のOSを用いた環境を新たに立ち上げ、古い環境は捨てるということであり、アプリケーションにとってインフラは起動時から終了時まで常に固定されている、不変であるということを指しています。

こうした柔軟なリソースの確保や破棄が可能なのは、クラウドが持つ柔軟性だからこそであり、イミュータブルインフラストラクチャとは事実上、こうした柔軟なリソース確保が可能なクラウドのことを指すのです。

クラウドネイティブにおける開発プロセスや組織にも変化

さて、マイクロサービスをアーキテクチャとして採用し、イミュータブルインフラストラクチャであるクラウドを基盤に、KubernetesやIstioを活用してアプリケーションを実現したら、それが“クラウドネイティブの実現”であるかというと、クラウドネイティブにはもう少し続きがあります。

例えば複数のサービスから構成される複雑なアプリケーションのビルドやデプロイは、手作業でやるのではなく自動化させたいところです。となると、継続的統合と継続的デリバリ（CI/CD）のパイプラインを構築することになるでしょう。それにはJenkinsやCircleCI、SpinnakerといったCI/CDの自動化ツールが用いられますし、ソースコードの管理もGitHubなどを使うことになるはずです。

そして、こうしたクラウドネイティブなツールを使いこなせるチームは、自ずとアジャイル開発手法やDevOpsといった、より柔軟な開発および運用のスタイルを採用することになるのではないでしょうか。

クラウドネイティブのハードルは非常に高い

クラウドネイティブとはどのようなものか、その概要をざっと説明してきました。こうしてみると、クラウドファーストに対してクラウドネイティブの実現は極めてハードルが高いものと言えるでしょう。

アプリケーションのアーキテクチャをマイクロサービス化し、コンテナやKubernetesなどを取り入れ、さらに開発プロセスに自動化を取り入れ、そうした開発に親和性のあるような開発組織と文化を作っていくという、組織からプロセス、設計、実装という、非常に幅広い領域に影響するのです。

逆に言えば、クラウドのメリットを徹底的に取り入れようとすると、これだけ大きな変化が求められるということでもあり、これが実現できる組織とそうでない組織では、（もちろんクラウドのメリットを得る手段としてクラウドネイティブがすべてではないものの）得られるメリットにおいて大きな差が出てくるということでもあります。

つまり、クラウドネイティブの実現は企業の情報部門だけに任せられる課題ではなく、企業文化そのものに対する課題も含まれており、その実現には経営陣のコミットメントなしに容易には成し得ないと言えるでしょう。

※本記事は東京エレクトロンデバイスが提供する不定期連載のタイアップコラムです。
※会社名および商標名は、それぞれの会社の商標あるいは登録商標です。