LaravelアプリケーションをAWSサーバーレスに移行した理由（および時間とお金を節約できる理由）

この記事では、AWS ServerlessにLaravelアプリケーションを展開することの利点を調査し、従来のEC2ホスティングとは対照的です。 著者は、リソース集約型のEC2セットアップから、費用対効果の高いスケーラブルなサーバーレスアーキテクチャに移行した経験を共有しています。

---

---

ネタバレ：それはお金を節約するだけではありませんが、私の財布は不平を言っていません。 これを想像してみてください：あなたは素晴らしいLaravelアプリケーションを構築しました - あなたの傑作、バターをカットすることができる非常に便利な機能を備えたデジタルスイスアーミーナイフ...またはユーザーのフィードバック。 しかし、キャッチがあります。毎月、あなたは十分に活用されていないEC2インスタンスにお金を払っています。スケーリングは、ハリケーンにクルーズ船を駐車するように感じます。 おなじみの音？それは私にしました。

3年前、私はほとんどの開発者がクレイジーと呼ぶことをしました。私はPHPをAWS Lambdaに展開しました。 「PHP？サーバーレスで？それはピザにパイナップルを置くようなものです！」と彼らは言いました

---

しかし、ここに私は3年後、誇らしげにパイナップルピザを食べています。サーバーレスのlaravelがあなたが必要としていなかったクラウドのアップグレードである理由を教えてください。

伝統的なLaravelホスティングの問題

---

（または：私のEC2インスタンスが実存的な危機を抱えていた理由）サーバーレスの前に、私のLaravelアプリケーションはEC2に存在していました。初心者の場合、EC2はAmazonのバージョンの仮想プライベートサーバーであり、コードを実行するためにマシンのスライスをレンタルします。いいですね？現実が不正 a）最初：存在のコスト

EC2インスタンスを実行することは、運転したい場合に備えて、24時間年中無休で走るテスラを所有するようなものです。私のアプリケーションはいつも忙しくなかったが、それはメーターを止めなかった。 EC2インスタンス、ロードバランサー、共有ストレージの間で、私はほとんどの時間をアイドル状態に費やしたサーバースタックに月額約110ドルを費やしていました。私の財布？タイタニックのように沈んだ。

私は知っている、それは物事の壮大な計画ではなく、ソロ開発者/起業家として、あらゆるドルがカウントされます。

b）その後：悪夢のスケーリング

composer update ec2インスタンスは、すべてに過剰に反応する友人のようなものです。

トラフィックスパイク？

「私は今クラッシュしています、ありがとう！」

トラフィックはありませんか？ 「私はまだあなたのお金を燃やします！」

自動焦点の管理は、魚にジャグリングを教えるように感じましたが、それは何のコストですか？スケーリンググループを手動で調整し、ロードバランサーを構成し、過度にプロビジョンが私が適用したことのない2番目の仕事のように感じないように祈る。

c）そして最後に：devops、無給インターン

ララヴェルの開発にはsysadminの責任があるとは言わなかった：

• セキュリティパッチの適用。
• 午前3時にnginx/apache構成のデバッグ。
• 今回は彼らが働くことを望んで、sudoコマンドに甘いものをささやく。
私はこの人生にサインアップしませんでした。

---

それは私が代替案を探求し始めたときであり、サーバーレスはこれらの頭痛の完璧な解決策として際立っていました。

---

AWSサーバーレス：クラウドでのPHPの復活

2. 神話を明確にしましょう。サーバーレスは「サーバーなし」を意味するものではありません。それは、サーバーが他の誰かの問題であることを意味します。この場合、AWSは私が実際に楽しんでいるものに焦点を合わせながら、重い持ち上げを処理します：コーディング。
a）ラムダ：イベント主導の魔術師

aws lambdaは、必要なときにのみ表示されるスーパーヒーローのようなものです。イベントに応じてコードを実行します。HTTPリクエスト、SQSメッセージ、スケジュールされたタスク、名前を付けます。そして、仕事が終わったら、開発者のミートアップで無料のピザよりも速く消えます。

アイドルコストなし

：実行時間のみを支払います（ミリ秒で測定）。

• 自動スケーリングマジック：100,000のリクエストのスパイクを取得しましたか？ラムダは汗をかくことなく（または銀行口座を空にする）ことなくそれを処理します。
• デザインによるステートレス：それは毎回新たなスタートのようなもので、モジュール式の考えを強いるデザインです。
• b）マネージドサービス：Unsung Heroes サーバーレスはラムダだけではなく、生態系です。 AWSは、DIYインフラストラクチャを「機能するだけ」のマネージドサービスに置き換えます：

データベース

：sql loversのaurora serverless（mysql/postgres）などのオプション

s3
• ：ディスクのスペースが不足することを心配せずにファイルを保存します。
sqs
• ：長期にわたる仕事を切り離し、非同期に処理します。
c）PHPパラドックス
• 私はそれを認めます：phpはサーバーレスのために生まれた
• セッション：mysqlやredisなどの外部データベースに移動します。
• ファイルストレージ：Laravelのファサードを使用して、すべてのストレージ操作をS3にリダイレクトします。 Storageキュー管理
：非同期タスク実行のデフォルトドライバーとしてSQSを設定します。
• キャッシュ：ローカルストレージの代わりにRedisやDynamodbなどの外部サービスを活用してください。
• ブートタイムの最適化：脂肪をトリミングすることでコールドスタートを最小限に抑える（未使用の依存関係）。
環境変数
• ：ファイルをAWS Secrets Managerまたはパラメーターストアに置き換えて、集中的で安全な構成管理。
• サーバーレスは、サーバーをLambda関数に置き換えるだけではありません。それはあなたのアーキテクチャを再考することです。あなたが構築に焦点を合わせながら、AWSが運用上の痛みのポイントを処理することです。 .env

---

サーバーレスがLaravelの完全な潜在能力のロックを解除する方法

それで、サーバーレスのlaravelは実際にその約束を届けますか？

---

サーバーレスは単なる流行語ではなく、変革的な変化です。サーバーレス上のLaravelの美しさは、従来のホスティングの弱点に対処しながら、より速く、よりスケーラブルで、費用対効果の高いソリューションを可能にする能力にあります。しかし、本当の魔法は、これらの利点がどのように組み合わされるかを掘り下げるときに起こります。それを分解しましょう。

3. a）コールドスタート：神話を現実と分離します

   Lambdaが新しいインスタンスを初期化すると、

   coldが発生します。昼寝から目覚めるPHPと考えてください。批評家はそれらを黙示録のように扱いますが、それらは管理可能です：

リアリティ

：典型的なコールドはPHPララヴェルから約3〜5秒です。

solutions

：

• laravel octane ：リクエスト間でアプリケーションを生かし続け、スタートアップ時間を短縮します。後続のリクエストは、約200m以下で処理されます。
• プロビジョニングされた同時性：クリティカルエンドポイントの就学前インスタンス（追加費用がかかりますが、キーエンドポイントには価値があります）
  。
  • 。
  • ほとんどのアプリケーションでは、交通量の少ない最中にサブ3秒の遅延が許容されます。ほとんどのユーザーは、特にラムダが「暖かく」と留まる交通スパイク中に、コールドスタートに気付くことはありません。 b）痛みのないスケーリング 従来のホスティングでのスケーリングは、しばしば終わりのない戦いのように感じられます。サーバーレスでは、スケーリングが楽になります。突然の交通量の増加中に、自動透視ルールを微調整したり、指を交差させたりしません。 AWS Lambdaは当て推量を削除し、デフォルトで水平方向にスケーリングします 例は次のとおりです
    • シナリオ：あなたのアプリケーションはバイラルになりますか？イェーイ！
    • 古いEC2セットアップ：レイテンシを経験し始め、急いでAWSにログインし、インスタンスの数を手動で調整し、最高のために祈りますか？ああ、そして可用性ゾーン全体でそれらのインスタンスのバランスを適切にバランスさせることを忘れないでください。
    • 新しいLambdaセットアップ：AWSは、指を持ち上げることなく何千もの同時リクエストを処理し、必要な数のインスタンスを自動的に作成します。ポップコーンをつかんで、NetflixシリーズのようなCloudWatchメトリックを見ますか？
    これは単なる利便性ではなく、安心です。アプリケーションの成功を祝うことに焦点を合わせている間、ラムダは重い持ち上げを行います。そして、最高の部分？使用するコンピューティング時間のみを支払うだけでなく、「念のため」が必要なアイドル容量には支払います。

    c）コスト効率：MVP

    サーバーレスはお金を節約するだけでなく、消費するものだけに支払うだけで食べ放題のビュッフェを持っているようなものです。

    私の古いEC2セットアップ：

    〜$ 110
    /月。
    • 4x t3.Small EC2インスタンス：$ 60.00 1xロードバランサー：
    • $ 16.40
    1x EBS（EC2インスタンス間の共有ストレージ）：
    • $ 7.80 1x rds mysqlインスタンス（db.t4g.medium）：〜$ 26.00
    lambda：
    • 〜$ 34/month（60％節約！）
    。
  lambda、APIゲートウェイ〜2.5mリクエスト（〜500ms / 512MBメモリ） /月：
  • $ 4.80 マネージドサービス（S3、SQS、CloudWatch）：〜$ 2.90 rds mysqlインスタンス（db.t4g.medium）：
  • 〜$ 26.00
  要するに、サーバーレスはお金を節約するだけでなく、精神的な帯域幅を解放します。過度のプロビジョニングを心配することを無駄にするリソースが少ないほど、驚くべきものを作ることに集中することができます。

  この時点で、私はまだデータベースエンジンとしてMySQLインスタンスを使用していました。将来の投稿では、コストをさらに削減するためにDynamodbに移住することを探求します。

  d）メンテナンスの自由：運用悪夢に別れを告げる

  サーバーレスは、サーバーメンテナンスの束縛から私を解放しました。方法は次のとおりです

  これ以上のマニュアルアップデート

  ：AWSは、セキュリティパッチ、OSの更新、ランタイムの改善を処理します。つまり、常に安全で最新のインフラストラクチャで実行されています。

  簡略化された構成
  • ：API GatewayやS3などのサービスを使用すると、Nginx構成とカスタム展開の管理の複雑さが過去のものになります。 弾性容量
  ：使用されていないサーバーリソースの過払いや、トラフィックスパイク中にさらにプロビジョニングするためにスクランブルすることを忘れてください。ラムダは自動的にスケールして需要を満たし、アイドル時に請求を停止します。
  • 消防ではなく機能に焦点を当てている：以前にパッチの適用や生産の問題のデバッグに費やした時間は、機能の構築とユーザーエクスペリエンスの改善に投資されています。
  • サーバーレスはメンテナンスを減らすだけでなく、コーディングを防ぐことができる運用的な注意散漫を排除します。
  • しかし、Laravelは誰にとってもサーバーレスですか？
  サーバーレスのlaravelと同様に、
  革新的なのは、普遍的な解決策ではありません。一部のアプリケーションでは、サーバーレスのステートレスとイベント主導の性質は、夢が実現するように見えるかもしれません。他の人にとっては、正方形のペグを丸い穴に取り付けようとするように感じるかもしれません。サーバーレスの時流にジャンプする前に、一歩下がって、それがあなたのプロジェクトに適しているかどうかを評価しましょう。

  a）ステートレスの性質：両刃の剣

  Laravelは、ファイルをローカルに保存したり、セッションをファイルシステムに保存するなど、インタラクション間で情報を保存する操作が大好きです。サーバーレスに移動するには、変更する必要があります：

  ---

  4. セッション

     ：データベース（mysql/postgres）またはredisを使用します。これ以上ファイルシステムの依存関係はありません
  ファイル

  ：ファイルのアップロードをs3にリダイレクトするか、laravelを完全に避けてS3の事前署名URLを使用します。

  logs

  ：laravelを構成して、それらをCloudWatchにストリーミングします。
  構成
  • ：変数をAWS Secrets Managerまたは集中管理のパラメーターストアに移動します。
  キュー
  • ：スケーラブルなキューとメッセージの処理のために、ジョブをAWS SQSに移行します。
  b）ベンダーのロックインの考慮事項
  • AWSサービスは魔法ですが、独自のものでもあります
    • SQSからRedisキューに移行したいですか？コードを書き換える準備をします
    ラムダからドッカーに引っ越したいですか？コーヒーをつかむ：それは長い夜になるでしょう。
    c）ServerLessを選択しない場合
    サーバーレスは、すべてのワークロードの銀の弾丸ではありません。次の場合はそれを避けてください：
    • websockets：API Gateway WebSocket APIやサードパーティのツールなどのサービスで達成可能ですが、複雑さを追加します。 あなたのアプリケーションには
    重いコンピューティングロードがあります
    • ：AI/mlの推論やビデオエンコーディングなどのタスクは、ラムダの15分の時間制限にヒットする可能性があります。 あなたはステートフルサービスに依存しています
    ：永続的なディスクまたはサーバー状態がリファクタリングに費用がかかると仮定するアプリケーション。
    次は何ですか？

    ---

    5. ServerLessのLaravelは、アプリケーションの構築と展開方法を変革する可能性がありますが、実際の魔法は実装にあります。跳躍して、Laravelアプリケーションにサーバーレストリートメントを与える準備はできましたか？パート2にご期待ください。このアーキテクチャを実現するための正確な手順をご案内します。

    あなたへの質問
    ：サーバーレスに対するあなたの最大の恐怖は何ですか？以下で共有してください。パート2のトップ3に対処します！

以上がLaravelアプリケーションをAWSサーバーレスに移行した理由（および時間とお金を節約できる理由）の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。