Lab 4

Lab4：Amazon EC2 と Amazon RDS にスケーラビリティを追加

概要

この Lab では、EC2 Auto Scaling を使用し、Amazon Elastic Compute Cloud (Amazon EC2) のスケールアウトを実施します。

目標

このラボを修了すると、次のことが出来るようになります。

  • EC2 Auto Scaling を使用し、Amazon EC2 インスタンスをスケールアウトする

  • 最終的には、次の図で示すようなアプリケーション環境を構築する

前提条件

このラボの前提条件を次に示します。

  • Microsoft Windows、Mac OS(X以降）、または Linux（Ubuntu、SUSE、または Red Hat）が搭載されているノートパソコンで、Wi-Fi アクセスができること
  • Microsoft Windows ユーザーの場合は、コンピュータへの管理者アクセスができること
  • Chrome、Firefox、Internet Explorer 11（これより前のバージョンの Internet Explorer はサポートされていません）などのインターネットブラウザを利用できること

時間

このラボは、終了までに 40 分かかります。

各タスクへのリンク

Lab4-Task1: 起動テンプレート、Auto Scaling グループの作成

このセクションでは “起動テンプレート” と “Auto Scaling グループ” を作成し、自動的に EC2 インスタンスが ALB の負荷分散先 (Target) に組み込まれる環境を構成します。

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 左側のナビゲーションペインで [起動テンプレート(テンプレートの起動)] をクリックします。

  3. [起動テンプレートを作成] をクリックします。

  4. 以下の値を入力します。

    起動テンプレート名と説明
    – 起動テンプレート名 MyLaunchTemplate
    – テンプレートバージョンの説明 Lab4 1st
    – Auto Scaling のガイダンス [レ] EC2 Auto Scaling で使用できるテンプレートをセットアップする際に役立つガイダンスを提供
    Amazon マシンイメージ (AMI)
    – AMI “AMI を選択してください"をクリック
    検索フォームに myami と入力
    myAMI-Lab3 を選択
    インスタンスタイプ
    – インスタンスタイプ “起動テンプレートに含めないでください"をクリック
    検索フォームに t2 と入力
    t2.micro を選択
    – キーペア デフォルトのまま
    ネットワーク設定
    – セキュリティグループ websg
    ストレージ（ボリューム）
    デフォルトのまま
    リソースタグ
    デフォルトのまま
    ネットワークインターフェイス
    デフォルトのまま
    高度な詳細
    – 購入オプション デフォルトのまま
    – IAM インスタンスプロフィール WP-Role
    – ホスト名のタイプ デフォルトのまま
    – DNS ホスト名 デフォルトのまま
    – シャットダウン動作 デフォルトのまま
    – 停止 - 休止動作 デフォルトのまま
    – 終了保護 デフォルトのまま
    – CloudWatch モニタリングの詳細 有効化
    – Elastic GPU デフォルトのまま
    – Elastic Inference デフォルトのまま
    – クレジット仕様 デフォルトのまま
    – プレイスメントグループ名 デフォルトのまま
    – EBS 最適化インスタンス デフォルトのまま
    – キャパシティーの予約 デフォルトのまま
    – テナンシー デフォルトのまま
    – RAM ディスク ID デフォルトのまま
    – カーネル ID デフォルトのまま
    – Nitro Enclave デフォルトのまま
    – ライセンス設定 デフォルトのまま
    – アクセス可能なメタデータ デフォルトのまま
    – メタデータのバージョン デフォルトのまま
    – メタデータレスポンスのホップ制限 デフォルトのまま
    – ユーザーデータ デフォルトのまま

  5. [起動テンプレートを作成] をクリックします。

  6. [テンプレートから Auto Scaling グループを作成] の Auto Scaling グループを作成 のリンクをクリックします。

  7. [名前] に MyAutoScalingGroup と入力します。

  8. [次へ] をクリックします。

  9. 以下の値を選択します。

    ネットワーク
    VPC LabVPC
    サブネット Public Subnet1
    Public Subnet2

  10. [次へ] をクリックします。

  11. 以下の値を入力します。

    ロードバランシング
    既存のロードバランサーにアタッチ チェックする
    既存のロードバランサーにアタッチ
    ロードバランサーのターゲットグループから選択 チェックする（デフォルトのまま）
    既存のロードバランサーターゲットグループ wptarget を選択
    ヘルスチェック
    ELB チェックする
    ヘルスチェックの猶予期間 90 秒
    その他の設定
    モニタリング CloudWatch 内でグループメトリクスの収集を有効にする にチェックする

    ヒント : この設定で ALB のターゲットグループ wptarget と関連付けたため、EC2 Auto Scaling グループ 内の EC2 インスタンスは自動的に ALB の負荷分散対象に組み込まれます。

  12. [次へ] をクリックします。

  13. 以下の値を入力します。
    グループサイズ
    – 希望する容量 2
    – 最小キャパシティ 2
    – 最大キャパシティ 2
    スケーリングポリシー なし（デフォルトのまま）
    インスタンスのスケールイン保護 [ ] インスタンスのスケールイン保護を有効にする(デフォルトのまま)

    ヒント : グループサイズとして"希望するキャパシティ”、“最小キャパシティ”、“最大キャパシティ” がすべて同じ値なので、“Auto Healing” の挙動になります

  14. [次へ] をクリックします。

  15. ステップ 5: 通知設定は行いません。 [次へ] をクリックします。

  16. ステップ 6: タグ設定は行いません。 [次へ] をクリックします。

  17. [Auto Scaling グループを作成] をクリックします。 ここまでの設定で、Auto Scaling グループ が作成されました。すでに Atuo Scaling の動作が開始されていますので、状態を確認していきましょう

  18. [Auto Scaling グループ] の一覧で、[MyAutoScalingGroup] をクリックします。

    [詳細]、[アクティビティ]、[インスタンス管理] タブの内容を確認します。 [詳細] は Auto Scaling Group の設定内容の表示・編集、[アクティビティ] は時系列の処理内容の表示、[インスタンス管理] は Auto Scaling Group 内のインスタンスの状態の参照や Group からの除外などを行います。

  19. [インスタンス管理] タブをクリックし、Web サーバーが新規に 2 つ起動していることを確認します。

  20. 左側のナビゲーションペインで[インスタンス(Instances)] をクリックします。

  21. インスタンスの一覧で、Auto Scaling グループにより 2 つの Web サーバーが新たに起動していることを確認します。

Lab4-Task2: ELB (ALB) から手動で作成した Web サーバーを削除

このセクションでは、ELB (ALB) の負荷分散対象となる Web サーバーを Auto Scaling グループで作成された Web サーバーのみとするために、手動で作成した Web サーバーを ELB (ALB)から削除します。

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 左側のナビゲーションペインで [ターゲットグループ] をクリックします。

  3. [wptarget] をクリックします。

  4. [ターゲット (Targets)] タブをクリックします。

  5. Web Server01,Web Server02 にチェックし、[登録解除 (Deregister)] をクリックします。 Web Server01、Web Server02 は draining 状態になり、既存コネクションは維持したまま新規トラフィックが送信されない状態となります。

  6. 左側のナビゲーションペインで [インスタンス] をクリックします。

  7. インスタンスの一覧から [Web Server01] と [Web Server02] にチェックを入れ、上部の [インスタンスの状態] をクリックし [インスタンスを終了] の順に選択します。

  8. インスタンスの削除画面で [終了] をクリックします。

    ここまでの操作により、ALB (WordPressLB) の配下のインスタンスは、Auto Scaling グループ (MyAutoScalingGroup) によって作られた Web サーバーだけとなりました。

  9. WordPress で構築されたブログサイトがこれまで通り表示されることを確認します。

    アクセス先 URL は、http://<ロードバランサー (WordPressLB)の DNS 名> と指定します。

    以下は URL の例です。 例）http://wordpresslb-123456789012.ap-northeast-1.elb.amazonaws.com

Lab4-Task3: Auto Scaling グループの動作の確認 (Auto Healing)

このセクションでは、EC2 Auto Scaling の動作を確認します。
EC2 Auto Scaling によって作成された Web サーバーのうち、いずれか 1 つを停止します。
Auto Healing によって停止した Web サーバーが削除され、正常な代替 Web サーバーが起動するか確認します。

  1. EC2 Auto Scaling によって起動された Web サーバーを停止するために、AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 左側のナビゲーションペインで [インスタンス] をクリックします。

  3. インスタンス一覧から Auto Scaling によって起動された Web サーバー (Name 欄が空欄のもの) のうちの 1 つを右クリックし、[インスタンスを停止] をクリックします。

  4. インスタンスの停止画面で、[停止] をクリックします。 当該インスタンスの状態が 停止中 > 停止済み > 終了済み の順に変化するはずです。

  5. そのまましばらく待機し、停止した Web サーバーが Auto Scaling によって終了 (terminate) され、新しい Web サーバーが起動することを確認します。

    ヒント : インスタンスの終了～新規 Web サーバの起動には 5 分ほどかかります。

    質問1：手順としては、EC2 インスタンスを 停止 (stop) しただけにも関わらず、最終的には 終了 (terminate) されました。なぜ、このような動作になったのですか？

    質問2：このような Auto Healing の構成は、実際のシステム設計・運用でどのように活かすことができますか？

Lab4-Task4: Auto Scaling グループのグループサイズの変更

このセクションでは、Auto Scaling グループのサイズを拡大します。

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 左側のナビゲーションペインで [Auto Scaling グループ] をクリックします。

  3. Auto Scaling グループ MyAutoScalingGroup の名前をクリックします

  4. [詳細] タブ > [グループの詳細] で [編集] をクリックします。(画面右に見切れている場合がありますので、スクロールして表示してください。)

  5. Auto Scaling Group のグループサイズの [最大キャパシティ] を以下の値に変更します。
    グループサイズ
    – 希望する容量 2
    – 最小キャパシティ 2
    – 最大キャパシティ 4

  6. [更新] をクリックします。

    最大キャパシティ(Auto Scaling Group 内の EC2 インスタンス数の上限) を変更しただけなので、希望する容量 (現在起動したい EC2 インスタンス数) に変化はありません。

Lab4-Task5: スケーリングポリシーの作成

このセクションでは、Auto Scaling グループが需要に応じてスケールアウトするようにスケーリングポリシーを設定します。

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 左側のナビゲーションペインで [Auto Scaling グループ] をクリックします。

  3. Auto Scaling グループ (MyAutoScalingGroup) を選択し、[自動スケーリング] タブをクリックして [動的スケーリングポリシー] の [動的スケーリングポリシーを作成] をクリックします。

  4. [スケーリングポリシーを作成] で、以下の値を指定します。
    ポリシータイプ ターゲット追跡スケーリング
    スケーリングポリシー名 MyScalingPolicy
    メトリクスタイプ ターゲットごとの Application Load Balancer リクエスト数
    ターゲットグループ wptarget
    ターゲット値 100
    メトリクスに含める前にウォームアップする秒数 90
    スケールインを無効にしてスケールアウトポリシーのみを作成する チェックなし

    ヒント : 起動テンプレートで指定したAMIおよびインスタンスサイズで WordPress を動作させた際に、250～300 リクエスト/分 が正常動作する閾値 (Target Value) と仮定した設定にしています。

    ヒント : Target Tracking Scaling Policy を利用すると、EC2 Auto Scaling によって Scale-out (インスタンス追加)・Scale-in (インスタンス削除) するために自動的に CloudWatch Alarm が設定されます。

  5. [作成] をクリックします。

Lab4-Task6: 負荷テストサーバーの作成

このセクションでは、EC2 Auto Scaling の動作を確認するための負荷テスト用サーバーを作成します。

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 左側のナビゲーションペインで [インスタンス] をクリックします。

  3. [インスタンスを起動] をクリックします。

  4. Amazon Machine Image (AMI) を選択します。[クイックスタート] の最初のエントリである[Amazon Linux 2 AMI (HVM) - Kernel 4.14, SSD Volume Type] の横にある[選択] をクリックします。

  5. [インスタンスタイプの選択] ページで、t2.micro を選択して、[次の手順:インスタンスの詳細の設定] をクリックします。

  6. [インスタンスの詳細の設定] ページで、次のように指定します。
    ネットワーク Lab VPC
    サブネット PublicSubnet02
    自動割り当てパブリック IP 有効
    IAM ロール WP-Role
    高度な詳細(ユーザデータ) 下記コマンド群をコピー ＆ ペーストしてください

    ・ユーザーデータ

    #!/bin/bash
yum -y update
yum -y install httpd httpd-tools
systemctl enable httpd.service
systemctl start httpd.service

    ヒント : ユーザーデータによって、インスタンス作成時に自動的に Apache httpd をインストールします。WordPress に負荷をかけるための Apache Bench コマンドが内包されています。

  7. [次の手順: ストレージの追加] をクリックします。
    インスタンスのストレージ設定はデフォルトのままにします。

  8. [次の手順: タグの追加] をクリックします。

  9. [クリックして Name タグを追加します] をクリックします。

  10. 追加されたテキストボックスに以下の値を入力します。
    キー Name
    値 Stress Server

  11. [次の手順: セキュリティグループの設定] をクリックします。

  12. [セキュリティグループの割り当て] で、[既存のセキュリティグループを選択する] ラジオボタンをクリックします。  

  13. [websg]を選択します。

  14. [確認と作成]をクリックします。

    ヒント:【警告メッセージが出た場合】
    下記警告メッセージは、このハンズオンでは無視して下さい。
    「AMI では、アクセスを可能にするためにポート 22 を開く必要があるため、このインスタンスに接続できません。現在のセキュリティグループでは、ポート 22 が開いていません。」
    尚、実際のシステム構築・運用では、警告メッセージをよく読み、セキュリティや運用上の問題がないか確認することをお勧めします。

  15. 表示された設定を確認して、[起動] をクリックします。

  16. [既存のキーペアの選択] をクリックして [キーペアなしで続行] を選択します。

  17. “私は、キーペアがない場合、EC2 Instance Connect を使用するか、AMI に組み込まれているパスワードを知っている場合にのみ、このインスタンスに接続できることを認識しています。EC2 Instance Connect は、Amazon Linux 2 および Ubuntu でのみサポートされています。詳細はこちらをご覧ください。“のチェックボックスに、チェックを入れます。

  18. [インスタンスの作成]をクリックします。

  19. [インスタンスの表示] をクリックします。

  20. EC2 インスタンス一覧の画面が表示されます。
    作成した EC2 インスタンス (Stress Server) を選択し、インスタンスの [ステータスチェック] が [2/2 のチェックに合格しました] と表示されるのを確認します。

    ヒント : 表示が変わらない場合は、マネジメントコンソール右上の [更新] アイコンをクリックし、画面をリフレッシュしてください。

Lab4-Task7: スケーリングポリシーの動作確認

このセクションでは、負荷テスト用サーバーから Apache Bench コマンドで WordPress のブログサイトに負荷を与えて、Auto Scaling グループ内の Web サーバーをスケールアウトさせます。

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. EC2 のマネジメントコンソールのナビゲーションペインで [ロードバランサー] をクリックします。

  3. 「ラボ 2」で作成した ELB (WordPressLB) を選択し、画面下部の [説明] タブをクリックします。

  4. [説明] タブに表示されている [DNS 名] の値をコピーします。

  5. 左側のナビゲーションペインで [インスタンス] をクリックします。

  6. Stress Server 左のチェックボックスをクリックします。

  7. 画面上部の [接続] をクリックします。

  8. 接続方法 [セッションマネージャー] を選択します。

  9. [接続] をクリックします。
    新しいブラウザのタブで、コマンドプロンプトが表示されます。

  10. Stress Server の Session Manager 接続画面に戻ります。

  11. Stress Server から Web サーバー (WordPress) に大量の HTTP リクエストを送信して負荷をかけます。
    Stress Server で以下のコマンドを実行します。これは 同時接続数 = 6 で 12,000 回 の HTTP リクエストを実行するコマンドです。

    ab -c 6 -n 12000 http://<ELBのDNS名>/

    注意: URL の末尾はスラッシュ('/') で終了するように設定してください。

    ヒント : “Ctrl” キーと “c” キーを同時に押すと、Apache Bench の実行を強制終了します

    EC2 インスタンス数が増えるには、負荷をかけ始めてから 数分～10 分程かかります。次の手順に進みましょう

  12. 負荷状況については、CloudWatch の メトリクス で確認することが出来ます。 Lab3 で作成した CloudWatch のダッシュボード WordPressDashboard を参照して、“ALB 配下のインスタンス数” や “リクエスト数/ターゲット” を参照しましょう。

    時間の経過とともに ALB の負荷分散ターゲットホスト数、ターゲット当たりのリクエスト数が変化する事が分かるでしょう。 下記ダッシュボードの表示例では、可視性を高めるために注釈線などを追加しています。

    ヒント : EC2 インスタンス数が増えるには、負荷をかけ始めてから 数分～10 分程かかります。Task8 に進みましょう

    質問1：EC2 Auto Scaling は具体的にどのようなトリガーによって EC2 インスタンスを作成しているのでしょうか？ CloudWatch のアラーム、EC2 Auto Scaling のアクティビティ履歴に注目して調べてみましょう。

    質問2：EC2 Auto Scaling は具体的にどのようなトリガーによって EC2 インスタンスを削除しているのでしょうか？ CloudWatch のアラームに注目して調べてみましょう。

  13. EC2 マネジメントコンソールのナビゲーションペインで [インスタンス] をクリックし、Web サーバーが 2 つ追加されていることを確認します。

Lab4-Task8: DB サーバーのスケールアップ

このセクションでは、インスタンスクラス、ボリュームサイズを変更して DB インスタンスのスケールアップを実施します。

  1. AWS マネジメントコンソールで [サービス] から [RDS] をクリックします。

  2. 左側のナビゲーションで [データベース] をクリックします。

  3. 作成されている DB サーバー [chapter1] の左側の〇をクリックして、 [変更] を選択します。。

  4. [DB インスタンスクラス] で 標準クラス を選択します。

  5. ドロップダウンの一覧で [db.m5.large] を選択します。

  6. [ストレージ] の [ストレージ割り当て] に「25」と入力します。

    警告メッセージ インスタンスストレージをスケーリングすると、次のことが起こります。 が表示されることがありますが、このトレーニングでは次の手順に進んで下さい。

    ヒント : 実際のシステム運用では要求されるパフォーマンスと変更に要する時間について十分に検討・検証してください。

  7. ページ下部の [続行] をクリックし、 変更のスケジューリング で [すぐに適用] チェックボックスをオンにします。

    警告メッセージ 予期されないダウンタイムの可能性 が表示されることがありますが、このトレーニングでは次の手順に進んで下さい。

    ヒント : 実際のシステム運用ではメッセージ内容について十分に検討・検証してください。

  8. 確認画面で内容を確認し、問題がなければ、[DB インスタンスを変更] をクリックします。

    ヒント : DBインスタンスの変更 ボタンが押下できない場合は、一度変更をキャンセルしてから DB インスタンスクラス db.t2.small や db.t3.micro 等を指定してください

  9. データベースの [ステータス] が [利用可能] になれば、DB インスタンスのスケールアップは完了です。

    暫くすると、[ステータス] が [変更中] に変わります。その後、[利用可能] になるまで 10 分 〜 25 分程度の時間がかかります。 スケールアップの過程で行われる RDS の FailOver は、およそ 1 ～ 2 分で完了します。RDS コンソールの [ログとイベント] で FailOver の開始～完了を確認できます。

  10. WordPress のブログサイトが参照できるか確認してみましょう。 http://<ロードバランサー (WordPressLB)の DNS 名> にアクセスします。

  11. DB インスタンスのスケールアップ開始が確認できたら、CloudWatch のダッシュボードに戻り EC2 インスタンスのスケールアウトの状態を確認しましょう。

Lab4-Challenge Task1: 外部公開範囲の最小化

この Challenge Task では EC2 Auto Scaling で生成する EC2 インスタンスが稼働する Subnet を、Public Subnet から Private Subnet に変更します。また、Security Group “websg” の inbound ルールを変更して、ALB からの HTTP のみ許可するように変更します。

ヒント : Challenge Task はハンズオンをより深く理解をするための Task です。次のモジュールやラボに進むための必須手順ではありません。

  • Task 実施時間目安：10 分

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 画面左側のナビゲーションペインで [セキュリティグループ] をクリックします。

  3. websg のチェックボックスをクリックします。

  4. [インバウンドルール] タブ をクリックします。

  5. [インバウンドルールを編集 (Edit inbound rules)] をクリックします。

  6. 既存のルール (Access to WordPress) 右側の [削除]をクリックし、ルールを削除します。

  7. [ルールを追加] をクリックし、以下の内容でルールを追加します。

    タイプ プロトコル ポート範囲 ソース(またはリソースタイプ) 説明
    HTTP を選択 (自動的に選択されます) (自動的に選択されます) 検索フォームに lbsg と入力し、選択候補をクリック Access to WordPress

    WordPress サーバーに紐づいているセキュリティグループを変更し、許可する通信を ALB からの HTTP アクセスのみに限定しました。これで WordPress サーバーはインターネットから直接アクセスされなくなりました。

  8. [ルールを保存] をクリックします。

  9. 画面左側のナビゲーションペインで [Auto Scaling グループ] をクリックします。

  10. [MyAutoScalingGroup] をクリックします。

  11. [詳細] タブ > ネットワーク > [編集] をクリックします。

  12. サブネットの選択を以下のように指定します。

    ネットワーク
    削除 Public Subnet1
    削除 Public Subnet2
    追加 Private Subnet1
    追加 Private Subnet2

  13. [更新] をクリックします。

  14. [インスタンス管理] タブをクリックします。

  15. Auto Scaling グループのすべての EC2 インスタンスを選択します。

  16. [アクション] > デタッチ をクリックします。

  17. インスタンスをデタッチ のポップアップで 負荷を分散するため、新しいインスタンスを Auto Scaling グループに追加する をチェックします。

  18. [インスタンスをデタッチ] をクリックします。 数分で新規 EC2 インスタンスが Auto Scaling グループに追加されます。

    ヒント : 表示が変わらない時は、更新ボタンをクリックしてください

  19. 新規 EC2 インスタンス ID をクリックします。EC2 インスタンス一覧の画面に変わります。

  20. [説明] タブを参照して、新規 EC2 インスタンスの所属するサブネットが Private Subnet になっていることを確認してください。

ここまでの設定で、Internet に公開されているシステムの範囲を最小化しました。

  • ALB 及び Stress Server のみ Public Subnet に存在し、WordPress サーバは全て Private Subnet に配置されるようになりました。これにより WordPress サーバは Internet 経由での直接アクセスを受けることがなくなりました。
  • WordPress への HTTP アクセスを ALB からのみ受け付けるようにセキュリティグループのルールが変更されました。

終了

この Lab では、EC2 Auto Scaling を使用した Amazon Elastic Compute Cloud (Amazon EC2) のスケールアウトと、RDS DB インスタンスのスケールアップを実施しました。

お疲れさまでした。これで Lab4 は終了です。 このラボで作成した環境は継続して利用するので、[ラボを終了] はクリックしないでください。