サーバーレス コンピューティングの徹底的な考察: 起源、シナリオ、問題

[51CTO.com オリジナル記事] 1. サーバーレスコンピューティングの起源

過去 10 年間で、私たちはアプリケーションと環境の多くの共通部分をサービスに変換してきました。サーバーレスの出現は飛躍的な変化をもたらしました。サーバーレスでは、ホスト管理、オペレーティング システム管理、リソース割り当て、容量拡張、さらにはアプリケーション ロジックのすべてのコンポーネントをアウトソーシングし、それらを一種の商品として扱います。つまり、メーカーがサービスを提供して、私たちがその料金を支払うのです。従来は「サーバー上で実行し、複数のイベントに応答するためのフレームワークを構築する」というものでしたが、サーバーレスは「イベントに応答するためにマイクロサービスまたはマイクロ関数を構築または使用する」ものになりました。アクセスされると、関連するリソースが呼び出され、実行が開始されます。操作が完了すると、すべてのオーバーヘッドがアンロードされ、オンデマンドおよび従量課金制の課金が真に実現されます。これは、クラウド コンピューティングの徹底的な開発にとって自然なプロセスです。

[[250586]]

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

Amazon、Microsoft、Google、IBM、Alibaba Cloud、Tencent Cloud、Huawei Cloudなど国内外の大手クラウドベンダーが相次いでサーバーレス製品を発売している。サーバーレスも概念とビジョンから実装へと徐々に移行し、さまざまなインターネット企業に適用されてきました。

2. サーバーレステクノロジーの理解 - FaaS と BaaS

サーバーレスは、開発者が実装し、ステートレス コンピューティング コンテナーで実行されるサーバー側ロジックです。これはイベントによってトリガーされ、サードパーティによって完全に管理されます。ビジネス レベルのステータスは、開発者が使用するデータベースとストレージ リソースによって記録されます。サーバーレスは多くのテクノロジーをカバーしており、FaaS と BaaS の 2 つのカテゴリに分けられます。

1.ファアス

FaaS は、サーバー システムや独自のサーバー アプリケーションを管理することなく、バックエンド コードを直接実行するように設計されています。ここで言及されているサーバー アプリケーションは、このテクノロジとコンテナーや PaaS (Platform as a Service) などの他の最新アーキテクチャとの最大の違いです。

FaaS は、一部のサービス処理サーバー (物理コンピューターの場合もありますが、何らかのアプリケーションを実行する必要があります) を置き換えることができるため、サーバーを自分でプロビジョニングしたり、アプリケーションをフルタイムで実行したりする必要はありません。

FaaS 製品では、開発に特定のフレームワークやライブラリを使用する必要はありません。言語と環境の面では、FaaS 機能は単なる通常のアプリケーションです。たとえば、AWS Lambda 関数は、Javascript、Python、および任意の JVM 言語 (Java、Clojure、Scala) で実装できます。ただし、Lambda 関数は、必要なデプロイメント アーティファクトにバンドルされている任意のプロセスも実行できるため、Unix プロセスとしてコンパイルできる限り、任意の言語を使用できます。 FaaS 機能には、特に状態と実行時間に関して、特定のアーキテクチャ上の制限があります。

FaaS への移行中に変更する必要がある唯一のコードは「メイン メソッド/スタートアップ」コードです。ここでは、最上位メッセージ ハンドラー (「メッセージ リスナー インターフェイス」の実装) の関連コードを削除する必要がある場合がありますが、メソッド シグネチャの変更のみが必要になる場合があります。 FaaS の世界では、コードの他の部分 (データベースに書き込むコードなど) を変更する必要はありません。

従来のシステムと比較すると、展開方法が大幅に変わります。コードを FaaS プロバイダーにアップロードすると、プロバイダーが他のすべてを実行します。現在、このアプローチでは通常、コードの新しい定義をアップロードし (たとえば、zip または JAR ファイルをアップロード)、独自の API を呼び出して更新プロセスを開始することを意味します。

FaaS の関数は、プロバイダーによって定義されたイベント タイプによってトリガーできます。 Amazon AWS の場合、このようなトリガー イベントには、S3 (ファイル) の更新、時間 (スケジュールされたタスク)、メッセージ バス (Kinesis など) に追加されたメッセージなどが含まれます。通常、関数では、パラメータを通じてバインドする必要があるイベント ソースを指定する必要があります。

ほとんどのプロバイダーでは、通常は何らかの API ゲートウェイ (AWS API Gateway、Webtask など) からの受信 HTTP リクエストへの応答として関数をトリガーすることもできます。

2.基本

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

まず、BaaS は PaaS ではありません。両者の違いは、PaaS はアプリケーションのライフサイクル管理に参加する必要があるのに対し、BaaS はアプリケーションが依存するサードパーティのサービスのみを提供するという点です。一般的な PaaS プラットフォームでは、アプリケーションを Tomcat コンテナに自動的にデプロイしたり、アプリケーションのライフサイクルを管理したりするなど、開発者がアプリケーションをデプロイおよび構成するための手段を提供する必要があります。 BaaS にはこれらのコンテンツは含まれません。 BaaS は、データベースやオブジェクト ストレージなど、アプリケーションが依存するバックエンド サービスのみを API の形式で提供します。 BaaS は、パブリック クラウド サービス プロバイダーまたはサードパーティ メーカーによって提供されます。第二に、機能的な観点から見ると、BaaS は PaaS のサブセット、つまりサードパーティの依存コンポーネントを提供する部分として見ることができます。

BaaS サービスを使用すると、他者によってすでに実装されているアプリケーション ロジックを利用することもできます。認定はその良い例です。多くのアプリケーションでは、登録、ログイン、パスワード管理、その他のロジックを実装するために独自のコードを記述する必要があり、これらのコードはさまざまなアプリケーションで類似していることがよくあります。これらの反復タスクを抽出して外部サービスにすることは完全に可能であり、それが Auth0 や Amazon Cognito などの製品の目標です。開発チームがこれらの機能を実装するコードを独自に記述したり管理したりしなくても、包括的な認証とユーザー管理が可能になります。

3. サーバーレス コンピューティングはどのように機能しますか?

サーバーレス コンピューティングは、仮想マシンや基盤となるテクノロジーを使用してアプリケーションを展開および管理するよりも高いレベルの抽象化を提供します。なぜなら、それらは異なる抽象化と「トリガー」のセットを持っているからです。

コンピューティングの場合、この抽象化には特定の機能と抽象化のトリガー（通常はイベント）があります。データベースの場合、この抽象化はテーブルであり、トリガーはテーブルのクエリや検索、またはテーブル内で何かを実行することによって生成されるイベントになります。

たとえば、モバイル ゲームでは、ユーザーはさまざまなプラットフォーム上の世界中のトップ プレイヤーのハイスコア テーブルを使用できます。この情報が要求されると、その要求はアプリケーションから API インターフェースに送信されます。 API インターフェースは AWS Lambda 関数またはサーバーレス関数をトリガーし、データベース テーブルからデータ ストリームを取得して、上位 5 つのスコアを含む特定の形式でデータを返します。

一度構築すると、アプリケーションの機能はゲームのモバイル バージョンと Web ベース バージョンの両方で再利用できます。

これはサーバーの設定とは異なります。 Amazon EC2 インスタンスまたはサーバーを用意してリクエストを待つ必要はありません。環境はイベントによってトリガーされ、イベントに応答するために必要なロジックは、応答としてのみ実行されます。つまり、関数を実行するために必要なリソースは関数の実行時にのみ作成されるため、アプリケーションを非常に効率的に構築できます。

4. サーバーレス コンピューティングはどのようなシナリオに適していますか?

サーバーレス コンピューティングは、イベント駆動型のさまざまなユースケースに適しています。これには、モノのインターネット、モバイル アプリ、Web ベースのアプリケーション、チャットボットなどが含まれます。検討すべきシナリオを 2 つ示します。

シナリオ 1: アプリケーションの負荷に大きなピークと谷がある

サーバーレス アプリケーションの成功を判断する基準は、会社の規模ではなく、ビジネスの背後にある特定の技術的な問題です。たとえば、ビジネスに明らかな山と谷がある場合、山を滑らかにして谷を埋めるにはどうすればよいでしょうか。企業の業務負荷にピークと谷がある場合、ピーク需要に応じてマシンリソースを見積もる必要があります。谷間期間中は、リソースを再利用できず、無駄が生じるため、マシンの使用率が大幅に低下します。

業界の一般的なコンセンサスとしては、所有マシンの使用率が 30% 未満の場合は、サーバーレスを使用すると効率が大幅に向上するということです。クラウド サービス プロバイダーの場合、十分な数のユーザーが集まると、さまざまなピークと谷が重なり合って安定し、集約後のリソースの再利用性が向上します。たとえば、食品配達会社のピーク負荷は食事の時間帯ですが、警備業界のピーク負荷は夜間です。これは各社の事業ポジショニングによって制限されます。クラウド サービス プロバイダーの場合、プラットフォームが十分に大きく、十分なユーザー数があれば、明らかなピークや谷は発生しないはずです。

シナリオ 2: 典型的なユースケース - イベントベースのデータ処理

ビデオ処理のバックエンド システムの一般的な機能要件は、ビデオ トランスコーディング、データ抽出、顔認識などです。これらは、関数コンピューティングによって実行できる一般的なコンピューティング タスクです。

開発者は独自の実装ロジックを記述し、制御フローに従ってタスクを接続する必要があります。各タスクの具体的な実行はクラウドベンダーの責任となります。これにより、開発がより便利になり、構築されたシステムは自然に高可用性とリアルタイムでの弾力的な拡張性を備え、ユーザーはマシンレベルの問題を心配する必要がなくなります。

5. サーバーレスコンピューティングの問題点

企業にとって、サーバーレス コンピューティングをサポートするプラットフォームは、多くの時間とコストを節約できるだけでなく、従業員の負担を軽減し、開発者がインフラストラクチャの管理ではなく、より価値のある作業を実行できるようにします。一方、俊敏性が向上し、新しいアプリケーションやサービスをより迅速に立ち上げることができるため、顧客満足度が向上します。ただし、サーバーレスは完璧ではありません。また、いくつか問題があり、実稼働環境では注意して使用する必要があります。

1. 長期実行アプリケーションには適していません

サーバーレスはリクエストが届いたときに実行されます。つまり、アプリケーションが実行されていない場合は、「休止状態」になります。次にリクエストが来たとき、アプリケーションには起動時間、つまりコールド スタート時間が必要になります。アプリケーションを長時間中断することなく実行し、大量のリクエストを処理する必要がある場合は、サーバーレス アーキテクチャは適さない可能性があります。 CRON または CloudWatch を使用してアプリケーションを定期的に起動すると、より多くのリソースが消費されます。

2. サードパーティのサービスに全面的に依存

エンタープライズ クラウド環境にすでに大量のインフラストラクチャが存在する場合、サーバーレスは適していません。サーバーレス アーキテクチャを採用すると、サービス プロバイダーに縛られるため、サービスを他のクラウド サービス プロバイダーに移行するのは簡単ではありません。

シリーズの基盤となるコードを変更する必要があり、私たちが取れる解決策は分離レイヤーを確立することです。つまり、アプリケーションを設計する際には、Firebase と DynamoDB などの両方をサポートできる成熟した ORM ツールが市場に存在しないことを考慮して、API ゲートウェイとデータベース レイヤーを分離する必要があります。これにより、追加のコストも発生し、解決するよりも多くの問題が発生する可能性があります。

3. デバッグおよび開発ツールの不足

Serverless Framework を使用したときに、デバッグおよび開発ツールが不足するという問題に遭遇しました。その後、serverless-offline や dynamodb-local などの一連のプラグインを見つけ、問題は少し改善されました。しかし、これはログ記録システムにとって依然として困難な課題です。

デバッグするたびに、コードを何度もアップロードする必要があります。アップロードするたびにサーバーを展開しているような感じになり、問題がどこにあるのかをすぐに特定できないことがあります。その後、log4j と同様に、さまざまなレベルでログを記録できる Node.js ライブラリ winston を見つけました。エラー、警告、情報、詳細、デバッグ、および silly の 6 つの異なるレベルのログをサポートし、ログ分析とフィルタリングのためにビッグ データと組み合わせて、問題をすばやく特定できます。

4. 複雑な構造

サーバーレスは安価ですが、簡単というわけではありません。 AWS Lambda の CloudFormation 構成は非常に複雑で、読み書きが困難です (JSON 形式)。 CloudFormation は Template テンプレートを提供していますが、それを使用する場合は、スタックを作成し、スタック内で使用する Template を指定する必要があります。その後、AWS はテンプレートの定義に従ってリソースを作成し、初期化します。

Serverless Framework の構成はよりシンプルで、YAML 形式を使用します。デプロイ中に、Serverless Framework は設定に基づいて CloudFormation 設定を生成します。ただし、これは実際に本番環境で使用される構成ではありません。実際のアプリケーションシナリオはこれよりもはるかに複雑です。

VI.結論

長年の開発を経て、クラウド コンピューティングは徐々に進化し、ユーザーはビジネスと必要なリソースだけに集中できるようになりました。たとえば、Swarm や K8S などのオーケストレーション ツールを使用すると、ユーザーはマシン レベルを気にすることなく、独自の計算と必要なリソース (CPU、メモリなど) にのみ集中できます。

サーバーレス アーキテクチャにより、運用に必要なリソースについて心配する必要がなくなります。ビジネス ロジックに集中し、実際に消費したリソースに対してのみ料金を支払う必要があります。サーバーレス アーキテクチャの台頭により、真のクラウド コンピューティングの時代が到来したと言えます。

新しい概念やテクノロジーの実装は、特定の問題を真に解決するためには、基本的に特定のビジネスと組み合わせる必要があります。サーバーレスは多くの面で未熟であり、早急に改善する必要があります。しかし、サーバーレス自体の優れた機能は開発者にとって非常に魅力的です。テクノロジーの急速な発展により、サーバーレスは将来的に無限の可能性を秘めていると信じています。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]