メインコンテンツまでスキップ

デプロイメントモデル(Deployment Model)

Lambdaと従来のサーバーベースのアプリケーションの違いについての上位概念としては、「実行環境（Execution Environment）」や「デプロイメントモデル（Deployment Model）」が当てはまる。

これらの用語は、アプリケーションがどのように実行され、管理されるかというコンテキストで使用されます。

  • VPNにコードを配置しており、く
  • 従来のサーバーベース
    • クラウドに配置している従来のサーバーベース（EC2にPHPやRails）
    • コンテナオーケストレーションがあり、コンテナーで実行されている
  • サーバーレス（Lambdaなど）

実行環境とデプロイメントモデルの比較​

以下は、その内容をまとめたドキュメントの例です：

AWS Lambda（サーバーレス環境）​

概要​

AWS Lambdaはサーバーレス実行環境であり、開発者はサーバーのプロビジョニングや管理を意識することなくコードを実行できます。Lambdaはイベント駆動型で、コードは個別のリクエストごとに短時間実行されるため、スケーリングやサーバーの状態を管理する必要がありません。

特徴​

  • 自動スケーリング: リクエストが増えると自動でスケールアップし、減少するとスケールダウンします。
  • ステートレス: 各リクエストは独立していて、状態を持たないため、一貫性のあるパフォーマンスを提供します。
  • マネージドサービス: インフラストラクチャの管理が不要で、開発者はコードに集中できます。

従来のサーバーベースのアプリケーション​

概要​

従来のサーバーベースのアプリケーションは、開発者がサーバーのプロビジョニング、セットアップ、保守を行う必要がある実行環境です。アプリケーションは長期間稼働するプロセスとして実行され、多くのリクエストを処理するために継続的に稼働します。

特徴​

  • 永続的実行: サーバープロセスは常時稼働し、複数のリクエストを連続して処理します。
  • ステートフル: セッション情報や一時データを長期間保持できます。
  • 再起動メカニズムの必要性: システムのクラッシュやリソースリークに対応するため、自動的にプロセスを再起動するメカニズムが必要です。

デプロイメントモデルによってアプリケーションコードの違い​

従来のサーバーベース

  • 再起動メカニズムを考える必要がある（アプリケーションが500を返したときに自動的に再起動する仕組み。） ここでコンテナーorクラウドサービスで使用しているかによって分岐される。
  • コンテナオーケストレーション: DockerやKubernetesなどのコンテナオーケストレーションツールは、コンテナが停止した場合に自動で再起動する機能を提供しています。
  • クラウドサービス: AWSのEC2インスタンスやElastic Beanstalk、AzureのApp Service、Google CloudのApp Engineなど、多くのクラウドサービスは、アプリケーションの実行を管理し、障害が発生したときに自動的に回復する機能を備えています。

fargateは？​

AWS Fargateは、Amazon ECSのサーバーレスコンピューティングエンジンの1つで、サーバーのプロビジョニングや管理から解放され、コンテナを直接実行することを可能にします。Fargateを使用する場合、以下のような特徴があります：

  1. サーバーレス: コンテナを実行するためのサーバーインフラストラクチャの管理はAWSによって抽象化され、ユーザーはコンテナの実行にのみ集中できます。

  2. タスク単位でのスケーリング: ECSと同様に、Fargateはサービスとして定義されたタスクをスケーリングしますが、サーバーの数やクラスターの管理を心配する必要はありません。タスクの数はリクエスト量に基づいて自動的にスケールアップまたはダウンします。

  3. 持続的実行: FargateもECSと同じく、コンテナタスクは状態を持つことができ、リクエストに応じて連続的に処理を行います。Lambdaと異なり、個々のリクエストごとに新しいコンテナが起動するわけではありません。

  4. ロードバランシング: ECSのFargateタスクもロードバランサーを用いてトラフィックを分散し、複数のタスク間でリクエストを処理します。

Fargateは、インフラストラクチャの管理を気にせずにコンテナを実行したい場合に適していますが、Lambdaとは異なり、実行されるコンテナはリクエスト間で状態を共有する可能性があります。このため、Fargate上で実行されるコンテナアプリケーションには、Lambdaと同様に自動で新しいインスタンスが起動するわけではないので、適切なスケーリング戦略と監視が必要です。また、アプリケーションの健全性を維持するために、再起動ポリシーなどの自動回復メカニズムを設定することも一般的です。

に最終更新