はじめに
AWSを基盤としたWEBアプリケーションのインフラアーキテクチャを検討する際に、求められる要件やアプリケーションの特性次第で選択するサービスは異なります。ユーザー端末からアプリケーションへの通信経路をスコープとして考えると、代表的なサービスとしてElastic Load BalancingやAmazon API Gateway、Amazon CloudFrontの設置を検討する機会が多いのではないでしょうか。
この3つのサービスは、「アプリケーションのフロントに置き、ユーザーからのアクセスを受け付ける」、「必要に応じて適切なルーティングを行う」、という点は共通していますが、それぞれ本質的な目的は異なり、サービスごとに強みを活かせるユースケースも様々です。今回は、どのようなケース（要件）で、どのサービスを採用すればよいのか判断するための指針として、取り得る組み合わせとそのユースケースをご紹介します
各サービスの利用目的
まず、サービスの採否を判断するため、各サービスはどのような目的で使われるのかを知る必要があります。そのため、ここではElastic Load Balancing、Amazon API Gateway、Amazon CloudFrontの各サービスについて、主な利用目的をご紹介します。
Elastic Load Balancing
Elastic Load Balancing（ELB）は、AWSのロードバランシングサービスです。
1つまたは複数のAZ内の複数のターゲット (EC2 インスタンス、コンテナ、IP アドレス、仮想アプライアンス、等) のヘルスチェックを行い、受信したトラフィックを正常なターゲットにのみ自動的に分散させることが目的となります。
ELBには、以下の4つの種類があります。
- Application Load Balancer
- Network Load Balancer
- Classic Load Balancer
- Gateway Load Balancer
この4種類のうち、Classic Load Balancerは前世代のロードバランサーであり、新規に利用することは推奨されておらず、現在はあまり利用されていません。
また、Gateway Load Balancerは、サードパーティの仮想アプライアンスに対するロードバランシングが主軸であるため、他の3つとは立ち位置がかなり異なります。
従って、本記事では、ロードバランサーとしてApplication Load BalancerとNetwork Load Balancerを対象として取り上げることとします。
Application Load Balancer
Application Load Balancer（ALB）は、リクエストの内容に基づいて、トラフィックをターゲットにルーティングするレイヤー7のロードバランサーです。
ALBでは、ターゲットアプリを個別にグループ化ができ、パスベースやホストベース、クエリ文字ベース等、コンテンツに従ったリダイレクトを設定することができます。
レイヤー7のロードバランサーなので、HTTP/HTTPSリクエストの負荷分散を行う場合に適しています。
Network Load Balancer
Network Load Balancer（NLB）は、IPプロトコルデータに基づいて、トラフィックをターゲットにルーティングするレイヤー4のロードバランサーです。
NLBでは、低いレイテンシーを維持しながら1秒間に数百万件ものリクエストを処理することが可能です。また、AZごとに単一の静的IPアドレスを使用しながら、突発的で不安定なトラフィックパターンに対処できるよう最適化されています。
レイヤー4のロードバランサーなので、ネットワーク/トランスポートプロトコルの負荷分散、および非常に高いパフォーマンス/低レイテンシーの通信が必要な場合に適しています。
なお、組み合わせるサービスによっては、ALB/NLBの選択が限られる場合もあるので、ロードバランシングだけでなくアーキテクチャ全体を見て採否の判断をする必要があります。
上記以外の詳細な解説については、AWS公式ドキュメントをご確認ください。
Amazon API Gateway
Amazon API Gatewayは、あらゆる規模のREST、HTTP、およびWebSocket APIを作成、公開、維持、モニタリング、およびセキュア化することを目的としたフルマネージド型のAWSサービスです。
APIの統合管理により、複数のサービスやリソース、共通の機能を一元的に管理し、バックエンドの開発の効率化を図ることができます。
また、スロットリングやレート制限を設定することで、APIへのアクセス上限数のコントロールや、アクセス数に基づくAPI課金の仕組み等が実装可能です。
AWS Cognitoやカスタム認証基盤と統合することもできるため、複数の外部クライアントにAPIを公開したい場合に、誰がAPIを利用しているのか、APIにアクセスしたユーザーが権限を持っているのかを確認する認証/認可の仕組みを取り入れることもできます。
Amazon CloudFront
CloudFrontは、AWSのコンテンツ配信ネットワーク (CDN) サービスです。
エッジロケーションというデータセンターの世界的ネットワークを経由し、コンテンツをキャッシュ・圧縮することによって、世界中のユーザーへ低レイテンシーなコンテンツ(.html、.css、.js、イメージファイル、ビデオストリーミングなど) の配信を実現することを目的としています。
エッジロケーションでのキャッシュは、有効期限や、エッジキャッシュからファイルを削除するInvalidation機能等、より細かな設定が可能です。
キャッシュを有効活用することで、オリジンサーバーの負荷軽減にもつながります。
以上、ELB、Amazon API Gateway、Amazon CloudFrontの利用目的をご紹介しました。
各構成パターンとそのユースケース
次に、ELB、Amazon API Gateway、Amazon CloudFrontをスコープとした場合に、どのようなケースでどのような構成を取るべきか、という視点で、構成パターン6つとそれぞれのユースケースについてご紹介します。
構成パターン1：【ELB】も【CloudFront】も【API Gateway】もいらない！
構成図
ユースケース
ユーザーからのアクセスのターゲットリソース (EC2インスタンス、コンテナ、IPアドレス、等)が単一であり、スケーリング設定も行わない場合、ELBによるロードバランシングは不要です。
また、ELBを不要とするような小規模のアプリケーションの場合、CloudFrontによるパフォーマンス改善や、API GatewayによるAPI管理も不要となるケースがほとんどです。
本構成が、以降5つの構成パターンのベースとなります。
以降で掲載する構成図には、簡略化のためInternet GatewayとNAT Gatewayの記載を省略していますが、インターネットからPrivateSubnetに配置したアプリケーションへのアクセスを許可するには、InternetGatewayとNatGatewayは必須となりますのでご注意ください。
構成パターン2：【ALB】のみ
構成図
ユースケース
ユーザーからのアクセスのターゲットが、複数、またはオートスケーリングが設定されたリソースの場合、トラフィックを各ターゲットに振り分けるためにロードバランサーが必要になります。
ALBは、WAFの設置やSecurityGroupの設定が可能な点から、NLBと比較してセキュリティ面を重視する場合の選択肢になります。
また、レイヤー7で機能するため、パスベースやホストベース、クエリ文字ベース等、コンテンツに従ったリダイレクトを設定したい場合にもALBが有効です。
ただ、コンテンツを前段でキャッシュする機能が無いため、CloudFront併用時と比較するとレイテンシーは高いです。レイテンシーをある程度許容できるケースでの採用を推奨します。
構成パターン3：【NLB】のみ
構成図
ユースケース
複数のリソースに対してトラフィックを振り分けることができる点はALBと同様です。
ALBと比較すると、スケーリング性能の高さやレイテンシーの低さが特徴なので、高パフォーマンスが求められるケースでの採用を推奨します。
ただ、WAFの設置やSecurityGroupの設定が出来ないため、セキュリティレベルが低いことが許容できる場合の選択肢となります。また、レイヤー4で機能するため、コンテンツに従ったリダイレクトは設定できません。
ALB同様、キャッシュ機能は無いため、CloudFront併用時と比較するとレイテンシーは高いです。
構成パターン4：【ALB】+【CloudFront】
構成図
ユースケース
前述のALBのユースケースに加え、世界中のユーザーに対してより低レイテンシーなコンテンツ配信を行いたい場合や、キャッシュの設定を細かく行いたい場合にこのパターンを採用します。
なお、CloudFrontは一般的にALBと併用されることが多いため、本記事ではCloudFrontとNLBの組み合わせはスコープ対象外としています。
構成パターン5：【NLB】+【API Gateway】
構成図
ユースケース
モニタリングや変換、バージョニング等の機能と併せてAPIを構築・統合管理したい場合にこのパターンを採用します。
一般的に、サーバーレスアーキテクチャ（Lambda等）のアプリケーションをバックエンドとするケースが多いです。
さらに、アクセスの上限数のコントロールやアクセス数に基づくAPI課金の仕組みなどを実装したい場合や、AWS Cognitoやカスタム認証基盤と統合し、認証/認可の仕組みを取り入れたい場合に最適です。
CloudFront併用時には及びませんが、キャッシュやペイロード圧縮により、高パフォーマンスが実現でき、NLB単体で利用する場合は設置できないWAFも、API Gatewayには設置可能であるため、求められるセキュリティレベルが高い場合も対応できます。
なお、API Gatewayを利用する場合に、併用してELBを設置する場合はALBは利用できないので、NLB一択になります。
構成パターン6：【NLB】+【API Gateway】+【CloudFront】
構成図
ユースケース
前述のNLB + API Gatewayのユースケースに加え、CloudFrontの利点である、世界中のユーザーに対して低レイテンシーなコンテンツ配信を行いたい場合や、キャッシュの設定を細かく行いたい場合にこのパターンを採用します。
また、コスト面では、エッジロケーションでのキャッシング効果を活用することによりAPIコール数を減らし、API Gateway利用料の削減を図ることができます。アクセス数が多いほど、コスト削減につながりやすいですが、CloudFront導入により削減されるAPI Gateway利用料と、追加で発生するCloudFront利用料を確認して判断する必要があります。
サービス採否検討フローチャート
次に、本記事に記載した内容を、簡易的なフローチャートとしてまとめました。各問いに対してYES/NOを判断することで、要件に適した構成を選択することができるようになっています。実際にアーキテクチャを検討する際にお役立てください。
さいごに
今回は、ELB（ALB/NLB）、API Gateway、CloudFrontをスコープとし、それぞれのサービスの採否検討の指針として活用できるよう、各サービスの特徴とユースケース、及び、採否検討用フローチャートをご紹介しました。
本記事が、WEBアプリケーション構築に伴うインフラアーキテクチャ検討の際の一助になれば幸いです。
アクセンチュア株式会社所属の社員有志による運営です。アクセンチュアの社員による様々な発信をまとめています。なお、投稿内容は社員個人の見解であり、所属する組織を代表するものではありません。
Discussion