クラウドネイティブは、マイクロサービス、コンテナ、コンテナオーケストレーター、不変インフラストラクチャなどのテクノロジーを使用して、クラウドコンピューティング環境で応答性、拡張性、耐障害性に優れたソフトウェアアプリケーションを構築、デプロイ、実行、管理するアプリケーション開発手法です。
クラウドネイティブとは、クラウド上で動作するように構築されたソフトウェア・アプリケーションの設計と運用を指します。クラウドネイティブがデジタル革新を加速するのは、クラウドベースのサービスの柔軟性、拡張性、回復力を最大限に活用し、管理と保守が容易なアプリケーションを効率的に提供するためです。
ある銀行が新しいアプリケーションを作成する必要があるとします。クラウド・コンピューティングが導入される前は、銀行は開発者を雇ってアプリを構築し、オンプレミスでアプリケーションを実行するために必要な物理インフラを購入し、アプリケーションのライフタイムを通じてそのインフラを保守していました。このアプリにアクセスするには、ユーザーは銀行のサーバーに接続する必要があり、そのサーバーはアプリが提供する個々のサービス(口座番号の検索、資金の移動など)をホストしているため、1つのサービスを更新・保守するにはシステム全体をシャットダウンする必要がありました。
クラウドでアプリをホスティングするようになったとき、開発者はアプリの全体的なアーキテクチャや制限を維持しながら、オンプレミス環境からアプリを「リフト&シフト」しました。アプリケーションをホストするサーバーを購入して管理する代わりに、クラウドサービスプロバイダー(CSP)からクラウド コンピューティング リソースをレンタルしました。しかし、Platform as a Service、Containers as a Service、 サーバーレスインフラストラクチャなどの新しいサービスによって、アプリケーションを猛スピードで構築、デプロイ、管理する新たな機会が生まれました。
オンプレミスでアプリケーションを構築するという慣習は、仮想化の登場と、開発者がクラウド上で仮想マシンをプロビジョニングして管理できるようにしたAmazon Web Services(AWS)などの IaaS(Infrastructure as a Service) プロバイダーの出現によって、2000年代前半に変化し始めました。これにより、Google App EngineやHerokuのような、クラウドベースのアプリケーションを構築およびデプロイするための、より高度な抽象化レイヤーを提供する PaaS(Platform as a Service )が開発される道が開かれました。
しかし、初期のプラットフォームは柔軟性に欠け、開発者は独自のAPIやツールを使用しなければならず、閉じ込められていました。これに対し、クラウド向けに設計されたアプリケーションの構築とオープンソース技術の利用に焦点を当てた新しいアプローチが登場しました。
このアプローチの初期の例は、移植性、スケーラビリティ、および回復力のために設計されたクラウドネイティブアプリケーションを構築するための一連の原則で構成されるTwelve-Factor App方法論でした。これらの原則には、構成に宣言形式を使用すること、ステートレス・プロセスに依存すること、バッキング・サービスをアタッチされたリソースとして扱うことなどが含まれます。
同じ頃、Dockerコンテナ化技術がクラウド・ネイティブ・アプリケーションの重要な構成要素として登場しました。Dockerは、開発者がアプリケーションと依存関係を軽量コンテナにパッケージ化し、異なるクラウド環境に簡単にデプロイできるようにし、アプリケーションの移植性の問題を解決しました。
2014年、GoogleはオープンソースのコンテナオーケストレーションプラットフォームであるKubernetesをリリースしました。コンテナ化アプリケーションのデプロイ、スケーリング、管理を自動化する強力なツール群を提供するKubernetesは、クラウドにおけるコンテナ化アプリケーション管理の標準となりました。
それ以来、アプリケーション構築のためのクラウドネイティブアプローチは、新興企業から大企業まで、あらゆる業界の組織に受け入れられ、オープンソースの技術、ツール、プラットフォームのエコシステムの発展につながりました。
基本的なレベルでは、クラウドネイティブアプリケーションは、機能がマイクロサービス(互いに独立して動作する、疎結合の小さなサービス)に分解されたソフトウェアプログラムです。このモジュール構造により、クラウドネイティブアプリケーションは従来のモノリシックなアプリケーションよりも構築や変更が容易です。デプロイメントは、システムを中断することなく、アプリケーションに新機能やアップデートをデプロイできます。
それに比べて、モノリシックアプリケーションは、単一のコードベースとして構築され、すべてのコンポーネントが緊密に結合され、単一のサーバーまたはマシン上で実行されます。つまり、アプリケーションの変更や更新には、アプリケーション全体の再コンパイルと再デプロイが必要になります。
クラウドネイティブアプリケーションに特徴的な技術や方法論には、他にも以下のようなものがあります:
クラウドネイティブアーキテクチャは、高速で軽快なアプリケーション開発技術をサポートする設計手法であり、クラウドネイティブアプリケーションを、保守、変更、大規模化、移行が容易な、より小さく構成可能なピースの集合として構築します。クラウドネイティブ・アーキテクチャの構成要素を以下に示します。
イミュータブル・インフラストラクチャとは、何かを更新、修正、変更する必要がある場合に、サーバーや仮想マシン(VM)を変更するのではなく、入れ替えるというパラダイムです。変更が必要な場合は、その変更を組み込んだ新しいコンポーネントが共通のイメージから構築され、古いコンポーネントは生産から外されます。このアプローチにより、クラウドネイティブのデプロイメントに予測可能なプロセスが生まれます。
クラウド ネイティブの台頭は、クラウド ネイティブ アプリケーションで連携する、それぞれが特定のビジネス機能を持つ独立したデプロイ可能なサービスの使用を重視するソフトウェア設計パターンであるマイクロサービス アーキテクチャによって牽引されてきました。マイクロサービスにより、開発者はより小さく管理しやすいコンポーネントを組み合わせることで、複雑なアプリケーションを構築することができます。
APIは クラウドネイティブアプリケーションで使われるコミュニケーションツールです。独立したマイクロサービス間の標準的で効果的な情報伝達を促進し、情報を共有することで、全体としてまとまった機能を発揮できるようにします。
サービスメッシュとは、クラウドネイティブアーキテクチャにおいて、マイクロサービス間の通信を管理するレイヤーのことです。また、サービスメッシュを使用することで、新しいコードを追加することなく、サービスにトラフィック管理、セキュリティ、追加機能を追加することができます。
コンテナにより、マイクロサービスは依存関係(コード、リソースファイル、システムツール、システムライブラリ)を自己完結型の環境にパッケージ化できるため、どのような状況でも一貫したパフォーマンスを発揮します。これにより、開発者はサービスの再現や分析、切り分けを容易に行うことができます。 コンテナには アプリケーションの実行に必要なものがすべて格納されているため、クラウド ネイティブ アプリケーションをオンプレミスまたはクラウドのどこにでもデプロイできます。
各マイクロサービスがコンテナにデプロイされ、コンテナ群がシステム(スタック)として連携し、完全なネイティブアプリを形成します。ダイナミック・オーケストレーション・システムは、各コンテナを自動的に監視し、ユーザーのニーズに応じてコンテナの起動と停止を行い、スケーラビリティと効率の向上を実現します。
クラウドネイティブアプリケーション開発とは、プライベートクラウド、パブリッククラウド、またはハイブリッドクラウドで運用するための安定したスケーラブルなアプリケーションを構築するプロセスです。一般的なクラウドネイティブ開発のプラクティスには次のようなものがあります:
継続的インテグレーション(CI)とは、コードの変更を自動的にビルドし、テストし、中央リポジトリに統合することです。これは、コード変更が徹底的にテストされ、アプリケーションのコードベースの残りの部分と統合されることを確実にするのに役立ちます。クラウドネイティブ開発では、CIはしばしばコンテナ化と組み合わせて使用されます。コンテナ化によって、開発者はコード、依存関係、設定を単一の自己完結型ユニットにパッケージ化することができます。
継続的デリバリー(CD)とは、 CIプロセスで作成されたアプリケーションを 本番のような環境に デリバリー するプロセスのことで、予期せぬパフォーマンスの問題を排除するために追加の自動テストが行われます。CDは、運用中のアプリケーションのインクリメンタルなアップデートを可能にすることで、変更を提供するコスト、時間、リスクを削減し、開発者がより迅速かつ頻繁に高品質のソフトウェアを構築、テスト、リリースできるようにします。クラウドネイティブ開発では、CDは自動化やDevOpsプラクティスと併用されることが多く、ソフトウェア開発とデプロイメントプロセスの合理化に役立ちます。
DevOpsは、ソフトウェア開発とIT運用を組み合わせて、ソフトウェア開発とデリバリーの効率、スピード、品質、セキュリティを向上させるアプローチです。
クラウドネイティブ開発では、ソフトウェア開発とデプロイメントプロセスの多くの側面を自動化するために DevOpsが よく使用されます。迅速で反復的なアプローチに重点を置くことは、クラウドネイティブモデルに合致し、組織がアプリケーションとサービスをベロシティで提供するのに役立ちます。これにより、企業は顧客により良いサービスを提供し、業界においてより効果的に競争することができます。
サーバーレスコンピューティングは、マイクロサービスと組み合わせて使用され、開発者が基盤となるクラウドインフラストラクチャを管理することなくコードを記述してデプロイできるようにするクラウドネイティブ開発モデルです。リソースは需要に応じて動的に割り当てられるため、サーバーレス・コンピューティングはコストを削減し、スケーラビリティを向上させることができます。
クラウドネイティブの実践は、デジタル革新とビジネスの成長を促進する最良の機会を提供します。ネイティブ・アプリケーションの開発はコスト効率が高く、継続的インテグレーション/継続的デリバリー(CI/CD)により、アプリケーションの更新と保守を容易に行うことができます。また、開発、運用、セキュリティにまたがるサイロを取り払い、アプリケーション開発ライフサイクル全体で一貫したエクスペリエンスを提供することもできます。
クラウドネイティブアプリケーション開発のその他の利点は以下のとおりです:
クラウド ネイティブ アプリケーションは、アジャイル開発プロセスを使用して開発され、個々のサービスは独立して開発およびデプロイされるため、新機能やアップデートをより迅速に反復してデプロイできます。
クラウド ネイティブ アプリケーション開発では、クラウド プロバイダーが基盤となるインフラストラクチャを管理するため、開発者はアプリの価値提供に専念できます。これにより、動作環境の一貫性と信頼性も向上します。
クラウドネイティブアプリケーションは水平スケーラブルに設計されており、需要に応じてリソースを動的に追加または削除できます。逆に、モノリシック・アプリケーションは通常、垂直方向に拡張されます。これは、需要の増加に対応するために、サーバーやマシンにリソースを追加することを意味します。この方法は、ピーク需要に対応するためにリソースを過剰にプロビジョニングする要件が必要になることが多いため、コストがかかり非効率的です。
クラウド ネイティブ アプリケーション開発では、更新、変更、大規模化がリアルタイムで簡単にできる疎結合のマイクロサービスからなるアプリケーションを提供するため、顧客やビジネスのニーズの変化に対応しやすくなります。
クラウドネイティブのアプリケーション開発では、分離可能なマイクロサービスを使用するため、耐障害性が向上します。モノリシック・アプリケーションの1つのコンポーネントに障害が発生すると、システム全体がダウンする可能性があります。しかし、フォールト・トレラントなクラウドネイティブ・アプリケーションは、個々のサービスに障害が発生しても継続的に機能するように設計されています。
クラウドネイティブのアプリケーション開発では、コンテナを使用して異なるベンダーのインフラ間でマイクロサービスを転送するため、組織は特定のベンダーに縛られません。複数のクラウドプロバイダーのサービスを利用し、自社のビジネスに最適なオプションを選択することができます。
クラウド ネイティブ アプリケーションの開発では、マイクロサービス アーキテクチャによって問題をソース サービスまで簡単に追跡し、サーバーのダウンタイムなしに問題を修正できるため、トラブルシューティングが簡素化されます。
クラウドネイティブ・アプリケーションはセキュリティのために設計されており、通常、個々のサービスは互いに分離されています。これにより、攻撃者が機密データにアクセスしやすくなる、緊密に結合したコンポーネントで構築された従来のモノリシック・アプリケーションからのアタックサーフェスが減少します。
クラウドネイティブスタックとは、開発者がクラウドネイティブアプリケーションを構築、管理、実行するために使用するツールやテクノロジーのレイヤーを指します。クラウドネイティブスタックのレイヤーには以下のようなものがあります:
インフラレイヤーはクラウドネイティブスタックの基盤を形成します。OS、ストレージ、ネットワーク、その他のコンピューティング・リソースなど、クラウドネイティブ・アプリケーション開発を支えるコンポーネントで構成されています。インフラレイヤーはサードパーティのクラウドプロバイダーによって管理されます。
クラウドネイティブスタックのプロビジョニングレイヤーは、インフラストラクチャの作成とセキュリティ確保に使用されるツールで構成されています。これには、コンテナイメージをスキャンして保存し、ポリシーの設定と実施を可能にするツールが含まれます。
ランタイム・レイヤーは、コンテナがクラウドネイティブ環境で動作するために必要なすべてを包含しています。これには、コンテナの起動に使用するコードや、コンテナで永続ストレージを利用できるようにするツールが含まれます。
オーケストレーションと管理のレイヤーはオペレーティングシステムに似ており、クラウドのコンポーネントをまとめ、1つのまとまったユニットとして連携できるようにする役割を担っています。Kubernetes、Docker、OpenShiftのようなオーケストレーションツールによって、開発者はコンテナ化されたアプリケーションのデプロイ、管理、スケーリングを行うことができます。
アプリケーションの定義と開発レイヤーは、データベース、メッセージングシステム、コンテナイメージ、 CI/CDパイプラインなど、開発者がアプリケーションを構築するために使用するすべてのテクノロジーで構成されています。
観測可能性と分析ツールは、クラウド ネイティブ スタックのすべてのレイヤーを観測して、クラウド アプリケーションの健全性を監視および評価し、アプリケーションのサービス品質に障害がないことを確認します。これらは、ロギング、モニタリング、トレースのカテゴリーに分けられ、CPU使用率、レイテンシ、メモリなどのメトリクスを監視するために使用されます。
クラウド環境とクラウドネイティブ環境は異なるアーキテクチャを持ち、異なるテクノロジーに依存しているため、 クラウドセキュリティと クラウドネイティブセキュリティは異なります。クラウドのセキュリティは、さまざまな資産やアプリケーションを対象とするため、セキュリティに対する広範で全体的なアプローチが要件となります。一方、 クラウドネイティブ・セキュリティには、クラウドネイティブ・アプリケーションとインフラストラクチャ特有のセキュリティ上の懸念を考慮した特殊なアプローチが必要です。
クラウドネイティブのセキュリティに関する一般的な課題には、次のようなものがあります:
可視性の欠如:クラウド環境は複雑なため、完全に可視化することが難しく、セキュリティ・リスクが潜在化するブラインド・スポットが生じます。
多様な脅威:クラウドの脅威アクターは、創造的な攻撃経路を見つけ、セキュリティ・ソリューションに対する回避策を素早く見つけます。
一貫性のあるポリシーの実施不能:組織のクラウドネイティブインフラストラクチャには、通常、複数のクラウドサービスプロバイダと異なるセキュリティツールが含まれているため、セキュリティポリシーを一元化して一貫性を持って適用することは困難です。
設定ミス:アプリケーション開発プロセスに統合されたセキュリティが歴史的に欠如しているため、設定ミスやオープンソースコードの脆弱性の余地があり、その結果、データの漏洩や ワークロードへの 不正アクセスが発生する可能性があります。
遅いセキュリティプロセス:高速なCI/CDパイプラインで要求される用心深いコンプライアンスとセキュリティを維持することは、クラウド・コンピューティング固有の柔軟性、俊敏性、スピードを低下させます。
安全でないデフォルト:CSPが提供するクラウド・ネイティブ・ツールの多くは柔軟な設定を提供していますが、その中にはセキュリティ違反につながりかねない安全でないデフォルト設定も含まれています。
ソフトウェア・サプライチェーンの脆弱性:オープンソースソフトウェアの未パッチの脆弱性は、ソフトウェアサプライチェーンの脆弱性を増大させます。
適切なツールがあれば、セキュリティチームはクラウドネイティブのセキュリティ課題を解決できます。 クラウドネイティブアプリケーション保護プラットフォーム(CNAPP) は、単一のダッシュボードで継続的な可視性を提供し、クラウド環境全体で一貫したセキュリティポリシーの実施を実現します。