クラウドネイティブの分析

クラウドネイティブとは

過去数年間、クラウド コンピューティング、分散アーキテクチャ、およびマイクロ サービス アーキテクチャの概念は比較的ホットでしたが、過去 2 年間で、分散アーキテクチャおよびマイクロ サービス アーキテクチャについて話している人々の声は大幅に低下しました。クラウドネイティブ、クラウドネイティブアーキテクチャという言葉がよく出てきますが、クラウドネイティブとは何か、クラウドネイティブアーキテクチャと分散アーキテクチャ前提のマイクロサービスアーキテクチャとの違いは何なのか、そんな疑問からクラウドネイティブの定義を探ります。現在、クラウド ネイティブの理解にはさまざまな意見があり、統一された標準化された説明はありませんが、CNCF によるクラウド ネイティブの最新の定義は、誰もがよく目にする見解の 1 つです。

クラウド ネイティブ テクノロジにより、組織は、パブリック クラウド、プライベート クラウド、ハイブリッド クラウドなどの最新の動的な環境でスケーラブルなアプリケーションを構築および実行できます。コンテナー、サービス メッシュ、マイクロサービス、不変のインフラストラクチャ、および宣言型 API は、このアプローチの例です。

これらの手法により、回復力があり、管理しやすく、監視可能な疎結合システムが可能になります。堅牢な自動化と組み合わせることで、エンジニアは最小限の労力で、影響の大きい変更を頻繁かつ予測どおりに行うことができます。

クラウドネイティブ テクノロジにより、組織は、パブリック クラウド、プライベート クラウド、ハイブリッド クラウドなどの最新の動的環境で、弾力的にスケーラブルなアプリケーションを構築および実行できます。代表的なクラウドネイティブ テクノロジには、コンテナー、サービス グリッド、マイクロサービス、不変のインフラストラクチャ、宣言型 API などがあります。これらの手法により、フォールト トレラントで管理しやすく、監視可能な疎結合システムの構築が可能になります。強力な自動化と組み合わせることで、クラウドネイティブ テクノロジーにより、エンジニアの労力を最小限に抑えて、頻繁で予測可能な重大な変更が可能になります。

初めてこの説明を見た方は、まだクラウドネイティブをよく理解できていないと思います。この記事では、クラウド ネイティブに関連する概念を現地語で紹介しようとします。クラウドネイティブとは「Cloud Native」という言葉で、ネイティブとは英語でネイティブを意味し、クラウドアプリケーションがネイティブのようにクラウド環境に適応し、クラウド環境の柔軟性を使いこなし、さまざまなクラウド環境条件に冷静に立ち向かうことができることを意味します。複雑さの問題が発生します。クラウドネイティブ アーキテクチャは、アプリケーションをクラウド上でクラウドネイティブな方法でより適切に実行できるようにするためのアーキテクチャの原則とベスト プラクティスのコレクションです。クラウドネイティブ アーキテクチャの中心となるアイデアは、クラウド アプリケーションの非ビジネス コード部分のストリッピングを最大化することです。これにより、クラウド インフラストラクチャがアプリケーションの多数の非機能的機能 (柔軟なスケーラビリティ、高可用性など) を引き継ぐことができます。アプリケーション、アプリケーション障害の自己修復機能、オブザーバビリティなどを適用して、開発および運用保守担当者がビジネス自体により集中できるようにします。

クラウドに移行する理由

クラウドネイティブ アーキテクチャは、アプリケーションがクラウド上でより適切に使用できるようにすることを目的としています。次に、アプリケーションがクラウドに移行する理由をまず理解する必要があります。

技術的な観点からは、2 つの利点があります。

• クラウドに移行する最初の利点は、アプリケーションの柔軟なスケーリングを実現することです. クラウドは分散アーキテクチャに基づいて構築されており、本質的に水平方向の拡張が可能です. このような技術的特徴により、システムのビジネス量が急速に増加した場合でも、アプリケーション システムのサポート能力を効果的に保証することができ、インフラストラクチャの利用効率を向上させ、ビジネス中にリソースを拡張することができます。ビジネスのピークが低い時間帯には、ピークとリソースを削減できます。リソースの冗長な計画と構築を減らします。

• クラウドに移行することの 2 つ目の利点は、製品提供モデルに変化がもたらされることです。元のオフライン製品配信では、各製品は独自の構造を持ち、特定の方法でプロジェクトに配信され、プロジェクト展開担当者はホスト コンピューターで手動操作を実行するか、ツールを使用して、製品展開ドキュメントに従って製品展開を実装します。 . 標準化された配信アクションと自動化された配信プロセスがないため、製品配信サイクルは比較的長く、配信効率は比較的低く、この配信モードは大規模な製品インスタンスの展開要件をサポートできません。クラウド移行後、継続的デリバリー＋コンテナ化技術をベースにソフトウェアや製品をCDプロセスにより標準化されたイメージにパッケージ化することで、マルチクラウド環境への迅速な展開を効率的に実現し、アジャイルデリバリーのコンセプトを実現します。リードタイムも元の月から時間または日に増加します。

ビジネスの観点から見ると、クラウドへの移行はビジネスのビジネス モデルに革新をもたらしました。オフラインのシステムがオンラインのシステムに変わり、ビジネス価値の相互作用効率が大幅に向上しました。クラウドへの移行は、企業にコストの恩恵をもたらし、企業が元の CAPEX モデルから OPEX モデルに移行するのに役立ちます。システムがクラウドに移行された後、システムは上流および下流の顧客とより密接に接続され、システムの生態学的発展に無限の可能性を提供し、より多くのビジネス革新を助長します.

クラウドに適用する方法は何ですか

クラウドへの移行の利点を理解した企業は、実際の状況に応じて適切なクラウドへの移行方法を選択する必要があります。

最初の方法: 再ホスト

アプリケーションの動作環境を変えることなく、システムとデータをクラウドに移行します。直接移行には、通常、物理マシンから仮想マシンへの移行、または仮想マシンから仮想マシンへの移行が含まれます。企業が迅速にクラウドに移行したい場合、またはクラウドに移行する必要がある大規模なアプリケーションがある場合は、直接移行が最も適切で効果的な移行方法です。

2 番目の方法: 再プラットフォーム化

アプリケーションのコアアーキテクチャを変更しないことを前提として、データやシステムをクラウドに移行する際に、アプリケーションプログラムの簡単なクラウド最適化を行う方法を「パッチ適用後移行」と呼んでいます。たとえば、元のリレーショナル データベースをクラウド サービス プロバイダーが提供するデータベース サービスに置き換えたり、元の自作メッセージ ミドルウェアをクラウド サービス プロバイダーが提供するメッセージ キュー サービスに置き換えたりします。ほとんどの企業は、このアプローチを使用して管理コストを削減し、効率を高めています。

3 番目の方法: リファクタリング

「再構築」とは、アプリケーションのアーキテクチャや開発モデルを再構築して、クラウドネイティブなアプリケーション サービスを実現することです。既存のアプリケーション環境が将来の使用を満たすことが困難な場合、またはパフォーマンスとスケールが将来のニーズを満たすことができない場合、「再構築」移行モードが採用されます。「再構築」は、他の方法と比較してコストが最も高くなりますが、長期的には、将来のビジネスやシステムのニーズによりよく対応できます。

次の表は、クラウドにアクセスする 3 つの方法で考慮される要素の比較を示しています。

クラウド ネイティブ アーキテクチャで使用されるテクノロジーの紹介

クラウド ネイティブ アーキテクチャ テクノロジの初期の言及では、トロイカ、マイクロサービス + コンテナー化 + DevOPS がありました。これら 3 つの技術システムにより、アプリケーションはリファクタリング モードでクラウドに移行するという目標を達成できます。これは、すでにクラウドに移行しているほとんどの企業が採用している技術的手段です。

また、クラウド ネイティブ アーキテクチャは絶えず発展していますが、一方ではビジネス開発のニーズに伴い、モノのインターネットと 5G テクノロジが広く使用されており、エンタープライズ アプリケーションは単一のクラウド上で実行する形式を満たしていません。マルチクラウド、ハイブリッド クラウド、クラウド エッジ コラボレーション、エッジ コンピューティングなどのより良い運用を実現することが期待されています。一方、サービス メッシュやサーバーレスなど、クラウド上でサービスを実行する際の複雑さとコストを削減するテクノロジの出現など、クラウド ネイティブ テクノロジは常に改革と革新を続けています。そのため、クラウドネイティブ アーキテクチャで使用されるテクノロジは常に更新されています。CNCF が検討しているクラウドネイティブ アーキテクチャ テクノロジーには、サービス ネットワーク、不変インフラストラクチャ、宣言型 API の 3 つのテクノロジーが追加されています。

したがって、クラウド ネイティブ アーキテクチャの中心的な概念に目を向ける必要があります.アプリケーションがクラウド ネイティブをより適切に実現するのに役立つ技術的な実践である限り、クラウド ネイティブ アーキテクチャ技術として分類されるべきです.次に、どの技術がどのような技術であるかを紹介します.主にクラウド ネイティブ アーキテクチャで使用されます。

マイクロサービス

マイクロサービス アーキテクチャは単一のアーキテクチャに関連しており、この 2 つは異なるアーキテクチャ スタイルに属しています。マイクロサービス アーキテクチャでは、サービスは、いくつかの有用な機能を実装する、独立してデプロイ可能な単一のソフトウェア コンポーネントです. サービスの API は、その内部実装をカプセル化します. モノリシック アーキテクチャとは異なり、開発者は、サービスの API をバイパスすることはできません サービス内のメソッドとデータへの直接アクセス.したがって、マイクロサービス アーキテクチャは、アプリケーションのモジュール性を強化します。

マイクロサービス アーキテクチャのコア機能は、サービス間の疎結合です。サービス間の対話は、サービスの実装の詳細をカプセル化する API を使用して行われるため、クライアントに影響を与えることなく実装メソッドを変更できます。

マイクロサービス アーキテクチャは、大規模なシステムをビジネス サービスの粒度に応じて分割し、各サービスを個別に開発、テスト、検証、および展開することができます。

• 大規模で複雑なアプリケーションの継続的な配信と継続的な展開を可能にします
• 各サービスは比較的小さく、保守が容易です
• サービスは個別にデプロイ可能
• サービスは独立してスケーリングできます
• チームの自律性を可能にするマイクロサービス アーキテクチャ
• 新しいテクノロジーの実験と採用が容易になる
• 耐障害性の向上

しかし、マイクロサービスは特効薬ではありません. マイクロサービスの導入にはコストがかかります. マイクロサービスを使用すると、問題の特定の複雑さ、ログ分析、アプリケーションの可観測性、アプリケーションの高可用性などの複雑さなどの点で、より多くの技術的課題が発生します. 、企業はビジネスのさまざまな段階に応じてそれらを合理的に導入する必要があり、マイクロサービスのためだけに「マイクロサービス」を完全に導入することはできません。

マイクロサービスの技術分野では、Whale Technology は、マイクロサービス フレームワーク製品である ZDubbo と、マイクロサービス ガバナンス プラットフォーム製品である SGP を提供しています。

SGP 製品機能図:

DevOPS

DevOPSにはDev分野とOPS分野があり、Dev分野は製品の高頻度継続的デリバリーを実現するためのアジャイルな研究開発の概念を実装し、OPS分野はシステムの可観測性の要件を満たすためにさまざまな運用および保守機能を提供します。

Whale Technologyは、DevOPSの分野でZCM製品を提供しています

容器

コンテナー イメージ テクノロジに基づいて、アプリケーションの実行に必要な完全な環境がイメージに直接パッケージ化されます。このようにして、アプリケーションのコンテナベースの配信機能を実現でき、配信効率が向上しますが、コンテナの軽量特性に基づいて、迅速に引き上げる機能の要件を満たすことができます。クラウド アプリケーションが弾力的にスケーラブルな場合のアプリケーション。

ホエールテクノロジーは、コンテナ分野でコンテナクラウドプラットフォーム製品を提供します

クラウド ネイティブ ミドルウェア

クラウドネイティブ ミドルウェアは、クラウド上でアプリケーションを実行するために必要なより多くの技術コンポーネント機能を提供し、高性能、高安定性、使いやすく操作しやすい技術コンポーネントを提供し、ビジネス アプリケーションが技術的な複雑さを保護して実現するのに役立ちます。テクノロジーの再利用。

ミドルウェアの分野では、分散キャッシュ ミドルウェア製品 ZCache、分散メッセージ ミドルウェア製品 ZMQ、および分散データベース ミドルウェア製品 ZDAAS を提供しています。

ZCache 製品機能図

ZMQ 製品機能の概略図

ZDAAS製品機能の模式図

サービスネットワーク

サービス メッシュは、サービス間通信を処理するための専用のインフラストラクチャ レイヤーであり、マイクロサービス間のリクエストを確実に配信します。通常、サービス メッシュは、アプリケーション自体を意識せずにアプリケーション コードと一緒にデプロイされる一連の軽量ネットワーク プロキシを介して実装されます。

規模の拡大と複雑化に伴い、サービス グリッドにはますます多くの機能が含まれるようになり、その要件には、サービスの検出、負荷分散、障害復旧、インジケーターの収集と監視、および通常は A /B テストなどのより複雑な運用と保守の要件が含まれます。カナリア リリース、トラフィック制限、アクセス制御、エンドツーエンド認証など。その展開構造を次の図に示します。

サービス グリッドには次の特徴があります。 - アプリケーション間通信用の中間層 - 軽量ネットワーク プロキシ - アプリケーションに依存しない - 分離されたアプリケーションの再試行/タイムアウト、監視、追跡、およびサービス検出 - 言語間のサービス通信機能。

不変のインフラストラクチャ

ワークロード (コンテナー、仮想マシンなど) は、デプロイ後に変更することはできません。何かを更新、修正、または変更する必要がある場合は、古いものを実績のある新しいワークロードに置き換えるだけです。

不変のインフラストラクチャの役割は、主にシステムの安定性に反映されます。従来のアプリケーションがユーザー固有のサーバーにデプロイされると、サーバー システムは変化し続けます. オペレーティング システムがアップグレードされるか、新しいアプリケーションがインストールされると、競合が発生する可能性があり、その結果、アプリケーションを引き続き使用する必要があります.ユーザーのシステム環境の変化に伴い、バージョンアップ、途中で新たな問題が次々と出てきます。不変インフラストラクチャは、これらの問題をすべて回避します。クラウドネイティブ アプリケーションは不変インフラストラクチャにデプロイされるため、変更の問題はありません。

宣言型 API

宣言型 API は、命令型 API よりも高度なインターフェイス設計方法です. 簡単に言えば、命令型 API はユーザーに何を行う能力を提供しますが、宣言型 API はユーザーに何を行う能力を提供します. 宣言型 API に基づいて、クラウド アプリケーションはインフラストラクチャ機能をより簡単に使用できるようになり、ビジネス開発がビジネス自体に集中できるようになります。

クラウド ネイティブ アーキテクチャ成熟度評価システム

クラウド上のアプリケーションの有効性を評価する方法として、Alibaba Cloud はクラウドネイティブ アーキテクチャ成熟度モデル (SESORA) を提供しており、クラウドネイティブをサービス機能 (Service)、弾力性機能 (Elasticity)、およびサーバーレス度 (Serverless) に分割しています。 、Observability(オブザーバビリティ)、Resilience(レジリエンス)、Automation level(自動化)の6つの異なる次元(SESORA)で、各評価次元はACNA-1からACNA-4までの4つの異なるレベルを設定し、順番に0から3までカウントされます。同時に、ゼロ レベル、基礎レベル、開発レベル、成熟レベルの 4 つの異なる成熟度レベルが設定されます。クラウド ネイティブ アーキテクチャの成熟度モデルは、企業のクラウド ネイティブ化の現状、不明確な機能と開発パスの評価と最適化の方向性を提供し、企業がデジタル トランスフォーメーションの「最短パス」に着手するのを支援するために提案されています。