クラウド ネイティブ テクノロジー - マイクロサービスからサーバーレス サーバーレス アーキテクチャへの進化に関する考察

今日は、マイクロサービスから ServerLess サーバーレス アーキテクチャへの進化プロセスについてお話します。以前、ServerLess について説明する記事を書きましたが、簡単な検証とテストを行うために Tencent Cloud ServerLess 環境にも申し込みました。詳細は下記記事をご参照ください。

知っておくべきサーバーレスアーキテクチャとアプリケーションシナリオ

過去 1 ～ 2 年にわたり、Alibaba、Tencent、Huawei などの主要なパブリック クラウド サービス プロバイダーは、ServerLess アーキテクチャとソリューションの推進に多大な努力を払ってきました。また、いくつかの垂直セグメンテーション シナリオでは、ServerLess アーキテクチャに基づく成熟したアプリケーションとプラクティスもいくつか見られました。しかし実際には、これらのアプリケーション シナリオは主にインターネット アプリケーションに集中していることがわかります。インターネット アプリケーションでも、基本的なサービス機能の統合、データの収集と送信、イベント応答シナリオ、IoT 垂直アプリケーションなど、かなり垂直的なシナリオがいくつかあります。

しかし、ServerLess は従来の企業情報化の分野ではほとんど使用されていません。

第二に、従来の IT アプリケーション システムの場合、マイクロサービス化してアーキテクチャを変革することは可能と言えますが、短期間で完全な ServerLess を実現することは困難です。

今日は、この記事についてもう一度お話しして、ServerLess サーバーレス アーキテクチャの重要な内容をさらに詳しく説明し、皆さんのアイデアと重要なポイントを整理できるようにしたいと思います。

サーバーレス サーバーレスアーキテクチャ

まず、サーバーレスの基本的な定義と説明を見てみましょう。

サーバーレスは、アプリケーションのデプロイメントをサーバーのデプロイメント レベルではなくサービスのデプロイメント レベルで管理できるようにする、マイクロサービス ベースのアーキテクチャを構築および管理するための完全なプロセスです。これは、サードパーティによって完全に管理され、イベントによってトリガーされ、ステートレスで一時的な（単一の呼び出しの間だけ存在する）コンピューティング コンテナー内に存在するという点で、従来のアーキテクチャとは異なります。

サーバーレス アプリケーションを構築すると、開発者はクラウドやオンプレミスでサーバーやランタイムを管理および運用する必要がなく、本番環境のコードに集中できるようになります。サーバーレスにより、インフラストラクチャの構築を伴わずにアプリケーションをデプロイし、サービスを自動的に構築、デプロイ、開始することが可能になります。

ここで改めていくつかの重要な点を強調したいと思います。

完全な意味でのリソースからサービスへ

実際、マイクロサービスについて話すとき、私たちが期待しているのは、クラウド プラットフォーム全体が、IaaS レイヤーのリソース機能の提供から PaaS レイヤーのサービス機能の提供まで、抽象化され、上方に移動し続けることです。

しかし、実際のアプリケーション開発プロセスでは、リソース層を完全に分離できていません。たとえば、自社開発の基本コンポーネントの開発と展開、および一部のデータベース リソースの展開については、現在も同様の仮想マシン リソースを申請し、自社で展開および管理しています。つまり、リソース レイヤーの完全な透明性は実現されません。

サーバーレスの段階になると、完全なサービス指向を実現する必要があります。表示および使用できるのは、API ゲートウェイを通じて公開される API インターフェース サービス機能のみであり、リソース レイヤーについてはまったく気にする必要はありません。

したがって、サーバーレスという用語は、リソースフリーとして理解できます。つまり、リソース レイヤーに直接直面するのではなく、サービス機能、順序付け、および API サービス機能の使用に直面します。

重複排除された開発フレームワークとコンポーネントの依存関係

サーバーレスは、マイクロサービスのさらなる分割として理解できます。つまり、マイクロサービスによって実装されるすべての機能が分割および分離され、各サービス機能がステートレス API インターフェース機能になります。これらの API インターフェース機能は、スクリプトを通じて実装できるクラウド機能であり、サーバーレス アーキテクチャの FaaS レイヤーを形成します。

従来のアーキテクチャ、さらにはマイクロサービス アーキテクチャでも、比較的重いマイクロサービス開発フレームワークや、共通の基盤技術コンポーネントの依存関係などが依然として存在していますが、これらすべてを Serverless では削除するか、クラウド プラットフォームによって均一に提供されるように変換する必要があります。

簡単に言えば、共通の基本フレームワーク層を削除しないと、上位層を完全に機能化することはできません。

完全に無国籍

完全に機能化するのがなぜ難しいのでしょうか?

前述の一般的な技術フレームワークの依存関係に加えて、もう 1 つの重要なポイントは、さまざまなメソッドと関数間の呼び出しが状態に存在することが多く、セッションの永続化などの関連アクションが必要になることです。

メソッド間に状態が存在すると、各メソッドまたは関数の実際の実装を完全に自己管理することはできません。初期導入、その後の弾力的なスケーリング、高可用性など、さまざまなシナリオで状態保存の問題を考慮する必要があり、全体的なアーキテクチャが複雑になります。

したがって、サーバーレスでは、イベント駆動型、ステートレス、およびあらゆるインターフェース呼び出しの終了が常に重視されます。この目的は、状態が保持されないだけでなく、FaaS 機能を担う軽量なステートレス コンテナがすぐに破棄される可能性があることも意味します。

したがって、ステートレスであることが、呼び出し回数に基づいて Serverless を課金できるようにする鍵であることもわかります。この従量課金を実現するには、リソース層の迅速な起動、作成、迅速な拡張、破棄など、さまざまな機能が必要です。

マイクロサービスからサーバーレスへ サーバーレスアーキテクチャ

実際のところ、マイクロサービスを ServerLess サーバーレス アーキテクチャと比較したり、ServerLess をマイクロサービスのその後の開発トレンドと見なしたりするのは合理的ではありません。

上の写真からわかるように

ServerLess サーバーレス アーキテクチャは、実際には、クラウド プラットフォーム全体の焦点が継続的に上方にシフトされ、機能がリソースからサービス レイヤーに継続的に抽象化されるプロセスです。

では、マイクロサービスはどこにあるのでしょうか?

マイクロサービスは、実際には PaaS レイヤーの開発の第 2 段階として理解できます。 PaaS レイヤーの最初のステージは、依然としてモノリシック アプリケーションであり、アプリケーションのスケジュールとホスティングのための仮想マシンに基づく従来の PaaS プラットフォームです。同時に、データベースやメッセージなどの技術的なサービス機能は十分に成熟していません。

クラウドネイティブ技術、特にクラウドネイティブのマイクロサービスの発展に伴い、コンテナ技術も継続的に発展しています。パブリッククラウド PaaS プラットフォームは、コンテナと技術サービスを中心としたクラウドネイティブ PaaS プラットフォームへと発展しました。このプロセスでは、従来のモノリシック アプリケーションも、より優れたパフォーマンスとスケーラビリティを実現するために、モノリスからより小さなマイクロサービスに変換されます。

この開発段階は次の図に示されています。

進化のプロセス全体を3つの段階に分けることができます。

従来のモノリシック アーキテクチャ ステージでは、クラウド プラットフォームによって提供される仮想化リソース プールのみが、弾力性のあるコンピューティング機能と弾力性のあるストレージ機能の提供に使用されることがよくあります。アプリケーションは仮想マシンに適用され、環境をインストールして管理します。同時に、アプリケーションの開発後、テストされたバージョンを手動で仮想マシン環境にデプロイします。

クラウドネイティブ PaaS プラットフォームの段階では、基盤となるリソース プールはより軽量なコンテナーになっています。同時に、上位レベルのモノマーは、複数の独立した疎結合のマイクロサービスに分割されました。ミドルウェア PaaS レイヤーは 2 つの機能を実現します。

1 つ目は、K8s で実装されているものと同様のコンテナ リソースのオーケストレーションとスケジューリングです。 2 つ目は、データベース、メッセージング、キャッシュ、その他の技術サービス機能を含む共通の技術サービス機能の提供です。

上位層のマイクロサービスと基盤となるコンテナ クラウド リソースをより適切に接続するために、DevOps の継続的インテグレーションとデリバリーのベスト プラクティスとツール セットを統合することで、要件、開発、テスト、統合、デリバリーのプロセス全体を完全に自動化できます。つまり、コンパイル、ビルド、パッケージ化、およびデプロイメントのアクションはすべて DevOps プロセスによって自動的に完了します。

ServerLess 段階になると、実際に以下のような変化が見られます。

まず、基盤となるコンテナがステートレス コンテナになり、軽量で作成や破棄が簡単になります。次に、上位層のマイクロサービス機能は、独立したステートレスなクラウド機能またはサービスにさらに分割されます。 3番目に、PaaSレイヤーの技術サービス機能がさらに強化され、完全なBaaSレイヤーが構築されます。

BaaS (Backend as a Service) とは、サーバー側のすべてのコンポーネントを作成または管理する必要がなくなり、ドメイン全体のリモート コンポーネント (インプロセス ライブラリではなく) を使用してサービスを提供できることを意味します。

従来のエンタープライズアプリケーションを ServerLess に移行することを検討中

現時点では、Serverless は主に以下のシナリオで使用されます。まず、Web およびモバイル サービスでは、API ゲートウェイと Serverles サービスを統合して Web およびモバイル バックエンドを構築できるため、開発者は弾力的にスケーラブルで可用性の高いモバイルまたは Web バックエンド アプリケーション サービスを構築できます。

IoT シナリオでは、リアルタイムのストリーミング データを効率的に処理できます。デバイスによって生成される大量のリアルタイム情報ストリーム データは、Serverles サービスによって分類および処理され、処理のためにバックエンドに書き込まれます。さらに、リアルタイム メディア情報コンテンツ処理シナリオでは、ユーザーはオーディオとビデオをオブジェクト ストレージ OBS にアップロードし、アップロード イベントを通じて複数の機能をトリガーして、高解像度トランスコーディングやオーディオ トランスコーディングなどの機能を完了し、リアルタイム機能と同時実行機能に対するユーザーの高い要件を満たします。

サーバーレス コンピューティングは、モノのインターネット、モバイル アプリケーション、Web ベースのアプリケーション、チャットボットなど、イベント駆動型のさまざまなユース ケースにも適しています。

私は以下の点について言及しました。

従来のエンタープライズ情報アプリケーションでは、独自のビジネス ルールとロジックの実装が複雑なため、プロセス、データ、アプリケーション機能間のコラボレーションと統合のカテゴリも多岐にわたります。このシナリオでは、完全にサーバーレスなアーキテクチャに切り替える可能性は基本的にありません。

ここで考え方を変えて、従来のエンタープライズ情報アプリケーションを ServerLess サーバーレス アーキテクチャに移行するにはどのような準備が必要なのかを考えたいと思います。

この問題についていくつかの点から考えてみたいと思います。

まず、BaaSのバックエンド・アズ・ア・サービス機能は、依然として従来の方法で構築されています。

ここで改めて強調しておきたいのは、BaaS バックエンドの共通サービス機能の提供は、依然として従来のアーキテクチャまたは現在のマイクロサービス アーキテクチャを使用して提供されているということです。

サーバーレス アーキテクチャについて話すとき、FaaS クラウド機能レイヤーに焦点を当てることは簡単です。その理由は、現在のパブリッククラウドサービスでは、ストレージ、データ、メッセージングなどのさまざまな BaaS バックエンドサービス機能がすべてクラウドプラットフォームによって提供されているためです。しかし、エンタープライズレベルのアプリケーションを開発する場合、この BaaS バックエンド サービスの意味は変化します。

つまり、BaaS バックエンド サービスは技術的なサービスであるだけでなく、一般的なビジネス サービス機能も備えています。

「ミドルプラットフォーム」という用語を引き続き使用すると、企業の共通ビジネスミドルプラットフォームとデータミドルプラットフォームが提供する共通サービス機能も、BaaSバックエンドサービスの重要な構成要素であることがわかります。

つまり、エンタープライズレベルのアプリケーションを開発したい場合は、まず BaaS レイヤーを開発しなければ先に進めません。

2番目: 完全にステートレスな開発モード

前述したように、サーバーレス アーキテクチャは完全にステートレスなアーキテクチャ モデルです。たとえば、もともと開発にイベント駆動型アーキテクチャを使用していた場合、サーバーレスに移行するのは非常に簡単です。ただし、元々長期トランザクションや状態保持シナリオが多数あった場合、移行全体が非常に複雑になります。

ステートレス開発は、SOA アーキテクチャ概念におけるサービス アセンブリやサービス オーケストレーションに似ており、メッセージ イベント メカニズムに基づくイベント チェーン オーケストレーション モデルにも似ています。しかし、コアはステートレスなので、状態を維持するためにトークン パッシングや、状態を一時的に保存するためのメッセージ メカニズムの使用など、他の方法を使用する必要があります。

3番目: リソース指向開発ではなくサービス指向開発

これも先ほど強調した点です。将来的にサーバーレス アーキテクチャ モデルに移行する場合は、現在の開発ガイドラインをすべてリソース指向ではなくサービス指向にする必要があります。

仮想マシンまたはコンテナ リソースの申請と注文は今後検討する必要はありません。考慮すべき点は、技術的なニーズを技術サービスのニーズに変換することです。ビジネスニーズを独立したステートレス機能に変換します。

先ほど、クラウド移行プロセス中にデータやメッセージ ミドルウェアを自分でインストールするために仮想マシンを申請している場合、将来的に ServerLess モードに移行するのがより困難になると述べました。先ほどの Tencent Cloud ServerLess の簡単な検証でわかるように、永続的なデータ ストレージが必要な場合、仮想マシンを申請して自分で MySQL データベースをインストールする必要はありません。代わりに、基本サービスにはデータベース サービスがあり、このサービス機能を直接使用してデータベース コレクションを作成できます。

サービス指向開発は、すべての開発者にとって比較的重要なトピックです。

4番目：開発チームと人員の分担

ServerLess サーバーレス段階に入ると、開発チームのメンバーが頻繁に作業を再配分していることがわかります。これは、現在のマイクロサービスのフロントエンドとバックエンドの分業の分岐として見ることができます。

つまり、BaaS バックエンド サービス層専用のチームになります。このチームは、開発と継続的インテグレーションおよびデリバリーに、従来の方法または現在のマイクロサービス アーキテクチャを依然として使用しています。もう一方の開発チームは、アプリケーションとユーザーを担当し、バックエンドに API インターフェース サービスを提供します。この開発チームは、すべて現在のフロントエンド開発者で構成できます。

つまり、バックエンドの BaaS サービスが安定した後は、新しいアプリケーションの作成では、フロントエンド アプリケーションと FaaS クラウド関数の作成が中心になります。フロントエンド開発者は、ビジネスシナリオとルールの実装にさらに注意を払い、BaaS レイヤーの既存のビジネスサービスと技術サービス機能を組み立てて組み合わせることで、さまざまなニーズを満たすことができます。

簡単な例を挙げてみましょう。

従来の OA オフィス自動化シナリオでは、組織、権限、人員、プロセスなどの共通のバックエンド サービス機能が利用可能になると、休暇申請や出張申請書などのさまざまなフロントエンド機能の開発を完全にクラウドベースで行うことができます。現時点では、フロントエンド アプリケーションの開発は、現在のローコード開発プラットフォームで行われている開発に似ています。