クラウド ネイティブは「世界を食い尽くす」大物です...

過去 1 年間、クラウド ネイティブは間違いなくクラウド コンピューティングの分野で最もホットなトピックでした。しかし、1年が経過した現在でも、クラウド ネイティブとは何かを説明できる人はほとんどいません。インターネット上の科学雑誌の記事もわかりにくく、読んでもまだよくわかりません…

今回の「SFKP・コンピュータ百科事典」では、クラウド ネイティブの概念、特徴、適用シナリオを明らかにして、皆さんが「クラウド ネイティブ」の定義を頭の中でイメージできるようにお手伝いします。

クラウドネイティブの概念

[[314289]]

用語集: クラウドネイティブ

Cloud Native は、クラウド ネイティブと翻訳され、Matt Stine によって提唱された概念です。 DevOps、継続的デリバリー、マイクロサービス、アジャイルインフラストラクチャ、コンウェイの法則など、ビジネス能力に応じた企業の再編など、さまざまなアイデアをまとめたものです。クラウド ネイティブには、テクノロジーと管理の両方が含まれており、一連のクラウド テクノロジーとエンタープライズ管理方法の集合体であると言えます。 (Baidu百科事典より)

「クラウド ネイティブ」という用語は、実際には孤立したものではありません。これは、2013 年に Pivotal (米国カリフォルニア州のコンピュータ ソフトウェア会社) によって初めて提案されました。2015 年に、同社の Matt Stine 氏は著書「Migrate to Cloud Native Architecture」で、クラウド ネイティブ アーキテクチャのいくつかの特徴 (12 の要素、マイクロサービス、自己アジャイル アーキテクチャ、API ベースのコラボレーション、回復力) を定義しました。

2017 年、Matt Stine 氏はメディアのインタビューで、クラウド ネイティブ アーキテクチャをモジュール性、可観測性、展開可能性、テスト可能性、置き換え可能性、処理可能性という 6 つの特性にまとめました。

Pivotal の最新の公式 Web サイトでは、クラウド ネイティブを DevOps + 継続的デリバリー + マイクロサービス + コンテナという 4 つの主要ポイントにまとめています。

2015 年に、Cloud Native Computing Foundation (CNCF) が設立されました。彼らは当初、クラウド ネイティブを次のように定義しました: コンテナ化されたパッケージング + 自動管理 + マイクロサービス指向。

2018 年に CNCF はクラウド ネイティブの定義を更新し、サービス メッシュと宣言型 API を追加して、不変インフラストラクチャ、コンテナー、サービス メッシュ、マイクロサービス、宣言型 API という現在のバージョンになりました。

クラウド ネイティブの概念は確かに常に変化しており、権威ある組織の間でもクラウド ネイティブの概念や定義には違いがあることがわかります。

しかし、これらは実際には重要ではありません。要因は常に変化しています。根本的な原因は、クラウド ネイティブを実装する方法が絶えず変化していることです。上に挙げた要素はいずれもクラウド ネイティブを実現するための手段ですが、これらを備えているからといって必ずしもクラウド ネイティブになるわけではありませんし、これらを備えていないからといって必ずしもクラウド ネイティブを実現できないわけではありません。

しかし、クラウドネイティブとは何かを議論しているので、現在の開発状況に基づいて分析することしかできません。さまざまな権威ある機関や組織によれば、マイクロサービス、コンテナ、DevOps、継続的デリバリーが不可欠です。今日は、次の 4 つの要素の分析に焦点を当てます。

1. マイクロサービス

マイクロサービスは、単一の責任と機能に重点を置いた小さな機能ブロックに基づくソフトウェア アーキテクチャ スタイルであり、モジュール アプローチを使用して複雑な大規模アプリケーションを組み合わせます。各機能ブロックは、言語に依存しない API セットを使用して相互に通信します。

クラウド ネイティブのほぼすべての定義にはマイクロサービスが含まれています。マイクロサービスの核となる手法はカッティングであり、これはソフトウェア開発で常に追求してきた低結合＋高凝集の問題を解決し、将来のシステム変更にも柔軟に対応します。

2. コンテナ

コンテナ化はマイクロサービスの実装保証を提供し、アプリケーションの分離に役立ちます。利点は、各サービスが区別なくコンテナ内にカプセル化され、区別なく管理および保守できることです。現在、より人気のあるツールは Docker と Kubernetes です。

Docker は、ソフトウェア コンテナー内のアプリケーションの展開を自動化するオープン ソース プロジェクトであり、Linux オペレーティング システムに追加のソフトウェア抽象化レイヤーを提供し、オペレーティング システム レベルの仮想化の自動管理メカニズムを実現します。 Docker は最も広く使用されているコンテナ エンジンでもあり、Cisco や Google などの企業のインフラストラクチャで広く使用されています。

Google が開発した Kubernetes は、コンテナの自動展開、管理、スケーリングを可能にするツールであり、コンテナ間の負荷分散、障害が発生したコンテナの再起動、コンテナが使用するストレージのオーケストレーションなどの強力な機能を提供します。

コンテナはクラウドネイティブ アプリケーションにさらなる利点を追加します。コンテナを使用すると、環境を再構成することなく、マイクロサービスとそれらに必要なすべての構成、依存関係、環境変数を完全に新しいサーバー ノードに移動できるため、強力な移植性が実現します。

3. デブオプス

DevOps (Development と Operations の組み合わせ) は、ソフトウェア開発者と IT 運用技術者間のコミュニケーションとコラボレーションを重視する文化、運動、または実践です。 「ソフトウェア配信」と「アーキテクチャ変更」のプロセスを自動化することで、ソフトウェアの構築、テスト、リリースをより迅速かつ頻繁に、そしてより信頼性の高いものにすることができます。

DevOps は、ソフトウェア製品とサービスを予定どおりに提供するには開発と運用が緊密に連携する必要があるというソフトウェア業界の認識の高まりの結果として登場しました。

企業やプロジェクトが優れたコミュニケーション効率を備えている場合にのみ、生産性が向上します。 DevOps の導入は、製品の提供、テスト、機能開発、メンテナンス (かつてはまれでしたが、現在では一般的になっている「ホット パッチ」を含む) に大きな影響を与える可能性があります。

4. 継続的デリバリー

継続的デリバリー（CD）とは、ソフトウェア製品の製造プロセスを短いサイクルで完了させ、ソフトウェアをいつでもリリースできる状態で安定的かつ継続的に維持できるようにするソフトウェアエンジニアリング手法です。その目標は、ソフトウェアの構築、テスト、リリースをより迅速かつ頻繁に行うことです。このアプローチにより、ソフトウェア開発のコストと時間を削減し、リスクを軽減できます。

継続的デリバリーの一般的な表現は、サービスの使用に影響を与えることなく、ユーザーに頻繁に新しい機能をリリースすることです。

これを達成するのは非常に困難です。一般的な要件は、時間どおりに開発し、ダウンタイムなしで更新することです。これには、開発バージョンと安定バージョンの共存が必要であり、多くのプロセスとツールのサポートが必要です。

継続的デリバリーは継続的デプロイメントと混同されることがあります。継続的デプロイメントとは、すべての変更が自動的に本番環境にデプロイされることを意味します。継続的デリバリーとは、すべての変更を本番環境にデプロイできることを意味しますが、ビジネス上の理由により、デプロイしないことを選択することもできます。

継続的デプロイメントを実装する場合は、まず継続的デリバリーを実装する必要があります。

クラウドネイティブとオンプレミス展開の違い

クラウド ネイティブの概念を理解したところで、クラウド ネイティブとローカル デプロイメントの違いを見てみましょう。

真のクラウド化は、インフラストラクチャとプラットフォームの変更だけではありません。アプリケーションも変更する必要があります。新しいクラウドベースのアプリケーション、つまりクラウドネイティブ アプリケーションを構築するには、アーキテクチャ設計、開発方法、展開、保守などのすべての段階と側面をクラウドの特性に基づいて再設計する必要があります。

ここでは、アリババの上級技術専門家である Jiangyou (ニックネーム) が公開した記事からの分析を引用します。

• ローカルに展開される従来のアプリケーションは、多くの場合 C/C++ やエンタープライズ レベルの Java で記述されますが、クラウド ネイティブ アプリケーションは、ネットワーク中心の Go や Node.js などの新興言語で記述する必要があります。
• ローカルに展開された従来のアプリケーションでは、更新のためにダウンタイムが必要になる場合がありますが、クラウドネイティブ アプリケーションは常に最新の状態に保たれ、頻繁な変更、継続的な配信、ブルーグリーン展開をサポートする必要があります。
• ローカルに展開された従来のアプリケーションは動的に拡張できず、トラフィックのピークに対処するために冗長なリソースが必要になることがよくあります。一方、クラウド ネイティブ アプリケーションは、クラウドの弾力性と自動スケーリングを活用して、共有を通じてコストを削減し、効率を高めます。
• ローカルに展開される従来のアプリケーションは、IP やポートなどのネットワーク リソースに依存し、ハードコードされていることもありますが、クラウド ネイティブ アプリケーションには、ネットワークやストレージに関するそのような制限はありません。
• ローカルに展開される従来のアプリケーションは通常、手動で展開および保守されますが、クラウドネイティブ アプリケーションはすべて自動化されています。
• ローカルに展開される従来のアプリケーションは通常、システム環境に依存しますが、クラウド ネイティブ アプリケーションはどのシステム環境にも固定されていません。代わりに、優れた移植性を実現するために抽象的なインフラストラクチャに依存しています。
• ローカルにデプロイされる従来のアプリケーションの中には、モノリシック (モノリス) アプリケーションであったり、強い依存関係があったりするものがありますが、マイクロサービス アーキテクチャに基づくクラウド ネイティブ アプリケーションは、サービスを垂直に分割し、よりモジュール化されています。

クラウド ネイティブ アプリケーションに移行するには、概念で説明したマイクロサービス、コンテナー、DevOps、継続的デリバリーといった新しいクラウド ネイティブ メソッドを使用する必要があることがわかります。

クラウドネイティブ「世界を食べる」

この写真は、誰にとっても馴染みのある、また馴染みのない写真であるに違いありません。

2011 年にマーク・アンドリーセンは「ソフトウェアが世界を飲み込んでいる」と述べました。 3年後、ジョナサン・ブライスはこう付け加えた。「この世のあらゆるものはオープンソースから生まれている」その後、業界では「クラウド コンピューティングは空の色を変えた」という意見が一般的になりました。しかし、現在ではクラウドコンピューティングの概念は明確に細分化されており、「クラウドネイティブ」が最大のテーマとなっています。

クラウド ネイティブは非常に優れているので、すぐにクラウド ネイティブ アーキテクチャに切り替えるべきでしょうか?

クラウドネイティブの核はアプリケーションなので、実際のアプリケーションはより慎重になる必要があると思います。企業の実際のニーズを考慮する必要があります。現在のアーキテクチャはビジネス開発に影響しますか?取り壊しと再建にかかる費用を負担できますか?

これらはすべて考慮する必要がある問題です。

昨年、Lingque Cloudは生態調査を実施しました。国内上位100社のITソリューションプロバイダー（ISV）のうち、約60～70％が自社の企業内でクラウドネイティブの概念に触れています。しかし、調査対象を上位300社まで拡大すると、この認知度は大幅に低下するでしょう。これは、大企業がより多くの顧客にサービスを提供し、より良いサービスを提供するために、より多くのクラウドネイティブ機能が必要であることを示しています。

小規模企業は柔軟性が高い反面、需要はそれほど強くありません。一方、クラウド ネイティブは依然として継続的な反復と変更が行われており、この変更には多くのリスクが伴います。

しかし、デジタル運用は企業の発展にとって避けられない選択となっており、クラウドネイティブ技術とデータミドルプラットフォームは、デジタル運用を実現するために必要な革新的な技術と方法論です。しかし、ほとんどの企業はデジタル変革のプロセスに多大な労力と時間を費やしていますが、クラウドネイティブとデータミドルエンドテクノロジーの方法論に対する理解が不足しており、深い理解を得るための適切なプラットフォームとシステムがないため、多くの回り道をしています。

クラウド ネイティブはエンタープライズ開発にとって良い薬ですが、有害でもあります。慎重になるべきだ。