こんにちは。クラウドエース編集部です。

社内システムの構築や変更を検討する際に、「クラウドネイティブ」という言葉を耳にしたことがあるかもしれません。クラウド環境に関する言葉だと想像できるものの、その正確な意味については曖昧という人も多いのではないでしょうか。

今回は、クラウドネイティブの概念を説明した上で、それがどのような技術によって成り立っているのか、どのようなメリットがあるかについて紹介します。

クラウドネイティブとは

クラウドネイティブとは、「クラウドの長所を徹底的に活用する」という意味を持つ言葉です。システム構築にクラウドを用いることを前提に、その特性を活かし、最適化するような設計を行うことを指します。

より具体的な内容について見てみましょう。2015年、クラウドネイティブを推し進める団体「 Cloud Native Computing Foundation ( CNCF )」が設立されました。彼らは、クラウドネイティブを以下の通り定義付けています。

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

つまり、クラウドネイティブではコンテナを基盤とすることで、拡張性が高く柔軟なアプリケーション構築を目指すのです。また、後ほど詳しく解説しますが、そのためにはサービスメッシュやマイクロサービス、イミュータブルインフラストラクチャなどの技術が用いられます。

注目される背景や事例

クラウドネイティブという概念が注目されている背景としては、やはりクラウド環境が一般化したことが挙げられるでしょう。

クラウドの登場以前は、オンプレミスでシステムを動かすことが一般的でした。しかし、クラウドの導入までのハードルの低さやコストパフォーマンスの高さなどから、あらゆる企業においてクラウド移行が進んでいきます。

実際に、クラウドネイティブな技術を社内の基幹システム運用に適用するだけでなく、 IT 企業が自社サービスを提供するために利用していることも珍しくありません。また、障害時の影響範囲を最小限にすることや、サービスのリリース後の機能の追加・修正を簡単に行うことを目的にクラウドネイティブの考え方を取り入れる事例もあります。

このように、現在は「クラウドにするか、オンプレミスにするか」を議論するのではなく「クラウドをどう活用するか」を議論する段階に突入しています。結果として、初めからクラウドを使うことを前提に、そのメリット最大化させるクラウドネイティブという考え方が注目されているのです。

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

クラウドネイティブと比較される言葉に「クラウドファースト」があります。これは「クラウド利用を優先してシステム構築すること」を指します。

クラウドファーストは、クラウドネイティブの登場以前から存在していた概念です。システムの導入や構築をする際に、オンプレミスよりも低コストでの運用・管理を目的にクラウド利用を優先する考え方と言えるでしょう。しかし、運用上のやベンダーの都合に応じては、クラウド以外のサービスが利用されるケースもあります。

クラウドネイティブは、クラウドファーストをさらに進めた概念と言えます。

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

クラウドファーストと同様に、「クラウドバイデフォルト」という言葉を目にすることもあるかもしれません。これは、政府情報システムの構築・整備において「クラウド利用を第1候補としてシステム構築すること」を指す言葉です。

クラウドファースト同様に、クラウド環境を優先するものの、必ずしもクラウドが利用されるわけではないことが、クラウドネイティブと異なる点です。

クラウドネイティブの技術的要素

ここまで、クラウドネイティブの概要と定義について解説してきました。ここからは、クラウドネイティブの具体的な技術的構成要素について紹介します。

 CNCF で定義されている通り、クラウドネイティブのアプローチの代表例は、コンテナ、マイクロサービス、サービスメッシュ、イミューダブルインフラストラクチャ、宣言型 API です。それぞれについて、どのような技術なのか具体的に見てみましょう。

コンテナ


コンテナとは、 OS 上に複数の環境を作り出すことができる仮想化技術です。ひとつの OS 上でのプロセスを独立した空間に隔離できる点が従来の仮想化技術と異なり、ゲスト OS を介さずに軽量な環境を作ることが可能です。

コンテナは、従来の仮想化技術よりも軽量で必要とする起動時間が短いため、サービスのリリースや障害時の復旧にかかる時間を短縮できます。また、少ないリソースで動作可能なため、1つのサーバーでよりたくさんのアプリケーションを実行できます。加えて、動作に必要となるものを最低限のみパッケージングするため、 OS への依存度が低く、移行も比較的気軽に行えます。

マイクロサービス


マイクロサービスとは、1つのアプリケーションを機能ごとに「サービス」という単位に分け、それぞれを連携させてシステムを機能させることです。

アプリケーションを細かいサービスに分解することで、負荷を分散させたり、拡張性を向上させたりすることが可能となります。結果として、リソースの最適化や可用性の向上に繋げられます。また、各サービスごとに開発やテスト、リリースができるようになるため、機能の追加・変更への柔軟な対応も可能です。さらに、障害が発生した場合にも、その影響を最小限に抑えらるというメリットもあります。

このように、マイクロサービスは拡張性の向上やリソースの最適化に繋がる技術のため、クラウドネイティブに必要な要素の1つです。

サービスメッシュ


サービスメッシュとは、コンテナ間の通信などを管理するソフトウェアのことです。

上で紹介したマイクロサービスには、負荷分散や拡張性の向上をはじめとした、さまざまなメリットがあります。しかしその一方で、サービス間の通信が複雑になってしまうというデメリットがあるのも事実です。

この問題を対処する仕組みが、サービスメッシュです。サービスメッシュでは、ネットワーク上のサービスを抽象化し、通信トラフィックの最適化、アプリケーションの識別、認証や暗号化といった機能を提供します。

サービスメッシュは、クラウドネイティブに必須のマイクロサービスを実現する上で必要な技術と言えるでしょう。

宣言型 API


宣言型 API とは、 API の定義を宣言して API を生成する仕組みのことです。

上で紹介したマイクロサービスでは、サービス同士の連携はサービスが公開するAPIを介して行われます。そして、ここで言う「宣言」とは、サービスに対して「実行すべきコマンド」を指示するのではなく、サービスの「あるべき状態」を指示することです。

宣言型と対比される指示方法は「命令型」です。これは、アプリケーションに対して実行させたいコマンドを命令する方法です。命令通りにアプリケーションは動作しますが、コマンドの失敗などが起きれば、意図した結果が得られないリスクもあります。

一方、宣言型では「最終的にどういう結果を得るべきか」と指示します。この方法のメリットは、システムが正常な結果を得るべく自律的に動くため、運用管理者が常に監視したり、細かな命令を指示する必要がないことです。

例えば、「コンテナを5つ含む Pod を起動」と宣言すれば、5つのコンテナが起動されます。もしも、何らかの理由でコンテナの数が増減したり、停止したりした場合にも、宣言に従い自動的に代替のコンテナを別途起動するなどして、5つのコンテナを維持するように振る舞います。

このように、宣言型 API では自律的な動作や制御が期待できるため、サービス運用を単純化できるのです。

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


イミュータブルインフラストラクチャとは、直訳すると「不変なインフラ」となります。アプリケーションの管理方法で、インフラとなるソフトウェアが不変であることを意味します。

具体的には、アプリケーションの構成要素に変更が発生した場合、本番環境で変更するのではなく、変更したソフトウェア一式を置き換える方法を取ります。従来のオンプレミス環境では、アプリケーションに変更があるたびにパッケージ追加やパッチ適用が必要でした。そのため、 OS のアップデートや設定変更のたびにインフラが複雑化し、アプリケーションの動作に影響が出るリスクがありました。それを避けるため、古いバージョンのまま使われ続けらたり、セキュリティ上の問題が放置されたりというケースも見られます。

一方で、クラウドネイティブでは、一度構築した本番環境には変更を入れません。更新が必要な場合は、変更作業を実行するのではなく、変更済みの OS を用いた環境を新規に立ち上げ、本番環境の切り替えを行います。インフラに対する変更が最小限に抑えられ、アプリケーションの更新がより気軽に行えます。

クラウドネイティブのメリット

ここまで、クラウドネイティブを実現するための技術的要素について紹介してきました。それでは、具体的にクラウドネイティブにはどのようなメリットがあるのでしょうか。

コスト削減が可能

1つ目のメリットは、コストを削減できることです。

オンプレミスでシステム構築する場合、物理的なハードウェアの購入や、運用・管理のための人件費など大きなコストがかかります。また、後からサーバーの性能を向上させたり、ストレージを増加させたりする場合にも、費用と時間がかかります。そのため、事前に必要な容量を予想し、それを程度上回るサーバーやストレージを用意することが多いです。結果として、導入初期は容量が余り続けてしまい、導入コストを回収するまで時間がかかります。

一方、クラウドネイティブであれば、物理的サーバーは不要で、運用や管理もクラウド事業者に委任できます。そのため、運用にかかる人件費の削減に繋がります。また、システム稼働後でも、簡単にサーバー性能の向上やストレージの追加が可能です。必要な時に必要なだけのストレージを利用できるため、コストに無駄が生じません。

スムーズな変更が可能

2つ目のメリットは、アプリケーションのスムーズな変更が可能なことです。

先述の CNCF のクラウドネイティブの定義には「インパクトのある変更を最小限の労力で頻繁かつ予測どおりに行う」という一文があります。つまり、クラウドネイティブでは迅速なシステムやアプリケーションの変更や環境構築を目指すのです。

説明した通り、クラウドネイティブでは、アプリケーションが小さなサービスの集合として設計されます。そのため、ひとつのサービスに障害や変更が生じても、アプリケーション全体に影響を及ぼすことはありません。また、宣言型 API を取るため、システムの実行状態も自動的に管理され、問題が生じても自動的に回復されます。このようなことから、変更や障害に柔軟に対応できるのです。

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


クラウドネイティブな技術でアプリケーション開発を始めるには、まずはシステムをクラウド移行する必要があります。

クラウド移行にはいくつかの手法が存在しますが、特に手軽な方法としては「リフトアンドシフト」が挙げられます。これは、既存のシステムを丸ごとクラウド環境に移行し、その後、必要に応じてクラウドに最適化するように少しずつ修正する方法です。

Google Cloud などのクラウドサービスでは、既存のインフラと同じ環境をクラウド上に簡単に構築できます。そのため、移行時にアプリケーションの改修などは不要です。

どのようなサービスを利用する場合でも、クラウドネイティブの考え方を取り入れる際には、クラウドの特徴を理解し、アプリケーションとの統合方法を慎重に検討することが重要です。

まとめ

ここまで、クラウドネイティブの概念やそれを実現する技術について紹介してきました。クラウドネイティブの考え方を正しく理解して、システム構築や変更に活かしてみてください。
また、クラウドネイティブなアプリケーション開発やシステム構築に関するご依頼や、ご相談がございましたら クラウドエースまでお気軽にお問い合わせください。

(よろしければこちらより 弊社と Google Cloud に関するご紹介資料をダウンロードいただけますと大変嬉しく思います。)
Google Cloud と クラウドエース のご紹介資料

合わせて読みたい