AWSで基本的なWebアプリを構築するときのアーキテクチャ3パターン
AWSでWebアプリを構築する場合、コードをどこで実行するかは大きな検討ポイントです。
今回は Lambda, ECS, EC2 の3パターンから、それぞれの構成の特徴を整理していこうと思います。
目次
はじめに
こんにちは。
クラウドソリューショングループのwatanabe.tです。
この記事は アイソルート Advent Calendar 2020 6日目の記事です。
昨日は suzuki.ko さんの ESXi内のルーティングに必須！VyOSで仮想ルーター構築 でした。
クラウドとは切っても切り離せない、ネットワークの話はやはり勉強になりますね。
それでは、さっそくアーキテクチャを見ていきましょう。
1. Lambda + API Gateway パターン
まずはAWS LambdaとAmazon API Gatewayを利用したパターンからです。
このパターンはAWSサーバレスアーキテクチャの恩恵を最大に活かしたものです。
コードの実行にはLambdaを利用することで、EC2などのサーバをあらかじめ用意することなく、それらの管理からも解放された状態でアプリを実行することができます。
課金体系も実際の実行数に依るため、小～中規模案件ではコストをかなり小さく抑えることができます。
さらに、API Gatewayと組み合わせることでクライアントからAPIを実行できるようにし、Webサービスとして公開することができます。
このパターンの場合、Amazon CloudFront + Amazon S3でReactやVue.jsといったフロントエンドアプリをホスティングし、Client Side Rendering(CSR)のアーキテクチャが採用されることも多くあります。
しかし、このパターンではアプリ開発者にも、ある程度Lambdaの挙動に精通していることが求められ、これまでの一般的なサーバ上でアプリを構築する場合とは異なる知識が必要となります。
さらに、Lambda自身のスケーリングを制御できなかったり、コールドスタート問題があったりと、ちょっとしたコツが求められることがあります。
2. ECS + ELB パターン
次に、Amazon Elastic Container Service(ECS)とElastic Load Balancing(ELB)を利用したパターンです。
このパターンは流行りのコンテナを採用した、高い信頼性と拡張性を兼ね備えたサーバレスアーキテクチャです。
コードの実行にはFargate(コンテナ)を利用することで、EC2などのサーバをあらかじめ用意することなく、それらの管理からも解放された状態でアプリを実行することができます。
これはLambda + API Gatewayパターンと同じですが、最大の違いはその開発にあります。
Fargateであればローカルで開発に利用したコンテナをそのままサービスに利用できます。
これにより、ローカルで開発した場合と実際にサービスを提供している際の挙動の差異を小さくすることができます。
ただし、Fargateの実行時間単位の料金はEC2よりも高額になりがちなため、適切にコンテナのスケーリングを行い、リソースの無駄をなくすことが肝要です。
また、コンテナのオーケストレーションサービスは他のパブリッククラウドやOSSとしても提供されているため、AWSからGCPなどへの移行・拡大をすることも可能な点は大きなメリットです。
しかし、2020年12月のリリースでLambdaがコンテナイメージをサポートしたことにより、この差はかなり限定的なものになりました。
New for AWS Lambda – Container Image Support | AWS News Blog
このパターンでも、アプリ開発者にある程度のコンテナの知識が求められるため、これまでの一般的なサーバ上でアプリを構築する場合とは異なる知識が必要となります。
3. EC2 + ELB パターン
最後は、Amazon Elastic Compute Cloud(EC2)とElastic Load Balancing(ELB)を利用したパターンです。
このパターンは仮想サーバをそのまま利用した、一般的なWebサービスアーキテクチャです。
サーバーレスという概念が生まれるまでのスタンダードな構成、といっても良いでしょう。
コードの実行にはEC2(仮想サーバ)を利用しています。
これにより、オンプレミスで動いていたシステムをそのままクラウド上で動作させることができたり、かなり自由度が高くサーバのカスタマイズを行えたり、といったメリットがあります。
さらに、ELBを利用することでEC2のスケーリング・負荷分散にも対応し、一定の信頼性を確保することができます。
しかし、OSやミドルウェアの管理を自分で行わなければならなかったり、スケーリングの管理も自分で行わなければならなかったりと、保守・運用に関する手間が多い点がデメリットです。
おわりに
今回はAWSでWebサービスを構築する場合のアーキテクチャ3パターンをご紹介しました。
基本的には、Lambdaを利用することから検討を始め、それが難しい場合にECSやEC2のパターンを検討していく、という流れが推奨です。
とはいえ、要件にあったサービスを選定・利用していくことが肝心なので、必ずしもこれらのパターンを採用しなければならないということもありません。
適材適所、必要に応じて組み合わせていくことが大切です。
明日は suzuki.ko さんの 初歩から解説！BINDでシンプルDNSサーバー構築【用語編】です。
