もう混乱しないでください。クラウドネイティブをこのように理解できるかもしれない

過去2年間、クラウドネイティブの人気は、2014年の3Dプリンティングや2018年のブロックチェーンに劣らない。それは人々に「まるで春風が一夜にして吹き荒れ、何千本もの梨の木が花を咲かせる」というデジャブの感覚を与える。そこで筆者は、この「東風」を利用してクラウドネイティブについて語ってみたいと思います。クラウドネイティブの概念が明確ではないため、著者の理解に偏りがある可能性があります。文章に誤りがありましたら、ご訂正ください。

実際、クラウド ネイティブの完全な英語名は「CloudNative」であり、この単語は Cloud と Native という 2 つの単語に分けられます。Cloud はクラウドを意味し、アプリケーションが従来のデータ センターやサーバーではなくクラウド上にあることを示します。ネイティブとは、ネイティブ、土着、ローカル、自家製を意味し、アプリケーションがクラウド環境向けに特別に設計されていることを示します。ご想像のとおり、「クラウド ネイティブ」の中国語名は、クラウド ネイティブ、クラウド ローカル、クラウド ネイティブではなく、非常に美しい名前であるクラウド ネイティブを使用しています。

したがって、クラウド ネイティブとは、アプリケーションを構築および実行するための技術的なシステムと方法論です。この技術システムは、設計の最初からクラウド環境を考慮し、クラウド プラットフォームの弾力性と分散性の利点を最大限に活用して発揮します。ファーウェイはかつて、クラウドネイティブ アーキテクチャに準拠したアプリケーションについて、コンテナ化にオープン ソース スタック (K8S+Docker) を使用し、マイクロサービス アーキテクチャに基づいて柔軟性と保守性を向上させ、アジャイル手法と DevOps を使用して継続的な反復と運用および保守の自動化をサポートし、クラウド プラットフォーム機能を使用して、弾力的なスケーリング、動的スケジューリング、リソース使用率の最適化を実現すると説明していました。

Huawei の説明から、クラウド ネイティブの 4 つの要素、つまりコンテナ化、マイクロサービス、DevOps、継続的デリバリーがわかります。これらは現在認識されており、Pivo​​tal によってまとめられた 4 つの主要要素でもあります。この点に関して、さまざまなクラウド コンピューティング ベンダーが元の 4 つの要素を拡張し、独自の洞察を持っています。

2013 年に、Pivo​​tal の Matt Stine 氏が初めてクラウド ネイティブの概念を提案しました。

2015 年の「クラウド ネイティブ アーキテクチャへの移行」では、クラウド ネイティブ アーキテクチャの特徴として、12 の要素、マイクロサービス、自己アジャイル アーキテクチャ、API ベースのコラボレーション、回復力が定義されました。

同年、Cloud Native Computing Foundation (CNCF) が設立され、クラウド コンピューティングをコンテナ化されたパッケージング + 自動管理 + マイクロサービスとして定義しました。

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

当時、Pivo​​tal はクラウド ネイティブを DevOps + 継続的デリバリー + マイクロサービス + コンテナとして要約していました。

2018 年、CNCF はクラウド ネイティブの定義を更新し、サービス メッシュと宣言型 API を含めました。

クラウドネイティブの誕生から発展に至るまで、クラウドネイティブの定義は継続的に改良され、概念に混乱や不統一が生じているのが現状です。しかし、現在、ほとんどのクラウド コンピューティング企業は、クラウド ネイティブを定義するために DevOps + 継続的デリバリー + マイクロサービス + コンテナーを使用することに慣れています。次に、クラウドネイティブの4つの主要要素について簡単に理解しておきましょう。

1. マイクロサービス

マイクロサービスとは、独立したコンポーネントとしてアップグレード、段階的に移行、または再利用できる、独立してリリースされるアプリケーション サービスです。各サービスは、専用の組織によって独立して完了できます。依存側は、サービスを完全に開発するために、入力ポートと出力ポートを決定するだけで済みます。チーム全体の組織構造をさらに合理化し、コミュニケーションコストを削減し、効率を高めることができます。

2. デブオプス

DevOps は文字通り、開発者と運用担当者を意味する Dev と Ops という単語を組み合わせたものです。実際、DevOps は一連のプロセス、方法、システムを表す一般的な用語です。 DevOps では、自動化されたツールを通じてチームを効率的に編成し、共同作業とコミュニケーションを行ってソフトウェア ライフサイクル管理を完了し、より安定したソフトウェアをより迅速かつ頻繁に提供することに重点を置いています。

3. 継続的デリバリー

アジャイル開発では、大規模なグループ環境で常にバージョンが利用可能であることが求められるため、継続的な配信が必須です。継続的デリバリーの目的は、顧客ニーズの変化に迅速に対応することであり、そのためには非常に頻繁なリリースが必要になります。そのため、同時に複数のバージョンでサービスを提供することになるため、グレースケールリリース/カナリアリリースなどに対応する必要があります。

4. コンテナ化

Docker は、ソフトウェア業界で最も人気のあるソフトウェア コンテナ プロジェクトです。 Docker はアプリケーション分離の役割を果たしており、マイクロサービスとそのすべての必要な構成、依存関係、環境変数を、移植性に優れた新しい非差別的なオペレーティング環境に移行します。ただし、Docker は分散アプリケーションの展開とオーケストレーションを考慮しておらず、Docker-compose を含め、ネットワークとストレージに関してより優れた方法を提案していません。

また、ネイティブ展開とオンプレミス展開の違いは何ですか?

1. プログラミング言語

ローカルに展開される従来のアプリケーションは、C/C++ およびエンタープライズ レベルの Java で記述されていると報告されています。クラウドネイティブ アプリケーションは、ネットワーク中心の Go や node.js などの新興言語で記述する必要があります。

2. 継続的デリバリー

ローカルに展開された従来のアプリケーションでは、更新のためにダウンタイムが必要になります。クラウドネイティブ アプリケーションは常に最新の状態である必要があり、頻繁な変更、継続的な配信、ブルーグリーン デプロイメントをサポートする必要があります。

3. ダイナミックな拡張

ローカルに展開された従来のアプリケーションは動的に拡張できず、トラフィックのピークに対処するために冗長なリソースが必要になることがよくあります。一方、クラウド ネイティブ アプリケーションは、クラウドの弾力性と自動スケーリングを活用して、共有を通じてコストを削減し、効率を高めます。

4. ネットワーク制限

ローカルに展開される従来のアプリケーションは、IP やポートなどのネットワーク リソースに依存し、ハードコードされていることもありますが、クラウド ネイティブ アプリケーションには、ネットワークやストレージに関するそのような制限はありません。

5. 自動化

ローカルに展開される従来のアプリケーションは通常、手動で展開および保守されますが、クラウドネイティブ アプリケーションはすべて自動化されています。

6. 携帯性

ローカルに展開される従来のアプリケーションは通常、システム環境に依存しますが、クラウド ネイティブ アプリケーションはどのシステム環境にも固定されていません。代わりに、優れた移植性を実現するために抽象的なインフラストラクチャに依存しています。

7. サービスアーキテクチャ

ローカルにデプロイされる従来のアプリケーションの中には、モノリシック (モノリス) アプリケーションであったり、強い依存関係があったりするものがありますが、マイクロサービス アーキテクチャに基づくクラウド ネイティブ アプリケーションは、サービスを垂直に分割し、よりモジュール化されています。