ELB vs API Gateway vs CloudFront / 結局何を選べばいいの？

Transcript

1. ELB vs API Gateway vs CloudFront 結局何を選べばいいの？ 2025/4/14 tanabe haruko
2. • 外資コンサルファームのエンジニア • 2024 Japan AWS All Certifications Engineers • Google Cloud認定資格 12種保有 tanabe haruko https://zenn.dev/haruko_tanabe @hrsaaaam
3. アジェンダ 1. はじめに 2. 各サービスの利用目的 3. 各構成パターンとユースケース 4. 実際、スピードってどれだけ変わるの？ 5. まとめ
4. 1 はじめに
5. はじめに • エンジニア経験が浅いと、インフラアーキテクチャの検討は難易度が高い。 • Elastic Load BalancingやAmazon API Gateway、Amazon CloudFrontは、「アプリケーションのフロントに置き、ユーザーからのアクセ スを受け付ける」という点は共通しているが、それぞれ本質的な目的は異な る。 ➢どのようなケースで、どのサービスを採用すればよいのか判断するための 指針がほしい！ • レスポンス速度の違いについても調査。
6. 2 各サービスの利用目的
7. 各サービスの利用目的（1/5） 1. Elastic Load Balancing（ELB） ➢ 1つまたは複数のAZ内の複数のターゲット の ヘルスチェックを行い、受信したトラフィックを 正常なターゲットにのみ自動的に分散させる ことが目的。 https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html
8. 各サービスの利用目的（2/5） Application Load Balancer（ALB） ➢ レイヤー7のロードバランサー ✓ URLに基づいたパスベースのリクエスト転送 ✓ HTTPヘッダーに基づいたホストベースのリクエスト転送 ✓ リクエスト内のフィールドに基づいたリクエスト転送
9. 各サービスの利用目的（3/5） Network Load Balancer（NLB） ➢ レイヤー4のロードバランサー ✓ 低いレイテンシーを維持したリクエスト処理 ✓ 静的IPアドレスのサポート ✓ IPアドレスによるターゲットの登録
10. 各サービスの利用目的（4/5） 2. Amazon API Gateway ➢ あらゆる規模のREST、HTTP、およびWebSocket APIを作成、公開、維持、 モニタリング、およびセキュア化することが目的。 https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/getting-started.html
11. 各サービスの利用目的（5/5） 3. Amazon CloudFront ➢ エッジロケーションを経由し、コンテンツを キャッシュ・圧縮することによって、世界中の ユーザーへ低レイテンシーなコンテンツの配 信を実現することが目的。 https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/Introduction.html
12. 3 各構成パターンとユースケース
13. • ユーザーからのアクセスのターゲットリソース (EC2インスタンス、コンテナ、IPアドレス、等)が 単一であり、スケーリング設定も行わない場合。 ① ELBもCloudFrontもAPI Gatewayもいらない！
14. • ユーザーからのアクセスのターゲットが、複数、 またはオートスケーリングが設定されたリソー スの場合。 • ALBは、WAFの設置やSecurityGroupの設 定が可能な点から、NLBと比較してセキュリ ティ面を重視する場合。 • また、レイヤー7で機能するため、パスベースや ホストベース、クエリ文字ベース等、コンテンツ に従ったリダイレクトを設定したい場合。 ② ALBのみ
15. • ユーザーからのアクセスのターゲットが、複数、 またはオートスケーリングが設定されたリソー スの場合。（ALB同様） • スケーリング性能の高さやレイテンシーの低さ が特徴なため、高パフォーマンスが求められる 場合。 ③ NLBのみ
16. • 前述のALBのユースケースに加え、世界中の ユーザーに対してより低レイテンシーなコンテ ンツ配信を行いたい場合。 • キャッシュの設定を細かく行いたい場合。 ④ ALB + CloudFront
17. • モニタリングや変換、バージョニング等の機能 と併せてAPIを構築・統合管理したい場合。 • さらに、アクセスの上限数のコントロールやア クセス数に基づくAPI課金の仕組みなどを実 装したい場合 • AWS Cognitoやカスタム認証基盤と統合し、 認証/認可の仕組みを取り入れたい場合。 ⑤ NLB + API Gateway
18. • ⑤NLB + API Gatewayのユースケースに 加え、世界中のユーザーに対して低レイテン シーなコンテンツ配信を行いたい場合 • キャッシュの設定を細かく行いたい場合にこの パターンを採用します。 • エッジロケーションでのキャッシング効果を活 用することによりAPIコール数を減らし、API Gateway利用料の削減を図ることが可能。ア クセス数が多いほど、コスト削減につながりや すい。 ⑥ NLB + API Gateway + CloudFront
19. 4 実際、スピードってどれだけ変わるの？
20. • 「hello,AWS!」の文字列を返すシンプルなウェブサイトをus-east-1の EC2に各パターンでデプロイ。 • 日本からブラウザでアクセスし、開発者ツールでコンテンツ取得速度を比 較。 検証方法
21. 検証結果：レスポンス速度の違い
22. 考察① アプリの前段にサービスを置かなくても初 回アクセス時とリロード後アクセス時にレス ポンス速度に違いあり。これは、今回の検証 範囲であるELB、API Gateway、 CloudFrontの外側（DNSキャッシュ等）に 要因あり。
23. 考察② NLBは「1秒間に数百万件もの大量なリク エストや、突発的で不安定なトラフィックを 処理すること」を得意としているため、今回 のような1回のアクセスで検証してもNLBの メリットが十分に発揮されていない。
24. 考察③ 初回アクセス時はAPI Gateway利用時の 方がレイテンシーが高い。これは、まだキャッ シュが作成されていない状況で、API Gatewayの経由に時間が掛かるため。
25. 考察④ CloudFrontを利用する場合も、まだキャッ シュが作成されていない初回アクセス時 は他パターンと比較するとレイテンシーが 大きくなる。2回目以降のアクセスでレスポ ンス速度が大幅に向上する。
26. 考察⑤ API GatewayとCloudFrontは同様 にキャッシュ機能があるが、 CloudFrontはユーザーに近いエッジ ロケーションでコンテンツがキャッシュ されているため、リロード後アクセス時 のレスポンス速度はCloudFront利用 時の方が圧倒的に低くなる。
27. 5 まとめ
28. 全体のまとめ • アプリケーションに求められる要件（ルーティング、セ キュリティレベル、レスポンス速度、等）によって、適し たサービスが存在する。 • その他詳細は以下記事参照。 https://zenn.dev/acntechjp/articles/8bde90d02ff2ef
29. 宣伝 • 埼玉県を拠点とした地方支部「JAWS-UG 彩の国埼玉支部」が発足しま した！ イベント参加登録（connpass）
30. Thank you！