クラウドネイティブ時代において、アプリケーション アーキテクチャはどのように進化するのでしょうか?

クラウドネイティブはPaaSが主なクラウドプラットフォームとなる段階に入った

Alibaba は IaaS クラウドの段階を経て、PaaS クラウドの時代に入りました。アリババは昨年の「ダブル11」期間中、主にIaaS層において、コアとなる電子商取引システムの完全なクラウド移行をすでに達成していた。いわゆる IaaS は、主にコンピューティング、ネットワーク、ストレージの仮想化です。この段階を経て、アリババはPaaSクラウド段階に入りました。 PaaS クラウド ステージでは、ミドルウェア、ストレージ、キャッシュ、さらにはアプリケーション ホスティング プラットフォームなど、さらに多くのクラウド製品を使用する必要があります。

​​

実は、IaaS ステージと PaaS ステージには大きな違いがあります。 IaaS ステージでは、アプリケーション開発は、通常仮想マシンまたはコンテナと呼ばれるインフラストラクチャとリソースに関係することが多く、アプリケーション アーキテクチャにはほとんど影響しません。ただし、PaaS クラウドの段階で、クラウド Redis、クラウド RDS、クラウド OSS、クラウド RabbitMQ などのクラウド製品を使用すると、アプリケーション アーキテクチャへの侵入が強くなります。では、このような侵入はアプリケーション アーキテクチャにどのような影響を与えるのでしょうか?これは、すべての R&D アーキテクトが考える必要がある質問です。

クラウドネイティブテクノロジー

クラウド ネイティブ テクノロジーを検索してみると、Google Cloud の定義、CNCF の定義、その他多くのクラウド ベンダーやオープンソース ソフトウェアの定義が表示されますが、これらの定義にはそれぞれ異なる見解があります。簡単にまとめると、下の図に示すようにいくつかのカテゴリに分けられます。垂直的な観点から見ると、アプリケーション アーキテクチャ、ライフサイクル管理、トラフィック管理、インフラストラクチャと依存関係の 4 つの次元に分かれています。水平的な視点から見ると、マイクロサービス、12 ファクター アプリ、コンテナー、BaaS、GitOps/IaC、サービス メッシュに分類されます。

​​

今日では、モノリシック アプリケーション アーキテクチャや単純な CS アーキテクチャではなく、マイクロサービス アーキテクチャに基づくクラウド ネイティブについて誰もが話しています。 Quarkus は 12 Factor Apps を提案しました。これは、現在 Quarkus などのアプリケーション ホスティング プラットフォームでアプリケーションを実行する場合、アプリケーションに対して特定の要件があり、構成やコードの分離など、おそらく 12 の原則があることを意味します。もちろん、将来的には多くの拡張が行われるでしょう。これらの原則の項目の多くは、これらの原則に準拠している限り、アプリケーション ホスティング プラットフォームが無料の運用やメンテナンスなどのより多くの機能を提供できることを意味します。コンテナの中核は、標準的な対話方法を使用して、プラットフォームがリリース、拡張、自己修復などのアプリケーション ライフサイクルを管理できるようにすることです。

BaaS（Backend as a Service）は、既存のサービスを最大限に活用してアプリケーションを構築できます。サービス メッシュの本質はトラフィックを管理することです。今日のアプリケーションはすべてトラフィックを受信して​​おり、サービスを提供する際にはトラフィックを送信する必要があります。このプロセスでは、サービス検出、トラフィック ルーティング ルールなどを管理するために、サービス メッシュ テクノロジが必要です。最後に、GitOps と IaC (Infrastructure as Code) に焦点を当てる必要があります。これらの技術は現在、業界でますます注目を集めています。まだ事実上​​の標準はありませんが、多くのクラウドコンピューティング企業がこれに熱心に取り組んでいます。つまり、今日インフラストラクチャを使用する場合、コードを使用してこのインフラストラクチャのニーズを宣言できるということです。要約すると、上記の内容はすべて、アプリケーション アーキテクチャ、ライフサイクル管理、トラフィック管理、インフラストラクチャと依存関係という 4 つの側面を中心に展開されています。

ビジネスは配送スピードを重視

ビジネスにとって、最大の懸念事項は多くの場合、配送のスピードです。ビジネス ディレクターや CTO と話をすると、ビジネスにこれほど多くのテクノロジーを導入することのメリットは何かと尋ねられるでしょう。コスト面のメリットや経営面でのメリットが語られることもありますが、ほとんどの企業にとって最も重要なのは研究開発の効率化です。したがって、クラウド ネイティブ テクノロジーがより迅速な配信の実現にどのように役立つかを考える必要があります。

クラウドネイティブテクノロジーを使用してサービス提供の速度を向上させることは、大きく分けて 3 つのステップに分けられます。

サービスとアプリケーションのための標準化されたプラットフォーム/プロトコル

プラットフォーム/サービスとアプリケーション間のプロトコルを標準化します。 IaaS 層がクラウドを使用する場合、プロトコルはマシン、つまり仮想マシン、コンテナなどです。ビジネス アプリケーションの場合、見えるのはオペレーティング システムであり、アプリケーションはオペレーティング システム上のさまざまなリソースを使用できます。これの利点は、物理的なマシンやマシンの障害を心配する必要がないことです。

ビジネスに依存しない機能をプラットフォームからさらに分離

ビジネス アプリケーションの場合、オペレーティング システムだけでなく、プラットフォームがアプリケーションの自動スケーリングや自己修復などを実現できるようにする高レベルのプロトコルが表示されます。また、アプリケーションの自動再配置にも役立ちます。基盤となるインフラストラクチャに障害が発生した場合、アプリケーションをあるマシンから別のマシンに移行できます。これがライフサイクル管理です。上記のプロトコルに基づいて、プラットフォームの多くの機能を分散化できます。例えば、本来は手動で管理する必要があったものが、コード宣言によってうまく実装できるようになります。これらのプロトコルを使用すると、ビジネス アプリケーションは関連するライフサイクル管理をプラットフォームに委託できます。

アプリケーションアーキテクチャのアップグレード

上記の 2 つのポイントに加えて、3 番目のステップでは、アップグレードを通じてアプリケーション アーキテクチャを適応させ、関連する機能をクラウド プラットフォームに転送できるようにします。

IaaSからクラウドネイティブへの移行

さらに詳しく調べてみると、当初の IaaS クラウドの段階では、ビジネス ロジックに配慮するだけでなく、ビジネス アプリケーションのライフサイクル管理やトラフィック管理にも配慮する必要があることがわかります。また、クラウド環境での Redis や Kafka の構築など、ミドルウェアを自ら構築して構成する必要もあります。つまり、クラウド プラットフォームでは管理できないアプリケーションの依存関係の管理に多くの時間が費やされていることになります。現在、PaaS クラウドやクラウド ネイティブ クラウドの段階で私たちが目指しているのは、クラウド プラットフォームが提供する機能を最大限に活用し、ビジネスそのものにより注力し、ビジネスとは関係のない一般的な技術的機能はクラウドに任せて管理することです。

​​

中心的な質問:

• ビジネスに依存しない機能をプラットフォームに切り離すにはどうすればよいでしょうか?
• プラットフォームとビジネス (アプリケーション) 間のプロトコルをどのように定義しますか?
• アプリケーション アーキテクチャをどのように適応させる必要がありますか?

過去の IaaS クラウド段階では、アプリケーションとオペレーティング システム間のやり取りのための標準プロトコルがありました。しかし、今日の PaaS クラウドの段階では、そのようなプロトコルがどうあるべきかを再定義する必要があります。さらに、このようなプロトコルに基づいて機能の下位転送を実現する方法は、Alibaba Cloud を含む多くのクラウドベンダーが行っていることでもあります。例えば、Alibaba Cloud は RocketMQ をベースに RocketMQ サービスを開発し、いくつかのコンテナ プロトコルをベースにしたコンテナ サービスなどを提供しています。もちろん、これはまだ始まったばかりであり、この部分の内容は今後さらに豊富で充実したものになるでしょう。

例1: サービスメッシュはサービス検出とトラフィックをビジネスから分離します

同時に、アプリケーション アーキテクチャも適応する必要があります。ここでは、Service Mesh を例に挙げます。以前は、アプリケーション内のトラフィックは SDK の形式でした。したがって、進化の過程で、サービス検出とトラフィックをビジネス SDK から分離して Sidecar に配置し、クラウド プラットフォームに渡して処理する方法は、アプリケーション アーキテクチャの進化の一例です。

​​

• サービス登録と検出
• トラフィックルーティング
• 交通再生
• 公開中のトラフィック制御

例2: 軽量コンテナはログ収集と業務運用を分離します

従来、ログを収集する場合、各仮想マシンでログ収集プロセスを開始し、収集したログをログ収集プラットフォームに転送し、視覚的なインターフェースを通じて分析する必要がありました。今日のクラウド ネイティブ時代では、コンテナー サービスに stdout からログをキャプチャさせるか、構成を通じて特定のログ ディレクトリからログ データを取得する方が優れたアプローチです。ただし、エージェントのアップグレードを実装するには、コレクションを Sidecar に移動する必要があります。したがって、ログ収集と業務運用を分離する軽量コンテナも、アーキテクチャの進化の一例です。

​​

• リソースの分離
• 独立したアップグレード

例3: ビジネスはプラットフォームがライフサイクル管理を実装できるようにプローブを提供する

アプリケーション アーキテクチャのライフサイクル管理の要件は、元のアプリケーションが起動後に正常であるか異常であるかであり、これはアプリケーションの運用と保守または研究開発の責任と関心事です。クラウドネイティブ時代では、このプロトコルを修正し、ビジネスを通じてプローブを提供して、アプリケーションが正常かどうかを判断することを望んでいます。これには、アプリケーション ライフサイクル管理をプラットフォーム上で実装できるように、アプリケーション内の HTTP プロトコルまたはシェルを介してヘルス情報を提供する必要があります。

​​

• 自動弾力性
• 自動巻き
• 自動再起動（自己修復）

契約 = API + 構成

全体として、プロトコルは API + 構成です。 API の場合、キャッシュを使用すると、基本的にオープン ソース プロトコルを API として扱うことになります。これは通常、クローズド ソース プロトコルよりも使いやすいものです。 RPC プロトコルの場合、オープンソースの GRPC と DUBBO はプライベート HSF よりも優れています。さらに、Terraform や Pulumi など、実際にオープンソースの構成言語を定義しているインフラストラクチャ用のプロトコルもあります。これらの構成言語は、コンテナ、ディスク、ネットワーク、ストレージなどの必要なインフラストラクチャを宣言するのに役立ちます。現在、構成言語の種類は多数ありますが、将来的には 1 つまたは 2 つの言語が最終的に存在するようになります。 Java SDK と同様に、将来のクラウド リソースの使用では必然的に SDK セットが登場し、この SDK は構成コーディング言語のセットに基づいて構築する必要があります。さらに、GitOps などのツールでは、リリース プロセスとリリース戦略を言語セットとして定義しており、将来的にはアプリケーションとクラウド間の標準プロトコルになります。

Docker (および OCI) は標準のソフトウェア配信 API です。

• RPC プロトコルとしては、オープン ソースの GRPC/DUBBO はプライベートの HSF よりも優れています。
• キャッシュ プロトコルとしては、オープン ソースの Redis はプライベートの Tair よりも優れています。
• Microsoft の Dapr は、サイドカー アーキテクチャに基づいて HTTP/GRPC レイヤーへの API を標準化し、SDK を排除して複数の言語をサポートしようとしています。
• Terraform や Pulumi などの IaC 製品は、構成言語を通じてインフラストラクチャを宣言します。
• GitOps はさらにコードを使用して、環境、リリース プロセス、リリース戦略のコンテンツを宣言します。

研究開発の重点の転換

これまで、アプリケーションではさまざまな SDK やさまざまな運用および保守イベントなど、非常に多くのことを考慮する必要がありましたが、実際にはこれらのことはモデルに抽象化され、新しい言語を使用して定義できます。これはクラウド業界全体が懸念していることでもあります。

​​

新しい言語と新しいプロトコルが常に強調される理由は、新しい言語またはプロトコルが定義された後は、アプリケーションが気にする必要があるのはそれだけだからです。開発者にとって最も重要なのはコードです。コードを使用して、インフラストラクチャ、運用と保守、ホスティングに関するアプリケーションの要件を記述できる場合、そのコードはアプリケーションにとって非常に使いやすくなります。アプリケーションがこのプロトコルに接続できる限り、プライベート クラウド、パブリック クラウド、Alibaba Cloud 上で同時に実行できます。

​​

要約する

将来的にはクラウドリソースはますます豊富になるでしょう。オペレーティング システムがプロセス機能に加えて多くの SDK を提供するのと同様に、クラウド プラットフォームはインフラストラクチャに加えてさらに多くの PaaS 機能を提供します。しかし、これらの機能は現在、非常に非効率的で非標準的な使用方法であり、使用プロセスも比較的面倒です。現在では、クラウドはアセンブリに似た形で利用されており、クラウド ネイティブでは、アプリケーションとクラウド プラットフォーム間の契約を再定義し、この契約を中心に高レベルのプログラミング言語とツールを構築しています。これは、クラウドネイティブ時代のアプリケーション アーキテクチャの進化にとって非常に重要な方向性です。

【この記事は51CTOコラムニスト「アリババオフィシャルテクノロジー」によるオリジナル記事です。転載については原著者にお問い合わせください。

この著者の他の記事を読むにはここをクリックしてください