1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【AWSプロフェッショナルへの道】現役エンジニアが贈るクラウド実践ガイド - 第6回

Last updated at Posted at 2025-07-18

Webアプリの守護神!ELBとAuto Scalingで高可用性とスケーラビリティを実現

こんにちは!現役エンジニアのakrです。

【AWSプロフェッショナルへの道】現役エンジニアが贈るクラウド実践ガイド」の第6回をお届けします。前回はDNSの基礎とRoute 53を使って、独自ドメインをAWSサービスに紐付ける方法を学びました。これで、あなたのWebサイトはプロフェッショナルな顔を持つことができましたね。

今回は、Webアプリケーションを安定稼働させる上で非常に重要な2つのサービス、ELB (Elastic Load Balancing)Auto Scaling (AWS Auto Scaling) を解説します。これらのサービスを組み合わせることで、アプリケーションの「高可用性」(システムが停止しないこと)と「スケーラビリティ」(負荷に応じて柔軟に性能を変化させること)を劇的に向上させることができます。

「ユーザーが急増したらサーバーが落ちるかも...」「障害が起きたらどうしよう...」といった心配は、ELBとAuto Scalingが解決してくれます。本記事では、それぞれのサービスの役割から、連携による強力なWebアプリケーション基盤の構築までを、実践的に学びましょう。

Webアプリの守護神!ELBとAuto Scalingで高可用性とスケーラビリティを実現 - visual selection.png


1. ELB (Elastic Load Balancing) とは?Webアプリの交通整理役

ELB (Elastic Load Balancing) は、その名の通り、複数のEC2インスタンス(または他のターゲット)にトラフィックを自動的に分散するロードバランシングサービスです。Webアプリケーションの入り口として機能し、ユーザーからのリクエストを適切に振り分けることで、アプリケーションのパフォーマンスと可用性を向上させます。

なぜELBが必要なのか?

  • 負荷分散: 複数のサーバーに均等にリクエストを分散させることで、特定のサーバーに負荷が集中してダウンするのを防ぎます。
  • 高可用性: ヘルスチェック機能により、異常のあるインスタンスを自動的に検出し、トラフィックを正常なインスタンスにのみ転送します。これにより、一部のサーバーに障害が発生してもサービス全体が停止するのを防ぎます。
  • スケーラビリティ: 新しいインスタンスが追加された場合、ELBが自動的にそのインスタンスをロードバランシングの対象に含めます。
  • SSL/TLS終端: SSL/TLS証明書をELBに設定することで、サーバー側のSSL/TLS処理負荷を軽減し、セキュリティを強化できます。

ELBの主要な種類

ELBには主に3つのタイプがあり、それぞれ異なる用途に適しています。

  1. Application Load Balancer (ALB):
    • レイヤー7 (HTTP/HTTPS) で動作するロードバランサーです。
    • URLパスやホスト名に基づいてトラフィックをルーティングできる「パスベースルーティング」や「ホストベースルーティング」が可能です。
    • マイクロサービスやコンテナベースのアプリケーション(ECS/EKS)に最適です。
    • ALBはHTTP/HTTPSトラフィックに特化しており、より高度なルーティング機能を提供します。
  2. Network Load Balancer (NLB):
    • レイヤー4 (TCP/UDP/TLS) で動作するロードバランサーです。
    • 非常に高速で、秒間数百万のリクエストを処理できる超高パフォーマンスが特徴です。
    • 静的なIPアドレスを持ち、IPアドレスベースのルーティングが可能です。
    • 極めて高いパフォーマンスと低レイテンシーが求められるアプリケーションや、TCP/UDPプロトコルを使用するサービスに適しています。
  3. Classic Load Balancer (CLB):
    • 旧世代のロードバランサーで、レイヤー4とレイヤー7の両方で動作します。
    • 現在ではALBやNLBが推奨されており、新規で利用することはほとんどありません。

今回は、最も汎用的に利用されるALBを中心に解説を進めます。

ELBの構成要素

  • リスナー (Listener): ロードバランサーが受信するリクエストのプロトコルとポート(例: HTTP:80, HTTPS:443)を定義します。
  • ターゲットグループ (Target Group): ロードバランサーがトラフィックを転送するEC2インスタンスなどのターゲットの集合です。ヘルスチェックの設定もここで行います。
  • ヘルスチェック (Health Check): ターゲットグループ内のインスタンスが正常に稼働しているかを定期的に確認します。異常と判断されたインスタンスにはトラフィックが転送されなくなります。

2. Auto Scalingとは?Webアプリの自動増減機能

Auto Scalingは、アプリケーションの負荷に応じて、EC2インスタンスの数を自動的に増減させるサービスです。これにより、需要の変動に柔軟に対応し、常に最適なリソースを提供しながらコストを最適化できます。

なぜAuto Scalingが必要なのか?

  • スケーラビリティ: トラフィックの増加に合わせて自動的にインスタンスを増やし、パフォーマンスの低下を防ぎます。
  • コスト最適化: トラフィックが減少したら自動的にインスタンスを減らし、不要なリソースに対する課金を抑えます。
  • 高可用性: インスタンスに障害が発生した場合、Auto Scalingが自動的に異常なインスタンスを終了し、新しいインスタンスを起動して置き換えます。これにより、手動での復旧作業が不要になり、サービスの中断時間を最小限に抑えます。

Auto Scalingの主要な構成要素

  • 起動テンプレート (Launch Template):
    • Auto Scalingが新しいEC2インスタンスを起動する際のテンプレートです。
    • AMI、インスタンスタイプ、キーペア、セキュリティグループ、ユーザーデータ(インスタンス起動時に実行するスクリプト)など、EC2インスタンスの全ての起動設定を定義します。
    • これにより、常に同じ設定のインスタンスを確実に起動できます。
  • Auto Scalingグループ (Auto Scaling Group - ASG):
    • EC2インスタンスのコレクションです。
    • 最小容量 (Min capacity): 常に稼働させておく最小インスタンス数。
    • 最大容量 (Max capacity): 負荷が増加した場合にスケールアウトする最大インスタンス数。
    • 希望する容量 (Desired capacity): 現在稼働させたいインスタンス数。
    • VPCとサブネット: インスタンスを配置するVPCとサブネットを指定します。通常、複数のAZにまたがるサブネットを指定し、高可用性を確保します。
  • スケーリングポリシー (Scaling Policy):
    • Auto Scalingグループのインスタンス数を増減させるルールです。
    • ターゲット追跡スケーリング: CPU使用率やELBのリクエスト数など、特定のメトリクスを目標値に維持するようにインスタンス数を調整します。最も一般的なスケーリングポリシーです。
    • ステップスケーリング: メトリクスが特定のしきい値を超えた場合に、段階的にインスタンスを増減させます。
    • シンプルスケーリング: メトリクスがしきい値を超えた場合に、インスタンスを増減させます(古いタイプ)。
    • スケジュールスケーリング: 特定の時間にインスタンス数を増減させます(例: 夜間はインスタンスを減らす)。

3. 実践!ELBとAuto Scalingを連携させてWebアプリ基盤を構築

それでは、実際にALBとAuto Scalingを連携させて、高可用性・スケーラビリティを持つWebアプリケーション基盤を構築してみましょう。前回のVPCとEC2の知識を活用します。

3.1. Webサーバー用AMIの準備 (任意だが推奨)

EC2インスタンス起動時にWebサーバー(Apacheなど)が自動的に起動するように、AMIを準備しておくと便利です。今回は、前回のEC2インスタンスでApacheをインストールした状態のAMIを作成してみましょう。

  1. 前回のEC2インスタンス (my-web-server-instance) が起動していることを確認します。
  2. EC2コンソールで my-web-server-instance を選択し、「アクション」→「イメージとテンプレート」→「イメージを作成」をクリックします。
  3. イメージ名: my-web-server-ami
  4. イメージの説明: AMI for web server with Apache installed
  5. 「イメージを作成」をクリック。作成には数分かかる場合があります。

3.2. Application Load Balancer (ALB) の作成

  1. AWSマネジメントコンソールにサインインし、「EC2」サービスに移動します。
  2. 左のナビゲーションペインから「ロードバランサー」を選択し、「ロードバランサーの作成」をクリックします。
  3. Application Load Balancer」を選択し、「作成」をクリックします。
  4. ステップ1: ロードバランサーの設定
    • ロードバランサー名: my-web-app-alb
    • スキーム: 「インターネット向け」を選択します(インターネットからのアクセスを許可するため)。
    • IPアドレスタイプ: 「IPv4」
    • VPC: 前回作成した my-web-app-vpc を選択します。
    • マッピング: 複数のアベイラビリティゾーン (AZ) にわたるパブリックサブネットを選択します。今回は学習のため、前回作成したmy-web-app-public-subnet-aを選択しますが、本番環境では必ず複数のAZに分散配置してください
    • セキュリティグループ: 新しいセキュリティグループを作成します。
      • セキュリティグループ名: alb-sg
      • 説明: Allow HTTP/HTTPS traffic to ALB
      • インバウンドルール:
        • タイプ: HTTP / ソース: どこでも (IPv4) (0.0.0.0/0)
        • タイプ: HTTPS / ソース: どこでも (IPv4) (0.0.0.0/0)
    • リスナー:
      • プロトコル: HTTP / ポート: 80
      • デフォルトアクション: 「ターゲットグループに転送」で、後で作成するターゲットグループを設定します。
  5. 「次へ」をクリック。
  6. ステップ2: ターゲットグループの設定
    • 「新しいターゲットグループ」を選択します。
    • ターゲットグループ名: my-web-app-tg
    • プロトコル: HTTP / ポート: 80 (Webサーバーがリッスンするポート)
    • VPC: my-web-app-vpc
    • ヘルスチェック:
      • プロトコル: HTTP
      • パス: / (Webサーバーのルートパス)
    • 「次へ」をクリック。
  7. ステップ3: ターゲットの登録
    • 今回はAuto Scalingでインスタンスを登録するため、ここでは何も選択せず「ロードバランサーの作成」をクリックします。

ALBの作成には数分かかる場合があります。ステータスが「active」になるまで待ちましょう。

3.3. 起動テンプレートの作成

Auto Scalingがインスタンスを起動するためのテンプレートを作成します。

  1. EC2コンソールで左のナビゲーションペインから「起動テンプレート」を選択し、「起動テンプレートを作成」をクリックします。
  2. 起動テンプレート名: my-web-app-launch-template
  3. AMI: 先ほど作成した my-web-server-ami を選択します。または、AWSが提供する「Amazon Linux 2023 AMI」を選択し、ユーザーデータでApacheをインストールするスクリプトを記述しても構いません。
  4. インスタンスタイプ: t2.micro (無料枠対象)
  5. キーペア: 前回作成した my-web-server-keypair を選択します。
  6. ネットワーク設定:
    • ネットワークインターフェース: 「新しいネットワークインターフェースを作成」を選択します。
    • セキュリティグループ: web-server-sg (前回作成したWebサーバー用SG) を選択します。
    • 自動割り当てパブリックIP: 「有効にする」を選択します。
    • (※高度な詳細 - ユーザーデータにApacheインストールスクリプトを記述する場合の例)
      #!/bin/bash
      yum update -y
      yum install -y httpd
      systemctl start httpd
      systemctl enable httpd
      echo "<h1>Hello from Auto Scaling EC2!</h1>" > /var/www/html/index.html
      
  7. 「起動テンプレートを作成」をクリック。

3.4. Auto Scalingグループの作成

最後に、起動テンプレートとALBを関連付けてAuto Scalingグループを作成します。

  1. EC2コンソールで左のナビゲーションペインから「Auto Scalingグループ」を選択し、「Auto Scalingグループを作成」をクリックします。
  2. ステップ1: Auto Scalingグループと起動テンプレートを選択
    • Auto Scalingグループ名: my-web-app-asg
    • 起動テンプレート: 先ほど作成した my-web-app-launch-template を選択します。
    • 「次へ」をクリック。
  3. ステップ2: ネットワークの設定
    • VPC: my-web-app-vpc を選択します。
    • アベイラビリティゾーンとサブネット: 前回作成したパブリックサブネットmy-web-app-public-subnet-a)を選択します。本番環境では必ず複数のAZに分散配置してください。
    • 「次へ」をクリック。
  4. ステップ3: ロードバランシングの設定
    • 「既存のロードバランサーにアタッチ」を選択します。
    • 「ターゲットグループを選択」で、先ほど作成したALBのターゲットグループ(my-web-app-tg)を選択します。
    • ヘルスチェック: 「ELBヘルスチェック」を有効にします。
    • 「次へ」をクリック。
  5. ステップ4: グループサイズとスケーリングポリシーの設定
    • グループサイズ:
      • 希望する容量: 1 (最初に起動するインスタンス数)
      • 最小容量: 1 (常に稼働させておく最小インスタンス数)
      • 最大容量: 3 (負荷が増加した場合にスケールアウトする最大インスタンス数)
    • スケーリングポリシー: 「スケーリングポリシーを設定」を選択します。
    • ターゲット追跡スケーリングポリシー」を選択します。
      • ポリシー名: cpu-utilization-scaling
      • メトリクスタイプ: 平均CPU使用率
      • ターゲット値: 50 (CPU使用率が50%を超えたらスケールアウト)
    • 「次へ」をクリック。
  6. ステップ5: 通知、タグなど (オプション)
    • 今回は特に設定は不要です。
  7. 「Auto Scalingグループを作成」をクリック。

Auto Scalingグループが作成されると、自動的に指定されたインスタンス数(希望する容量)のEC2インスタンスが起動し、ALBのターゲットグループに登録されます。

3.5. Webサイトにアクセスしてみよう

ALBのDNS名にアクセスして、Webサイトが表示されるか確認しましょう。

  1. EC2コンソールで「ロードバランサー」を選択し、my-web-app-alb を選択します。
  2. 説明」タブの「DNS名」をコピーします。
  3. WebブラウザでコピーしたDNS名にアクセスします。

Hello from Auto Scaling EC2! と表示されれば成功です!

3.6. スケーリングの動作確認 (オプション)

Auto Scalingが設定通りに動作するか確認してみましょう。

  1. Auto ScalingグループのEC2インスタンスにSSH接続し、CPUに負荷をかけるコマンドを実行します(例: stressコマンドのインストールと実行)。
    sudo amazon-linux-extras install epel -y
    sudo yum install stress -y
    stress --cpu 8 --timeout 300s # 8コアのCPUに300秒間負荷をかける
    
  2. しばらくすると、CloudWatchのCPU使用率が上昇し、Auto Scalingグループが新しいインスタンスを起動し始めるのが確認できるはずです。
  3. 負荷を停止すると、CPU使用率が低下し、インスタンスが自動的に終了されるのが確認できます。

4. ELBとAuto Scalingのベストプラクティス

  • 複数AZへの分散: 高可用性を確保するため、ELBとAuto Scalingグループは必ず複数のアベイラビリティゾーンにまたがるように設定しましょう。
  • 適切なヘルスチェック設定: アプリケーションが正常に稼働しているかを正確に判断できるヘルスチェックパス(例: /healthz)を設定しましょう。
  • スケーリングポリシーの最適化: アプリケーションの特性(トラフィックパターン、レイテンシー要件など)に合わせて、スケーリングポリシーのメトリクスとターゲット値を調整しましょう。過度なスケールイン/アウトはコスト増やパフォーマンス低下に繋がる可能性があります。
  • 最小容量と最大容量の検討: 常に必要な最小インスタンス数と、予期せぬトラフィック増加に対応できる最大インスタンス数を適切に設定しましょう。
  • 起動テンプレートのバージョン管理: 起動テンプレートはバージョン管理が可能です。変更を加える際は新しいバージョンを作成し、Auto Scalingグループに適用することで、ロールバックも容易になります。
  • コスト最適化: ピーク時以外はインスタンス数を減らすように設定したり、リザーブドインスタンスやSavings Plansと組み合わせたりすることで、コストを最適化できます。

まとめ

今回は、Webアプリケーションの高可用性とスケーラビリティを実現する「ELB」と「Auto Scaling」について深く掘り下げました。

  • ELBは、複数のインスタンスにトラフィックを分散し、ヘルスチェックで異常なインスタンスを排除することで、可用性を高めます。
  • Auto Scalingは、アプリケーションの負荷に応じてEC2インスタンスの数を自動的に増減させ、スケーラビリティと高可用性を提供します。
  • 実際にALB、起動テンプレート、Auto Scalingグループを作成し、連携させてWebアプリケーション基盤を構築する手順を実践しました。

これで、あなたのWebアプリケーションは、急なアクセス増にも、一部のサーバー障害にも動じない、非常に堅牢な基盤の上に立つことができました。ELBとAuto Scalingは、クラウドネイティブなアプリケーション開発において最も重要なサービスの組み合わせの一つです。ぜひこの強力な機能を使いこなしてください。


この記事が皆さんのAWS学習の一助となれば幸いです。

もしこの記事が役に立ったと感じたら、ぜひ「いいね」👍をお願いします!励みになります!


1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?