#■はじめに
EC2(wordpress)・RDSの冗長化構成(※)に以下機能を追加して構築してみたので、その際の手順をまとめました。
※【AWS】EC2とRDSを冗長化しALBで通信を振り分ける
- Route53 フェイルオーバールーティングのプライマリとセカンダリレコードを用意し、正常時と異常時で異なる通信経路とする
- S3 WebサイトホスティングでSorryページ(メンテナンス中を表すもの)を表示する
- EC2が落ちた場合はAutoScalingで新たにインスタンス起動する
- CloudWatchでAutoScalingグループ内のインスタンス稼働台数を監視し、EC2が落ちてアラーム状態の場合はメール通知する
#■対象者
本記事はAWS初学者向けの情報共有として構築手順をまとめています。
また、自分用の手順メモでもあります。
#■構成図
※EC2後続のRDSについてはスペースの関係上省略。
【AWS】EC2とRDSを冗長化しALBで通信を振り分けると同じでMultiAZ構成。
- 独自ドメイン(今回はfreenom)を入手し、Route53で独自ドメインとLBを紐づける。ユーザはブラウザに独自ドメインを入力してブログサイトにアクセスできる。
- フェールオーバールーティングにより、異常発生時はS3 Webサイトホスティング機能によりSorryサイトへ遷移する。
- EC2が落ちた場合、AutoScalingによりEC2を復旧させる。
- また、CloudWatchはEC2が落ちるとアラーム状態となり、関連付けられたSNSトピックは指定の宛先にメール通知を行う。
#■作業内容
大まかに以下。
- Route53 ホストゾーン作成およびネームサーバ設定上書き
- Route53 独自ドメインとLB紐づけ および フェイルオーバールーティング プライマリ設定
- S3作成
- Route53 フェイルオーバールーティング セカンダリ設定
- AutoScalingグループ作成
- CloudWatchアラーム作成
- テスト
#■作業手順詳細
##1. Route53 ホストゾーン作成およびネームサーバ設定上書き
【Route53 ホストゾーン作成】
前提. freenomで独自ドメインを入手しておく
入手手順については省略する
1-1. AWSでRoute53検索 - 左ペイン ホストゾーン - ホストゾーンの作成押下
1-2. 「ホストゾーンの作成」画面
・ホストゾーン設定
以下を入力し「ホストゾーンの作成」押下
| 項目 | 説明 |
|---|---|
| ドメイン名 | freenomで入手した独自ドメイン名 |
| 説明 | 任意 |
| タイプ | パブリックホストゾーン ※外部から通信を受ける |
| タグ | 任意 |
 |
ホストゾーン画面に独自ドメイン名でNSレコードとSOAレコードが作成される。
【補足 レコードタイプについて】
レコードとは、ドメインと何かを紐づけて管理する情報。
| 項目 | 説明 |
|---|---|
| Aliasレコード | ドメインとAWSリソースを紐づけた情報 CloudFrontやS3など |
| Aレコード | ドメインとIPv4アドレスを紐づけた情報 |
| AAAAレコード | ドメインとIPv6アドレスを紐づけた情報 |
| NSレコード | ドメイン情報を管理するサーバ(ネームサーバ)の情報 |
| SOAレコード | ドメインの管理情報 |
| CNAMEレコード | ドメインとドメインを紐づけた情報。料金発生する |
※AliasレコードとCNAMEレコードの違いは以下公式ドキュメントに記載あり
https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html
【freenomのネームサーバ情報をAWSのネームサーバ情報で上書きする】
1-4. freenomのTOP画面 - Services - My Domains - Manage Domain - Management Tools - Nameservers の
Nameserver 1 ～ 4を、AWS Route53 - ホストゾーン画面のNSレコードの「値/トラフィックのルーティング先」の
ネームサーバ名で上書きし、「Change Namesevers」押下
※Successと出た後、実際の反映には多少時間がかかる。
##2. Route53 独自ドメインとLB紐づけ および フェイルオーバールーティング用プライマリレコード作成
【正常時の通信経路設定(LB向け)】
2-2. 「ルーティングポリシーを選択」画面
(この画面が表示されない場合、クイック作成になっているので「ウィザードに切り替える」を押下)
「フェイルオーバー」を選択し、「次へ」を押下
2-3. 「レコードを設定」画面
・基本的な設定
| 項目 | 説明 |
|---|---|
| レコード名 | レコード名先頭に付与する任意文字列。ここで決めた「xxx.ドメイン名」がブログサイトへのアドレスとなる |
| レコードタイプ | A-IPv4アドレスと一部のAWSリソースにトラフィックをルーティングします |
| TTL | 60秒 |
ここまで入力し、「フェイルオーバーレコードを定義」押下
2-4. 「フェイルオーバーレコードを定義」画面
この画面で独自ドメインとLBの紐づけを行う
| 項目 | 説明 |
|---|---|
| 値/トラフィックのルーティング先 | Application Load Balancer と Classic Load Balancer へのエイリアス |
| ロードバランサー | クリックすると出てくるELB名 ※ 紐づけを行う作成済みのELBの先頭にdualstackがついた名前となっている |
| フェイルオーバーレコードタイプ | プライマリ |
| ターゲットのヘルスを評価 | はい |
| レコード ID | 任意。後ほどセカンダリIDも設定するので判別しやすいモノで。 |
ここまで入力し、「フェイルオーバーレコードを定義」押下
【補足 項目「値/トラフィックのルーティング先」について】
| 項目 | 説明 |
|---|---|
| Application Load Balancer と Classic Load Balancer へのエイリアス | ALBとオリジナルドメインを紐づける場合に選択する |
| レコードタイプに応じたIPアドレスまたは別の値 | IPアドレスとオリジナルドメインを紐づける場合に選択する |
| S3ウェブサイトエンドポイントへのエイリアス | S3の静的ウェブサイトURLとオリジナルドメインを紐づける場合に選択する。※S3のバケットの名前はオリジナルドメインと同じ名前で作成する必要あり |
2-5. 「レコードを設定画面」に戻るので「レコードを作成」押下
Route53 - ホストゾーン - 作成したホストゾーン選択 - レコード に 2-3で設定したドメイン名(xxx.独自ドメイン)のプライマリ Aレコードが作成されていることを確認する
##3. S3作成
フェイルオーバールーティングのセカンダリを設定していないが、セカンダリにはS3のURLを指定する項目があるので、先にS3の作成を行う
【バケット作成】
3-2. 「バケットを作成」画面
・一般的な設定
| 項目 | 説明 |
|---|---|
| バケット名 | 先ほど作成したLBと紐づいたドメイン名(2-3.で設定したAレコード "xxx.独自ドメイン") |
| AWS リージョン | 使っているリージョン ここでは東京リージョン |
| 既存のバケットから設定をコピー | デフォルトのまま |
・このバケットのブロックパブリックアクセス設定
「パブリックアクセスをすべて ブロック」のチェックを外す ※世界中から許可する
「現在の設定により、このバケットとバケット内のオブジェクトが公開される可能性があることを承認します。」のチェックを入れる
・バケットのバージョニング
無効にする(デフォルト)
・タグ
任意
・デフォルトの暗号化
サーバ側の暗号化 無効(デフォルト)
・詳細設定
オブジェクトロック 無効(デフォルト)
ここまで入力したら、「バケットを作成」押下
【sorryサイト用ファイルをS3バケットにアップロード】
3-3. 作成したバケット名を押下
3-4. オブジェクトタブから「アップロード」押下
3-5. 「アップロード」画面
「ファイルを追加」「フォルダの追加」を押下し、Sorryサイト用のhtmlファイルや画像などを選択し、アップロード押下
【静的ウェブサイトホスティング機能 有効化】
3-6. 作成したバケット名 - プロパティタブ の下の方に"静的ウェブサイトホスティング"項目があるので「編集」押下
3-7.「静的ウェブサイトホスティングを編集」画面
以下を入力し、「変更の保存」押下
| 項目 | 説明 |
|---|---|
| 静的ウェブサイトホスティング | 有効にする ※有効にすると追加で以下の項目が出てくる |
| ホスティングタイプ | 静的ウェブサイトをホストする |
| インデックスドキュメント | アップロードしたファイル名 |
| エラードキュメント | アップロードしたファイル名 |
【バケットポリシー設定】
3-8. バケット名 - アクセス許可タブを選択 - 項目"バケットポリシー"の「編集」押下
3-9. AWS公式の「ウェブサイトアクセスのアクセス許可の設定」バケットポリシーのサンプルをコピーし、編集する
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/WebsiteAccessPermissionsReqd.html
以下の Bucket-Name の部分を 作成したバケット名に変更することで、
「全ユーザが S3バケットにアクセス可能」というポリシーになる。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::Bucket-Name/*" ←★ココを "arn:aws:s3:::作成したバケット名/*" にする
]
}
]
}
【補足 バケットポリシー記述内容】
| 項目 | 説明 |
|---|---|
| Version | バージョン。例では日付 |
| Statement | 詳細項目を配下に記載 |
| Sid | ID。 |
| Effect | "許可、拒否"の指定。許可するならAllow、拒否するならDeny。 |
| Principal | "誰が"の指定。全アカウント、特定のアカウントのみ、特定のIAMユーザのみ、AWSリソース(EC2など)指定可能。 |
| Action | "どのような操作か"の指定。 |
| Resource | "どのAWSリソースに対してか"の指定。ARNで指定する。省略不可。 |
| Condition | IPアドレスの接続元を制限したり、ポリシーの有効期限(時間など)を指定 |
また、Principal, Action, Resource には NotPrincipal, NotAction, NotResource という "そこに指定したもの以外" という項目もある。
3-10. 上記バケットポリシーを設定すると、プロパティタブ - 静的ウェブサイトホスティングの項目のS3URLにアクセス可能となる
##4. Route53 フェイルオーバールーティング セカンダリレコード作成
【異常時の通信経路設定(S3向け)】
4-1. Route53 - ホストゾーン - 作成したホストゾーンを選択 - 「レコードを作成」押下
4-2. 「ルーティングポリシーを選択」画面 ※この画面が表示されない場合、クイック作成になっているので「ウィザードに切り替える」を押下
フェイルオーバーを選択し、次へを押下
4-3. 「レコードを設定」画面
・基本的な設定
| 項目 | 説明 |
|---|---|
| レコード名 | プライマリのものと同じもの |
| レコードタイプ | A-IPv4アドレスと一部のAWSリソースにトラフィックをルーティングします |
| TTL | 60秒 ※DNSキャッシュ保持時間 |
ここまで入力し、「フェイルオーバーレコードを定義」押下
4-4. 「フェイルオーバーレコードを定義」画面
ここからプライマリレコードとは入力値が異なる
| 項目 | 説明 |
|---|---|
| 値/トラフィックのルーティング先 | S3 ウェブサイトエンドポイントへのエイリアス |
| リージョン | アジアパシフィック(東京)[ap-northeast-a] |
| S3エンドポイント | 作成したS3バケット名が出るので選択。するとS3URLに変わる ※もし出てこなければドメイン名とバケット名が一致していない |
| フェイルオーバーレコードタイプ | セカンダリ |
| ターゲットのヘルスを評価 | はい |
| レコード ID | 任意。セカンダリと判別しやすいモノで。 |
ここまで入力し、「フェイルオーバーレコードを定義」押下
4-5. 「レコードを設定」画面に戻るので「レコードを作成」押下
Route53 - ホストゾーン - 作成したホストゾーン選択 - レコード に セカンダリのAレコードが作成されている
##5. AutoScalingグループ作成
【起動テンプレート作成】
前提. あらかじめEC2を停止させ、AMIを作成しておく
5-1. EC2画面 - 左ペイン テンプレートの起動 - 「起動テンプレートの作成」押下
5-2. 「起動テンプレートを作成」画面
・起動テンプレート名と説明
| 項目 | 説明 |
|---|---|
| 起動テンプレート名 | 任意 |
| テンプレートバージョンの説明 | 任意 |
| Auto Scalingのガイダンス | する ※Auto Scalingでこのテンプレートを使用するかどうかの設定 |
| テンプレートのタグ | 任意 |
| ソーステンプレート | 未入力のまま ※作成済みのものをベースに新たに作成することもできる。今回は新規作成とする |
・AMI
作成済みのものを選択する
・インスタンスタイプ
AMIのものが出るのでそのまま。
・キーペア
作成済みのものを選択する
・ネットワーク設定
| 項目 | 説明 |
|---|---|
| ネットワーキングプラットフォーム | VPC |
| セキュリティグループ | 未入力のまま ※後でEC2インスタンスにアタッチするENI(IPアドレス)に対して設定する |
・ストレージ(ボリューム)
AMIのものが出るのでそのまま。
・リソースタグ
| 項目 | 説明 |
|---|---|
| キー | Name |
| 値 | 任意 |
・ネットワークインターフェイス
| 項目 | 説明 |
|---|---|
| デバイスインデックス | 0 |
| ネットワークインターフェイス | 新しいインターフェイス |
| セキュリティグループ | 作成済みのセキュリティグループを選択 |
| 終了時に削除 | 起動テンプレートに含めない |
他の項目はそのまま、「起動テンプレートを作成」押下
【補足 起動テンプレートについて】
バージョン管理できるのが特徴。
また、EC2画面 - アクション - イメージとテンプレート - インスタンスからテンプレートを作成 から起動テンプレートの作成も可能。
【AutoScalingグループ作成】
5-3. EC2画面 左ペイン - AutoScalingグループ - 「AutoScalingグループを作成」押下
5-4. 「起動テンプレートまたは起動設定を選択する」画面
・名前
| 項目 | 説明 |
|---|---|
| Auto Scaling グループ名 | 任意 ※ここで設定した名前は後々 アラームのグループメトリクス選択の際に 対象AutoScalingグループ名として出てくる |
・起動テンプレート
| 項目 | 説明 |
|---|---|
| 起動テンプレート | 作成したテンプレート名 |
| バージョン | 作成したテンプレートのバージョン |
5-5. 「インスタンス起動オプションを選択」画面
・ネットワーク
| 項目 | 説明 |
|---|---|
| VPC | どのVPCで起動するのか、作成済みのVPC |
| アベイラビリティゾーンとサブネット | どのアベイラビリティゾーンのどのサブネットで起動するのか、作成済みのもの |
・インスタンスタイプの要件
起動テンプレートと同じものが表示されているのでそのままで。「次へ」押下。
5-6. 「詳細オプションを設定」画面
・ロードバランシング
作成済みのものにアタッチするので「既存のロードバランサーにアタッチ」を選択する
・既存のロードバランサーにアタッチ
「ロードバランサーのターゲットグループから選択」を選択して、作成済みのターゲットグループを選択する
・ヘルスチェック
「ELB」にもチェックを入れる。
※ここの「EC2ヘルスチェック」とはEC2のステータスチェックのこと。EC2起動時に画面に出る"2/2のチェックに合格しました"が該当する
ヘルスチェックの猶予期間は300秒のままとする。
・その他の設定
「CloudWatch内でグループメトリクスの収集を有効にする」にチェックを入れて「次へ」押下
※AutoScalingグループの監視に必要
5-7. 「グループサイズとスケーリングポリシーを設定する」画面
・グループサイズ
| 項目 | 説明 |
|---|---|
| 希望する容量 | 2 ※AutoScalingグループ作成時に何台起動するか |
| 最小キャパシティ | 2 ※最小何台まで減少するか |
| 最大キャパシティ | 2 ※最大何台まで増加するか |
【補足 AutoScalingによる起動台数について】
個人的に誤解していた部分だが、
ここで設定するのは、あくまでAutoSclingグループ内での台数設定で、
すでに作成済みのEC2(AutoScalingではない方法で作成したもの)はその数に含まれない。
例えば、作成済みのEC2を2台(webserver1,2)起動してある状態で、AutoScalingグループ 希望する容量2、最小0、最大2で作成・起動すると、
以下のように作成済み2台 に加え AutoScalingにより EC2(WebServer-Auto)が2台起動するので合計4台が起動している状況になる。
「すでに2台作って起動しているからAutoScaling発動しない」ということにはならない。
次に、作成済みのEC2 webserver1 を落としてみる⇒AutoScalingは発動しない。webserver1はグループ内ではないため。
落とした webserver1 を起動させ、AutoScalingのEC2(WebServer-Auto)を落としてみる⇒AutoScalingが発動し、1台起動し始める。
AutoScalingグループ内のEC2が落ちたため。
ログにも形跡あり。
・スケーリングポリシー
ターゲット追跡スケーリングポリシーにチェックを入れると、以下のようなメトリクスの増減でスケーリングを実施することができる。
今回は EC2が落ちたらスケーリングするようにしたいので、ここでは「なし」を選択し、後述のCloudWatchで稼働台数の監視設定を行う。
・インスタンスのスケールイン保護
チェックを入れずに「次へ」押下
※チェックを入れるとスケールイン(EC2減少)がされなくなる
5-8. 「通知を追加」画面
SNSトピックで以下を契機に通知を飛ばすことができる。今回は設定しない。
5-9. 「タグを追加」画面
任意。今回は設定しない。
5-10. 「確認」画面
問題なければ「AutoScalingグループを作成」押下
※作成したらEC2が起動し始める
作成すると、ALBのターゲットグループの登録済みターゲットにも追加される
##6. CloudWatchアラーム作成
【メトリクスの指定と監視条件設定】
6-1. CloudWatch画面 - 左ペイン アラーム状態 - 「アラームの作成」押下
6-2. 「メトリクスと条件の指定」画面
「メトリクスの選択」押下
6-3. すべて - AutoScaling - グループメトリクス - GroupInServiceInstances(※) にチェックを入れる
※Auto Scaling グループの一部として実行するインスタンスの数。このメトリクスには保留中もしくは終了処理中のインスタンスは含まれません。
https://docs.aws.amazon.com/ja_jp/ja_jp/autoscaling/ec2/userguide/as-instance-monitoring.html#as-group-metrics
・メトリクス
| 項目 | 説明 |
|---|---|
| 統計 | 最大 |
| 期間 | 1分 |
・条件
| 項目 | 説明 |
|---|---|
| しきい値の種類 | 静的 |
| GroupInServeciInstances が次の時 | より低い |
| ...よりも | 2 |
ここまで入力したら「次へ」押下
・AutoScalingアクション
そのままで。
6-4. 名前と説明を追加
| 項目 | 説明 |
|---|---|
| アラーム名 | 任意 test-autoscaling-alarm |
| 説明 | 任意 test-autoscaling-alarm |
「次へ」押下すると、アラーム画面に test-autoscaling-alarm が表示される
##7. テスト
【正常性確認】
7-1. ブラウザから独自ドメインでブログサイトにアクセスできることを確認
【異常確認】
7-2. AutoScalingで起動したEC2 2台を停止する
ターゲットグループが unused となる。
7-3. ブログサイトにアクセスしようとすると、503応答であることを確認。また、TTL60秒経過後、Sorryサイトが表示されることを確認
7-4. CloudWatchでアラーム状態となり、メール通知されることを確認
【復旧確認】
7-5. AutoScalingが発動し、EC2 2台起動し始める
7-6. EC2が起動すると、再度ブログサイトが問題なく表示されることを確認
以上
#■総括
・実際に手を動かすことで、AutoScalingのグループサイズの誤解が判明したのは良かった
・今回、単にEC2を手動停止・台数減少でScalingするというテストにしたが、
EC2を手動停止させても、新EC2が立ち上がるまでの時間が速すぎてなかなかアラーム状態にならずに苦労した。
(2台落としてもグラフ上で2より下に落ち込まない)
お試し動作テストの観点だとCPUなどのリソースを監視して、意図的に負荷をかけ続けてスケールアウト、負荷停止でスケールインさせた方が多分楽かなと思った。
・RDSの死活監視も盛り込もうと思ったが、どうやらRDSの起動状態に関するメトリクスは存在しないようで実現には一手間必要そうだったのでパスしたがいずれ盛り込んでみたい。
#■おわりに
この記事はAWS初学者を導く体系的な動画学習サービス
「CloudTech」の課題カリキュラムで作成しました。
https://aws-cloud-tech.com