クラウドが一般化した昨今では、クラウドの利用を最大限に活かす「クラウドネイティブ」が主流になりつつあります。その一方で、その定義や詳細な内容について知らないという方も少なくないのではないでしょうか。今回はクラウドネイティブの定義やクラウドファーストやオンプレミスとの違い、技術的な構成要素、メリットを詳しく解説します。
目次
クラウドネイティブとは
クラウドネイティブとはプラットフォームからその上で動作するアプリケーションに至るまで、クラウド利用を前提としたシステムのことです。クラウドネイティブのシステムはクラウド向けに最適化され、クラウドのメリットを最大限活用することが求められます。部分的にクラウドを利用したとしても、クラウドネイティブとは呼ばれません。
クラウドファーストとの違い
クラウドネイティブと比較されることが多い概念として、「クラウドファースト」があげられます。「クラウドファースト」とは、システムを構築する際にクラウドの利用を「最優先する」という考え方です。
クラウドネイティブが登場する以前から、クラウドファーストの概念は存在していました。クラウドを利用するメリットが広く知られるようになり、クラウドファーストという考え方も普及したのです。
クラウドネイティブは、クラウドファーストをさらに一歩進めた概念です。クラウド利用を「最優先」しただけでは、クラウドネイティブとは言えません。クラウドファーストでは、運用上の都合によって非クラウドのサービスが利用されることもあるためです。
クラウドネイティブではプラットフォームだけにとどまらず、その上で実行されるアプリケーションも含め全てクラウド向けに最適化されます。最初の設計から利用まで徹頭徹尾クラウド利用を前提としたシステムがクラウドネイティブなのです。
オンプレミスとの違い
「オンプレミス」とはサーバーやソフトウェア等を運用するための機器を、自社が所有・管理する施設内に設置し運用する方法を指します。オンプレミス自体はITがビジネスで利用されるようになった当初から一般的な運用方法でした。自社ビル内だけでなく、契約したデータセンター内にサーバー機器を設置して運用する方法もオンプレミスと呼びます。
しかし従来はそもそもオンプレミス以外の選択肢がなかったので、この方法をオンプレミスと呼ぶこともありませんでした。自社でサーバー機器を運用する必要がないクラウドが登場してから、クラウドと区別するためオンプレミスという言葉が生まれたのです。
オンプレミスでは、サーバーをはじめとしたIT機器や回線、さらにはIT機器を設置する場所の確保も必要となります。機器や回線の購入等で初期費用が必要ですし、これらを継続利用・運用するための固定費もかかります。
一方、クラウド利用が前提であるクラウドネイティブでは、これら初期費用や固定費が一切必要とされません。オンプレミスでは機器・回線・場所等を確保しないと運用できませんが、クラウドネイティブではそれら全てが用意されています。サービスを申し込めばすぐに利用できる上に、必要に応じて途中でスペックを変更することも可能です。
クラウドネイティブの構築段階の違い
まずオンプレミスでは、システム構築にあたりサーバー機器や回線等を自社で準備することになります。そのため将来の利用状況も推測して、必要十分なスペックを確保しておかないといけません。サーバー機器や回線の保守運用も、自社で行うことが必要です。一方、それらの確保さえできれば自由にシステム設定できることから、業務のニーズが変動的な場合は適しています。
次にクラウドファーストでの構築では、クラウドのプラットフォームを利用することから、機器や回線の確保や運用が必要ありません。ただし、それらを自由に選べるオンプレミスと比べれば、使える機能が限定されるとは言えます。その点、クラウドネイティブであれば後述するコンテナ等の採用によって、クラウドファーストより柔軟なシステム構築が可能です。
クラウドネイティブを構成する主な技術的要素
クラウドネイティブのシステムでは、オンプレミスはもちろんのことクラウドファーストとも異なる技術が利用されます。クラウドネイティブについて理解するためには、クラウドネイティブを構成する技術的な要素を把握する必要があります。
以下、クラウドネイティブで実際にどのような技術が使われるか、代表的な要素を1つずつ紹介します。
アプリケーションの柔軟な運用を可能にする「マイクロサービス」
「マイクロサービス」とは、アプリケーションを機能ごとの小さな単位（サービス）に分割し、各サービスを個別で開発・運用する考え方です。大規模なアプリケーションでもマイクロサービスを採用することで、サービス単位で開発できるためリリースや改修がスピーディになります。特定のサービスの不具合や改修が、他のサービスに影響しにくいというメリットもあります。
仮想サーバーより少ないスペックで動作する「コンテナ」
「コンテナ」とはコンピューター仮想化の1つで、ホストとなるOS上に隔離された仮想的なアプリケーションの実行環境を作る技術を指します。IT資源を効率的に活用する技術という点では、クラウドファーストでも使われる「仮想サーバー」と同じです。
一方でコンテナは仮想サーバーより少ないスペックで実行できます。仮想サーバーでは、ホストOS上で、仮想サーバーごとに1つずつ仮想OSを動作させなくてはなりません。それだけハードウェアのスペックが消費されます。
コンテナの場合、仮想OSなしでアプリケーションの実行環境を用意可能です。その分、仮想サーバーより消費されるスペックが少ないため、仮想サーバーと比べ起動が速くなります。また同じスペックのハードウェア上なら、仮想サーバーより多くのコンテナを同時に動作させられるというメリットもあります。
前述のマイクロサービスを実現するためには、多数のサービスを運用しても消費スペックを軽減できるコンテナの活用が必要です。
複雑なサービス間の通信を制御する「サービスメッシュ」
クラウドネイティブの環境では、前述のマイクロサービスをもとに、様々なサービスが複雑に連携して機能します。「サービスメッシュ」は、これらサービス間の通信を制御するための機能です。
より具体的には、サービス間の通信を全て専用プロキシ経由で行うようにすることで通信を制御します。サービスメッシュにより負荷分散やトラフィック最適化、安全な通信が実現されます。
本番環境の運用をシンプル化する「イミューダブル・インフラストラクチャー」
同じ環境を使い続ける場合、必要に応じて更新やパッチの適用を行わなくてはなりません。しかし更新やパッチ適用により問題が発生すると、問題切り分けのために多くの時間が費やされることになります。更新やバッチ適用のたびにシステムが複雑化し、運用の負担も増えてしまいます。
「イミュータブル・インフラストラクチャー」は、これら課題を解決する考え方です。具体的には、更新やバッチ適用が必要な場合、すでにそれらが適用済の本番環境を利用します。そうして、新しい環境に問題ないことを確認した上で、旧環境との切り替えを行うわけです。仮に新しい環境に問題が起きても、旧環境に切り戻しさえすればすぐにサービスを再開できます。
つまりイミューダブル・インフラストラクチャーなら一度構築した本番環境を、その後に手を加えず使い続けられるのです。これにより問題が発生した際の負担を軽減したり、システムの複雑化を予防したりできます。
アプリケーションの自律的な動作を促す「宣言型API」
マイクロサービスにおいて、サービス同士の連携はAPIを通じて行われます。APIには「命令型」「宣言型」の2種類があります。
「命令型」とは、アプリケーションに実行させたい処理を具体的に指示するタイプです。複数の命令を組み合わせることによって、「こうして欲しい」という結果をえることができます。
一方で「宣言型（宣言型API）」は、クラウドネイティブで使われるタイプです。宣言型では「こうして欲しい」という内容のみを登録しておき、実際の処理内容はアプリケーションに任せます。仮に指定した状況にならない場合、アプリケーション側が自律的に指定の状況を実現しようと動作します。
その結果、宣言型APIでは複雑な命令をする必要がなくなるわけです。アプリケーションが自律的に動作するので、常に監視をする必要もなくなります。
クラウドネイティブの考えが必要な理由・メリット
クラウドの利用が一般化した昨今では、オンプレミスやクラウドファーストでなく、クラウドネイティブが主流となりつつあります。それではクラウドネイティブにはどのようなメリットがあり、どうして必要とされるのでしょうか。
以下、その主な理由やメリットを解説します。
コスト削減につながる
オンプレミスの場合、サーバー機器を購入するために膨大な初期費用が必要です。一方でクラウドネイティブなら、それらはサービス側で準備しているため、購入の必要がなくコストを削減できます。また仮想サーバーよりコストが安いコンテナを使える点も、クラウドネイティブによりコスト削減が実現できる理由です。
開発や運用がスムーズになる
サーバー機器を管理する必要がないことからオンプレミスと比べ開発や運用をスムーズにすすめることができます。仮にハードウェア的な障害が発生した場合でもクラウドのサービス提供側で対処するため、自社の人員を割いて対処する必要がありません。
またマイクロサービスやコンテナ等の活用により、仮想サーバーを利用するのに比べ開発を柔軟にすすめられる上、作業時間を短くできます。
環境や状況に応じて柔軟な拡張が可能
ビジネス環境は移り変わりが激しく、アプリケーションに求められる機能やスペックも日々変化します。しかし拡張のたびに新しいサーバー機器を確保しようとすると、それだけで時間がかかって要求の変化に対応できません。
その点、クラウドを利用すれば拡張の際にもサーバー機器を自社で準備する必要がありません。その分、状況に応じてスピーディに拡張ができるようになります。またコンテナやマイクロサービスといったクラウドネイティブの技術を活用することにより、仮想サーバーより柔軟な対応が可能になります。
アプリケーションの動作を保証できる
自社でアプリケーションを開発しても、どのクラウドでも正しく動作するとは限りません。場合によっては目的のクラウドで動作せず、開発時間が無駄になることもありえます。
一方、クラウドネイティブを前提に開発をすすめれば、基本的にどのクラウドでも正常に機能するアプリケーションを構築できます。結果、クラウドネイティブを採用することにより、クラウド上におけるアプリケーションの動作を保証できるわけです。
クラウドネイティブまでの5ステップ
これまでクラウドネイティブの概要や技術、メリットをみてきました。それでは自社でクラウドネイティブを実現するためには、どのような対応が必要になるでしょうか。ここでは主な対応を5つのステップに分けて紹介します。
STEP1.オンプレミス環境の仮想化
クラウドネイティブの実現にあたり、まずはオンプレミス環境を仮想化しクラウドへ移行しやすくします。そのためには、物理サーバーとシステムを切り離してこれらのライフサイクルを分離させることが必要です。
STEP2.クラウドの評価・体験
オンプレミスの環境のなかから、仮に問題が発生しても影響が少ないシステムからクラウド移行を開始します。スモールスタートをすることでノウハウの蓄積をはかることができる上、クラウド移行への課題も明確になります。
STEP3.クラウドの活用
次にクラウドのメリットを特に受けやすいシステムに関して、クラウド移行を開始します。これによって大幅なコスト削減を実現できる上に、その他のシステムもクラウドへ移行しやすくなります。このときクラウド移行で発生するラグを許容できるか、ハードウェアの保守期限が迫っているかも、優先度を決める際の基準にするとよいでしょう。
STEP4.運用基盤への変革
クラウド移行をすすめるため、クラウドの利用を前提とした運用の効率化や管理スキーム確立を目指します。これによって、さらなるコスト削減もはかります。
STEP5.クラウドネイティブ化
クラウドファーストから、クラウドネイティブへ至るステップです。これまでのステップで得た経験に基づき、クラウド利用を前提としたシステムを構築しクラウドネイティブ化をすすめます。
まとめ
クラウドネイティブは、徹頭徹尾クラウド利用を前提として構築されたシステムのことです。クラウド利用を最優先するクラウドファーストの考え方は従来から存在していますが、クラウドネイティブではその考えを一歩先へすすめています。クラウドネイティブでは、クラウドの利点を最大限活用することを目指します。
クラウドネイティブを実現するためには、コンテナやマイクロサービス、サービスメッシュといった新しい技術が必要です。これらの技術を活用することで、オンプレミスやクラウドファーストと比較しても低コストで柔軟なシステムの開発や利用が可能となります。
KAGOYA FLEX
カゴヤ・ジャパンは、自社国内データセンターを基盤に、月額4,400円の低価格からクラウド導入を強力サポート。
VMware ベースの仮想サーバーと物理サーバーの組み合わせで最適なコストバランスをご提案いたします。
回線引き込みや、ライセンスの持ち込みなど柔軟な対応も可能です。
