はじめに
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の利便性
1. URLに基づいたパスベースのリクエスト転送
クライアントからのリクエストURLに基づいて、通信の転送先を設定することができます。これにより、URLに基づいて適切なサービスにリクエストをルーティングすることができ、アプリケーションのマイクロサービス化を実現できます。
2. HTTPヘッダーに基づいたホストベースのリクエスト転送
クライアントからのリクエストHTTPヘッダーのホスト名に基づいて、通信の転送先を設定することができます。これにより、1 つのロードバランサーを使用して複数のサブドメイン、もしくは異なるトップレベルドメインへのルーティングが可能となります。
3. リクエスト内のフィールドに基づいたリクエスト転送
クライアントからのリクエストHTTPヘッダーに基づいて、通信の転送先を設定することができます。標準、またはカスタムのHTTPヘッダーフィールドの名前を指定でき、柔軟なルーティングが可能となります。
上記のように、コンテンツに従ったリダイレクトを設定することができる点が、ALBを利用するメリットと言えます。
Network Load Balancer
Network Load Balancer（NLB）は、IPプロトコルデータに基づいて、トラフィックをターゲットにルーティングするレイヤー4のロードバランサーです。
NLBの利便性
1. 低いレイテンシーを維持したリクエスト処理
揮発性のワークロードを処理し、1秒間に数百万件もの大量なリクエストや、突発的で不安定なトラフィックを処理することが可能です。
2. 静的IPアドレスのサポート
ロードバランサーの静的IPアドレスをサポートします｡ ロードバランサーで有効になっているサブネットごとに1つのElasticIPアドレスを割り当てることも可能です。
3. IPアドレスによるターゲットの登録
1つのEC2インスタンス上で稼働する複数のアプリケーションへのルーティングリクエストをサポートします。複数のポートを使用して、各インスタンス、またはIPアドレスを同じターゲットグループに登録することも可能です。
また、コンテナ化されたアプリケーションにも対応しており、タスクをスケジュールするときに未使用のポートを選択し、そのポートを使用するターゲットグループにタスクを登録することにより、クラスターを効率的に使用することができます。
上記のように、非常に高いパフォーマンス/低レイテンシーの通信が必要、IPアドレス単位でのルーティング設定が必要な場合に適しています。
なお、組み合わせるサービスによっては、ALB/NLBの選択が限られる場合もあるので、ロードバランシングだけでなくアーキテクチャ全体を見て採否の判断をする必要があります。
上記以外の詳細な解説については、AWS公式ドキュメントをご確認ください。
Amazon API Gateway
Amazon API Gatewayは、あらゆる規模のREST、HTTP、およびWebSocket APIを作成、公開、維持、モニタリング、およびセキュア化することを目的としたフルマネージド型のAWSサービスです。
API Gatewayの利便性
1. APIの一元管理による開発の効率化
API Gatewayを利用することにより、APIのバージョニングを簡単に実現し、新しいバージョンのAPIをスピーディーに実装、テスト、リリースすることができます。
このように、APIの統合管理により、複数のサービスやリソース、共通の機能を一元的に管理し、バックエンドの開発の効率化を図ることができます。
2. APIリクエスト時のコスト削減
API Gatewayの利用料金としては、APIリクエストと、送出されるデータに対してのみ料金が発生します。APIリクエストには段階的料金モデルが適用されており、最上位階層でもリクエスト100万件あたり0.90USDという低価格となっています。最低料金や前払いはなく、AWSアカウント全体でAPIの使用量が増えるほどコストを削減できます。
3. 簡単なモニタリングとセキュリティ設定
Amazon CloudWatchを併用することで、APIコール、データレイテンシー、エラー率に関するメトリクスを視覚的にモニタリングすることができます。
また、IAMやAWS Cognito、その他カスタム認証基盤と統合することができ、複数の外部クライアントにAPIを公開したい場合に、誰がAPIを利用しているのか、APIにアクセスしたユーザーが権限を持っているのかを確認する認証/認可の仕組みを取り入れることが可能です。
スロットリングやレート制限を設定することで、APIへのアクセス上限数のコントロールや、アクセス数に基づくAPI課金の仕組み等も実装可能です。
Amazon CloudFront
CloudFrontは、AWSのコンテンツ配信ネットワーク (CDN) サービスです。
エッジロケーションというデータセンターの世界的ネットワークを経由し、コンテンツをキャッシュ・圧縮することによって、世界中のユーザーへ低レイテンシーなコンテンツ(.html、.css、.js、イメージファイル、ビデオストリーミングなど) の配信を実現することを目的としています。
API Gatewayの利便性
1. 低レイテンシー、高スループットのコンテンツ配信
グローバルに分散したエッジロケーションにコンテンツをキャッシュし、自動化されたネットワークマッピングとインテリジェントルーティングを利用してデータを配信することで、レイテンシーを低減します。
2. ネットワークやアプリケーションへの攻撃対策
AWS Shield、AWS Web Application Firewall、Amazon Route 53と連携して、ネットワークやアプリケーションレイヤーのDDoS攻撃などの複数の種類の攻撃に対して、セキュリティ境界を作成し、主要な攻撃対象領域を重要なコンテンツやデータ、コード、インフラストラクチャから遠ざけることができます。
3. アプリケーションオリジンリクエストの削減
CloudFrontのエッジキャッシュとリージョナルキャッシュにコンテンツが保存され、必要な場合にのみオリジンから取得します。Origin Shieldを使用して一元化されたキャッシュレイヤーを有効にすることで、アプリケーションオリジンの負荷をさらに減らすことができます。
オリジンリクエストを削減することで、オリジンの運用上の負担とコストの軽減にもつながります。
以上、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つの構成パターンのベースとなります。
構成パターン2：【ALB】のみ
構成図
ユースケース
ユーザーからのアクセスのターゲットが、複数、またはオートスケーリングが設定されたリソースの場合、トラフィックを各ターゲットに振り分けるためにロードバランサーが必要になります。
ALBは、WAFの設置やSecurityGroupの設定が可能な点から、NLBと比較してセキュリティ面を重視する場合の選択肢になります。
また、レイヤー7で機能するため、パスベースやホストベース、クエリ文字ベース等、コンテンツに従ったリダイレクトを設定したい場合にもALBが有効です。
ただ、コンテンツを前段でキャッシュする機能が無いため、CloudFront併用時と比較するとレイテンシーは高いです。レイテンシーをある程度許容できるケースでの採用を推奨します。
構成パターン3：【NLB】のみ
構成図
ユースケース
複数のリソースに対してトラフィックを振り分けることができる点はALBと同様です。
ALBと比較すると、スケーリング性能の高さやレイテンシーの低さが特徴なので、高パフォーマンスが求められるケースでの採用を推奨します。
ただ、WAFの設置やSecurityGroupの設定が出来ないため、セキュリティレベルが低いことが許容できる場合の選択肢となります。また、レイヤー4で機能するため、コンテンツに従ったリダイレクトは設定できません。
ALB同様、キャッシュ機能は無いため、CloudFront併用時と比較するとレイテンシーは高いです。
構成パターン4：【ALB】+【CloudFront】
構成図
ユースケース
前述のALBのユースケースに加え、世界中のユーザーに対してより低レイテンシーなコンテンツ配信を行いたい場合や、キャッシュの設定を細かく行いたい場合にこのパターンを採用します。
構成パターン5：【NLB】+【API Gateway】
構成図
ユースケース
モニタリングや変換、バージョニング等の機能と併せてAPIを構築・統合管理したい場合にこのパターンを採用します。
さらに、アクセスの上限数のコントロールやアクセス数に基づく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を判断することで、要件に適した構成を選択することができるようになっています。実際にアーキテクチャを検討する際にお役立てください。
各パターンのレスポンス速度比較検証
上記のように、各サービスを併用することで様々なメリットを享受することができます。
既述の通り、CloudFrontをはじめとして「低レイテンシー」をメリットとしているサービスは複数ありますが、「実際にどれくらい早くなるの？」という点が気になりました。
そこで、それぞれのパターンでどの程度レスポンス速度が異なるのか、計6パターンを比較する形で実際に検証してみました。
なお、今回はレスポンス速度の比較に重点を置いているため、アプリケーションは「hello,AWS!」の文字列を返すシンプルなウェブサイトをus-east-1のEC2にデプロイしています。
また、レスポンス速度はネットワーク環境によって異なる結果が出ることがある点をご承知おきください。
構成パターン1：【ELB】も【CloudFront】も【API Gateway】もいらない！
構成図（再掲）
レスポンス速度
コンテンツ取得時間は482msであることが分かりました。
（ブラウザキャッシュの影響が出ないよう、シークレットウィンドウで検証をしています。）
ただ、リロードをすると、264ms程度までレイテンシーが低くなりました。
キャッシュの効果を測るためにも、初回アクセス時のレスポンス速度と、リロードした際のレスポンス速度について、他サービスと組み合わせたときにどのように変わるのか見ていきます。
構成パターン2：【ALB】のみ
構成図（再掲）
実装方法
1. Target groupsを作成する
1-1. [target type]はInstancesを選択する
1-2. [Target group name]に任意の名前を入力し、[VPC]にWebサイトをホスティングしているEC2が存在するVPCを選択する。
1-3. 他はデフォルトのままNextをクリックする
1-4. [Available instances]でWebサイトをホスティングしているEC2にチェックを入れて、[include as pending below]をクリックする
1-5. [Create target group]をクリックする
1-6. Target groupsの作成が完了
2. ALBを作成する
2-1. [EC2] > [Load Balancers] > [Create load balancer]をクリックする
2-2. [Application Load Balancer]の[Create]をクリックする
2-3. [Load balancer name]に任意の名前を入力する
2-4. [Network mapping]で、VPCとSubnetを選択する
2-5. [Listeners and routing]で、「1. Target groupsを作成する」で作成したTarget groupを選択する
2-6. 一番下までスクロールして[Create load balancer]をクリックする
2-7. ALBの作成が完了
3. アクセス確認
ALBの[DNS name]にアクセスすると、Webサイトが表示されることが確認できました。
コンテンツ取得時間
コンテンツ取得時間は431msであることが分かりました。
このパターンだと、リロードをすると205ms程度までレイテンシーが低くなりました。
構成パターン3：【NLB】のみ
構成図（再掲）
構成の実装方法
1. Target groupsを作成する
手順は「構成パターン2：【ALB】のみ」と同じため割愛します。
2. NLBを作成する
2-1. [EC2] > [Load Balancers] > [Create load balancer]をクリックする
2-2. [Network Load Balancer]の[Create]をクリックする
2-3. [Load balancer name]に任意の名前を入力する
2-4. [Network mapping]で、VPCとSubnetを選択する
2-5. [Listeners and routing]で、「1. Target groupsを作成する」で作成したTarget groupを選択する
2-6. 一番下までスクロールして[Create load balancer]をクリックする
2-7. NLBの作成が完了
3. アクセス確認
NLBの[DNS name]にアクセスすると、Webサイトが表示されることが確認できました。
コンテンツ取得時間
コンテンツ取得時間は378msであることが分かりました。
このパターンだと、リロードをすると206ms程度までレイテンシーが低くなりました。
構成パターン4：【ALB】+【CloudFront】
構成図（再掲）
構成の実装方法
1. Target groupsを作成する
手順は「構成パターン2：【ALB】のみ」と同じため割愛します。
2. ALBとCloudFrontを作成する
手順は「構成パターン2：【ALB】のみ」の、「2-5. [Listeners and routing]で、1. Target groupsを作成するで作成したTarget groupを選択する。」までは同じです。
最後、[Create load balancer]をクリックする前に、[Amazon CloudFront + AWS Web Application Firewall (WAF)]のチェックボックスをオンにすることで、CloudFrontを合わせて作成することができます。
ALBの作成と併せて、CloudFrontも作成されていることが分かります。
3. アクセス確認
CloudFrontの[Distribution domain name]にアクセスすると、Webサイトが表示されることが確認できました。
コンテンツ取得時間
コンテンツ取得時間は2,580msであることが分かりました。
このパターンだと、リロードをすると22ms程度までレイテンシーが低くなりました。
構成パターン5：【NLB】+【API Gateway】
構成図（再掲）
構成の実装方法
1. Target groupsを作成する
手順は「構成パターン2：【ALB】のみ」と同じため割愛します。
2. NLBを作成する
手順は「構成パターン3：【NLB】のみ」と同じため割愛します。
3. API Gatewayを作成する
3-1. API Gateway管理画面の[Choose an API type]で、REST APIの [Build]をクリックする
3-2. [API name]に任意の名前を入力し、[Create API]をクリックする
なお、このパターンではCloudFrontを利用しないため、API endpoint typeをデフォルトのResionalにしています。
3-3. REST APIが作成されたことを確認し、[VPC links]をクリックする
3-4. VPC linksの[Create]をクリックする
3-5. [Choose a VPC link version]でVPC link for REST APIsを選択し、[Name]に任意の名前を入力、Target NLBで「2. NLBを作成する」で作成したNLBを指定して[Create]をクリックする
3-6. VPC linkが作成されたことを確認し、[APIs]をクリックする
3-7. 先ほど作成したREST APIをクリックする
3-8. [Create method]をクリックする
3-9. 以下を設定し、[Create method]をクリックする
Method type：GET
Integration type：VPC link
HTTP method：GET
VPC link：先ほど作成したVPC link
Endpoint URL：先ほど作成したNLBのDNS name
3-10. methodが作成されたことを確認し、[Deploy API]をクリックする
3-11. Stageに[New stage]、Stage nameに任意の名前を入力し、[Deploy]をクリックする
3-12. Stageの[Cache cluster]と[Default method-level caching]をActive化する
3-13. [Invoke URL]を確認する
4. アクセス確認
API GatewayのInvoke URLにアクセスすると、Webサイトが表示されることが確認できました。
コンテンツ取得時間
コンテンツ取得時間は885msであることが分かりました。
このパターンだと、リロードをすると208ms程度までレイテンシーが低くなりました。
構成パターン6：【NLB】+【API Gateway】+【CloudFront】
構成図（再掲）
構成の実装方法
1. Target groupsを作成する
手順は「構成パターン2：【ALB】のみ」と同じため割愛します。
2. NLBを作成する
手順は「構成パターン3：【NLB】のみ」と同じため割愛します。
3. API Gatewayを作成する
手順は「構成パターン5：【NLB】+【API Gateway】」のケースとほぼ同じですが、CloudFrontと併用するためREST APIを作成する際にAPI endpoint typeをEdge-optimizedにしました。
4. CoudFrontを作成する
4-1. [CloudFront] > [Create distribution]をクリックする
4-2. [Origin domain]に先ほど作成したAPI Gatewayを選択する
4-3. [Cache policy]にCachingOptimizedを選択する
4-4. [Web Application Firewall (WAF)]でEnable security protectionsを選択する
(構成パターン4：【ALB】+【CloudFront】と条件を同じにするため)
4-5. 下までスクロールして[Create distribution]をクリックする
4-6. CloudFront distributionが作成されたことを確認する
5. アクセス確認
CloudFrontの[Distribution domain name]/[API GatewayのStage名] にアクセスすると、Webサイトが表示されることをが確認できました。
コンテンツ取得時間
コンテンツ取得時間は2,720msであることが分かりました。
このパターンだと、リロードをすると27ms程度までレイテンシーが低くなりました。
検証まとめ
今回のレスポンス速度に関する検証結果をまとめると以下の通りとなります。
| 構成パターン | 初回アクセス時（ms） | リロード後（ms） | 初回時とリロード時の差（ms） |
|---|---|---|---|
| 構成パターン1：【ELB】も【CloudFront】も【API Gateway】もいらない！ | 482 | 264 | 218 |
| 構成パターン2：【ALB】のみ | 431 | 205 | 226 |
| 構成パターン3：【NLB】のみ | 378 | 206 | 172 |
| 構成パターン4：【ALB】+【CloudFront】 | 2,580 | 22 | 2,550 |
| 構成パターン5：【NLB】+【API Gateway】 | 885 | 208 | 677 |
| 構成パターン6：【NLB】+【API Gateway】+【CloudFront】 | 2,720 | 27 | 2,693 |
以下は、本検証結果を踏まえた私の考察を記載します。
-
「構成パターン1：【ELB】も【CloudFront】も【API Gateway】もいらない！」の場合でも、初回アクセス時とリロード後アクセス時にレスポンス速度に違いが出ています。これは、今回の検証範囲であるELB、API Gateway、CloudFrontの外側（DNSキャッシュ等）に要因があると考えます。
-
NLBの特徴として、「低いレイテンシーを維持したリクエスト処理」と前述しました。
検証結果の「構成パターン2：【ALB】のみ」と、「構成パターン3：【NLB】のみ」を比較すると「構成パターン3：【NLB】のみ」の方が若干レスポンス速度が低い結果となりましたが、誤差の範囲内であるとも捉えられます。
顕著な差として現れなかったのは、NLBは「1秒間に数百万件もの大量なリクエストや、突発的で不安定なトラフィックを処理すること」を得意としているため、今回のような1回のアクセスで検証してもNLBのメリットが十分に発揮されていないことが原因と考えました。 -
「構成パターン3：【NLB】のみ」と「構成パターン5：【NLB】+【API Gateway】」を比較すると、初回アクセス時はAPI Gateway利用時の方がレイテンシーが高いです。これは、まだキャッシュが作成されていない状況で、API Gatewayの経由に掛かる時間と考えられます。
リロード後アクセス時はAPI Gatewayのキャッシュ機能が働いているため、初回アクセス時とリロード後アクセス時の差が大きい結果となっています。 -
CloudFrontを利用する場合も、まだキャッシュが作成されていない初回アクセス時は他パターンと比較するとレイテンシーが大きくなることが分かります。
API GatewayとCloudFrontは同様にキャッシュ機能がありますが、CloudFrontはユーザーに近いエッジロケーションでコンテンツがキャッシュされているため、リロード後アクセス時のレスポンス速度はCloudFront利用時の方が圧倒的に低くなりました。 -
今回は静的コンテンツを前提としてレスポンス速度を軸に比較しましたが、配信するコンテンツによってはキャッシュ機能が適していない場合もあるので、コンテンツ内容の特性を鑑みて各種設定を検討することが必要です。
さいごに
今回は、ELB（ALB/NLB）、API Gateway、CloudFrontをスコープとし、それぞれのサービスの採否検討の指針として活用できるよう、各サービスの特徴とユースケース、及び、採否検討用フローチャートをご紹介するとともに、各利用パターンのレスポンス速度の比較検証を行いました。
本記事が、WEBアプリケーション構築に伴うインフラアーキテクチャ検討の際の一助になれば幸いです。
Accenture Japan - ICE (有志) により固定
Cloudのキャリア・採用情報 | アクセンチュア
女性が活躍する職場｜採用情報 | アクセンチュア
アクセンチュア株式会社に所属する社員有志による運営です。アクセンチュアの社員による様々な発信をまとめています。なお、投稿内容は社員個人の見解であり、所属する組織を代表するものではありません。
Discussion