サーバーレスエンジニアリングの実践 |サーバーレスサポートサービスのカウント

序文

前述のように、クラウド コンピューティングの 10 年以上にわたる発展は、インターネット業界全体に大きな変化をもたらしました。サーバーレスは、クラウド コンピューティングの産物、またはある時代におけるクラウド コンピューティングの現れとして、多くの人から真のクラウド コンピューティングであると考えられています。 「サーバーレスとは​​何か」という質問は、実際にはさまざまな角度から分析できます。

Martin Fowler 氏は、記事「Serverless Architectures」の中で、Serverless を Serverless 構成の観点から定義しています。彼は、Serverless は実際には BaaS と FaaS の組み合わせであると信じており、BaaS と FaaS について詳しく説明しています。

サーバーレスは、サーバー側のロジックと状態を管理するために、主にまたは完全にサードパーティ (クラウド) アプリケーションまたはサービスに依存するアプリケーションを表すために最初に使用されました。これらのアプリケーションは通常、データベース (Parse、Firebase)、アカウント システム (Auth0、AWS Cognito) などを含むクラウド サービス エコシステム上に構築されたリッチ クライアント アプリケーション (シングル ページ アプリケーションまたはモバイル アプリ) です。これらのサービスは当初、Baas (Backend as a Service) と呼ばれていました。

サーバーレスは、アプリケーションのサーバー側ロジックの一部が開発者によって完了されている状況を指す場合もありますが、従来のアーキテクチャとは異なり、ステートレス コンピューティング コンテナーで実行され、イベント駆動型で、ライフサイクルが短く (呼び出しが 1 回だけの場合も)、サード パーティによって完全に管理されます。このような状況を FaaS (Functions as a service) と呼びます。 AWS Lambda は現在最も人気のある FaaS 実装の 1 つです。

Martin Fowler 氏の説明に基づいて、FaaS、BaaS、Serverless の関係を次の図のようにまとめることができます。

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

サーバーレス構造の観点から見ると、サーバーレス = FaaS + BaaS は一般的に認識されている概念です。サーバーレス機能の観点から見ると、サーバーレスはステートレス コンピューティング コンテナーで実行され、イベントによってトリガーされ、柔軟なスケーリングと従量課金制の機能を備えているため、ユーザーはサーバーに余分なエネルギーを費やすことなく、ビジネス自体に集中できます。

さまざまな視点から見たサーバーレスの定義

サーバーレスワークフロー

実際の運用では、サーバーレス アーキテクチャは通常、FaaS と BaaS の組み合わせであり、弾力的なスケーリングと従量課金制という特徴があります。

開発者がプロ​​ジェクトを開発したい場合:

通常は、FaaSプロバイダーが提供するランタイムに基づいて使い慣れたプログラミング言語を選択し、プロジェクトの開発とテストを実行するだけです（図のステップ1）。
完了したら、コードをFaaSプラットフォームにアップロードします（図のステップ2）
アップロードが完了したら、API/SDK を実行するだけです。またはクラウド イベント ソース (図のステップ 3)
FaaSプラットフォームにアップロードされた関数をトリガーすると、FaaSプラットフォームはトリガーの同時実行性に基づいて対応する関数を柔軟に実行します（図のステップ4）
最後に、ユーザーは実際のリソース使用量に基づいて使用量を支払うことができます（図のステップ5）

サーバーレスワークフロー

Web アプリケーションの例を見てみましょう。通常、一部の Web アプリケーションは、従来の 3 層 C/S アーキテクチャに基づいています。たとえば、一般的な電子商取引アプリケーションでは、サーバー側で Java を使用し、クライアント側で HTML/JavaScript を使用します。

従来の Web アプリケーションの 3 層 C/S アーキテクチャ

このアーキテクチャでは、サーバーはクラウド サーバーのみであり、多数のビジネス機能とビジネス ロジックを実行します。たとえば、システム内のロジックのほとんど (認証、ページ ナビゲーション、検索、トランザクションなど) はサーバー上に実装されます。サーバーレス アプリケーションに変換します。

サーバーレス アプリケーション フォーム図

サーバーレス アプリケーション フォームでは、元のアプリケーションの認証ロジックが削除され、サードパーティの BaaS サービスに置き換えられます (上図のステップ 1)。クライアントはデータベースコンテンツの一部に直接アクセスできます。この部分のデータは完全にサードパーティによってホストされており、対応するデータへのクライアントのアクセスを管理するためにいくつかのセキュリティ構成が使用されます (上図のステップ 2)。前の 2 つのポイントは、すでに非常に重要な 3 番目のポイントを暗示しています。つまり、ユーザー セッションの維持、アプリケーションの UX 構造の理解、データの取得、ユーザー インターフェイスのレンダリングなど、以前のサーバー側ロジックの一部がクライアントに転送されているということです。

実際には、クライアントは徐々にシングルページ アプリケーションへと進化しています (上図のステップ 3)。負荷の高いコンピューティング タスクや大量のデータへのアクセスを必要とする操作など、一部のタスクはサーバー上に保持する必要があります。 「検索」を例にとると、検索機能は常時稼働しているサーバーから切り離し、APIゲートウェイ（詳細は後述）からリクエストを受け取り、レスポンスを返すというFaaS的な実装が可能です。このサーバー側関数は、クライアントと同じデータベースから製品データを読み取ることができます。元のサーバーは Java で記述されており、AWS Lambda (これが使用される FaaS プラットフォームであると仮定) も Java をサポートしているため、元の検索コードを少し変更してこの検索機能を実装できます (上図のステップ 4)。 「購入」関数を別の FaaS 関数に書き換えることもできます。セキュリティ上の理由から、クライアントではなくサーバーに実装する必要があります。また、API ゲートウェイを介して外部でも利用できるようになります (上図のステップ 5)。

プロジェクト全体を通して、サーバーレス ユーザーが実際に気にするのは、関数内のビジネス ロジックだけです。認証ロジックやAPIゲートウェイ、データベースなど、本来サーバー側にある製品やサービスについては、すべてクラウドベンダーによって提供されています。プロジェクトの開発、開始、保守プロセス全体を通じて、ユーザーはサーバーレベルのメンテナンスに注意を払う必要はなく、トラフィックのピークや谷に対応する運用および保守リソースに投資する必要もありません。セキュリティ、弾力性、運用、保守の作業はすべてクラウドベンダーによって処理/スケジュールされます。ユーザーが注意する必要があるのは、ビジネス コードがビジネス要件を満たしているかどうかだけです。同時に、サーバーレス アーキテクチャでは、ユーザーはアイドル リソースに対して追加費用を支払う必要がありません。サーバーレス アーキテクチャの従量課金モデル、柔軟なスケーリング機能、メンテナンスの低さ/不要機能により、サーバーレス ユーザーのリソース コスト、人件費、全体的な研究開発効率が大幅に向上し、プロジェクトのパフォーマンス、セキュリティ、安定性が大幅に保証されます。

サーバーレスサポートサービス

1. 開発者ツール

サーバーレス開発ツールには、コマンドライン ツール、エディター プラグイン、その他のツールが含まれます。

一般的に、コマンドライン ツールは、ベンダー側のツールとオープン ソースのサードパーティ ツールの 2 種類に分けられます。たとえば、AWS Lambda の SAM CLI や Alibaba Cloud Function Compute の Funcraft は、典型的なベンダー側ツールです。このタイプのツールの特徴は、メーカーや製品との互換性が高く、一部の機能は比較的早くサポートされることです。欠点は、比較的保守的であることです。 Serverless Devs と Serverless Framework は典型的なサードパーティ ツールです。どちらのツールも、AWS Lambda、Alibaba Cloud Function Compute、Tencent Cloud Cloud Function などのクラウドベンダーの FaaS 製品をサポートしています。

クライアントパフォーマンスの観点から見ると、これらはすべてサーバーレス開発ツールであり、コンポーネント化されたコマンドラインツールであり、マルチクラウドをサポートしています。形式の観点から見ると、Serverless Framework はデプロイメントと運用および保守に重点を置いているのに対し、Serverless Devs は Serverless アプリケーションのライフサイクル全体に重点を置いています。同時に、Serverless Devs は Serverless Framework と比較して視覚的なインターフェースを追加しました。

サーバーレス開発者 GUI ホーム

図に示すように、このインターフェースを通じて、ユーザーはアプリケーションを迅速に展開できます。

サーバーレス開発者 GUI ビジュアル Yaml 編集ページ

図に示すように、ユーザーはクラウド上でサーバーレス関連のリソースを迅速に管理できます。

Serverless Devs GUI プロジェクト管理ページ

Azure Functions では、次の図に示すように、Visual Studio Code プラグインも提供されます。 Visual Studio の Azure Functions プロジェクト テンプレートを使用して、Azure の関数アプリに公開できるプロジェクトを作成できます。関数アプリを使用すると、ユーザーは関数を論理単位にグループ化して、管理、展開、リソースの共有を容易にすることができます。

Azure Functions が提供する VSCode プラグイン

図に示すように、Alibaba Cloud は開発者ツール レベルで VSCode プラグインを提供します。

同時に、Alibaba Cloud Function Compute は、クラウド関数の実行とダウンロード、ローカルの Jet Brains IDE でのローカル関数の作成とアップロードを可能にする Cloud Toolkit ツールも提供します。 IntelliJ IDEA を例にとると、その機能管理インターフェースは次の図のようになります。

Alibaba Cloud Function Compute VSCodeプラグイン関数管理インターフェース

2. サーバーレスワークフロー

Serverless Workflow は、複数の分散タスクの実行を調整するための完全に管理されたクラウド サービスです。

図に示すように、サーバーレス ワークフローでは、ユーザーは分散タスクを順次、分岐、または並列方式で調整できます。サーバーレス ワークフローは、設定された手順に従ってタスクを確実に調整し、各タスクの状態遷移を追跡し、必要に応じてユーザー定義の再試行ロジックを実行して、ワークフローがスムーズに完了するようにします。

サーバーレス ワークフローは、ログ記録と監査を提供することでタスクの実行を監視し、ユーザーがアプリケーションを簡単に診断およびデバッグできるようにします。サーバーレス ワークフローは、ビジネス プロセスの開発と実行に必要なタスク調整、状態管理、エラー処理などの面倒なタスクを簡素化し、ユーザーがビジネス ロジックの開発に集中できるようにします。

サーバーレスワークフローの例

サーバーレス ワークフローは、分散コンポーネントを調整して、さまざまなインフラストラクチャ、さまざまなネットワーク、さまざまな言語で記述されたアプリケーションをオーケストレーションし、ハイブリッド クラウド、プライベート クラウドからパブリック クラウドへの移行、またはモノリシック アーキテクチャからマイクロサービス アーキテクチャへの移行におけるギャップを埋めることができます。サーバーレス ワークフローは、シーケンス、選択、並列処理などの豊富な制御ロジックを提供するため、ユーザーは少ないコードで複雑なビジネス ロジックを実装できます。サーバーレス ワークフローは、ユーザーのプロセス状態を管理し、組み込みのチェックポイントおよび再生機能を提供して、アプリケーションが期待どおりに段階的に実行されるようにします。エラーの再試行とキャプチャにより、ユーザーはエラーを柔軟に処理できます。サーバーレス ワークフローは、実際の実行ステップ数に基づいて課金され、実行が完了した後はそれ以上の料金は発生しません。サーバーレス ワークフローは自動的にスケーリングされるため、ユーザーはハードウェアの予算とスケーリングを管理する必要がなくなります。

サーバーレスアプリケーションの可観測性

サーバーレス アプリケーションの可観測性は多くのユーザーにとって懸念事項です。観測可能性は、システムの外部的な現れを通してシステムの内部状態を判断することによって測定されます。アプリケーション開発において、可観測性はユーザーがシステムの健全性を判断するのに役立ちます。システムに問題が発生した場合、ユーザーが問題を特定し、トラブルシューティングし、分析するのに役立ちます。システムがスムーズに実行されると、ユーザーはリスクを評価し、起こりうる問題を予測するのに役立ちます。サーバーレスアプリケーション開発において、機能の同時実行性が増加し続けていることを観察すると、ビジネス規模の急速な拡大に向けてビジネス推進チームが懸命に取り組んでいる可能性が考えられます。同時実行制限しきい値に達しないようにするには、開発者は事前に同時実行性を高める必要があります。 Alibaba Cloud Function Compute を例にとると、Alibaba Cloud Function Compute は、ロギング、メトリック、トレースなど、可観測性に関して複数の次元を提供します。

機能コンピューティングの可観測性の全体図

コンソール監視センターでは、全体のメトリック、サービス レベル メトリック、および各機能のメトリックを表示できます。さらに、現在の関数のリクエスト記録も確認できます。

機能計算可観測性機能リクエストレコード

さまざまなリクエスト レコードに応じて、図に示すように、関数の詳細情報を表示できます。

機能 コンピューティングの可観測性リクエストレベルの記録の詳細

コンソールの監視センターで機能ログやその他の情報を表示できるほか、機能詳細ページでも詳細な機能ログ情報を表示できます。

関数計算ログの表示

トレース関連情報は図に示されています。

関数計算可観測性トレース関連情報