基礎知識
クラウドネイティブとは？ クラウドファーストとの違いやポイントを解説
昨今、ソフトウェア開発の現場に定着しつつある開発手法の1つが、開発担当者と運用担当者が連携する「DevOps」です。このDevOpsを推進していくうえで「クラウドネイティブ」というキーワードが登場することがあります。本記事では、クラウドネイティブの考え方や構成する技術要素などを解説します。
クラウドネイティブとは
クラウドネイティブと似た言葉に「クラウドファースト」や「クラウド・バイ・デフォルト」があります。クラウドファーストは「システム構築を行う際にクラウドの利用を優先する」という考え方のことです。また、クラウド・バイ・デフォルトは、そこからさらに一歩進んで「システム構築を行う際には、クラウドの利用を第1候補（デフォルト）とする」という考え方のことです。多少の差異はあるものの、これらはどちらもシステムを構築するプラットフォームには優先的にクラウドを検討するという点において、同じ考えだと言えるでしょう。
これに対して、「クラウドネイティブ」は「クラウドの利点を徹底的に活用するシステム」といった意味を持つ言葉です。オンプレミスのシステムをそのままクラウド上に移行しただけでは、クラウドネイティブとは呼べません。クラウドネイティブとは、単にプラットフォームにクラウドを採用したシステムのことではなく、最初からクラウド上で動くことを前提にクラウドならではの特性を活かせるよう設計されたシステムのことです。
クラウドネイティブなシステムのベースには、従来の仮想サーバーに代わってより粒度の細かい「コンテナ」が採用されています。コンテナの採用により、仮想サーバーに比べてよりスケーラブルで柔軟なアプリケーションの構築が可能になっています。また、「マイクロサービス」「サービスメッシュ」「宣言型API」「イミュータブルインフラストラクチャー」といったテクノロジーを用いることにより、より効率的にクラウドネイティブなシステムが構築できるとされています。詳細は、CNCFCloud Native Computing Foundationによるクラウドネイティブの定義を参照してください。
クラウドネイティブで代表される技術要素
クラウドネイティブは、以下に挙げた技術要素が代表例として挙げられています。
マイクロサービス
1つのアプリケーションを機能ごとに細かい「サービス」に分割し、それぞれのサービスを連携させることでシステムを動かすという考え方を「マイクロサービス」と呼びます。
従来のモノリシック（一枚岩）なアプリケーションは、概して大きく複雑になりがちです。大きく複雑なアプリケーションは機能追加やテストがしづらく、またリリースにかかるコストも大きくなることから、高速な開発サイクルの足を引っ張りがちでした。しかし、アプリケーションを小さなサービスという単位に分割することで、各サービスごとの開発・テスト・リリースが行いやすくなります。機能の追加やリリースがサービス単位で可能になるため、万が一、あるサービスに障害が発生してもその影響を局所的に抑えられるというメリットもあります。さらにサービスごとに負荷分散やスケーラビリティを持たせることもできるため、リソースの最適化や可用性の向上も実現しやすくなります。
アプリケーションをマイクロサービスとしてホストするために必要不可欠な技術が「コンテナ」です。コンテナは、従来の仮想サーバーと同様にマイクロサービスを構成する個々のサービスの実行環境として機能します。コンテナは、1つのOS上で実行されるプロセスを独立した空間に隔離する技術です。そのため、仮想マシンを利用してサービスごとに独立したOSを起動する場合と比較して、CPUやメモリといったリソースのオーバーヘッドを抑えられるというメリットがあります。
本番環境では可用性を向上させるため、コンテナは複数のホストで構成される「クラスター」の上で稼動させるのが一般的です。この場合、クラスターを構成するホストの管理・コンテナ間のネットワーク接続・サービスの動作状況の確認といった仕組みが必要になります。こうしたコンテナの管理を効率よく行うためのツールが「コンテナオーケストレーションツール」です。現在、デファクトスタンダードとなっているオーケストレーションツールが「Kubernetes」です。
サービスメッシュ
複数の小さなサービスが連携して機能するマイクロサービスには、前述のようなさまざまなメリットがあります。しかし、その反面でサービス間の通信が複雑になるといったデメリットも存在します。
この問題を解決するために利用されるのが「サービスメッシュ」です。サービスメッシュは、サービス間の通信などを管理する仕組みで負荷分散や通信トラフィックの最適化、安全な通信を実現するためのセキュア化といった機能を提供するソフトウェアです。サービスメッシュの代表的な実装に「Istio」があります。
宣言型API
マイクロサービスを構成するサービス同士の連携は、サービスが公開しているAPIを介して行われるのが原則です。特長的なのは、ここで「宣言型のAPI」を用いる点です。宣言型のAPIとは、サービスに実行すべき命令を伝えるのではなく、サービスのあるべき状態を指示できるAPIです。
「宣言型」と対になる概念に「命令型」があります。これはアプリケーションに対し、「具体的に実行させたいコマンド」を「命令」することで順次実行させる方法です。命令型では、コマンドを実行した結果としてアプリケーションはあるべき状態に到達しますが、コマンドの実行が失敗するなどの理由により、意図した結果が必ず得られるとは限りません。
これに対して、「最終的にどういう結果が得られるべきか」を「宣言」する形でアプリケーションを動作させることを「宣言型」と呼びます。例えば、宣言型の構成管理を採用しているKubernetesでは、ユーザーが「コンテナは3つ起動されていること」という宣言を行えば、その宣言に従ってKubernetesが3つのコンテナを起動します。また、何らかの理由でコンテナの数が増減した場合は、Kubernetesが宣言に従ってコンテナの削除や追加起動を行い、過不足分を自律的に調整してくれます。
Kubernetesが仮に命令型のシステムであったら、ユーザーは常にコンテナの数を監視し、コンテナが不足した場合は起動するコマンドをコンテナが過剰の場合は削除するコマンドを実行しなくてはならないでしょう。しかし、宣言型のシステムであれば、システムが宣言に従って自律的に動作するため、ユーザーが状況を判断して、都度命令を実行する必要はありません。
イミュータブルインフラストラクチャー
Immutable（イミュータブル）とは、「不変」を意味する英単語です。つまり、Immutable Infrastructure（イミュータブルインフラストラクチャー）とは、直訳すると「不変なインフラ」ということになります。
長期間システムの運用を継続していると、サーバーのOSにセキュリティパッチを当てたり、設定を変更したりといった作業を行う必要が出てきます。従来であれば、運用中のサーバーに対して、OSのアップデートや設定の変更を行い、必要に応じて再起動などをするのが一般的でした。これは言いかえると、OSなどのインフラは「状態」を持っており、アップデートなどの管理作業によって都度状態が変化していくのが当たり前でした。
イミュータブルインフラストラクチャーが従来のインフラと決定的に異なるのは、インフラが「状態を持たない」という点です。インフラには、起動した状態から一切の変化を加えないのが原則でOSのアップデートや設定変更などが必要になった場合は、運用中のインフラに変更を加えるのではなく、変更が適用済みのOSを用いたインフラを新規に立ち上げ、本番環境の切り替えを行った後に古いインフラを破棄するという運用を行います。
イミュータブルではない従来のインフラでは、アプリケーションの動作に影響が出る可能性が否定できないため、OSのアップデートや設定変更といった作業が気軽に行えず、結果としてセキュリティ上の問題が放置されたり、古いバージョンのミドルウェアが利用し続けられてしまうことがありました。しかし、インフラの状態を不変とすることで、こうした問題を回避できるのです。
クラウドネイティブが求められる理由
クラウドネイティブが求められている背景には、ビジネスにおける昨今の要求が変化が挙げられます。顧客のニーズを素早くキャッチアップし、迅速にリリースすることが求められている現代において、その要求に応えられるような手法が必要とされているのです。こうした要求を満たすのが、開発手法としての「アジャイル（迅速な開発）」や「DevOps」であり、インフラとしての「クラウドネイティブ」だと言えるでしょう。
クラウドには、オンデマンドなリソース確保による柔軟なスケールアップやスケールアウトが可能というメリットがあります。従来のアプリを単にオンプレミスからクラウドに移植するだけでも、ある程度のメリットは享受できます。しかし、それだけではクラウドならではのメリットを最大限に活かせるとは言えません。クラウドのメリットを最大限に活かすためには、オンプレミスに代表されるシステムに対する考え方や従来の開発手法から根本的に脱却し、クラウドを前提とした開発体制を整える必要があるのです。
まとめ
クラウドネイティブは、クラウド環境における従来のアプリケーション開発の延長線上にある考え方です。技術面で言えばアプリケーションのマイクロサービス化やコンテナ・オーケストレーションツールの採用、開発プロセスの自動化など、導入すべき事柄は非常に多岐に渡ります。しかも、こうした個別の技術を単に導入すればよいというものではありません。クラウドネイティブの導入は、開発のプロセス、設計、実装という、非常に幅広い領域において、既存のやり方から脱却することを求められます。アジャイルやDevOpsと同様にこうした新しい概念を受け入れられる組織と文化から作っていくことが求められるでしょう。
言いかえると、クラウドのメリットを最大限に活かすためには、組織全体に対してこうした大きな変化が求められるということでもあります。従来のしかも上手く動いていたプロセスを変化させることには、非常に大きな抵抗があることが予想されます。しかし、そうした変化が実現できない組織では、いざクラウドの導入に踏み切ったとしても、そのメリットを最大限に享受することは難しいでしょう。
もちろん、クラウドの活用方法はさまざまで組織ごとに事情も異なるため、クラウドネイティブが唯一の解というわけではありません。しかし、クラウドネイティブに対応できた組織とそうでない組織の間にはクラウドの活用において大きな差が出てくるのは間違いないでしょう。
クラウドネイティブを実現するためには、従来の企業文化そのものに対して抱えている課題も解決しなければなりません。これは企業の情報部門だけに任せられる技術的な問題ではないため、実現のためには経営陣のコミットメントが必要不可欠です。クラウドネイティブを実現しようとする組織には、今までのやり方とはまったく異なる手法も積極的に取り入れることができるか、そうした姿勢が問われています。
