AWS-マルチAZWordPressサイト構築練習【前編】

TERAO


この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。

お久しぶりです。株式会社協栄情報システム3部所属の寺尾です。

今回は自身の練習のためAWS上にマルチAZWordpressサイトを構築していこうと思います。

今回は一つの環境を0から構築していく都合上長くなりますので、前編・中編・後編の三つに分けて投稿します。

それでは長くなりますがよろしくお願いします。

構成図とやりたいこと

今回マルチAZ構成Wordpressサイトを構築していくにあたっての構成図です

今回構築する中でやりたいことは

  1. インターネットから暗号化された通信を使ってドメイン名でアクセスできること
  2. マルチAZ構成でWebサーバーを稼働し、高可用性を実現すること。
  3. マルチAZ構成でデータベースサーバーを稼働し、高可用性を用意すること
  4. ストレージやデータベースのデータに不正にアクセスされても、解読できないように暗号化されていること
  5. EC2に障害が起きた時は通知をだし、自動的に復旧すること
  6. EBSの使用率や、ALBとEC2の死活監視をおこない、閾値を超えた時は通知を出すこと
  7. apacheのアクセスログをマネジメントコンソールから確認できるようにし、それをコストの低い保管方法で保存すること

になります。

必要なサービス

今回必要なAWSサービスを目的とともにまとめました。

サービス名 利用目的
Route53 名前解決のため
ACM（AWS Certificate Manager） https通信を行うための証明書の作成/利用のため
ALB (Application Load Balancer) 二つのEC2にヘルスチェックを行いながらリクエストを振り分け、高可用性を実現するため
IAM (Identity and Access Management) EC2にCWAgent用の権限を与えるため
KMS (Key Management Service) RDS、EBSなどの暗号化のために暗号化鍵の作成と管理を行うため
AWS Systems Manager CloudWatchAgentの設定パラメータを配置するため
EC2 (Elastic Compute Cloud) Webサーバーとして使用するため
RDS (Relational Database Service) DBサーバーとして使用するため
EFS (Elastic File System) WordPressのインストールファイルをEC2間でファイル共有を行うため
S3 (Simple Storage Service) Apacheアクセスログのエクスポート先として使うため
CloudWatchAlarm ・システムエラー、EC2とALBの死活状態、ディスク使用率の監視を行うため
・閾値を超えればメールで通知し、システムエラーが起きた時にオートリカバリーをするため
CloudWatchAgent ・ディスク使用率の監視メトリクスをCWAlarmに発行するため
・ApacheアクセスログをCloudWatchLogsに発行するため
CloudWatchLogs Apacheアクセスログの発行先
Amazon EventBridge(CloudWatchEvents） Lambdaのトリガーとして利用するため
Lambda CloudWatchLogsからS3へとログをエクスポートするため
SNS (Simple Notification Service) アラーム発生時のメール送信先トピックを作成するため

今回必要なサービスは以上の12個になります。

また、

  • EC2はマルチAZ構成かつALBでヘルスチェックを行う
  • RDSはマルチAZ構成でプライマリとセカンダリを用意する

以上の条件が必要になります。

WordPress環境構築手順

さて、作りたいものも定まりましたので早速構築していきたいですが、まずはどの順番で作るか決める必要があります。
今回はそれぞれのサービスの関係性を考慮して、

1.VPCなど基盤構築

  1. VPC作成
  2. サブネット作成
  3. インターネットゲートウェイ作成
  4. ルートテーブル作成
  5. セキュリティグループ作成
  6. IAM作成

2.データベース・ストレージ・ファイルシステム構築

  1. KMSで暗号化鍵の作成
  2. サブネットグループ作成
  3. RDS作成
  4. EFS作成
  5. S3バケット作成

3.WEBサーバー構築

  1. AWS Systems Managerでパラメータ作成
  2. EC2インスタンス作成

4.ネットワーク構築

  1. ALB作成
  2. Route53作成

5.監視システム構築

  1. SNSトピック作成
  2. CWAlarm(オートリカバリー)作成
  3. CWAlarm(ディスク監視)作成
  4. CWAlarm(EC2死活監視)作成
  5. CWAlarm(ALB死活監視)作成
  6. ApacheアクセスログのエクスポートLambda作成
  7. Amazon EventBridgeでイベント作成

6.WordPress設定とhttps設定

  1. WordPressのインストールおよび設定
  2. ACMで証明書の作成
  3. httpsの設定

以上の流れで構築していきます。

1.VPCなど基盤構築

1.VPC作成

VPCはリージョンサービスでVPCそのものの利用料金は無料です。
AWSアカウントが初期状態の場合、1つのリージョンにつき5個までVPCを作成することができます。(リクエストによって拡張可能です)

1.まずはAWSマネジメントコンソールにサインインしてVPCを作成していきましょう。
サービス一覧からVPCを選びました。

2.サイドメニューからVPCを選びVPC作成を選択していきます。

3.以下の設定値に従って設定を入力して作成します。

設定項目 設定値 理由
名前 VPC-Wordpress01 入力内容は任意
IPv4 CIDRブロック 10.0.0.0/16 プライベートIPアドレスの範囲の中から利用していないものを選択
IPv6 CIDRブロック IPv6 CIDRブロックなし 今回はIPv6を利用しない
テナンシー デフォルト 占有要件がないため費用を考慮してデフォルト
タグ:Name VPC-Wordpress01 入力は任意
タグ:Env WordPress01 入力は任意

IPv4にVPC全体のCIDRブロックを作成します。
今回は10.0.0.0/16です。

CIDRについて

  • 区切られた一つの数字につき8桁の二進数、すなわち0~255を表しています。末尾の16は2進数で何桁までがVPCのアドレスかを表していますので、10.0までがVPCのアドレスになります。(実際にVPC全体を指定する場合は10.0.0.0になります)

プライベートIPアドレスについて

  • 以下の範囲のアドレスはプライベートIPアドレスとして利用できるものです。
クラス IPアドレス
クラスA 10.0.0.0〜10.255.255.255
クラスB 172.16.0.0〜172.31.255.255
クラスC 192.168.0.0〜192.168.255.255

タグは後で削除する際に困らないよう分かりやすいものを付けてあげます。
ですので今回は全てにサービス名＋Wordpress01タグとEnv+Wordpress01タグをつけていきます。

4.作成完了です。

5.名前解決を利用してVPC内部のコンポーネントにアクセスするのでDNS解決を有効にしておきます。

※以下2023/2/15追記

DNS解決を有効にする手順に変更がありました。
以下の通りDNSホスト名を有効にし、DNS解決DNSホスト名が共に有効であることを確認しましょう。
file
file

2.サブネット作成

次にVPC内のサブネットを作成していきます。
構成図より大阪リージョンのAZ3aとAZ3cにそれぞれプライベートサブネットとパブリックサブネットを一つずつ作成していきます。
AWSアカウントが初期状態の場合、1つのVPCにつき200個までサブネットを作成することができます。(リクエストによって拡張可能です)
今回は下記のCIDRで設定していきます。

AZ\サブネット パブリック プライベート
大阪3a public-subNet-3a「10.0.1.0/24」 private-subNet-3a「10.0.3.0/24」
大阪3c public-subNet-3c「10.0.2.0/24」 private-subNet-3c「10.0.4.0/24」

また、すべてに

  • Name:「サブネット名と同一」
  • Env:「Wordpress01」
    タグをつけています。(任意)

ここでいうパブリックサブネットとプライベートサブネットですが、サブネットを作るうえでどちらかを選ぶような選択肢はありません。
そこで何がパブリックとプライベート、二つのサブネットで何が違うかというと、

  • パブリックサブネット　インターネットゲートウェイへのルート先があるサブネット
  • プライベートサブネット　インターネットゲートウェイへのルート先がないサブネット
    となっています。

ルート先の設定はルートテーブルで行うので、サブネットを作る段階ではその二つに機能の違いはありません。

1.サイドメニューからサブネット、サブネットの作成を選びます。

2.あらかじめ作成しておいたVPCを選び、先述の設定に従って4つのサブネットを作りましょう。

CIDRについて

  • 今回は10.0.1.0/24～10.0.4.0/24のアドレスを使用しました。末尾が24ですのでこのサブネット配下に割り当てられるアドレスは10.0.X.0/24~10.0.X.255/24になりますね。(実際はサブネット配下0,1,2,3,255はAWSによって予約されていますので使えません)

3.4つのサブネットが無事完成しました。

3.インターネットゲートウェイ作成

インターネットゲートウェイはVPCとインターネットと接続するためのコンポーネントです。
インターネットゲートウェイを利用して行いたい事は以下になります。

  • 自分のコンピュータからインスタンスへのSSHでのアクセスを行うため
  • ALBにインターネットからアクセスするため
    以上の二点はパブリックサブネット（インターネットゲートウェイが関連付けられたサブネット）にEC2とALBを配置することで実現できるので、インターネットゲートウェイが必要です。

1.サイドメニューからインターネットゲートウェイを選択し、インターネットゲートウェイの作成を選びます。

2.タグと名前を入力して作成します。
Name:「IGW-Wordpress01」(任意)
ENV:「Wordpress01」(任意)

3.VPCにアタッチを選びます。

4.先ほどのVPCにアタッチすればVPCからインターネットに接続できるようになります。

5.アタッチ成功！　次はルートテーブルです。

4.ルートテーブル作成

ルートテーブルとはネットワークトラフィックの送信先を設定するコンポーネントです。
ルートテーブルをサブネットと関連付けることでサブネットのトラフィック送信先が、ルートテーブルに準拠したものになります。
こちらにインターネットゲートウェイをネットワークトラフィックの送信先として設定し、ルートテーブルをサブネットに関連付けすることで、インターネットと通信できるサブネット(＝パブリックサブネット)を作ることができます。

1.サイドメニューのルートテーブルからルートテーブルの作成を選びましょう。

2.以下の設定内容に従ってパブリックサブネット向けルートテーブルを作成します。

設定項目 設定値 理由
名前 RTB-Wordpress01-public 入力内容は任意
VPC VPC-Wordpress01 VPC-Wordpress01用のパブリックサブネットのため
ルート ・Local「10.0.0.0/16」
・IGW-Wordpress01「0.0.0.0/0」		 パブリックサブネット用ルートテーブルのためIGWをルーティング先として指定
Name RTB-Wordpress01-public 入力は任意
Env WordPress01 入力は任意　
関連付け ・public-subNet-3a「10.0.1.0/24」」
・public-subNet-3c「10.0.2.0/24」		 パブリックサブネット用ルートテーブルのため

名前は今回はパブリックサブネット向けのルートテーブルですので名前の末尾にpublicを添えました。

3.作成できました。

4.ルートを編集していきます。

5.次にサブネットの関連付けを行います。

6.次に以下の設定内容に従ってプライベートサブネット向けルートテーブルを作成します。

設定項目 設定値 理由
名前 RTB-Wordpress01-private 入力内容は任意
VPC VPC-Wordpress01 VPC-Wordpress01用のプライベートサブネットのため
ルート ・Local「10.0.0.0/16」 プライベートサブネット用ルートテーブルのため
Name RTB-Wordpress01-public 入力は任意
Env WordPress01 入力は任意　
関連付け ・private-subNet-3a「10.0.3.0/24」」
・private-subNet-3c「10.0.4.0/24」		 プライベートサブネット用ルートテーブルのため

7.今回はインターネットにアクセスする必要がないですので直接サブネットの関連付けを編集します。

これでVPC周りの作成が完了しました！

5.セキュリティグループ作成

次にこのVPCで使うセキュリティグループ(以下SGをまとめて作成していきます。今回作成するのはALB用、EC2用、RDS用、EFS用の四つです。

名前 インバウンドルール・タイプ インバウンドルール・ソース
SG-ALB-Wordpress01 HTTPS　 0.0.0.0/0　
SG-EC2-Wordpress01 ①HTTP
②SSH		 ①SG-ALB-Wordpress01
②MYIP
SG-RDS-Wordpress01 MYSQL/Aurora SG-EC2-Wordpress01
SG-EFS-Wordpress01 NFS SG-EC2-Wordpress01　

以下設定理由を記します。

  • ALB用のものはRoute53のパブリックホストゾーンからのトラフィックを受け入れる必要がありますのでソースは0.0.0.0/0としました。また、その通信は暗号化されている必要があるのでタイプはHTTPSになります。

  • EC2は二つのものを別々のAZに用意し、ALBでリクエストを振り分けることで高可用性を実現する予定です。
    ですので、EC2用のもの①はALBからのトラフィックを受け入れる必要がありますのでソースはSG-ALB-Wordpress01としました。また、VPC内部の通信は暗号化されている必要がないのでタイプはHTTPになります。
    また、②は自分のコンピュータよりEC2インスタンスと通信するために、タイプはSSH(Secure Shell）でソースは自分のIPとしています。

  • RDSはEC2(Webサーバー)に対するDBサーバーとして扱う予定です。
    ですのでRDS用のものはEC2からのトラフィックを受け入れる必要がありますのでソースはSG-EC2-Wordpress01としました。タイプはDBにMYSQLを選定しますので(この理由はRDS作成時に記します)MYSQL/Auroraを選びました。

  • EFSはEC2(Webサーバー)のWordpressインストールファイルを共有するために使用します。
    ですのでEFS用のものはEC2からのトラフィックを受け入れる必要がありますのでソースはSG-EC2-Wordpress01としました。タイプはEFSはNFSの一種ですのでNFSを選びました。

1.まずはサービスからEC2を選択し、サイドメニューからセキュリティグループを選び、セキュリティグループを作成しましょう。

2.ALB用のSGから作成していきます。
VPCは先ほど作成したものを選び、インバウンドルールにhttps経由でのインターネットからのアクセスを許可します。

3.無事作成できました

4.次はEC2用のSGです。EC2用ですので自身がアクセスするためのSSH、そしてALBからのhttpアクセスを許可します。22番ポートと80番ポートになりますね。

5.次はRDS用のSGです。MYSQL/Auroraを選んでEC2からの3306番ポートへのアクセスを許可します。

6.次はEFS用のSGです。NFSを選んでEC2からの2049番ポートへのアクセスを許可します。

7.すべてのセキュリティグループが完成しました！

6.IAM作成

次に今後必要になるIAMロールをあらかじめ作っておきます。
今回利用するIAMロールは以下になります。

IAMロール名 付与先サービス 目的
IRL-EC2-Wordpress01-tr EC2 CloudWatchAgentを動作させるため
IRL-Lambda-Wordpress01-tr Lambda ・LambdaでCloudWatchLogsのエクスポートタスクを実行するため
・タスク失敗時にデッドレターキューを配信するため

また、IAMロールに付与するIAMポリシーは以下になります。

IAMロール IAMポリシー
IRL-EC2-Wordpress01-tr CloudWatchAgentServerPolicy
IRL-Lambda-Wordpress01-tr IPL-Lambda-Wordpress01

それでは早速作っていきましょう。

1.サービス一覧からIAM、サイドメニューからロールへ進んでロール作成を選ぶ。

2.次に信頼されたエンティティを選びます。
今回はEC2用ですのでAWSサービスからEC2を選びました。

3.CloudWatchAgentServerポリシーを選びましょう。

4.タグと名前をつけます。

  • 名前:「IRL-EC2-Wordpress01-tr」(入力内容は任意)
  • Name:「IRL-EC2-Wordpress01-tr」(入力は任意)
  • Env:「Wordpress01」(入力は任意)

このAWSアカウントはリージョンを分けて複数人で利用していますので、他の方と区別しやすいように少し名前を変えています。

5.名前を入力して作成しましょう。

6.同じようにLambda用のIAMロールを作成します。

7.このロール用のポリシーを作成します。
以下のjson形式の設定を張り付けて作成しましょう。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "logs:CreateExportTask",
                "s3:GetBucketAcl",
                "s3:PutObject",
                "sns:Publish"
            ],
            "Resource": "*"
        }
    ]
}
  • Version : ポリシー言語のバージョン。2012-10-17が最新版。
  • Statement : 設定項目の大枠。この中に一つまたは複数のStatementを作成できる。
  • Sid : ポリシードキュメントに与える任意の識別子。
  • Effect : Statement内部のActionをAllow(許可)するかDeny(拒否)するか定義する。
  • Action : EffectによってAllow(許可)またはDeny(拒否)される操作を定義する。下記の権限がLambdaに必要なので設定する。
    • S3バケットに対するオブジェクトの書き込み、取得権限
    • ロググループに対するエクスポートタスクの作成権限
    • ロググループに対する自身のログの作成権限
    • SNSに対するメール配信権限
  • Resource : EffectとActionの対象となるリソース。全て(*)を指定した。
  • 参考リンク　→　IAM JSON ポリシーの要素のリファレンス


8.タグと名前をつけて作成しましょう。

  • 名前:「IPL-Lambda-Wordpress01」(入力内容は任意)
  • Name:「IPL-Lambda-Wordpress01」(入力は任意)
  • Env:「Wordpress01」(入力は任意)


9.以下の項目を入力して作成します。

  • アタッチするポリシー:「IPL-Lambda-Wordpress01」
  • 名前:「IRL-Lambda-Wordpress01-tr」(入力内容は任意)
  • Name:「IRL-Lambda-Wordpress01-tr」(入力は任意)
  • Env:「Wordpress01」(入力は任意)



10.二つのIAMロールが作成できました。

今回はいったんここで区切ります。
中編後編ともに順次投稿予定ですので是非ご確認ください。

Last modified: 2024-02-06

Author