1. 序章

このチュートリアルでは、サーバーレスアーキテクチャと、それからどのように利益を得ることができるかについて学習します。 また、使用できる人気のあるサーバーレスプラットフォームのいくつかについても説明します。 その過程で、このスタイルのアーキテクチャの利点と制限のいくつかについても学びます。

2. サーバーレスの背景

業界の他の多くの流行語と同様に、サーバーレスという単語の出所を確実に追跡することは非常に困難です。 ただし、重要なのは、アプリケーションにもたらすメリットを理解することです。 サーバーレスアーキテクチャは、そもそも非常に独特に聞こえるかもしれませんが、それをよりよく理解するようになると、それは理にかなっています。

2.1. サーバーレスとは何ですか?

通常、アプリケーションを開発するときは、サーバーがそれらをホストして提供する必要があります。 たとえば、WARファイルとしてバンドルされたJavaアプリケーションを開発する場合、仮想化機能を備えたLinuxマシンなどのホストで実行するには、Tomcatなどのアプリケーションコンテナが必要です。 次に、高可用性とフォールトトレランスを備えたインフラストラクチャのプロビジョニングなどの他の考慮事項があります。

もちろん、これは、最初のリクエストに対応できるようになる前であっても、多くの準備を行う必要があることを意味します。 そして、これはそれだけではありません。サービスを維持するために、このインフラストラクチャを今後管理する必要があるからです。 アプリケーション開発に厳密に関連していないこれらすべてのタスクについて気にする必要がない場合はどうなりますか?

これがサーバーレスの基本的な前提です。 つまり、基本的に、サーバーレスアーキテクチャは、サードパーティのサービスでアプリケーションをホストするソフトウェアデザインパターンです。 これにより、そのために必要なハードウェアおよびソフトウェア層を管理する必要がなくなります。 さらに、負荷に合わせてインフラストラクチャを拡張することを心配する必要もありません。

2.1. それはFaasですか、それともPaasですか?

業界内では、サーバーレスは、サービスとしての機能(FaaS)という一般的な用語で大まかに知られていることもよくあります。 FaaSは、その名前が示すように、インフラストラクチャを管理することなく、アプリケーションを機能として構築、実行、および管理できるクラウドコンピューティングサービスです。 しかし、これはPlatform-as-a-Service(PaaS)と呼ばれる別の構成とあまり似ていませんか?

ええと、基本的にはそうですが、の違いはアプリケーションのデプロイメントユニットにあります。 PaaSを使用すると、従来からアプリケーションを開発し、WARファイルなどの完全なアプリケーションをデプロイして、アプリケーション全体をスケーリングします。

しかし、FaaSでは、アプリケーションを個別の自律機能に分解します。 したがって、より正確なスケーラビリティを備えたFaaSサービスに各機能を個別にデプロイできます。

さらに、PaaSでは、FaaSで手放すことができるスケーラビリティの一部を管理する必要があります。 さらに、FaaSは、新しいリクエストが発生した場合にインスタンスを起動し、不要になったときにインスタンスを破棄することを期待しています。 これは、アプリケーション全体のように、より大きなデプロイメントユニットで通常効果的なものではありません。 したがって、FaaSはPaaSよりも最適なリソース使用率をもたらします。

サーバーレスの正確な定義がないため、これにあまり夢中にならないようにする必要があります。 基本的な考え方は、クラウドベースのサービスが提供できるコスト最適化の恩恵を受けることです。 これは、コンピューティングリソースがどこから来ているのかを気にすることなく、必要なだけコンピューティングリソースを使用することで可能になります。 これには、アプリケーションをより小さく、一時的な展開単位に再設計する必要があります。

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

サーバーレスアーキテクチャの基本的な前提は非常に魅力的ですが、これにアプローチする方法を理解することはあまり直感的ではないかもしれません。 自律機能の組み合わせとしてアプリケーションを作成することは、よりも簡単です。 サーバーレスアーキテクチャをよりよく理解し、アプリケーションがそれからどのように利益を得ることができるかを探求するために、少し時間を費やしてみましょう。

このチュートリアルでは、タスクの管理に役立つ簡単なアプリケーションを選択します。 3層アーキテクチャを備えたこの単純なアプリケーションを想像することができます。

このアプリケーションは、クライアント側のReactJS、サーバー側のSpringBoot、データベースとしてのMongoDBなどの一般的なフレームワークを使用して開発できます。 さらに、これをオンプレミスまたはクラウド管理のインフラストラクチャに展開できます。 ただし、自動スケーリングのオプションがいくつかある場合でも、コンピューティングリソースの浪費を排除することはできません

ただし、サーバーレスでダウンさせることはできますか? どれどれ。 まず、この単純なアプリケーションを、独立した自律的な機能のグループとして再設計する必要があります。

ここでは、単純なアプリケーションを個々の関数に分解して、タスクを処理しました。 機能分解はかなり直感的ですが、その技術的な意味はどうですか? 議論する価値のあるものがいくつかあります。

まず、開発のためにFaaSサービスプロバイダーが提供する開発SDKとAPIに頼る必要があります。 次に、アプリケーションのデバッグ、監視、および管理の従来のツールに関する課題にも直面します。 ただし、プラス面としては、 FaaSサービスプロバイダーのネイティブ機能に依存して、必要な場合にのみfunctionインスタンスを作成および管理できます。

4. 人気のサーバーレスプラットフォーム

前に説明したように、サーバーレスアーキテクチャの主な利点の1つは、すべてのインフラストラクチャ管理をサードパーティに委任できることです。 もちろん、これは、サーバーレスアプリケーションを作成する能力は、利用可能なサービスに大きく依存することを意味します。 さらに、サーバーレスとは、単一のサービスだけでなく、サーバーレスアーキテクチャのメリットを享受できる多数のサービスです。

サーバーレスサービスの非常に成熟したカタログを誇る、今日利用可能なクラウドサービスベンダーはかなりあります。 サーバーレスは非常に柔軟な方法で定義できるため、これらのベンダーが提供するサービスも非常に異なります。 それらに特定の共通の側面がありますが。 いくつかのベンダーからのこれらのサービスのいくつかを調査します。

4.1. AWSでのサーバーレスサービス

AWSのサーバーレスサービスのカタログで最も重要なサービスは、FaaSサービスLambdaです。 AWS Lambdaはサーバーレスコンピューティングサービスであり、サーバーをプロビジョニングまたは管理せずにコードを実行できます。 これにより、Node.js、Python、Go、Javaなどの一般的な言語のいずれかでLambda関数を記述できます。 コードをZIPファイルまたはコンテナ画像としてアップロードするだけです。

したがって、あらゆる規模のトラフィックに対して正確な計算能力を使用することができます。 さらに、AWSはサーバーレスアプリケーションに他の多くのサービスを提供しています。 たとえば、イベント駆動型アプリケーションを構築するための AmazonEventBridge Amazon API Gateway は、APIを作成、公開、維持、監視、および保護します。 Amazon S3 は、スケーラビリティと可用性を備えた任意の量のデータを保存します。

4.2. GCPのサーバーレスサービス

同様に、GCPのサービスの中で、 CloudFunctionsは主要なサーバーレス製品です。 Cloud Functionsは、サーバー管理なしでコードを実行するためのスケーラブルな従量課金制のFaaSです。 負荷に応じてアプリケーションを自動的にスケーリングします。 さらに、統合された監視、ロギング、およびデバッグを提供します。 さらに、役割および機能ごとのレベルで組み込みのセキュリティを備えています。

GCPが提供するもう1つの重要な機能は、PaaS製品 AppEngineです。 Cloud Functionsは、より単純で、スタンドアロンの、イベント駆動型の関数に適しています。 ただし、複数の機能を組み合わせたいより複雑なアプリケーションの場合、AppEngineはより適切なサーバーレスプラットフォームです。 GCPは、GKEなどのKubernetesクラスターにコンテナーとしてパッケージ化されたサーバーレスアプリケーションをデプロイするためのCloudRunも提供しています。

4.3. Azure上のサーバーレスサービス

同様に、MicrosoftAzureはFaaSサービスAzure Functions を提供し、イベント駆動型サーバーレスコンピューティングプラットフォームを提供します。 Durable Functions拡張機能を使用して、ステートフルな調整などの複雑なオーケストレーションの問題を解決することもできます。 トリガーとバインディングを使用してハードコーディングすることなく、他の多くのサービスに接続できます。 さらに、Kubernetesでも関数を実行できます。

以前と同様に、より複雑なアプリケーションの場合、Azureは AppServiceも提供します。 これにより、フルマネージドサーバーレスプラットフォーム Webアプリケーションを構築、デプロイ、スケーリングできます。 Node.js、Java、Pythonなどの一般的な言語を使用してアプリケーションを作成できます。 さらに、エンタープライズグレードの厳格なパフォーマンス、セキュリティ、およびコンプライアンスの要件を満たすことができます。

5. Kubernetesでサーバーレス

Kubernetes は、コンテナ化されたワークロードのデプロイ、スケーリング、管理を自動化するためのオープンソースのオーケストレーションシステムです。 さらに、Istioのようなサービスメッシュの専用インフラストラクチャレイヤーをKubernetesクラスターの上に置くことができます。 これは、サービス間の通信など、多くの一般的な問題を解決するのに役立ちます。

サーバーレス環境をホストおよび管理するために、Kubernetes上でIstioの組み合わせを活用することを考えるのは自然なことです。 このような展開モデルには多くの利点があります。 たとえば、はベンダー固有のサービスの多くから私たちを切り離します。 さらに、サーバーレスアプリケーションの標準的な開発フレームワークを提供できます。

5.1. ネイティブ

Knative は、サーバーレスワークロードをデプロイおよび管理するためのKubernetesベースのプラットフォームです。 これは、スケーラブルで安全なステートレスサービスを非常に簡単に立ち上げるのに役立ちます。 一般的なアプリケーションのユースケースに高レベルの抽象化を提供するAPIが付属しています。 さらに、ロギング、モニタリング、ネットワーキング、およびサービスメッシュ用の独自のコンポーネントをプラグインすることができます。

Knativeは基本的に、サービングとイベンティングの2つのコンポーネントで構成されています。 サービングを使用すると、がネットワーキング、自動スケーリング、バージョントラッキングを処理しながら、Kubernetesでサーバーレスコンテナを実行できます。 イベントは、イベントのサブスクリプション、配信、および管理のためのインフラストラクチャを提供します。 これにより、イベント駆動型アーキテクチャを備えたサーバーレスアプリケーションを作成できます。

5.2. キマ

Kyma は、Kubernetes上のサーバーレス機能とマイクロサービスでアプリケーションを拡張するためのプラットフォームを提供します。 基本的に、拡張機能の作成と管理を簡素化するために、クラウドネイティブプロジェクトの選択をまとめます。 Kymaの背後にある基本的な考え方は、イベントを送信したりコールバックを受信したりできるようにすることで、既存のアプリケーションを拡張することです。

Kymaには、適切に構成、監視、保護されたKubernetesクラスターが付属しています。 さらに、は、認証、ロギング、イベント、トレースなどのニーズに対応するオープンソースプロジェクトを提供します。 これは、サーバーレスコンピューティング、イベント、可観測性、API露出、アプリケーション接続、サービスメッシュ、およびユーザーインターフェイスにまたがるいくつかの主要なコンポーネントで構成されています。

6. サーバーレスアーキテクチャの制限

ここまでで、サーバーレスアーキテクチャが最適なリソース消費につながることは明らかです。 これにより、本質的に計算コストが削減されます。 さらに重要なことに、サーバーレスプラットフォームの利用者はインフラストラクチャについて心配する必要がないため、利用者の運用コストを大幅に削減できます。

すぐに利用でき、拡張性の高いサーバーレスプラットフォームは、市場投入までの時間を短縮し、ユーザーエクスペリエンスを大幅に向上させます。 ただし、このスタイルのクラウドコンピューティングアーキテクチャは、すべてのユースケースに適しているとは限らないため、コストとメリットを慎重に検討する必要があります。 サーバーレスの欠点も理解しない限り、サーバーレスを完全に評価することはできません。

6.1. プラットフォームの制限

サーバーレスアーキテクチャの主な懸念事項の1つは、ベンダーの管理です。 サーバーレスアーキテクチャを使用してアプリケーションを設計または再設計すると、使用できる言語やアップグレードするバージョンなど、システムの多くの側面の制御が自発的に失われます。 もちろん、日を追うごとに、各ベンダーからのサポートの範囲はさらに広がっています。

サーバーレスアーキテクチャに関するもう1つの非常に重要な懸念事項は、ベンダーロックインです。 前に見たように、あるベンダーのサーバーレスサービスは、他のベンダーのサービスとは大きく異なる可能性があります。 これにより、サーバーレスプラットフォームのベンダーを切り替えることが困難になり、多くの場合コストがかかる可能性があります。 これは主に、ベンダーからのいくつかのインフラストラクチャサービスに依存しているためです。

次に、セキュリティのような他のいくつかの懸念事項に注意する必要があります。 従来の方法でアプリケーションを開発する場合、セキュリティの面で多くの制御があります。 しかし、すぐにサーバーレスサービスの採用を開始し、ベンダーに固有のいくつかのセキュリティ実装にさらされます。 これにより、アプリケーションの複雑さと攻撃ベクトルが増加します。

6.2. アプリケーションの制限

ただし、アプリケーション自体の開発方法に固有の特定の課題があります。 たとえば、サーバーレスワークロードは、使用されていないときはゼロにスケールダウンされるため、起動遅延の影響を受ける可能性があります。 この問題はコールドスタートと呼ばれることが多く、さまざまな理由で発生する可能性があります。 これは、JVMでときどきトリガーされて実行されるアプリケーションに特に当てはまります。

注意すべきもう1つの非常に重要な側面は、テストです。 サーバーレスはより小さな自律型アプリケーションを強調するため、単体テストはかなり簡単になります。 しかし、統合テストはどうですか? アプリケーション全体はベンダーのインフラストラクチャサービスの数に依存しているため、統合テストの実装は困難になります

では、実際にサーバーレスアーキテクチャをどこで使用する必要があるのでしょうか。 これに対する良い答えはありません。 ただし、サーバーレスアーキテクチャの恩恵を受ける可能性のあるアプリケーションの特性は、非同期、同時、まれ、散発的な需要であり、予測できないスケーリング要件、ステートレス、エフェメラル、および非常に動的です。

7. 結論

このチュートリアルでは、サーバーレスアーキテクチャの基本について説明しました。 通常のアプリケーションを使用して、サーバーレスのメリットを享受できるようにこれを変換する方法を理解しました。 さらに、利用可能な人気のあるサーバーレスプラットフォームのいくつかを調査しました。 最後に、サーバーレスアーキテクチャの制限についても説明しました。