AWS の主力サーバーレス サービスである Lambda を使用すると、さまざまなランタイムでコードを実行できます。ただし、PHP は公式の製品説明に明示的に記載されていません。 Lambdas では PHP コードを実行できないということでしょうか?いいえ、そうではありません!

このシリーズ (AWS ユーザー グループ Poitiers での講演から派生したもの) では、サーバーレスとは​​何か、および PHP (お気に入りの言語の場合) を Lambda 上で実行する方法について説明します。

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

サーバーレスは、クラウド プロバイダーが顧客のワークロードに割り当てられたリソースを動的に拡張しながら、物理インフラストラクチャ (サーバー、電源冷却) だけでなく、実行ランタイム (パッチ適用など) まで管理するホスティング パラダイムです。

厳密な意味では、すべてのリクエストにコンピューティングが割り当てられ、「ゼロスケール」の料金モデル (時間単位でリソースが支払われることはなく、実際の需要にのみ比例して支払われる) につながり、同時に高い組み込みの機能を提供します。 -可用性。

これにより、クラウドの他の利点がさらに高まります。主に、すべてに API が付属し、自動化が可能になるという事実です。

これらの利点を合計すると、事実上無料の機能ブランチの一時的な環境が可能になり、開発者の生産性とリードタイムが向上します。

サーバーレスはコンピューティングだけを意味するものではありません。

サーバーレス エコシステムにはたくさんのソリューションがあります。 2014 年にサーバーレス コンピューティング (Lambda) が登場したとき、マネージド キュー (SQS) は 10 年前から存在し、S3 は 8 年前から存在していました。

上のスライドでは、Aurora はゼロにスケールしないため、サーバーレスの厳密な定義と一致しないことに注意してください (v1 はゼロにスケールされますが、開始に数分かかる可能性があります。v2 ではデータベースがクエリを処理できるようにするには、ライター インスタンスとリーダー インスタンスの両方に少なくとも 0.5 個の ACU が必要です。

サーバーレス サービスのみを含む Web アプリケーションをホストするための一般的なアーキテクチャを以下に示します。このようなアプリケーションのホスティング費用は、限られた数のユーザーであれば年間 1 ドル未満になる可能性があります。

サーバーレスはマイクロサービス専用ですか?

はい...そしていいえ。これはマイクロサービスを念頭に置いて設計されていますが、モノリシック アーキテクチャをデプロイすることもできます (新しい環境が起動されるたびに長時間実行される起動シーケンスがない限り)。

マイクロサービスの一般的な課題を解決するサーバーレス オプション: オーケストレーションとコレオグラフィー

マイクロサービス アーキテクチャにより、アプリケーション コンポーネント間の結合を減らすことができます (異なる言語を使用し、非同期パターンを通じて、インフラストラクチャ レベルの結合を削除することでスケーラビリティを向上させます)。

ただし、単一目的の関数が複数ある場合、ビジネス ロジックの実装には関数間の調整が必要になる場合があります。この調整は 2 つの基本パターンを使用して実装できます。

• オーケストレーション: このパターンでは、命令型の方法で関数の呼び出しを制御します。これは、機能が単一のサービス チームによって提供される場合に、ビジネス ドメイン内で を使用することがよくあります。これに対するサーバーレスのアプローチは、ワークフロー/ステートマシンである AWS StepFunction です。 StepFunction を使用して Lambda 関数を調整する方法に関する素晴らしいチュートリアルがここにあります。
• コレオグラフィー: このパターンは、非常に限定された結合を維持するために、別個のサービス チームが存在するクロスビジネス ドメインのシナリオでより適切です。イベント バスを使用すると、アプリケーションはイベントをプッシュしたり、イベントをサブスクライブしたりできます。複数のコンシューマが同じイベントをサブスクライブでき、各コンシューマは必要なイベントをフィルタリングできます。このための中核となる AWS サービスは EventBridge です。それについて私が書いたブログ投稿をここに載せます。

Lambda について知る

Lambda は AWS の Function-as-a-Service ソリューションです。 Lambda を使用すると、インスタンスのデプロイや OS やランタイムのパッチを気にすることなく、コードをデプロイして即座に高可用性とスケーラビリティを実現できます。

Lambda は、同期呼び出し (API ゲートウェイ、Application Load Balancer、または Lambda 関数 URL 経由) または非同期呼び出し (AWS 生成イベントまたはユーザー生成イベントに応答) で使用できます。

Lambda をデプロイするときに、実行に必要なメモリ量を選択します。割り当てられる CPU は比例します。その後、使用したミリ秒数に基づいて料金が発生します。たとえば、128Mb Lambda のコストは 1.7*10^-9$/ms です。最初の 1 ドルを費やすまでに 164 時間の計算が必要になります。

そしてラムダスケール。速い。他のものよりもはるかに速いです。トラフィックの変動が大きいために発生する 429 (ワークロードが十分に保護されていない場合は 500) エラーはもう発生しません。

LambdaLiths による主な課題の解決: コールド スタート

Lambda 実行環境は、一度に 1 つのリクエストのみを処理し、後続のリクエストで再利用されます。つまり、Lambda 関数をスケールする場合、または Lambda 関数がしばらく呼び出されなかった場合、Lambda は新しい実行環境を開始する必要があります。これはコールド スタートです。

コールド スタートがアプリケーションに悪影響を与える場合 (繰り返しになりますが、すべてのトラフィックが遅くなったり 429 に達したりするよりはおそらく良いでしょう)、いくつかのオプションがあります。 AWS には、Lambda ウォーマーの使用や、それに対処するためのプロビジョニングされた同時実行性の設定に関する優れた記事があります。これらに加えて、Java ユーザーの場合、Lambda SnapStart 機能を使用すると、JVM の起動後に microVM のスナップショットを作成することで、優れたコールド スタート パフォーマンスを実現できます。

PHP サポートについてはどうですか?

公式製品 FAQ には、「Java、Go、PowerShell、Node.js、C#、Python、Ruby コードをネイティブにサポートし、追加のプログラミング言語を使用して関数を作成できるようにするランタイム API が提供されます」と記載されています。

このシリーズの次のブログ投稿では、Bref と Lambda Web Adaptor という 2 つの異なるフレームワークを活用して Lambda 上で PHP を実行する方法を説明し、それぞれが提供する可能性を比較します。