見出し画像

AWS 入門の記録(102)

AWS 認定資格 SAA 合格を目指して学習中の、Udemy「【AWS初心者向け】手を動かして身につける! 実戦で役立つAWSサービスの基礎とアーキテクチャ(SAAレベル) 」 のハンズオンも大詰め、最後の再現課題「【再現】自動でスケールする設定をしよう」にチャレンジします。

再現環境の確認

画像1

前回、Web サーバーと DB の台数を増やして冗長化し、1つの AZ で障害が発生してもサービスが継続できる環境にしました。今回は、Web サーバーへの負荷が上限を超えたら自動的にサーバー台数を増やす AuteScaling 設定を追加します。さらに、各サーバーのログを CloudWatch に出力して、サーバーの増減に影響されずにLogを保存できるようにします。動画では、まず AutoScaling の設定後に CloudWatchAgent を使用してLog を出力する設定をしたEC2 を作成して、AutoScaling 用の起動用イメージをCloudWatchAgentがインストールされたAMIと差し替えるという手順でした。今日は、AutoScaling の設定の前に EC2 に CloudWatchAgent をインストールして、起動用の AMI を作成してから、AutoScaling 設定をすることにします。

考えた構築手順

 1.VPS に、Subnet × 6 、インターネットゲートウェイ (IGW) を作成。
 2.ルートテーブルを作成して IGW と、2つの Public 用 Subnet とを関連付け。
 3.Public Subnet -a に踏み台サーバー用 EC2 起動。
 4.Protected Subnet -a に Webサーバー用 EC2起動。
   ★踏み台経由で Webサーバーにログイン確認
 5.Public Subnet -c に NAT Gateway(NATGW) を作成。
 6.ルートテーブルを作成して NATGW と、2つの Protected 用 Subnet と関連付け。
 7.Webサーバーに、Apache、PHP、MySQLをインストール
   (WordPress はダウンロードして展開まで)
 8.ALB を作成して、ターゲットグループに Web サーバーを登録。
   ★ALB の DNS名にブラウザでアクセスして、Apache テストページ表示を確認。
 9.Amazon RDS を作成し、Webサーバーの MySQL クライアント経由で WordPress 用のユーザーとDBを登録
10.Web サーバーの wp-config.php の DB 設定を RDS に、ALB DNS名を URL 設定として追加
11.WordPress ファイル一式をドキュメントルートに配置
12.ALB のDNSにアクセスして、WordPress をインストール完了する。
13.Amazon S3 バケットを作成、パブリック・アクセスを許可
14.Web サーバーから S3 にアクセスするための IAM ロールを作成して Web サーバーにアタッチ
15.WordPressプラグインのインストールを可能にするため、Web サーバーのディレクトリ所有権を変更、PHP 追加モジュールをインストールして再起動。
16.WordPress に、Amazon S3 バケット保存用のプラグインをインストールする。
   WordPress にメディアをアップロードして、S3 バケットに保存されることを確認する。
17.Web サーバーに CloudWatchAgent をインストールする。
18.Web サーバーに、CloudWatch ログ出力用 AMI ロールを追加する。
19.ログ出力の確認

20.Web サーバーの AMI イメージをもとに、Protected-C に2台めのWeb サーバーを配置して、起動、ALB の対象に追加。
   ★1台目のWeb サーバーを停止しても、ALB を介してWordPress にメディアがアップロードができることを確認する。
21.サーバー台数を最小2台、最大4台の AutoScaling の起動設定に Webサーバーの AMI を登録する。
22.Webサーバーに負荷をかけて、3台目が起動することを確認する。

太字の部分が、前回と異なる手順です。AutoScaling CloudWatch が肝です。どちらも前回設定してみてから随分時間が経ってしまったので、動画で手順を確認しながら完成させたいと思います。

VPS、Subnet の作成~Webサーバーインストール

画像2

画像3

画像4

画像5

画像6

ALB 作成と Web サーバーをターゲットグループ登録

画像8

警告が表示されたので、サブネットをProtectedからPublicに設定しなおしました。

画像7

ALBのDNS名をブラウザ表示して、Apacheのテストページが確認できました。

RDS の登録と WordPress 設定の編集

画像9

画像10

RDS に、WordPress 用のDBとユーザーを追加して、wp-config.php を編集。WP_HOMEとSITEURLにALBのDNS名を設定、DB接続情報をRDSの内容に変更します。

画像11

画像12

wp-config.php を /var/www/html/配下にコピーしてhttpdを再起動したのですが、WordPressのインストール画面が表示できませんでした。。。えええええ。。。

画像13

ALB のターゲットグループを確認すると、Webサーバーが Unhealthy と表示されています。エラーコードは302です。

ロードバランサー、Unhealthy 302 で検索すると、以下の記事が見つかりました。

ALBのヘルスチェックでHealth checks failed with these codes [302]が出た場合の改善方法はどうすればいいですか?(Developers IO AWSテクニカルサポートノート)

Apache のインストール直後は、ドキュメントルートのテストページが表示されていたのですが、WordPressのインストール後、インストールページにリダイレクトされるため、302で応答するようになったことが原因でした。

画像14

ヘルスチェックパスを一旦編集して、WordPressのインストールページに変更します。

画像15

画像16

Healthy になりました!!!やった!いつも Developers IO の記事にお世話になっております。ありがとうございます。

画像17

WordPress のインストールができたので、ターゲットグループのヘルスチェック設定を元に戻しました。

画像18

さて、まだ設定しなければならないことが残っていますが、EC2 インスタンスと RDS を停止して、今日はここまで。続きは、またあした。

この記事が気に入ったらサポートをしてみませんか?