🚀

AWSのハンズオン記録①　EC2作成と負荷テスト

に公開
EC2
idea

今回の作業の主旨
パブリックサブネットに配置したEC2に負荷をかけてCloudWatchで確認しよう

おおまかな作業の流れ

  1. 基盤の構築とWebサーバーの立ち上げ
  2. 負荷テストによる性能検証
  3. 作業のあと片付け

構成図書くのも訓練かと思い、構成図を作成してから作業に臨みました。

これ作るのが一番作業時間がかかったかもしれません。
ちなみに今回は単にEC2を作成して負荷をかけるなのでやっていませんが
実際のソリューションでは冗長でない構成はほぼあり得ませんので要注意。

  1. VPC (Virtual Private Cloud)：図内の下向きのU字みたいな図が被っている緑枠
    役割: AWSクラウド上に用意された利用者専用の仮想データセンターです。他のユーザーから完全に隔離されたプライベートなネットワーク空間を提供します。

今回の設定: 指定したIPアドレス範囲（CIDRブロック）を持ち、その中で全てのサーバーやネットワーク機器を管理する基盤です。

  1. インターネットゲートウェイ (IGW)：下向きU字みたいなやつ
    役割: VPCとインターネットとの間の出入口となる接続ポイントです。VPCを外部とつなぐための「回線」を引き込む役割を果たします。

今回の設定: VPCにアタッチ（接続）することで、VPC内のEC2インスタンスがインターネットと通信できる状態になりました。

  1. パブリックサブネット：緑塗りした領域
    役割: VPCをさらに分割した「部屋」のようなもので、インターネットゲートウェイを経由して外部と通信できるように設定された領域です。

今回の設定: このサブネットにEC2インスタンス（Webサーバー）を配置しました。外部からSSH接続ができたり、Webサーバーとしてインターネットに公開できたりするのは、このサブネットに配置したからです。

通信経路の仕組み

  1. ルートテーブル (交通整理の地図)
    役割: サブネットからのトラフィックをどこへ向かわせるかを決める「交通ルールブック」です。
    今回の設定:
    10.0.0.0/16 (VPC内): ローカル（VPC内の通信はそのまま）
    0.0.0.0/0 (インターネット全体): IGW（外部宛の通信は全てIGWへ誘導）

  2. セキュリティグループ (SG) と ネットワークACL (NACL)：図内の赤枠がSG設定箇所
    SG : EC2インスタンスの個々のサーバー単位で、どのポート（例: SSHの22番、HTTPの80番）の通信を許可するかを細かく制御しました。今回のSSH接続の許可/不許可は主にこの設定に依存しました。

NACL (サブネット単位の門番): サブネットの入口と出口で、通信を許可・拒否するルールです。SGよりも大まかなブロックルールとして機能します。今回は特に設定などはいじっていないので図には記載していません

作成に使用したのはこちら
https://www.drawio.com/

  1. 基盤の構築とWebサーバーの立ち上げ

1-1 VPCの作成
AWS上に隔離された仮想データセンターを定義します。IPアドレス範囲（例: 10.0.0.0/16）を決めることで、使用できるサーバーの数や、他のネットワークとの連携ルールを設定する土台になります。
いじった設定内容は右部分の図に表示されるので、直観的に操作できます。
ここでキーペアを作成し、自分のローカル環境に保存します。

1-2 インターネットゲートウェイ (IGW) の作成とアタッチ
VPCにインターネット回線を接続します。これをアタッチしない限り、VPC内のサーバーは外部と一切通信できません。

1-3 パブリックサブネットの作成
VPCを分割し、IGWを経由して外部と通信することを許可した領域（パブリック）としてサーバーを配置する「部屋」を用意します。

1-4 ルートテーブルの設定（IGWへの誘導）
「交通整理のルール」を設定します。送信先 0.0.0.0/0（すべての外部IP）のトラフィックを、必ずIGWへと誘導するルートを追加することで、サーバーのインターネット通信を有効化しました。

1-5 EC2インスタンス（t3.small）の起動
Webサーバー本体となる仮想マシンを起動します。t3.smallは、無料利用対象の中で一番スペックが低そうなのでチョイスしましたが、負荷テストしようとしたら意外と性能が高くてもうちょっと調べておけばよかったなと思いました。
→EC2のスペックは用途に応じて要検討！

1-6 パブリックIPの自動割り当ての有効化
この設定により、EC2にインターネット上の住所（パブリックIP）が付与されます。これがなければ、外部からサーバーを見つけることすらできません。
最初に起動したときはこれの設定忘れてたのでいったん削除して再作成しました…

1-7 セキュリティグループ (SG) の設定
予め設定用のSGを作成。

EC2インスタンスの作成時に紐づけを行います。
名前は適当です。

1-8 SSH接続の実行
ダウンロードしたキーペアを使用し、EC2のパブリックIPにログインします。ここで接続できない場合、ネットワークかSGの設定に必ず問題があります。
テラタームを使用して接続を試みましたが接続できず...
原因はSGでアクセス許可を入れているのが自分のローカルアドレスだったからでした
グローバルアドレスを検索し、インスタンスとSGを再設定！

無事接続成功！

1-9 Apache (httpd) のインストールと起動
LinuxサーバーにWebサーバーの心臓部となるソフトウェアをインストールします。systemctl enable httpd コマンドで、サーバー再起動後も自動でWebサーバーが立ち上がるように設定しました。

1-10 テストページの配置
Webサイトが正常に動いているかを確認するためのテストファイルを作成します。
ブラウザからアクセスし、無事動作確認。

1-11 Apache Bench (ab) のインストール
Webサーバーに擬似的なアクセスを大量に送りつけるための専用ツールをEC2内にインストールしました。これにより、外部のマシンを準備することなく負荷テストが実行できます。

1-12 CloudWatch監視の設定
負荷テスト実行中に、AWSコンソールのCloudWatchでEC2インスタンスのCPU使用率グラフをすぐに開けるよう準備しました。「負荷がかかった」ことを視覚的に確認するためです。
下準備が整ったので、いよいよ実証を開始します。

  1. 負荷テストによる性能検証
    2-1 最初の負荷テスト実行
    ab -n 1000 -c 10 コマンドで負荷をかける。

コマンドの意味
このコマンドは、指定されたURLに対して以下の負荷をかけます。
ab: Apache Bench ツールの実行コマンドです。これは、Apache HTTP Serverに同梱されていることが多く、Webサーバーのパフォーマンス測定（ベンチマーク）に使用されます。
-n 1000: 総リクエスト数 (Requests to perform) を指定します。
この場合、合計で1000回のリクエストをサーバーに送信します。
-c 10: 同時並行数 (Concurrency) を指定します。
この場合、同時に10個のクライアント（接続）がリクエストを送信し続けます。

2-2 コマンドを調整して負荷テスト実行
思った以上に処理能力が優秀だったので、何度か負荷の度合いを調整して検証を実行。

-n 500000 -c 100 で実行したところいい感じに負荷のスパイクが観測できたので満足。

閾値越えの負荷でバーストが使用されていることも確認

  1. 作業のあと片付け
    今回使用したEC2は、基本的に起動中ずっとお金がかかり続けるため
    「停止」ではなくしっかり「終了」を選択。

というわけで無事に負荷を観測できましたので検証は完了です。
実際に手を動かして作ってみると設定漏れ等があったりするし時間もかかりますね…
そのためのIaCなんでしょうけども
このあたりの環境のコード化などもおいおいやっていきたいところではありますが
次は冗長性や負荷分散の構成を作るハンズオンをやっていこうかなと思っています。
では。

Discussion