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 つの基本パターンを使用して実装できます。
Lambda は AWS の Function-as-a-Service ソリューションです。 Lambda を使用すると、インスタンスのデプロイや OS やランタイムのパッチを気にすることなく、コードをデプロイして即座に高可用性とスケーラビリティを実現できます。
Lambda は、同期呼び出し (API Gateway、Application Load Balancer、または Lambda 関数 URL 経由) または非同期呼び出し (AWS 生成イベントまたはユーザー生成イベントに応答) で使用できます。
Lorsque vous déployez un Lambda, vous choisissez la quantité de mémoire dont il a besoin pour fonctionner. Le processeur alloué est proportionnel. Vous payez ensuite en fonction du nombre de millisecondes utilisées. Par exemple, un Lambda de 128 Mo coûte 1,7*10^-9$/ms. Cela représente 164 heures de calcul avant de dépenser votre premier dollar.
Et la balance Lambda. Rapide. Beaucoup plus rapide qu'autre chose. Fini les erreurs 429 (ou 500 si votre charge de travail n'est pas bien protégée) dues à une forte variation du trafic.
Les environnements d'exécution Lambda ne traitent qu'une seule requête à un moment donné et sont réutilisés pour les requêtes ultérieures. Cela signifie que, pour qu'une fonction Lambda évolue, ou lorsqu'une fonction Lambda n'a pas été invoquée depuis un certain temps, Lambda devra démarrer un nouvel environnement d'exécution : c'est un démarrage à froid.
Si les démarrages à froid sont préjudiciables à votre application (encore une fois, c'est probablement mieux que tout le trafic soit lent ou atteigne 429), alors il existe quelques options. AWS propose un article intéressant sur l'utilisation des réchauffeurs Lambda ou la définition de la concurrence provisionnée pour y remédier. En plus de cela, pour les utilisateurs Java, les fonctionnalités Lambda SnapStart permettent d'offrir de bonnes performances de démarrage à froid, en prenant un instantané de la microVM après l'initialisation de la JVM.
La FAQ officielle du produit indique qu'il "prend en charge nativement le code Java, Go, PowerShell, Node.js, C#, Python et Ruby, et fournit une API d'exécution qui vous permet d'utiliser n'importe quel langage de programmation supplémentaire pour créer vos fonctions."
Dans les prochains articles de blog de cette série, nous expliquerons comment exécuter PHP sur Lambda en tirant parti de deux frameworks distincts, Bref et Lambda Web Adaptor, et comparerons les possibilités offertes par chacun d'eux.
以上がAWS ServerLess アーキテクチャで PHP を実行するにはどうすればよいですか?パート サーバーレスとは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
