クラウドネイティブとは？導入するメリットと開発技術を詳しく解説

こんにちは。Wakka Inc.のWebディレクターの安藤です。
クラウドネイティブという言葉をよく聞くようになりました。IT業界の新しいトレンドになりつつあるようです。
しかし、言葉自体はよく耳にしても、「クラウドに関連するのはわかるが、具体的な意味はよくわかっていない」「導入するとどのようなメリットがあるのかを詳しく知りたい」といった方も多いのではないでしょうか。
本記事では、

• クラウドネイティブの意味
• 導入することで得られるメリット
• 具体的な技術の内容

について詳しく解説します。クラウドネイティブについて深く理解し、導入のきっかけにできるよう、ぜひとも本記事をお役立てください。

開発リソース不足にお悩みがある方はラボ型開発がおすすめ。
最適なプロジェクト体制で優秀な人材を低コストで確保できます。ラボ型開発に興味がある方は「【保存版】成長企業が導入するWakkaのラボ型開発」に詳しいサービス内容を掲載しているのでご覧ください。

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

クラウドネイティブという言葉は専門機関により定義されていますが、専門用語が多く難解に感じる方が多いかもしれません。
またクラウドネイティブと意味が似ている言葉も数多く存在しています。そこでこの章では、

• クラウドネイティブの定義
• 類似する他の用語との違い

について詳しく解説します。

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

クラウドネイティブとは、単にシステムをクラウド環境で構築するだけではなく、クラウドの利点を徹底的に活用することを意味しています。
言葉の意味は人それぞれ理解や解釈が異なる部分があるため、この定義が絶対ではありません。また、クラウドサービスの成熟と共に、言葉のとらえ方が少しずつ変化してきている面もあります。
2015年に設立されたCloud Native Computing Foundation（以下、CNCF）という非営利組織が、クラウドネイティブを次のように定義しています。

クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。

【引用】CNCF Cloud Native Definition v1.0

CNCFによるクラウドネイティブの定義

CNCFによるクラウドネイティブの定義を紹介しましたが、専門用語が多くやや難解な文章なので、もう少しかみ砕いて説明しましょう。

パブリッククラウド、プライベートクラウド、ハイブリッドクラウド

まず、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドについて。
一般的にクラウドと呼ばれているものはパブリッククラウドのことで、AWSやAzureなどが代表的なところでしょう。プライベートクラウドは特定の企業向けに提供される閉じたクラウド環境を指しています。
ハイブリッドクラウドはパブリッククラウドとプライベートクラウド、あるいはパブリッククラウドとオンプレミス（自社所有のシステム環境）を組み合わせたものです。

スケーラブルなアプリケーション

同じ文中に、スケーラブルなアプリケーションと出てきます。スケーラブルとは拡張性が高いことです。
つまり、クラウドネイティブ技術により、拡張も縮小も容易で、柔軟性のあるアプリケーションの構築が可能になると示されています。

疎結合システム

3つめの文には疎結合システムという言葉が出てきます。疎結合とはシステム部品同士が密接につながっていない、分離が容易な部品で構成されたシステムのことです。
疎結合の特性を持っていることが、拡張性の高さを裏づける根拠になっているのでしょう。

その他の専門用語

次に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、宣言型APIについて。後ほど詳しく解説しますが、いずれもクラウドネイティブの具体的な技術を指す名称です。
最後に、CNCFによるクラウドネイティブの定義をまとめます。

• クラウドネイティブの技術とは分離性の高い部品を構築するためのもの
• 分離性の高い部品を組み合わせてクラウド上にアプリケーションを構築すれば、拡張性の高い柔軟な運用が可能になる
• 拡張性の高いアプリケーションは自動化も容易であり、今までは難易度の高かった変更リリースを、労力をかけず、神経もすり減らさず、頻繁に確実に実施できる

クラウドファーストとの違い

クラウドネイティブよりも早くから使われていた、クラウドファーストという用語があります。システムを構築するときに、クラウドの利用を優先して検討するのがクラウドファーストの意味です。
あくまでクラウドの利用を優先するものなので、クラウドの利点を徹底的に活用するクラウドネイティブほど踏み込んではいません。

クラウドバイデフォルトとの違い

クラウドファーストと似ていますが、クラウドバイデフォルトという用語もあります。用語の意味もクラウドファーストと似ていて、クラウドの利用を前提にシステムの構築を検討するものです。
クラウドバイデフォルトもやはり、クラウドの利用を選択するレベルにとどまっており、クラウドネイティブほど踏み込んだ意味はありません。

クラウドリフトアンドシフトとの違い

クラウドリフトアンドシフトとは、オンプレミス環境で利用しているシステムを、クラウドへ移行するための手法です。リフトは、オンプレミス環境のシステムをそのままクラウド環境へ移行すること。
シフトは、クラウド環境へ移行したシステムを、徐々に改修してクラウド環境に最適化していくことです。
オンプレミス環境のシステムを、クラウド環境でそのまま利用するのはあまり効率的でなく、クラウドの特性も活かせません。
そのため、リフトするだけではなく、さらにシフトして、クラウドに適したシステムへと段階的に育てていくのです。

クラウドネイティブが求められる理由

ここまでは、クラウドネイティブの定義、他の用語との違いについて解説してきました。
ではなぜ今、クラウドネイティブなのでしょうか。この章では、クラウドネイティブが求められている理由について解説します。

システムに柔軟性が必要なため

クラウドネイティブではない従来のシステムは、モノリス、モノリシックと呼ばれます。
モノリシックとは一枚岩のことです。従来のシステムは、密接に結合され、OSやミドルウェアとも一体化した一枚岩のようなシステムだったためこのように呼ばれます。
モノリシックなシステムは設計、構築が比較的容易なのが利点です。アプリケーションの基盤をしっかり整備しなくても直観的に開発できるからです。

しかし、最初のうちは良くても、改修や機能拡張を繰り返していくうちにどんどんシステムが複雑になっていく恐れがあります。複雑化が進んだシステムの保守や機能追加は容易ではありません。
システムを改修するリスクも増大し、運用コストも大きくなるため、柔軟に対応できなくなってくるのです。老朽化した基幹システムなどは、機能を改善したくても気軽に変更を加えるのは難しいのではないでしょうか。
モノリシックなシステムを運用している企業の中には、老朽化したシステムを再構築し、今度はさらに柔軟性の高いものにしたいと考えている企業も少なくないでしょう。

ビジネスの変化に対してスピーディに対応するため

今の時代はビジネスを取り巻く環境が目まぐるしく変化しています。
企業にとってシステムを利用する目的は、昔のように効率化、コスト削減のためだけではありません。新たなビジネス、サービスを生み出す手段として使われるようになってきています。
つまり、ビジネスが目まぐるしく変化する中で、スピーディに対応できないとなると、システムがビジネスの足を引っ張ることになりかねません。
そのため、ビジネスの変化にスピーディに対応できるシステムが求められています。この要求に応えるのがクラウドネイティブというわけです。

システムの運用コスト増大を抑えるため

前述した通り、モノリシックなシステムは複雑化すると柔軟な対応が難しくなっていきます。
システムに変更を加えることが高いリスクになるため、同じことをするにも導入初期のころより労力が増え、運用コストも増大していくでしょう。
モノリシックなシステムから脱却し、クラウドネイティブなシステムを構築できれば、柔軟な対応ができる上に運用コストも抑えられるでしょう。

クラウドネイティブ化するメリット

クラウドネイティブを導入するのは決して簡単なことではありませんが、導入することで得られる様々なメリットがあります。この章では、システムをクラウドネイティブ化することで得られる代表的なメリットを見ていきましょう。

スピーディな開発ができる

クラウドネイティブなアプローチで開発を進めることで、開発期間を短縮し、高品質なシステムを開発できます。
詳しくは後述しますが、クラウドネイティブなアプローチとはひとつの機能を小さく区切り、独立したサービスとして構築するものです。
一つひとつのサービスが密接に結合していないため、変更したときの影響を最小限にとどめられるでしょう。
また、変更をリリースするときにシステムを停止して利用者に影響を与えることもないため、スピーディなリリースができるようになります。

プラットフォームの独立性が高い

クラウドネイティブな環境では、システムを稼働させる土台であるプラットフォームについて、開発者が意識する必要がありません。
プラットフォームとは具体的には、ハードウェア、OS、ミドルウェアなど、アプリケーションシステムを稼働させるのに必要な仕組みの総称です。
もちろん、クラウド環境を利用していても、モノリシックなシステムであればOSやミドルウェアと密接に結合しているため、意識しないわけにはいきません。
しかし、クラウドネイティブなシステムの場合は、コンテナと呼ばれる仮想化技術が使われているため、ハードウェアやOSの互換性などもコンテナが吸収してくれます。したがって、開発者はプラットフォームを意識しなくても、価値あるアプリケーションの提供に力を集中できるのです。

運用コストを抑えられる

自前でサーバーやストレージを所有してシステムを運用する場合、システムを利用するのに必要なリソースを見積もり、あらかじめ必要なリソースに余裕を持たせた環境を構築するでしょう。
そうすると、システムが稼働した当初は余分なリソースに対してコストがかかります。
クラウド環境でシステムを運用する場合は、実際に使用したリソースに対してのみ料金が発生するため、余分なコストをかけることなく運用できます。
また、リソースの拡張や縮小が容易にできるため、一時的に大量のリソースを消費する場合は必要な期間だけ必要な量のリソースを追加し、不要になれば縮小してコストを節約できるでしょう。
さらに、クラウドネイティブの技術を使用すると、システムのリリースや運用監視など、自動化できる部分が増えるため、運用にかかる人的なコストも減らせます。

クラウドネイティブで使われる技術

クラウドネイティブの定義、求められる理由、導入することで得られるメリットについてご理解いただけたでしょうか。ここからは、クラウドネイティブを実現するために使われている具体的な技術について解説します。

コンテナ

コンテナとは仮想化の技術です。
仮想化の技術は以前からありますが、従来の仮想化はサーバー型の仮想化でした。サーバー型の仮想化は、物理サーバー上に仮想マシンを搭載し、仮想マシン上にOS、ライブラリ、個別のアプリケーションを搭載する構造です。
仮想マシンとはいえ、使い方は物理サーバーと変わらないため、プラットフォームとアプリケーションが密接につながった状態と言えるでしょう。
コンテナ型の仮想化の場合は、物理サーバーのOS上にコンテナエンジンが搭載され、その上に複数のコンテナが搭載されます。

つまり、同じOSを共有する形で複数のコンテナが稼働する構造なのです。個別のアプリケーションはコンテナの中に、後述するマイクロサービスの形で構築します。
コンテナ型の仮想化は、アプリケーションとライブラリをパッケージ化することでOSと分離するため、環境が変わってもOSとの互換性などを気にする必要がありません。
また、サーバー型の仮想化と違い、ひとつのOS上で稼働するため、CPUやメモリなどのシステムリソースにかかる負荷も小さく、高速な動作環境を実現できます。

クラウドネイティブの技術はコンテナをベースに構成されます。
ただし、多くのコンテナを組み合わせてひとつのシステムを構築するため、複雑化したコンテナを管理するツールが欠かせません。コンテナを管理するツールで代表的なものとして、

• Docker（ドッカー）
• Kubernetes（クバネティス、クーべネティス）

などが挙げられます。DockerはLinuxベースのコンテナ管理システム、KubernetesはGoogle社が開発したオープンソースのコンテナオーケストレーションシステムです。

マイクロサービス

マイクロサービスとは、アプリケーションを独立可能な最小単位に分割し、コンポーネント化する設計思想です。複数のマイクロサービスを組み合わせてアプリケーションの機能を構築します。
マイクロサービス同士の連携はAPIを介して行うため、サービス間が密接なつながりを持つことはありません。そのため、開発、テスト、リリースを独立して実施でき、拡張性の高いアプリケーションを構築できます。
また、あるサービスに障害が発生した場合も、障害箇所を切り離すことが可能なので、システム全体に影響を及ぼすことなくサービスの提供を継続できるでしょう。

サービスメッシュ

複数の小さなサービスが連携して機能するマイクロサービスは、独立性が高く分離が容易なため、様々なメリットが得られると説明しました。
例えば、あるサービスの負荷が高くなれば、同じサービスのコンテナを増設し、複数のコンテナをひとつのシステムとしてコントロールします。
拡張によってサービス間の通信はどんどん煩雑になっていくため、効率的に管理しなければなりません。そこで、サービス間の通信を効率的に管理するために利用する仕組みがサービスメッシュです。

サービスメッシュは、通信の負荷分散、トラフィックの最適化、セキュリティの高い通信を実現する機能などを提供するインフラ系のツールです。
サービスメッシュを利用すれば、アプリケーションを改修しなくても追加機能が導入できるでしょう。
代表的なツールにIstio（イスティオ）というオープンソースのサービスメッシュがあり、大規模でより複雑になったサービスメッシュの管理に力を発揮します。

宣言型API

マイクロサービス同士の連携は原則としてAPIを介して行います。それも、クラウドネイティブでは宣言型APIを使用するのが特徴です。
宣言型APIとはどのようなものでしょうか。
呼び出すサービスに実行させたい命令を出すのではなく、最終的に得たい結果だけを宣言し、宣言どおりの結果を得ようとするのが宣言型APIです。
宣言型という用語がピンとこないかもしれないので、宣言型と対になる概念である命令型と比較しながらもう少し詳しく見ていきましょう。

命令型とは、アプリケーションに対して具体的に実行させたいコマンドを伝えることで命令し、実行させる方法です。コマンドを実行した結果としてアプリケーションはあるべき状態に到達します。
しかし、コマンドの実行が失敗するなど、必ずしも意図した結果が得られるとは限りません。
命令型に対して、最終的にどういう結果が得られるべきかを宣言し、アプリケーションを動作させる方法を宣言型と呼びます。具体的な内容を指示するのではなく、最終結果だけを伝えて詳細のプロセスは呼び出すAPIに任せるのです。

部下にやるべきことを細かく指示する上司と、最終的なゴールイメージだけを伝えて具体的な作業方法は部下に任せる上司の違いにイメージが近いでしょうか。
命令型の場合は実行に失敗する可能性があるため、処理結果を監視し、失敗したときのリカバリー対策まで打たないといけません。宣言型では最終的に得たい結果だけを伝えるため、宣言型APIは得たい結果を出すために自律的に動きを制御します。
つまり、クラウドネイティブでは宣言型APIを使用することで、システムの監視にかかる負荷を下げられるのです。

イミュータブルインフラストラクチャ

イミュータブルインフラストラクチャとは、直訳すると不変のインフラとなります。不変とは、インフラの状態が変わらないことを意味しています。
従来のインフラは、長期間のシステム運用でOSやミドルウェアにパッチを適用するなどの変更が必要な場合、変更のたびに状態が変化していました。
イミュータブルインフラストラクチャでは、変更が適用されたOSやミドルウェアの環境を新たに立ち上げ、古い環境は捨ててしまいます。つまり、運用中の実行環境には変更を加えないため、インフラの状態は変化しません。
インフラの状態が変化しなければ実行環境の状態管理が不要となるため、障害や管理コストの削減につながるのです。

クラウドネイティブのアプリケーション開発

クラウドネイティブな環境でアプリケーションを開発するには、どのようなことが必要になるのでしょうか。この章では、クラウドネイティブのアプリケーションを開発する際に、ポイントになる考え方をいくつか解説します。

CI/CD

CI/CDとは、Continuous Integration/Continuous Deliveryの略です。日本語訳では継続的インテグレーション、継続的デリバリーなどと訳されます。
継続的インテグレーションは、バラバラに作成されたソースコードを統合し、ビルド、テストするプロセスを自動化することです。
継続的デリバリーは、開発されたアプリケーションをユーザーに提供するためのリリースのプロセスを自動化します。
つまり、アプリケーションの追加や変更を常に自動でテストし、自動でリリースできる状態にしておくことで、頻繁な変更を安全に実施する手法と言えるでしょう。頻繁なアプリケーションの変更はクラウドネイティブの大前提なので、継続的なリリースに耐えられる仕組みがあることは重要なポイントです。

DevOps

DevOps（デブオプス）とは、開発チームと運用チームが協調してシステム開発を行うための概念です。開発チーム（Development）のDevと運用チーム（Operations）のOps、それぞれ3文字を取って名付けられました。
DevOpsの概念で開発チームと運用チームは、開発・運用するシステムによってビジネスの価値をより高めるにとどまらず、ビジネスの価値をより確実かつスピーディにユーザーに届け続けます。

開発チームと運用チームはお互いの利害が一致しないため、対立構造が生まれることがよくあります。開発チームの役割はシステムに機能の追加や改修を加えることで、運用チームの役割はシステムを安定稼働させることです。
システムに機能の追加や改修を加えることは、システムの安定稼働を損ねるリスクがあるため、お互いの利害が対立するわけです。

しかし、それぞれの役割は本来、開発・運用するシステムによってビジネスの価値をより高めるという大きな目的においては一致しています。
つまり、DevOpsの概念を採り入れることは、お互いが同じ目線で目的意識を持ち、お互いを尊重・信頼して協調できるように、社内組織の文化を改善することが含まれていると言えるでしょう。

アジャイル開発

アジャイル開発とは、短期間の開発を何度も繰り返しながらシステムをブラッシュアップしていく開発手法です。設計、開発、テストの工程を1～2週間程度の短期間で区切って実施し、その都度リリースします。
要件変更に柔軟に対応できるため、目まぐるしいビジネスの変化にも強い開発手法と言えるでしょう。

サーバーレス

通常、システムを稼働させるサーバーを構築して運用するには、サーバーのメンテナンスが必要です。また、システムが使用するリソースの状況を、常に監視する体制を取らなければなりません。
一方、サーバーレスとはサーバーを運用するのとは違い、容量を気にせずリソースを利用できるサービス形態です。サーバーレスを採用すれば、開発者はインフラのことを考慮することなく、アプリケーションの開発だけに集中できるでしょう。
サーバーレスサービスは、プログラムの実行時間に対して課金されるため、コストを抑えることにもつながります。

クラウドネイティブなアプリケーション開発のご相談はWakka inc.まで

Wakka inc.では、専門性の高いチームがお客様のニーズに寄り添い、それを実現するアイデアをご提案します。
フルスクラッチ開発の具体的な進め方や費用感などが知りたい場合はお気軽にお問い合わせください。（構想段階で形になっていないアイデアでも問題ありません）
発想力と細部にわたる設計・開発力で、成功に向けて着実にサポートします。

クラウドネイティブ化の進め方

CNCFが提唱するクラウドネイティブへの道しるべ

クラウドネイティブの定義で触れたCNCFは、クラウドネイティブへの道しるべとも言えるCLOUD NATIVE TRAIL MAPを提唱しています。
CLOUD NATIVE TRAIL MAPには全部で10ステップが書かれていますが、すべてを達成しなければならないわけではありません。
最初の3ステップは必須ですが、ステップ3以降は状況に応じて選択すれば良いとされています。 なお、CLOD NATIVE TRAIL MAPに記載されている10ステップは下記の通りです。

• コンテナ化
• CI/CD
• オーケストレーションとアプリケーションの定義
• 可観測性と分析
• サービスプロキシ、ディスカバリー、メッシュ
• ネットワーク、ポリシー、セキュリティ
• 分散データベースとストレージ
• ストリーミングとメッセージング
• コンテナレジストリとランタイム
• ソフトウェアの配布

CLOUD NATIVE TRAIL MAPの最初の3ステップを押さえる

ここからは、クラウドネイティブ化において必須とされる最初の3ステップについて簡単に解説します。

コンテナ化

前述した通り、コンテナはクラウドネイティブのベースとなる仮想化の技術です。CLOUD NATIVE TRAIL MAPでは、最初のステップでコンテナ化を進めることを推奨しています。
Dockerコンテナなどを使用して、アプリケーションをコンテナ化していきます。
分割可能なアプリケーションについては徐々に分割を進め、最終的にはマイクロサービスとして機能を実装することになるでしょう。

CI/CD

CI/CDも前述した通り、ソースコードの統合、テスト、ビルド、およびリリースを継続的に自動実行する仕組みです。
ビジネス環境の変化にスピーディに対応するのがクラウドネイティブの狙いなので、クラウドネイティブ化に向けては早い段階で達成しておきたいところでしょう。コンテナ化よりも、まずはCI/CDの方を先に実施すべきとの意見もあります。

オーケストレーションとアプリケーションの定義

コンテナのオーケストレーションシステムとして紹介したKubernetesなどのツールを使用し、コンテナの管理や各種設定、調整を自動化することで、アプリケーションを正常に稼働させます。
アプリケーションを構成する大量のコンテナやマイクロサービスは、複雑な組み合わせを管理しなければならないため、オーケストレーションシステムを使用するのが良いでしょう。

社内組織の文化を変える

社内組織の文化を変える必要性についてはDevOpsの章でも触れましたが、クラウドネイティブを実現するためにも同じことが言えます。ただ技術を採り入れるだけでは、クラウドネイティブを実現するのは難しいでしょう。
モノリシックなシステムを導入し、長年運用を続けている組織であれば、システムを気軽に変更して障害を起こしてしまう怖さをよく知っているはずです。
長年運用を続けているシステムは複雑化しており、変更によってどこに影響が出るかを正確に把握するのが難しくなっているからです。
複雑化したシステムを運用する難しさを知っている組織では、たとえ軽微な改修であっても慎重に、決してミスをしないようにリリースの承認プロセスを重視しているでしょう。

しかし、慎重に承認プロセスを踏むような社内組織の文化は、クラウドネイティブの実現を難しくする要因になりえます。クラウドネイティブではビジネスの変化にスピーディに対応できるよう、システムの改修とリリースの頻度を上げるのです。
リリースの頻度を上げるためには、前述したようなCI/CDの仕組み、DevOpsの考え方、アジャイル開発手法を合わせて採り入れるべきでしょう。
「CI/CDの仕組み、DevOpsの考え方、アジャイル開発手法は採り入れるが、社内組織の文化は今のまま」とはいきません。例えば、

• システムの改修に慎重だった文化は、失敗してもどんどんチャレンジする文化に変えていく
• 対立していた開発チームと運用チームが、上手く協調できるような空気を作っていく
• 外部に依存せず、自律的に動けるチームを構築していく

のような変化を社内組織に採り入れ、クラウドネイティブが根付きやすい土壌作りを目指しましょう。

クラウドネイティブの理解を深めて自社に合ったアプローチを

本記事をここまでお読みになって、「うちの会社にクラウドネイティブなんて導入できるのだろうか？」と思われた方もいらっしゃるでしょう。たしかにクラウドネイティブを導入するのは簡単ではありません。
社内組織の文化は一朝一夕で変えられるものではありませんし、クラウドネイティブに必要な知識と技術を持った技術者が不足している点も、導入を難しくしている要因のひとつでしょう。

単に技術だけを採り入れてみても、クラウドネイティブ化は上手くいかない。かと言って、難しいからと手を出さないでいると、モノリシックなシステムに縛られてビジネスの変化に追いつくのが困難になります。
まずはクラウドネイティブがどのようなものかしっかりと理解を深め、自社に適しているかを見極めるのが大切です。
そして、採り入れるのであれば可能なところから、自社に適したアプローチで計画的に進めていきましょう。本記事がクラウドネイティブ化を進めるきっかけとしてお役に立てば幸いです。

【あわせて読みたい】おすすめ関連資料

●すぐに使えるRFPテンプレート｜システム開発用
＞システム開発のRFPについて、情報を埋めるだけで簡単に作成ができるテンプレートです。

●すぐに使えるRFPテンプレート｜サイトリニューアル用
＞サイトリニューアルの際に、テンプレートの情報を埋めるだけで簡単にRFPが作成できます。

●DX進め方ガイドブック
＞DXプロジェクトを検討している担当者の方に向けて、失敗しない社内体制の構築から開発リソース確保までを網羅して解説しています。