サーバーレスアーキテクチャの簡単な紹介

著者 |ゾン・ティンティン

クラウド サービスの急速な発展に伴い、近年ではサーバーレス アーキテクチャを採用する企業が増えています。では、サーバーレス アーキテクチャとは何でしょうか?その利点と欠点は何ですか?この記事では、サーバーレス アーキテクチャについて詳しく説明します。

サーバーレス アーキテクチャとは何ですか?

「_サーバーレス アーキテクチャとは、サードパーティの「Backend as a Service」(BaaS) サービスを組み込んだアプリケーション設計、および/または「Functions as a Service」(FaaS) プラットフォーム上の管理された一時的なコンテナーで実行されるカスタム コードを含むアプリケーション設計です。」

Martin Fowler 氏の記事のこの定義は、サーバーレス アーキテクチャが何であるかを明確に説明していると思います。それで、その特徴は何でしょうか?

• アプリケーションのデザインです。
• サードパーティの BaaS サービスが含まれます。
• FaaS プラットフォーム上で実行およびホストされるカスタム プログラムを含めることができます。

上記の機能を読んだ後でも、サーバーレス アプリケーションがどのようなアプリケーションなのかについて、まだ少し混乱しているかもしれません。次の例で説明します。

従来のアプリケーション

写真

従来の 3 層アプリケーション: クライアント、サーバー、データベース。サーバーは、ビジネス ロジック、プロセス、セキュリティの大部分を制御します。この場合、クライアントの機能は薄く、あまりスマートではないように見えます。

サーバーレスアプリケーション

• 認証には Auth0 などのサードパーティの BaaS サービスを使用します。
• AWS DynamoDB などのサードパーティの BaaS サービスを使用してデータを保存すると、クライアントはさまざまなセキュリティポリシーを通じてデータベースにアクセスできます。
• クライアントにはナビゲーション機能などのロジックがさらにあります。プロセスの一部を制御することもできます。
• 常にサーバーを実行する代わりに、API ゲートウェイは HTTP リクエストに応答し、それらをさまざまな FaaS 機能にルーティングします。検索機能をクライアントに配置する場合、クライアントはデータベースから大量のデータを取得し、条件に基づいて必要なデータをフィルタリングする必要があります。データ量が多いと、非常に非効率になり、ユーザーエクスペリエンスに影響を及ぼします。そのため、検索機能はFaaS機能としてサーバー上に配置します。
• コース購入機能はセキュリティ上の理由からサーバー側にFaaSとして配置されています。コース購入システムは一般的に支払いに関係するため、比較的高いセキュリティ要件があります。

上記の例からわかるように、サーバーレス アプリケーションでは「サーバー」は必要なくなり、サーバーレス アプリケーション内の各コンポーネントは独立したサブサービスと見なすことができます。マイクロサービスに似ています。このアーキテクチャは、より柔軟性が高く (コンポーネントを簡単に削除または追加して、特定の機能を追加または削除できます)、保守も簡単です (FaaS 機能を変更しても、他の機能にほとんど影響がありません)。

しかし、一方で、この柔軟性により、システムの複雑さとコストも増加します。多くの BaaS および FaaS サービスを維持する必要がある可能性があり、サービスの数に応じてそれらの間の通信コストが徐々に増加します。

BaaS - バックエンド・アズ・ア・サービス

上記の例から、サーバーレス アーキテクチャには多くの BaaS サービスが含まれていることがわかります。では、BaaS サービスとは何でしょうか?

BaaS (Backend as a Service) はクラウド サービス モデルです。アプリケーションを構築する際、バックエンド機能の一部をクラウド プラットフォーム プロバイダーにアウトソーシングすることがあります。このアウトソーシングされた機能が BaaS です。ユニバーサル認証、データベース管理、クラウド ストレージ、メッセージ プッシュ、電子メール検証など。これらの一般的な機能をクラウド プラットフォーム プロバイダーにアウトソーシングすると、開発および保守コストを大幅に削減できます。したがって、開発の進捗を改善するために、複数の BaaS サービスがサーバーレス アーキテクチャに統合されます。

FaaS - サービスとしての機能

前の例からわかるように、サーバーレス アーキテクチャでは、従来のサーバーの機能がさまざまなコンポーネントに分散され、その一部は BaaS サービス用にパッケージ化され、一部はクライアントに配置され、一部は FaaS 機能に引き渡されます。

BaaS サービスの場合は、サードパーティによって提供されるため、どのように統合するかが重要になります。クライアントでは、この機能を実装するために UI 開発者が必要です。 FaaS の場合、関数の形でサービスを提供し、カスタムコードを持ち、FaaS プラットフォーム上で独立して実行できます。それで、その特徴は何でしょうか?

• 管理するサーバーはありません。 FaaS はサードパーティのクラウドプロバイダーが提供するプラットフォーム上で実行され、プログラムの起動や操作などの管理タスクはクラウドプロバイダーによって完了および監視されます。
• 自動スケーリング。 FaaS は完全に自動化され、柔軟性があります。つまり、FaaS インスタンスの数は必要に応じて自動的に増減できます。
• HTTP リクエストをサポートします。基本的に、主流のクラウド プラットフォーム プロバイダーは、FaaS 機能をトリガーするための API ゲートウェイを提供します。
• 言語制限はありません。
• 導入が簡単です。
• イベント駆動型。 FaaS 機能は、クラウド プラットフォームによって定義されたイベントによってトリガーされます。 S3 ファイル/オブジェクトの更新、スケジュールされたタスク、Kinesis メッセージなどのイベントはすべて、FaaS 機能をトリガーするイベントとして使用できます。

FaaS を使用する場合は、以下の点にも注意する必要があります。

州

FaaS 関数は、純粋関数と同様に、ステートレス関数です。つまり、ある関数の状態を、同じ関数の別の呼び出しに使用してはならないということです。 FaaS 関数の状態を永続化する必要がある場合は、外部の永続化サービスを使用できます。

開始遅延

AWS Lambda メソッドを例にとると、Lambda がイベントを受信すると、初期化、呼び出し、破棄の 3 つの段階を経ます。初期化フェーズ中に、Lambda は以前の実行環境の凍結を解除しようとします。凍結解除できる環境がない場合、Lambda はリソースを作成し、関数コードをダウンロードし、拡張機能とランタイムを初期化してから、コードの実行を開始します。呼び出しフェーズでは、Lambda はイベントを受信し、関数の実行を開始します。関数の実行が終了すると、Lambda は次のイベントが呼び出されるまで待機します。このフェーズは、Lambda 関数が破棄フェーズ中に一定期間呼び出しを受信しなかった場合にトリガーされます。破棄フェーズでは、ランタイムがシャットダウンし、各拡張機能に「破棄イベント」を送信し、最後に環境を削除します。

Lambda 関数がトリガーされたときに、呼び出し可能な現在アクティブ化された Lambda 関数がない場合、Lambda は関数コードをダウンロードし、Lambda 実行環境を作成します。イベントがトリガーされてから新しい Lambda 環境が作成されるまでの期間は、多くの場合「コールド スタート時間」と呼ばれます。

「コールド スタート」の遅延は間違いなく避けられないものであり、ユーザー エクスペリエンスに影響を与える重要な要素でもあるため、「コールド スタート」時間を短縮するための努力を行う必要があります。コールド スタートのレイテンシは、言語、ライブラリ、コード サイズ、関数環境、VPC リソースなど、さまざまな要因によって異なります。軽量言語の選択、コード サイズの最適化、軽量の依存パッケージまたは SDK の呼び出しなど、開発者が負担を軽減できるものもあります。

実行時間

FaaS 関数では通常、各呼び出しの実行時間が制限されています。現在、AWS Lambda 関数には、イベントに応答するまでに最大 15 分の「タイムアウト」があり、その後終了します。 Microsoft Azure と Google Cloud Functions にも同様の制限があります。

APIゲートウェイ

FaaS 関数は、一般的にイベントによってトリガーされるサーバー側アプリケーションですが、ほとんどのアプリケーションでは通常、HTTP リクエストを介してバックエンド API を呼び出します。そのため、FaaS機能の前にAPIゲートウェイをインストールします。 API ゲートウェイは、事前に構成されたルーティング テーブルに基づいて、HTTP リクエストをさまざまな FaaS 機能にルーティングします。

サーバーレスアーキテクチャの利点

（１）運用コストの削減

サーバーレス アーキテクチャを使用してバックエンド アプリケーションを構築すると、サーバー、データベース、および特定のアプリケーションを管理するために人件費を支払う必要がなくなります。インフラストラクチャ（ハードウェアやネットワークなど）を他者と共有することでもコストを削減できます。最後に、人件費が削減されるため、サーバーレス システムに費やす時間が短縮されます。

（２）拡張コストの削減

FaaS 機能のスケールアップとスケールダウンは完全に自動化されており、プロバイダーによって管理され、アクセス トラフィックの量に基づいてのみ料金が発生します。トラフィックが増加すると、クラウド プラットフォームはリクエストの急増に対応するために FaaS 機能の数を自動的に増やし、コストも増加します。アクセス要求がない場合、プラットフォームは FaaS 機能の数を減らすため、コストも削減されます。

（３）開発コストの削減

開発コストを削減する鍵は、前述の認証サービスやデータベースサービスなど、サプライヤーが提供する汎用的なBaaSサービスを活用することです。これらのサービスは、利用料の支払いのみが必要であり、再開発やメンテナンスは必要ありません。

（）操作と管理が簡単

関数のスケーリングは自動的に行われるため、同時実行の問題を手動で管理する必要はありません。第二に、FaaS のパッケージ化と展開も非常にシンプルで高速であるため、運用と保守の時間と人件費が効果的に削減されます。

サーバーレス アーキテクチャは低コストで構築され、スタートアップに適しています。第二に、サーバーレス アーキテクチャの柔軟性 (特定のビジネス機能の追加や削除が非常に便利) により、ビジネスの変更が特に頻繁に起こる企業に適しています。最後に、迅速な開発、導入、シンプルな操作と管理により、市場投入までの時間も短縮され、企業がより早く市場を獲得できるようになります。

サーバーレスアーキテクチャの欠点

固有の欠点

（１）サプライヤーのコントロールとロックイン

ベンダー制御により、システムのダウンタイム、予期しない制限、コストの変更、機能の損失、強制的な API アップグレードなどの問題が発生する可能性があります。ベンダーを切り替える場合、コード、設計、さらにはアーキテクチャの変更が必要になる場合があります。 AWS Lambda 関数などのシステムの一部は簡単に移行できますが、Kinesis やアプリケーションに統合されたその他のコンポーネントの場合、各クラウド プラットフォームが大きく異なる可能性があり、移行には多くの作業が必要になる場合があります。

（２）マルチテナント問題

複数の異なるテナントが同じマシン上で実行されているため、プラットフォームを使用しているのは自分だけであるかのような感覚になります。しかし、実際には同じインフラストラクチャを共有する可能性があり、セキュリティとパフォーマンスの問題が発生する可能性があります。

（３）サービスを最適化する権利の喪失

アプリケーションが BaaS または他のクラウド プラットフォーム コンポーネント (Knisis など) を使用してサービスを構築する場合、これらのサービスまたはコンポーネントにカスタマイズされた機能を追加することは困難です。また、顧客のニーズに応じて機能を最適化したり、カスタマイズしたりすることも困難です。

実装上の欠点

（１）実行時間

Lambda 関数には実行時間制限があり、この時間を超えて実行されると中止されます。一部のビジネスがより複雑で、実際に 15 分を超える実行時間が必要な場合は、Serverless を使用することはできません。

（２）「コールドスタート」の遅延

高いパフォーマンス要件を持つビジネスでは、「コールド スタート」の遅延を考慮する必要があります。もちろん、上記の方法のいくつかによって遅延時間を短縮することもできます。

（３）テストとデバッグ

単体テストは問題ではありませんが、統合テストは問題です。 FaaS は他のサーバーコードよりもコードが小さいため、統合テストがより重要になります。しかし、クラウド環境がなければ、統合テストをローカルで実行してデバッグすることは困難です。ローカルデバッグの場合は、デバッグ用のユニットテストを記述できます。 Kinesis、IoT クライアントなど、統合されたすべてのクラウド プラットフォーム モジュールをユニット テストでモックできるためです。

（４）モニタリング

Serverless の場合、サプライヤーが提供するデータとインジケーターのみが表示されます。一部のサプライヤーは、ユーザーが特定のインジケーターをカスタマイズできるようにいくつかのインターフェースを公開していますが、それらは依然としてサプライヤーによって制限されています。