フロントエンドクラウドコンピューティングでサーバーレスコンピューティングを実装する方法

企業は、アプリケーション全体をクラウドに移行せずに、既存のアプリケーション用のクラウド フロントエンド コンピューティング要素を構築することを選択できます。これを実現するために、サーバーレス コンピューティングやコンテナーなど、さまざまなテクノロジーから選択できます。

アプリケーションへのオンライン アクセスを提供するために Web サーバーをフロントエンドとして使用することは、新しいアイデアではありません。 Web ページとホスティング プロセスを緊密に統合するというアイデアも新しいものではありません。Common Gateway Interface (CGI) は何十年も前から使用されています。ただし、クラウド コンピューティングのフロント エンドを設計すると、スケーラビリティ、弾力性、パフォーマンスの向上のためにプレゼンテーションまたは GUI 機能がクラウド リソース上でホストされ、アプリケーションのバックエンドはどこにでも配置できるモデルが作成されます。

企業は、従来の Web サーバーと CGI 方式を通じてこのハイブリッド モデルを展開することもできますが、最新のクラウド テクノロジーではより優れたオプションが提供されます。クラウド フロントエンドを導入し、サーバーレス テクノロジーとマイクロサービスを活用することで、IT チームはオーバーヘッドとコストを削減できると同時に、アプリケーションの柔軟性とスケーラビリティも向上できます。

[[330054]]

近代化の圧力

典型的な最新のアプリケーション フロントエンドは、API ゲートウェイまたはプロキシを中心に構成されています。プロキシ要素は、Web ページまたはモバイル アプリケーションから呼び出すことができる一連の API を提供します。これらの API は、Web サーバーに接続したり、JavaScript などのプログラミング言語を使用して Web ページから直接呼び出すことができます。 API の背後には、クラウドまたはデータ センターでホストされているアプリケーション自体のソフトウェア コンポーネントがあります。

このフロントエンドのクラウド コンピューティング モデルはここ 2 年で普及し始めたばかりですが、すでに近代化への圧力がかかっています。アプリケーションのフロントエンド設計では、動的に拡張または置換できるロジックの小さなステートレス コンポーネントであるマイクロサービスを使用するのが最先端の方法です。サーバーレスは、これらのマイクロサービスなどのコードを実行するときにのみリソースを消費するアプリケーション アーキテクチャです。

マイクロサービスとサーバーレス アプローチにより、フロントエンドは完全にスケーラブルになり、障害に対して耐性が高まります。このタイプの戦略を使用すると、サーバー管理は必要なくなり、クラウド クライアントはアクティブなホスティングに対してのみ料金を支払います。アクティビティ レベルが低い場合は、常時稼働のクラウド ホスト アプリケーションよりもコストが安くなります。

トランザクションとイベント

マイクロサービスとサーバーレス設計はイベントに関するものですが、他のアプリケーション設計はトランザクションを中心に構築されます。マイクロサービスとサーバーレスのクラウド フロントエンドを設計する場合、開発者はイベントに関連するトランザクションの側面を考慮する必要があります。

一般的なアプリケーションでは、ユーザーは複数のステップのプロセスを通じてトランザクションを作成します。トランザクションのステップはイベントに対応します。すべてのイベントはトランザクション コンテキストに入る必要があります。マイクロサービスとサーバーレスの開発者は、多くの場合、トランザクションをオリジン（モバイル デバイスや Web サーバーなど）のイベントに分解します。

API ゲートウェイ モデルは、サーバーレス デプロイメントに適しています。フロントエンド Web サーバーまたはモバイル アプリからの呼び出しに基づいて、ゲートウェイは適切なサーバーレス コードを呼び出すことができます。フロントエンドはオンラインデータベースにもアクセスできます。このアクセスにより、サーバーレス ワークフローがトリガーされます。たとえば、このモデルに基づいて構築されたアプリケーションは、データベースにアクセスして注文を作成し、サーバーレス ワークフローをトリガーして、処理された注文を在庫管理用のバックエンド アプリケーションに転送します。

一部のアプリケーションには、単純なイベント ハンドラーよりも分散処理機能に近い機能豊富なフロント エンドがあります。これらの設計では、クラウド開発者は AWS Step Functions や Microsoft Azure の Durable Functions などのワークフローオーケストレーションツールを使用して、複雑なマルチサーバーレス関数ワークフローを構築できます。これらのワークフローは従来のアプリケーション ロジックに似ていますが、クラウドの価値を最大化するためにマイクロサービスに分割されている点が異なります。

マイクロサービス、サーバーレス、コンテナ

主要なクラウドベンダーは、ユーザーがマイクロサービスからサーバーレスデプロイメント、および常時利用可能なコンテナデプロイメントに簡単に切り替えられる方法を提供しています。 AWS と Google もマイクロサービスの展開を可能にしていますが、Microsoft はマイクロサービスの展開により直接的に重点を置いています。

アプリケーション チームは、サーバーレス コンピューティングではなく、マイクロサービスの観点から考える必要があります。マイクロサービス アーキテクチャは、サーバーレス コンピューティングを取り巻く一般的な懸念事項の 1 つに直接対処します。サーバーレスは、控えめに使用すると非常にコスト効率が高くなります。サーバーレスのお客様は使用量に応じてのみ料金を支払うため、使用量が増えると、サーバーレス アクティベーションのコストが、同じアプリケーション コードをホストする専用の常時オン コンテナーのコストを上回る可能性があります。

状態制御は、サーバーレス アプリケーションを構築する際、特にアプリケーションが従来のクラウド ネイティブ コンテナー ホスティングに切り替わる可能性がある場合には重要な考慮事項です。マイクロサービスまたはサーバーレス関数はステートレスです。アクティベーション間で情報を保存できないため、オンデマンドのアクティベーション、スケーリング、および置換に適しています。したがって、アプリケーションに複数のステップが含まれ、記憶する必要があるコンテキストがある場合は、状態制御を提供する必要があります。

クラウド フロントエンドの API ゲートウェイ モデルでは、状態を制御する方法が複数あります。モバイル デバイスまたは Web サーバーがアプリケーションにアクセスすると、アプリケーションで生成されるイベントの一部として状態が提供されます。マイクロサービスまたは関数に必要なすべての情報は、接続されたユーザー インターフェイスの状態情報を介して渡されます。 API ゲートウェイをデプロイしてコンテキスト情報を記憶し、状態ソースにすることができます。あるいは、マイクロサービスまたは関数は、各ユーザー トランザクションに関するコンテキスト情報を保持するバックエンド データベースから状態情報を取得できます。

振り付けは、内部プロセスまたはワークフロー ダイアグラム内の状態を維持する方法です。このアプローチを使用するには、まず、選択したクラウド プロバイダーが、コンテナーですでにホストされているマイクロサービスに対してこの種のマッピングを提供できるかどうかを調査します。サーバーレス マイクロサービスの一部を永続コンテナに移行することを検討している場合は、特定のクラウド プロバイダーとビジネス プロセス モデルにコミットする前に、その方法を理解することが重要です。

また、サーバーレスワークフローを詳しく見てみましょう。クラウド プロバイダーは、非アクティブなため実行時に遅延が発生するサーバーレス コンポーネントをオンデマンドでロードして実行する必要があります。ワークフロー内のサーバーレス要素が多すぎると、応答時間が大幅に長くなる可能性があります。同じコンポーネントを通常のコンテナにデプロイすると、この問題は発生しません。

マイクロサービスとステートレス実行は、サーバーレスではなく、クラウド フロントエンドのアーキテクチャを定義します。サーバーレス ホスティング モデルは多くのアプリケーションに適していますが、多くのアプリケーションは他の方法で実行するとコスト効率が向上したり、パフォーマンスが向上したりします。事前にワークフローを計画しておくと、サーバーレス ホスティングがコストとパフォーマンスに影響を与える可能性のあるアプリケーションを発見できます。最新のプラクティスが必ずしもベストプラクティスであるとは限らないので、盲目的に最新のプラクティスを追い求めないでください。