Amazon Web Services (AWS) を利用して、セキュアでスケーラブルなウェブサービスの構築手順を体験できるハンズオンを実施いたします。

AWS を使ってより安全にサービスを運用する方法、ウェブサービスの規模に合わせて、柔軟にシステムを拡張する方法を体験できる内容です。

準備事項

インターネットに接続可能な PC

AWS を利用するにはインターネット接続が必要です。Windows、mac、Linux をご準備ください。本ハンズオン資料は mac にて作成しています。

AWS アカウント

AWS アカウントを事前にご準備ください。

ブラウザ

Firefox もしくは Google Chrome を推奨します。本ハンズオン資料は Google Chrome にて検証しています。

AWS のセキュリティやスケーラビリティを高める機能・サービス 1/6

リージョン

AWS クラウドは、2022年4月現在、全世界 26 の地域にある 84 のアベイラビリティーゾーンにまたがっており、24 アベイラビリティーゾーンと 8 AWS リージョンを追加する計画が発表されています。

AWS のリージョンは必ず複数のデータセンタークラスタ（=AZ）で構成されています。各 AZ 間は数十キロ離れ、電源やネットワークが独立しており、高い耐障害性を提供できる設計になっています。

AWS グローバルインフラストラクチャマップ

AWS のセキュリティやスケーラビリティを高める機能・サービス 2/6

VPC はプライベートな仮想ネットワークサービスです。VPC を使うと AWS クラウド内にお客様専用のプライベートアドレスの空間を構築できます。

社内ネットワークとインターネット VPN やキャリアの閉域網で接続ができます。

VPCとサブネットについて

1 つの VPC は、1 つのネットワークアドレスを CIDR (Classless Inter-Domain Routing) で定義します。

1 つの VPC 内には、複数のサブネットを作成することができます。

サブネットは特定のアベイラビリティーゾーン内に配置します。

CIDR	IP アドレス数
xxx.xxx.xxx.xxx/16	65,531
xxx.xxx.xxx.xxx/20	4,091
xxx.xxx.xxx.xxx/24	251
xxx.xxx.xxx.xxx/28	11

上記は払い出される IP アドレス数から、AWS の予約 IP 数を抜いた「ユーザーが利用できる IP 数」です。

各サブネットにおいて先頭の 4 IP アドレスと最後の 1 IP アドレスは AWS 側で確保されます。

AWS > ドキュメント > Amazon VPC > ユーザーガイド > VPC とサブネットの概要 - IPv4 用の VPC とサブネットのサイズ設定

AWS のセキュリティやスケーラビリティを高める機能・サービス 3/6

各サブネットにはルートテーブルがアタッチされます。

ルートテーブルの設定を変更することでデータの流れを制御できます。

パブリックサブネット

ルートテーブル: rtb-XXXXXXXX

送信先	ターゲット
10.0.0.0/16	local
0.0.0.0/0	igw-XXXXXXXX

プライベートサブネット

ルートテーブル: rtb-XXXXXXXX

送信先	ターゲット
10.0.0.0/16	local

ルートテーブルのイメージ画像

AWS のセキュリティやスケーラビリティを高める機能・サービス 4/6

Firewall イメージアイコン

インターネットからのトラフィック (インバウンド) をブロックするだけでなく、EC2 からのトラフィック (アウトバウンド) も制限できるファイアウォール機能です。

セキュリティグループイメージ画像

個々のインスタンスごとに、インバウンド、アウトバウンドに対して下記の許可ルールを定義できます。ルールは ステートフル で扱われ、明示ルールが無い通信は拒否されます。

インバウンド

プロトコル (TCP/UDP/ICMP)
ポート範囲 (ポート番号の範囲)
送信元 (アクセス元の IP アドレス)

アウトバウンド

プロトコル (TCP/UDP/ICMP)
ポート範囲 (ポート番号の範囲)
送信先 (アクセス先の IP アドレス)

AWS のセキュリティやスケーラビリティを高める機能・サービス 5/6

制御可能な項目はセキュリティグループと同じです。

セキュリティグループは、ステートフルで動作し、NACL はステートレスで動作します。

Network Access Control List

個々のサブネットごとにアクセス制御が可能
インバウンド、アウトバウンドに対して下記の設定が可能

インバウンド

ポート範囲 (ポート番号の範囲)
送信元 (アクセス元の IP アドレス)
Allow（許可）/ Deny（否定）

アウトバウンド

ポート範囲 (ポート番号の範囲)
送信先 (アクセス先の IP アドレス)
Allow（許可）/ Deny（否定）

AWS のセキュリティやスケーラビリティを高める機能・サービス 6/6

IAM のアイコン

AWS 自体のリソース操作をよりセキュアに扱うための認証・認可の仕組みです。

AWS 利用者の認証とアクセスポリシーを「ユーザーグループ」「ユーザー」「ロール」で管理します。

実行出来る操作を IAM ポリシーで設定
ユーザーごとに認証情報の設定が可能
AWS マネージメントコンソールにはユーザ名とパスワードを使用さらに、MFA (多要素認証) の利用が推奨
API にはアクセスキーとシークレットキーを使用

IAM ポリシーで必要最小限のみ付与

AWS のセキュリティやスケーラビリティを高める機能・サービス - 備考

AWS アカウント (ルートアカウント) の保護

AWS アカウント (ルートアカウント) は、ハードウェアトークンで保護することが推奨されています。

また、ハードウェアトークンは金庫などで管理することが推奨されています。

IAM アカウントの保護

IAM アカウントは、個人で利用するアカウントです。

こちらは、仮想 MFA 対応のスマホアプリにて保護すると効率的にご利用いただけます。

MFA (多要素認証) を設定すると、AWS アカウントサインイン時に 6 桁 のコードを求められるようになります。

ハンズオンの流れ

フェーズ 1

WordPress サイトを最小構成でスタートします。

サーバー 1 台構成

パブリックサブネットに Amazon EC2 インスタンス (サーバー) を起動します。

サーバーには SSH ではなく、AWS Systems Manager のセッションマネージャー経由でセキュアに接続します。

WordPress をホスティングして、ユーザーがブラウザ経由で Web サイトを閲覧できるようにします。

フェーズ 1 は、サーバー 1 台構成のため、スケールするには インスタンスファミリー を変更してサイズアップする必要があります。

フェーズ 2

スケールできるアーキテクチャに移行する準備をします。

Web + DB (サーバー 2 台構成)

Amazon Aurora MySQL インスタンスを起動して、データベースにします。

サーバーにて稼働させていたデータベースを停止して、Aurora データベースに切り替えます。フェーズ 2 の状態はまだスケールするための準備で、スケールはインスタンスファミリーを変更してサイズアップする必要があります。

フェーズ 3

Web サーバーがスケールできる構成にします。

ALB + Web x 2 + DB (サーバー 3 台構成)

Web サーバーを複製できるように Amazon Machine Images (AMI) を取得します。

AMI から Web サーバーを複製して 2 台構成にします。

2 台のサーバーに Web リクエストがバランシングされるように、前段に Application Load Balancer を起動します。

フェーズ 3 になると、Web リクエストが増えた際に 1 台のサーバーをスペックアップする方法 (スケールアップ) に加えて、台数を増やす (スケールアウト) ができるようになります。

オプション

DB サーバーを冗長化された構成にします。

ALB + Web x 2 + DB x 2 (サーバー 4 台構成)

データベースに障害が発生した際に、フェイルオーバーするようにスタンバイインスタンスを起動して、Multi-AZ 構成にします。

最終構成図

【補足】無料利用枠 (個人アカウントでご参加の方向け)

ハンズオンの一部は AWS 無料利用枠の範囲で進めることができます。また、ハンズオンが終了した後で、作成したリソースを全て削除すると課金はされません。

<1年間、以下範囲が毎月無料で利用できます>

EC2: Windows/Linux/RedHat などの t2.micro インスタンスを合計約 1ヶ月分
EBS: 合計 30GB の General Purpose (SSD) と 1GB のスナップショットを合計約 1ヶ月分
RDS: MySQL/PostgreSQL などを 20GB まで db.t2.micro インスタンスを合計約 1ヶ月分 (シングルAZ構成限定)
ALB: 合計約 1ヶ月分、15GB の処理トラフィック:インターネットへのデータ送信 15GB

AWS 無料利用枠

スクリーンキャプチャに表示されている情報について

リソースの各種 ID (vpc-XXXXXX、subnet-XXXXXX、i-XXXXXX など) は AWS 全体でユニークとなっており、スクリーンキャプチャに記載の ID と実際に操作されて作成される ID は各自で異なります。

Elastic IP (固定IPアドレス) なども各自で異なります。

GUI インターフェイスデザインの変更について

画面のデザイン等が変更されて実際とは異なっていることがあります。画面の項目名等から判断して操作下さい。

例えば、ホーム画面は少し前まで ↓ のデザインでしたが、

少し前のコンソール

↓ のようなデザインに変わりました。

2022年4月の最新コンソール

↓ もっと前はこのような画面の頃もありました。

随分前のコンソール

コマンドライン

コマンドライン文は、なるべくコピペするようにしてください。

例えば、以下の SQL コードは wp_option テーブルにある option_name のカラムが「siteurl」か「home」のレコードだけ表示するコマンドですが、

select * from wp_options where option_name='siteurl' or option_name='home';

誤って以下のように入力してしまうと、テーブルのデータが全部表示されてしまいます。

select * from wp_options;

サーバー 1 台構成

最小構成で最も低コストですが、拡張性が低く、性能を一定以上上げることができません。

Phase1 完成図

拡張性: 低

拡張するには 1 台のインスタンスタイプを大きくします。

冗長性: 低

インスタンスが稼働する物理サーバが壊れると一旦停止になりますが、同じアベイラビリティーゾーン内の問題の無いサーバですぐ起動できます。

AWSマネジメントコンソールへのログイン

https://console.aws.amazon.com にブラウザでアクセスして、アカウントの E メールアドレスとパスワードでログインしてください。

AWS マネジメントコンソールサインイン画面

サインインするとホーム画面が表示されます。

AWS マネジメントコンソールホーム画面

左上の AWS アイコンをクリックするとホームに戻ります。

AWS マネジメントコンソールホーム画面 - ホーム

サービスをクリックすると、EC2 や RDS といった各種 AWS サービス名へのリンクにアクセスできます。

AWS マネジメントコンソールホーム画面 - サービス

テキストボックスにサービス名を入力することで候補が表示されるので便利です。

AWS マネジメントコンソールホーム画面 - テキスト検索ボックス

リージョンを変更する (シンガポール)

AWS マネジメントコンソールに初めてサインインすると、「バージニア北部」リージョンが表示されます。練習で、シンガポールリージョンに移動してみたいと思います。

このリージョン名をクリックして候補から、アジアパシフィック (シンガポール) ap-southeast-1 を選択してください。

AWS マネジメントコンソールリージョン移動 - シンガポール

リージョンを変更する (シドニー)

画面遷移して「シンガポール」リージョンが表示されたら、次は「シドニー」リージョンに移動してみてください。「シンガポール」をクリックし、「アジアパシフィック (シドニー) ap-southeast-2」を選択してください。

AWS マネジメントコンソールリージョン移動 - シドニー

リージョンを変更する (東京)

リージョンの移動は完璧でしょうか。

それでは、本日構築する「東京」リージョンに移動してください。「シドニー」をクリックし、「アジアパシフィック (東京) ap-northeast-1」を選択してください。

AWS マネジメントコンソールリージョン移動 - 東京

デフォルトリージョンを設定する

AWS マネジメントコンソールは「最後に利用したリージョン」を表示するようになっています。

これを変更するには、[設定] を開き、デフォルトリージョンの「最後に使用したリージョン」から希望のリージョンに変更してください。

AWS マネジメントコンソールリージョン移動 - 東京

VPC コンソールにアクセス

左上のサービスをクリックして、表示されたメニューからネットワーキングとコンテンツ配信をクリック、表示された VPC を選択します。

VPC コンソールに画面遷移します。

AWS マネジメントコンソールサインイン画面

VPC ウィザードで VPC コンポーネントを作成する

VPC コンソールが表示されたら、[VPC ウィザードを起動] ボタンをクリックしてください。

AWS マネジメントコンソールサインイン画面

VPC ウィザード - 全貌

VPC ウィザードは文字通り、画面の手順に沿ってクリックして進めていくと VPC が構築できる便利なウィザード機能です。

以前は画面が遷移していく形でしたが、2022年4月現在はリニューアルして 1 ページで収まらないほど大きな画面になりました。全貌は以下の画像の通りですが、順番に設定していきます。

AWS マネジメントコンソールサインイン画面

まず作成するリソースは「VPC、サブネットなど」を選択します。

AWS マネジメントコンソールサインイン画面

VPC ウィザード - 名前タグ

次に、名前タグを設定します。テキストボックスに入力された「プロジェクト」を消して、「handsonyyyymmdd(今日の日付)」などの名前を入力してみてください。

右側に表示された VPC やサブネット、ルートテーブル、インターネットゲートウェイ、エンドポイントなどの名前タグが動的に設定されます。

以前のウィザードでは手入力だったので便利になりました。

AWS マネジメントコンソールサインイン画面

VPC ウィザード - IPv4 CIDR ブロック

本ハンズオンで作成する VPC のレンジは 10.0.0.0/16 にしますので、

AWS マネジメントコンソールサインイン画面

デフォルトで入力されている「10.0.0.0/16」のまま、次に進んでください。

AWS マネジメントコンソールサインイン画面

VPC ウィザード - アベイラビリティーゾーン

アベイラビリティーゾーンは 2 のままで大丈夫です。AZ のカスタマイズから、どのアベイラビリティーゾーンを利用するか決めることができます。本ハンズオンでは、AZ-a と AZ-c を利用します。

AWS マネジメントコンソールサインイン画面

本ハンズオンでは、パブリックサブネットとプライベートサブネットを二つずつ作ります。設定値は以下になります。

Public／Private	AZ	CIDR
Public	ap-northeast-1a	10.0.0.0/24
Public	ap-northeast-1c	10.0.1.0/24
Private	ap-northeast-1a	10.0.2.0/24
Private	ap-northeast-1c	10.0.3.0/24

VPC ウィザード - NAT ゲートウェイ、VPC エンドポイント

NAT ゲートウェイは利用しません。

VPC エンドポイントも今回は利用しないのでなしにしてください。

DNS オプションはどちらもチェックを入れてください。

[VPC を作成] ボタンをクリックしてください。

AWS マネジメントコンソールサインイン画面

プレビューにも表示されている通り VPC、サブネット、ルートテーブル、インターネットゲートウェイが作成されます。

VPC が作成されたら [VPC を表示] ボタンをクリックしてください。

AWS マネジメントコンソールサインイン画面

ウィザードで作成された VPC を確認

[VPC を表示] ボタンをクリックすると、作成された VPC の詳細画面に遷移するので、左のメニューペインにある VPC のリンクをクリックしてください。

AWS マネジメントコンソールサインイン画面

左のメニューペインにある VPC でフィルタリング: のテキストボックスをクリックすると、候補が表示されますので、作成した VPC を選択してください。

AWS マネジメントコンソールサインイン画面

作成した VPC だけがフィルタリングされて表示されます。

AWS マネジメントコンソールサインイン画面

先ほど作成した VPC が存在するか (正しく絞り込めているか) を確認してください。この VPC の IPv4 CIDR が 10.0.0.0/16 であることを確認してください。

AWS マネジメントコンソールサインイン画面

ウィザードで作成されたサブネットを確認

左のメニューペインにあるサブネットをクリックします。

サブネット一覧が表示されますので、「public」と「AZ-a」の名前が記載されたリソースにチェックを入れてください。

AWS マネジメントコンソールサインイン画面

ページ下部のペインに詳細が表示されますので、アベイラビリティゾーンが ap-northeast-1a であること、IPv4 CIDR が 10.0.0.0/24 であることを確認してください。

AWS マネジメントコンソールサインイン画面

ウィザードで作成されたルートテーブルを確認

詳細ペインで、ルートテーブルのタブをクリックしてください。

VPC のネットワークアドレス 10.0.0.0/16 のターゲットが local に、デフォルトルートの 0.0.0.0/0 のターゲットがインターネットゲートウェイ (igw-XXXX) になっており、インターネットと通信できる設定になっています。

AWS マネジメントコンソールサインイン画面

EC2 インスタンスにアタッチする IAM ロールを作成する

EC2 インスタンスには、Linux OS の場合は SSH で、Windows OS の場合は RDP で接続をしますが、本ハンズオンでは SSH ポートを開放せずに AWS Systems Manager のセッションマネージャー経由で接続をします。

サービス から、セキュリティ、ID、およびコンプライアンス をクリックし、IAM を選択します。

AWS マネジメントコンソールサインイン画面

IAM コンソールに画面遷移したら、左側のメニューメインから ロール をクリックします。

ロール画面に遷移したら [ロールを作成] ボタンをクリックします。

AWS マネジメントコンソールサインイン画面

信頼されたエンティティタイプが AWS のサービス が選択されていること、ユースケースは EC2 が選択されていることを確認して、[次へ] ボタンをクリックしてください。

AWS マネジメントコンソールサインイン画面

許可を追加画面に推移するので、テキストボックスに AmazonSSMManagedInstanceCore を入力し、表示された AmazonSSMManagedInstanceCore のチェックボックスにチェックを入れて、[次へ] ボタンをクリックしてください。

AWS マネジメントコンソールサインイン画面

ロール名 には識別しやすい任意のロール名を入力してください。

ここでは、handson-ec2-role とします。

AWS マネジメントコンソールサインイン画面

最下部まで進み、[ロールを作成] ボタンをクリックします。

AWS マネジメントコンソールサインイン画面

ロールが作成されたら、本ロールを SSM Agent が利用できるように設定します。

テキストボックスにロール名を入力し、ENTER キーを押下します。

ロールが表示されたら、リンクをクリックしてください。

AWS マネジメントコンソールサインイン画面

ロールの詳細画面に遷移したら、[信頼関係] タブをクリックし、[信頼ポリシーを編集] ボタンをクリックしてください。

AWS マネジメントコンソールサインイン画面

以下のような形でポリシーが表示されるので、

＜変更前＞


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

"Service": ["ec2.amazonaws.com","ssm.amazonaws.com"] に書き換えてください。

＜変更後＞


{
        "Version": "2012-10-17",
        "Statement": [
                {
                        "Effect": "Allow",
                        "Principal": {
                                "Service": ["ec2.amazonaws.com","ssm.amazonaws.com"]
                        },
                        "Action": "sts:AssumeRole"
                }
        ]
}

ポリシーの記述に誤りがあると以下の通り誤りのある行に × 印でエラーマークが表示されます。エラーが消えるまで修正をしてください。

ポリシーが変更できたら下部にある [ポリシーを更新] ボタンをクリックしてください。

EC2 コンソールを開く

左上のサービスボタンをクリックして、コンピューティングから EC2 を選択してください。

テキストボックスに入れていただいても候補が表示されます。

AWS マネジメントコンソールサインイン画面

EC2 コンソールに画面遷移したら [インスタンスを起動] ボタンをクリックしてください。

EC2 コンソールは旧いコンソールと新しいコンソールがあり、表示の仕方が異なる場合があります。ハンズオンは新しいコンソールで進めますので、左上のトグルボタンを下記の通りにして新しいコンソールになっていることを確認してください。

AWS マネジメントコンソールサインイン画面

[インスタンスを起動] のボタンが展開されるのでクリックしてください。

AWS マネジメントコンソールサインイン画面

ステップ1: 名前とタグ

インスタンスを区別できるようにタグに名前を設定します。

IAM ユーザを利用している場合、他ユーザと区別が付くように -user1 等ユーザ名を付けると良いでしょう。

ここでは、handson-ec2-wordpress-1 とします。

ステップ2: アプリケーションおよび OS イメージ (Amazon マシンイメージ)

"その他のAMIを閲覧する"をクリックします。

本ハンズオンでは、Amazon Linux 2022 の AMI を利用します。

テキストボックスに以下の AMI ID を入力して、検索を行います。

コミュニティ AMI に該当の AMI があるので、選択ボタンを押下します。

AMI 名:
al2022-ami-2022.0.20220315.0-kernel-5.15-x86_64 al2022-ami-2022.0.20220928.0-kernel-5.15-x86_64
AMI ID:ami-082c70eb5ed5441a1 ami-0880701de3c9da14f
※ 東京リージョンの AMI ID です。
※ AMI の配布が終了しておりましたので、AMI ID を変更しました。

選択後に以下の様な表示に切り替わります。

ステップ3: インスタンスタイプ

インスタンスタイプは、無料利用枠の「t2.micro」を選択します。

ステップ4: キーペア（ログイン）

セッションマネージャーを利用するため、本ハンズオンではキーペアは利用しません。

[キーペアなしで続行（推奨させません）] を選択します。

ステップ5: ネットワーク設定

[編集] ボタンを押下し、以下の設定をお願いします。

項目	値
VPC	本日を作成したVPCを設定下さい手順書通りなら「handson20220425-vpc」となります。
サブネット	*-public1-ap-northeast-1aと記載されたサブネットを設定下さい手順書通りなら「handson20220425-subnet-public1-ap-northeast-1a」となります。
パブリックIPの自動割り当て	有効化
ファイアウォール（セキュリグループ）	セキュリティグループを作成する
セキュリティグループ名	web-sg
説明	web-sg
タイプ	HTTP
ソースタイプ	自分のIP

ステップ5: ストレージを設定

画面右上のアドバンストをクリックします

IOPSに3000を設定します。

ステップ6: 高度な詳細

以下の設定をお願いします。

項目	値
IAM インスタンスプロフィール	本日を作成したRoleを設定下さい手順書通りなら「handson-ec2-role」となります。
クレジット仕様	スタンダード（無制限の場合、t 系インスタンスで CPU クレジットが枯渇した際に予想以上のコストがかかる場合があります。）
ユーザーデータ	（以下をコピペ）

#!/bin/bash
dnf -y update
# WordPress のインストールを完了させるため、SELinux を一時的にPermissive に変更
setenforce 0

# WordPress のRDS切り替えを完了させるため、SELinux を恒久的に Permissive に変更
grubby --update-kernel ALL --args enforcing=0

# タイムゾーンを東京に変更
timedatectl set-timezone Asia/Tokyo
localectl set-locale LANG=ja_JP.utf8

# SSM Agent インストール
dnf install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
systemctl enable amazon-ssm-agent
systemctl start amazon-ssm-agent

# Nginx インストール
dnf install -y nginx

# php インストール
dnf install -y php
dnf install -y php-mbstring php-devel php-gd php-pdo php-xml php-mysqlnd php-json

# PHP FastCGI インストール
dnf install -y php-fpm

#php-fpm 設定変更
sed -i -e "s/user = apache/user = nginx/g" /etc/php-fpm.d/www.conf
sed -i -e "s/group = apache/group = nginx/g" /etc/php-fpm.d/www.conf
systemctl enable php-fpm.service
systemctl start php-fpm.service

# mariadb インストール
dnf install -y mariadb105-server
systemctl start mariadb
systemctl enable mariadb
mysql -u root -e "create database wp_database; grant all privileges on wp_database.* to wp_admin@localhost identified by 'wordpress';"

# WordPress インストール
cd /usr/share/nginx/html/
wget https://ja.wordpress.org/latest-ja.tar.gz
tar -xzf latest-ja.tar.gz
rm -f latest-ja.tar.gz
chown -R nginx. /usr/share/nginx/html

# WordPress ディレクトリとフォルダーの権限設定
find /usr/share/nginx/html/wordpress -type d -exec chmod 705 {} +
find /usr/share/nginx/html/wordpress -type f -exec chmod 604 {} +

# WordPress 用の Nginx 設定ファイル
cat << EOS >> /etc/nginx/conf.d/wordpress.conf
server {
        index index.php index.html;
        root /usr/share/nginx/html/wordpress;

        location ~* /wp-config.php {
                deny all;
        }

        location / {
                try_files \$uri \$uri/ /index.php\$is_args$args;
        }

        location ~ \.php\$ {
                include fastcgi.conf;
                fastcgi_pass   unix:/run/php-fpm/www.sock;
        }
}
EOS

# Nginx スタート
systemctl enable nginx.service
systemctl start nginx.service

ステップ7: 概要

「インスタンスを起動」ボタンを押下します

以下のような画面になれば成功です。

インスタンスの作成が完了するのを待ちます。

ステータスが「利用可能」になるまで数分かかります。

AWS マネジメントコンソールリージョン移動 - 東京

セッションマネージャー経由で EC2 インスタンスにアクセスする

起動したインスタンスは、AMI (Amazon マシンイメージ) から復元されたあと、ユーザーデータに入力したスクリプトによって、インストールが行われていきます。

下図の通り、

インスタンスの状態が 実行中 になること
ステータスチェックが 2/2 のチェックに合格しました

になることを確認してください。(これには数分かかります。)

また、バックグラウンドでは並行してユーザーデータによるインストールが進行していきます。

インストールが完了するまで少し時間がかかりますが、このインストールの途中でセッションマネージャーが利用できる状態になります。

ユーザーデータで行う処理

SELinux 無効化
Amazon Linux 2022 は Fedora ベースの OS で SELinux が有効になっています。
SELinux が有効だとセットアップ時に Nginx が正しく動作しません。
本番環境では SELinux を有効化して http などのポリシーの設定を行う必要がありますが、本ハンズオンでは無効化します。
タイムゾーンを東京に変更
Amazon Linux 2022 の AMI は UTC 時刻にて稼働します。そのため、起動後にタイムゾーンを UTC+9 (Asia/Tokyo) にします。
ロケールを日本語に変更
SSM エージェントのインストール
SSM エージェントをインストールすると、セッションマネージャーが利用できるようになります。
Nginx インストール
Web サーバーとして稼働させるため、Nginx をインストールします。
php インストール
WordPress の稼働に必要な PHP と PHP モジュールをインストールします。
MariaDB インストール
WordPress で利用する MariaDB をインストールします。
WordPress インストール
最新版の WordPress をダウンロードしてインストールします。

セッションマネージャーによる接続

インスタンスが起動したらセッションマネージャーで接続してみましょう。

EC2 コンソールの左側のメニューペインにあるインスタンスをクリックして、右側に表示されるインスタンス一覧から、起動したインスタンスを見つけてください。

インスタンスの左側にあるチェックボックスにチェックを入れて、[接続] ボタンをクリックしてください。

インスタンスが複数表示されている場合は、テキストボックスにインスタンス名を入れたり、ステータスを running でフィルタリングするなどすると効率的に見つけることができます。

[セッションマネージャー] タブを選択し、[接続] ボタンをクリックします。

接続が成功すると、ブラウザの新しいタブが開いて以下のようなプロンプトで停止します。

sh-5.1$

スイッチユーザーして、root ユーザーに昇格してください。

sh-5.1$ sudo -i
#

本ウインドウは閉じずにそのままにしておいてください。

セッションマネージャーによる接続がうまくいかない場合

インスタンスは完全に起動完了していますでしょうか。ステータスチェックは 2/2 になっていますか？

起動時に指定した内容どおりに起動しているでしょうか?

接続先のインスタンス ID は正しいですか？

次はブラウザから Web ページにアクセスしてみます。

EC2 コンソールでインスタンスを選択したら、下部の詳細ペインに表示された パブリック IPv4 アドレス を見つけて、アドレスの左側にあるアイコンをクリックしてください。IP アドレスがクリップボードにコピーされます。

Chrome タブを追加して、アドレスバーに貼り付けて、ENTER キーを押下しアクセスしてください。WordPress のセットアップ・ウェルカムページが表示されます。

Elastic IP (EIP) を取得

インスタンスを停止/開始した後も、同じ IP アドレスが使用できるよう、固定 IP アドレスであるElastic IP を取得します。

EC2 コンソールにて、左側のメニューペインから Elastic IP をクリックし、ページ上部に表示された [Elastic IP アドレスを割り当てる] ボタンをクリックしてください。

Elastic IP アドレスを割り当てる の画面に遷移するので、Name タグを設定してください。 ページの下部にあるタグ - オプション に進み、[新規タグ追加] ボタンをクリックします。キーと値に以下を入力してください。

キー	値
Name	handson-ec2-wordpress-1

AWS マネジメントコンソールサインイン画面

Elastic IP アドレスが割り当てられたら、割り当てられた IPv4 アドレスを控えておいてください。

メモができたら、上図の緑のラインに表示されている [この Elastic IP アドレスを関連づける] をクリックしてください。

インスタンス に起動した EC2 インスタンスを指定し、プライベート IP アドレスを選択して、[関連付ける] ボタンをクリックしてください。

アタッチしたアドレスは、EC2 の詳細画面からも確認できますので再度チェックしておいてください。

MySQL と Nginx が動いていることを確認

先ほど接続したセッションマネージャーのブラウザタブに戻り、MySQL と Nginx が動いていることを確認したいと思います。

以下の root 権限にて、

sh-5.1$ sudo -i
#

以下コマンドを入力してください。

systemctl status mariadb

以下のような running ステータスが返れば正常に起動しています。

# systemctl status mariadb
● mariadb.service - MariaDB 10.5 database server
     Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; vendor preset: disabled)
     Active: active (running) since Wed 2022-04-06 21:16:03 JST; 1h 48min ago
       Docs: man:mariadbd(8)
             https://mariadb.com/kb/en/library/systemd/
   Main PID: 29016 (mariadbd)
     Status: "Taking your SQL requests now..."
      Tasks: 8 (limit: 1096)
     Memory: 64.7M
        CPU: 1.324s
     CGroup: /system.slice/mariadb.service
             └─29016 /usr/libexec/mariadbd --basedir=/usr

 4月 06 21:16:03 ip-10-0-0-44.ap-northeast-1.compute.internal mariadb-prepare-db-dir[28974]: See the MariaDB Knowledgebase at>

 (中略)

 4月 06 21:16:03 ip-10-0-0-44.ap-northeast-1.compute.internal systemd[1]: Started MariaDB 10.5 database server.
lines 1-23/23 (END)

コマンドを投入したあとに以下のような画面で操作できない方は、キーボードの [Q] キーを押下すると抜けることができます。

続いて、Nginx サーバーを確認します。

以下のコマンドを入力してください。

systemctl status nginx

以下のような running ステータスが返れば正常に起動しています。

# systemctl status nginx
● nginx.service - The nginx HTTP and reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
    Drop-In: /usr/lib/systemd/system/nginx.service.d
             └─php-fpm.conf
     Active: active (running) since Wed 2022-04-06 21:16:16 JST; 1h 47min ago
    Process: 29098 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
    Process: 29099 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
    Process: 29100 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
   Main PID: 29101 (nginx)
      Tasks: 3 (limit: 1096)
     Memory: 5.9M
        CPU: 61ms
     CGroup: /system.slice/nginx.service
             ├─29101 nginx: master process /usr/sbin/nginx
             ├─29102 nginx: worker process
             └─29103 nginx: worker process

 4月 06 21:16:16 ip-10-0-0-44.ap-northeast-1.compute.internal systemd[1]: Starting The nginx HTTP and reverse proxy server...
 
 (中略)
 
 4月 06 21:16:16 ip-10-0-0-44.ap-northeast-1.compute.internal systemd[1]: Started The nginx HTTP and reverse proxy server.
lines 1-21/21 (END)

コマンドを投入したあとに以下のような画面で操作できない方は、キーボードの [Q] キーを押下すると抜けることができます。

http://<Elastic IPアドレス>/wordpress/ を開いて、WordPressの初期設定を始めます。

上記 URL にアクセスすると、自動で setup-config.php にリダイレクトします。

[さあ、始めましょう!] ボタンをクリックします。

作成した MySQL の DB 設定に基づき、設定します。

項目	値
データベース名	wp_database
ユーザー名	wp_admin
パスワード	wordpress
データベースのホスト名	localhost
テーブル接頭辞	wp_

以下の画面が表示されるので、上記の値を入力して、[送信] ボタンをクリックしてください。

以下画面に遷移するので、[インストール実行] ボタンをクリックしてください。

AWS マネジメントコンソールサインイン画面

以下画面に遷移するので、パスワードを除いて、画像の通り入力してください。

項目	値
サイトのタイトル	はじめてのAWS
ユーザー名	admin
パスワード	（初期設定のまま）
メールアドレス	abc@example.com
検索エンジンでの表示	チェックを入れる

[WordPress をインストール] ボタンをクリックしたあと、20 秒程度かかります。

ブラウザのローディングが終わるまで、リロードなど行わずに少々お待ちください。

AWS マネジメントコンソールサインイン画面

以下の画面が表示されたらセットアップ完了です。

[ログイン] ボタンをクリックしてください。

AWS マネジメントコンソールサインイン画面

WordPress ログイン画面

以下、ログイン画面が表示されるので先ほど入力したユーザー名とパスワードを入力してください。

[ログイン] ボタンをクリックしてください。

AWS マネジメントコンソールサインイン画面

WordPress 管理者画面

ユーザー名とパスワードが正しく入力され、認証が通れば WordPress の管理者画面が表示されます。

AWS マネジメントコンソールサインイン画面

[投稿] をクリックして、任意の新規ブログポストを書くことができます。
ブログタイトルをクリックするとブログが表示できます。

ブログの起動確認

Wordpress ブログが実行できていることを確認します。

(nginxの画面が出る場合はリロードしてみてください)

前ページの管理画面に戻るには http:// EIastic IP アドレス /wp-admin/ にアクセスします。

AWS マネジメントコンソールサインイン画面

Amazon Aurora は、クラウド向けに AWS が構築したデータベースです。

MySQL と PostgreSQL と互換性があります。

Aurora の DB クラスターは 1 つ以上の DB インスタンスと、データを管理するクラスターボリュームで構成され、データボリュームは 3 AZ に 3 個ずつ計 6 個のコピーが作成され、高い耐障害性を持ちます。

また、通常の RDS 同様にバックアップやフェイルオーバーに対応した DB を数クリックで利用可能にします。

メンテナンスフリーで、自動バックアップや、パッチ当てなどが自動で行われます。

フェーズ2の作成範囲について

フェーズ2は以下の範囲の作成を実施します。

フェーズ2：Web + DB (サーバー 2台構成)

拡張性が少し高くなり、DBの運用が楽になります。

◆拡張性：中

拡張方法はフェーズ 1 と変わらず、インスタンスタイプを大きくします。

2 台構成のため、フェーズ 1 よりも最大構成で対応できる規模が大きくなります。

◆冗長性：中

Amazon Aurora 自体はシングル AZ 上で構成されるものの、データそのものはデータクラスターの単位で各 AZ 上に分割される為、データの冗長性は向上します。

DB 用のセキュリティグループ

DB へのアクセスを許可するソースには、IP アドレスではなく Web サーバー用のセキュリティグループを指定します。

こうする事で DB は Web サーバーからのアクセスのみ許可されます。

DB 用のセキュリティグループを作成

EC2 のウィザードからセキュリティグループを選択し、以下の手順で実施します。

セキュリティグループ作成画面で以下を入力します。

・セキュリティグループ名：db-sg

・説明：Aurora for MySQL

・VPC：自分で作成したVPCを選択します。

インバウンドルールに [MySQL/Aurora] を選択し、web-sg を対象として選択し、セキュリティグループを作成します。

RDS 管理ページを開く

サービスからデータベースを選択し、RDSをクリックします。

DB サブネットグループを作成

RDS の管理画面からサブネットグループを選択し、DB サブネットグループの作成をクリックします。

DB サブネットグループの作成画面で以下を入力します。

・名前：db-subnet

・説明：Aurora for MySQL

・VPC：作成したVPCを選択します。

サブネットを追加の項目では、

アベイラビリティゾーンでは、[ap-northeast-1a] と [ap-northeast-1c] を選択します。

サブネットでは、[10.0.2.0/24] と [10.0.3.0/24] の 2 つを選択します。

作成したサブネットグループが存在する事を確認します。

Aurora インスタンスを作成

Amazon Aurora のライターインスタンスを作成します。RDS の管理画面からデータベースをクリックし、データベースの作成をクリックします。

データベースの作成で以下を選択、入力します。

・データベースの作成方法：標準作成

・エンジンのオプション：Amazon Aurora

・エディション：MySQL互換エディション

続けて以下の内容を選択します。

・レプリケーション機能を展開して、シングルマスターを選択します。

・利用可能なバージョン：[Aurora(MySQL 5.7) 2.10.2] を選択します。(デフォルトで設定されているバージョンではない可能性があります)

・テンプレート：開発/テストを選択します。

続けて、設定画面において、以下を入力します。

・DBクラスター識別子：aurora-mysql-db

・マスターユーザー名：admin

・パスワード：wordpress

DBインスタンスクラスは バースト可能クラス を選択し、db.t3.small を選択します。

可用性と耐久性の箇所では「Auroraレプリカを作成しない」を選択します。

接続の箇所は以下のように入力します。

・VPC：作成したVPCを選択します。

・サブネットグループ：db-subnetを選択します。

・パブリックアクセス：なし

・VPCセキュリティグループ：既存の選択を選び、db-sgのみを選択します。

アベイラビリティゾーンは [ap-northeast-1a] を選択し、

データベース認証はパスワード認証を選択します。

追加設定から最初のデータベース名に「wp_database」を入力します。

「DBクラスターのパラメータグループ」以下、メンテナンスウインドウの設定まではデフォルト設定のままとしてください。

設定画面の最下部にある削除保護の有効化のチェックを外し、

[データベースの作成]をクリックします。

インスタンスの作成が完了するのを待ちます。

ステータスが「利用可能」になるまで、数分かかります。

AWS マネジメントコンソールリージョン移動 - 東京

作成した Aurora インスタンスを確認

インスタンスの作成が完了するのを待ちます。

[データベース] に表示されるリージョン別クラスターとライターインスタンスのステータスが [利用可能] になるまで数分かかります。

[データベース] に表示されている利用可能となったリージョン別クラスターを選択する

ライターインスタンスのエンドポイント名をコピーしてメモする

作成した Aurora DB への接続確認

Web サーバの EC2 インスタンスから Aurora DB に接続出来る事を確認します。

パスワードを求められるので、wordpress と入力します。

# mysql -u admin -p -h endpoint
Enter password: wordpress

mysql> show databases;

+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
4 rows in set (0.004 sec)

mysql> exit

※ Aurora に接続しています。

EC2 上の MariaDB データをエクスポート

EC2 に保存された MariaDB のデータをエクスポートして、Aurora にインポートしていきます。
セッションマネージャーを開いて操作してください。

sh-5.1$ sudo -i
#

EC2 インスタンス上にインストールされている MariaDB からデータをエクスポートします。

tmp ディレクトリに移動します。

# cd /tmp/
# pwd
/tmp

データをエクスポートします。


# mysqldump -u root -p wp_database > export.sql
Enter password: wordpress

※ EC2 上の MariaDB に接続しています。

DB のデータがエクスポートできたか (ファイルが存在するか？) 確認します。


# ls -l export.sql
-rw-r--r--. 1 root root 295916  4月 24 14:40 export.sql

export.sql がエクスポートできたら、EC2 インスタンスにて稼働している MariaDB は今後使わないため停止します。

# systemctl stop mariadb
# systemctl disable mariadb

MariaDB からエクスポートしたデータを Aurora にインポート

エクスポートしたデータ (export.sql) を Aurora にインポートします。

# mysql -u admin -p -h endpoint wp_database < export.sql
Enter password:wordpress

※ Aurora に接続しています。

インポートされた事を確認します。

$ mysql -u admin -p -h endpoint wp_database
Enter password:wordpress

mysql> show tables;
+-----------------------+
| Tables_in_wp_database |
+-----------------------+
| wp_commentmeta        |
| wp_comments           |
| wp_links              |
| wp_options            |
| wp_postmeta           |
| wp_posts              |
| wp_term_relationships |
| wp_term_taxonomy      |
| wp_termmeta           |
| wp_terms              |
| wp_usermeta           |
| wp_users              |
| wp_database           |
+-----------------------+
13 rows in set (0.001 sec)

mysql> exit

※ Aurora に接続しています。

WordPress の DB 接続設定を削除

再設定をWebから行うため、DB接続設定を初期化します。

設定ファイル(wp-config.php)をホームディレクトリに移動させます。こうすることで/usr/share/nginx/html/wordpress/ から設定ファイルが消え、設定が初期化されます。

# mv /usr/share/nginx/html/wordpress/wp-config.php ~/

WordPressの再設定

http://<Elastic IPアドレス>/ を開いて、WordPressの初期設定を始めます。

作成した Aurora の DB 設定に基づき、設定します。

フェーズ１との違いはデータベースのホスト名で Aurora クラスターのライターエンドポイント名を指定している部分です。

・データベース名：wp_database

・ユーザー名：admin

・パスワード：wordpress

・データベースのホスト名：Aurora クラスターのライターエンドポイント名

画面が切り替わったら、インストールの実行をクリックしてください

以下の画面となりますが、正しい状態です。(Aurora にはすでにデータがインポートされている為)

フェーズ１で設定したブログのユーザ名とパスワードを入力します。

WordPressの管理者画面が表示されます。データベースをRDSに切り替えてもフェーズ１と同様にWordPressが動いていることを確認してください。

フェーズ3 の作成範囲

フェーズ３では、新しく以下のリソースを追加します。

・既存の EC2 の AMI を取得します。

・アベイラビリティゾーン C に EC2 を起動します。

・上段に ALB を配置して冗長構成にします。

フェーズ3：ALB + Web × 2 + DB 構成

◆拡張性：高

本構成では Web サーバーを自由に増減でき、拡張性が高い構成です。

DB サーバーについては変更がなく、1 台ですのでインスタンスタイプを大きくして拡張することになります。

◆冗長性：中

Web サーバーが複数台稼働している場合に、1 台の Web サーバーに障害が発生してリクエストを返せなくなったとします。すると、アプリケーションロードバランサー (ALB) は応答が停止した Web サーバー宛てにリクエストを送信しなくなるため可用性が高まります。

DB サーバーはフェーズ`1 / 2 と同じく 1 台構成ですが、Aurora で作成しているので、データ自体の可用性はアベイラビリティゾーンごとにデータクラスターに分散され、担保されています。(Multi-AZ 構成に比べると、冗長性は無い状態です。)

EC2 管理ページを開く

サービスから [コンピューティング] を選択し、[EC2] をクリックします。

WEB サーバの AMI 作成

EC2 の管理ページにて、左のメニューペインから [インスタンス] をクリックし、インスタンス一覧画面から先の手順で作成したインスタンスを選択します。

[アクション] ボタンから [イメージとテンプレート] - [イメージを作成] をクリックします。

イメージの作成画面にて、 handson-ec2-wordpress-image など分かりやすい名前をイメージ名として入力後、[イメージ] の作成をクリック

画面上部に緑の帯でイメージの作成に関するメッセージが表示されますので、「ami-」から始まる AMI イメージ ID をクリックしてください。

Amazon マシンイメージ (AMI) の画面で作成を待ちます。

完了するまで数分かかります。

AWS マネジメントコンソールリージョン移動 - 東京

AMI の作成画面で状態が [保留中] から [利用可能] になることを確認します。

2 台目の EC2 インスタンスを作成

AMI が利用可能になったら選択をして [AMI からインスタンスを起動] をクリックしてください。

ステップ1: 名前とタグ

名前には、handson-ec2-wordpress-2 と入力してください。

ステップ2: インスタンスタイプ

インスタンスタイプは、 t2.micro が選択されていることを確認してください。

ステップ3: キーペア (ログイン)

キーペア名 - 必須 は「キーペアなしで続行 (推奨されません)」を選択してください。

ステップ4: ネットワーク設定

ネットワーク設定の右側にある [編集] ボタンを押下し、以下の設定をお願いします。

項目	値
VPC	本日を作成したVPCを設定下さい手順書通りなら「handson20220425-vpc」となります。
サブネット	*-public2-ap-northeast-1cと記載されたサブネットを設定して下さい手順書通りなら「handson20220425-public2-ap-northeast-1c」となります。
パブリックIPの自動割り当て	有効化
ファイアウォール（セキュリグループ）	既存のセキュリティグループを選択する
セキュリティグループ名	web-sg

ステップ5: 高度な詳細

以下の設定をお願いします。

項目

値

IAM インスタンスプロフィール

本日を作成したRoleを設定下さい

手順書通りなら「handson-ec2-role」となります。

クレジット仕様

スタンダード

（無制限の場合、t 系インスタンスで CPU クレジットが枯渇した際に予想以上のコストがかかる場合があります。）

以上が設定できたら、[インスタンスを起動] ボタンをクリックしてください。

EC2 インスタンスの作成が始まりました。

[インスタンス一覧を表示] ボタンをクリックしてください。

インスタンスの一覧画面に遷移するので、2 台のインスタンスが 2 つの異なるアベイラビリティゾーンで起動している事を確認してください。

ALB のセキュリティグループ

以下のように Web サーバのフロントに ALB を作成します。

ALB 用のセキュリティグループは任意の IP アドレスから 80 番ポートへのアクセスを受け付けるように登録します。また、後続の手順で WEB サーバのセキュリティグループは ALB からのみ受け付けるように変更します。

ALB を作成

2 台の Web サーバへのアクセスを振り分ける ALB を作成します。

サービスから [コンピューティング] を選択し、[EC2] をクリックします。

EC2 の管理ページに移動したら、左ペインより [ロードバランサー] を選択し、[ロードバランサーの作成] をクリックします。

[ロードバランサーの選択] 画面に遷移しますので、左側にある [Application Load Balancer] の [作成] ボタンをクリックしてください。

データベースの作成で以下を選択、入力します。[基本的な設定] は以下のように設定してください。

・ロードバランサー名：alb-handson

・スキーム：インターネット向け

・IPアドレスタイプ：IPv4

[ネットワークマッピング] は以下のように設定してください。

項目	値
VPC	本日を作成したVPCを設定下さい手順書通りなら「handson20220425-vpc」となります。
マッピング ap-northeast-1a	パブリックサブネットを選択してください。ハンズオンの通りに命名している場合、以下となります。 handson20220425-subnet-public1-ap-northeast-1a
マッピング ap-northeast-1c	パブリックサブネットを選択してください。ハンズオンの通りに命名している場合、以下となります。 handson20220425-subnet-public2-ap-northeast-1c

セキュリティグループの設定

[新しいセキュリティグループの作成] をクリックすると、作成ウィザードが別タブで開きます。

[基本的な詳細] は以下のように設定してください。

項目	値
セキュリティグループ名	alb-sg
説明	alb-sg
VPC	フェーズ1 で作成したVPC ハンズオンの通りに命名している場合、以下となります。 handson20220425-vpc

[インバウンドルール] は [ルールを追加] ボタンをクリックして以下のように設定してください。

項目	値
タイプ	HTTP
ソース	マイ IP

アウトバウンドルール、タグはデフォルト設定のまま変更しません。

最後に [セキュリティグループを作成] をクリックします。

セキュリティーグループを作成したら、ロードバランサー作成途中のタブに戻ってください。

下図の更新ボタンをクリックすると、前項で作成したセキュリティグループ「alb-sg」が表示されます。

セキュリティグループ [alb-sg] を選択します。

「default」は × をクリックして外します。

以下の通り「alb-sg」だけが選択されている状態にしてください。

ターゲットグループの作成

[リスナーとルーティング] のセクションで、[ターゲットグループの作成] をクリックすると、別タブでターゲットグループの作成ウィザードが別タブで開きます。

別タブでターゲットグループの作成ウィザードが開いたら、[基本的な設定] を以下のように設定します。

項目	値
ターゲットタイプの選択	インスタンス
ターゲットグループ名	alb-target
VPC	本日を作成したVPCを設定下さい手順書通りなら「handson20220425-vpc」となります。

[ヘルスチェックの詳細設定] を展開して、[正常のしきい値] を 2 にしてください。

その他の設定はデフォルトのままとしてください。

画面右下の [次へ] ボタンをクリックします。

ターゲットの登録

ALB からのトラフィックを分散する先として、フェーズ2 で作成した EC2 インスタンスの登録を行います。VPC が正しく選択されていれば、作成した EC2 インスタンスが表示されます。

チェックボックスにチェックを入れて、[保留中として以下を含める] ボタンをクリックします。

ターゲット登録するインスタンスを確認したら [ターゲットグループの作成] をクリックします。

再びロードバランサーの作成ウィザードのタブに戻ります。

更新ボタンをクリックすると、作成したターゲットグループが表示されるので選択します。

画面最下部にある [概要] 欄にて上記の各設定が正しく設定されているかを確認して、[ロードバランサーの作成] ボタンをクリックしてください。

WEB サーバのセキュリティグループの編集

ALB から WEB サーバへ接続する為、既存の WEB サーバのセキュリティグループを編集します。

[サービス] をクリックして、[ネットワーキングとコンテンツ配信] - [VPC] を選択してください。

左側のメニューペインにある [セキュリティグループ] をクリックします。

セキュリティグループの一覧が表示されたら、[web-sg] を選択します。

下部の詳細ペインに表示された [インバウンド] タブをクリックして、[インバウンドのルールを編集] ボタンをクリックしてください。

ソース [カスタム] の右側にあるテキストボックスをクリックして、表示された候補から [alb-sg] を選択してください。

[ルールの保存] をクリックしてください。

下記のエラーが起きた場合は、既存のインバウンドルールを一旦削除してから、新たにタイプHTTP、ソースを [alb-sg] としてルールを追加してください。

[ルールの追加] ボタンから新しくルールを追加して [alb-sg] を指定します。

エラーが表示されたルールは [削除] ボタンで削除してください。

作成した ALB の動作確認

EC2 の管理ページに戻り、右側のメニューペインにある [ロードバランサー] をクリックします。

作成した ALB (手順通りであれば alb-handson になっているはずです) を選択して、詳細ペインに表示された DNS 名をメモします。

続いて、右側のペインにある [ターゲットグループ] をクリックして、作成したターゲットグループ (手順通りであれば alb-target になっているはずです) を選択します。

下部に表示された詳細ペインにある [ターゲット] タブをクリックし、ヘルスステータスが [healthy] であることを確認してください。

WordPress の設定変更

WordPress は、初期セットアップでデータベースにパブリック IPv4 アドレスを登録します。
先ほど初期セットアップをしたときは EC2 にアタッチした Elastic IP アドレスでアクセスしていました。なので、データベースには Elastic IP アドレスが記録されています。

このデータベースに登録されたアドレスを、ALB の DNS 名に変更する必要があります。

ひとまず、現在の設定を確認してみましょう。
[handson-ec2-wordpress]、[handson-ec2-wordpress-2] の 2 つのサーバーのどちらかにセッションマネージャーで接続し、以下のコマンドを実行します。

sh-5.1$ sudo -i

# mysql -u admin -p -h endpoint wp_database
Enter password: wordpress

mysql> select * from wp_options where option_name='siteurl' or option_name='home';

コマンドを投入すると、以下のように IP アドレスが表示されます。


+-----------+-------------+---------------------+----------+
| option_id | option_name | option_value        | autoload |
+-----------+-------------+---------------------+----------+
|         2 | home        | http://13.113.94.95 | yes      |
|         1 | siteurl     | http://13.113.94.95 | yes      |
+-----------+-------------+---------------------+----------+
2 rows in set (0.001 sec)

この IP アドレスを ALB の DNS 名に変更します。続けて、以下のようにコマンドを投入します。


MySQL [wp_database]> update wp_options set option_value='http://DNS名' where option_name='siteurl' or option_name='home';
Query OK, 2 rows affected (0.007 sec)
Rows matched: 2  Changed: 2  Warnings: 0

もう一度、SELECT 文を投入して、Elastic IP アドレスから、ALB の DNS 名に変わったことを確認してみてください。


MySQL [wp_database]> select * from wp_options where option_name='siteurl' or option_name='home';
+-----------+-------------+---------------------------------------------------------------+----------+
| option_id | option_name | option_value                                                  | autoload |
+-----------+-------------+---------------------------------------------------------------+----------+
|         2 | home        | http://alb-handson-500587210.ap-northeast-1.elb.amazonaws.com | yes      |
|         1 | siteurl     | http://alb-handson-500587210.ap-northeast-1.elb.amazonaws.com | yes      |
+-----------+-------------+---------------------------------------------------------------+----------+
2 rows in set (0.001 sec)

MySQL を抜けてください。


mysql> exit;

アクセス確認

http://<ALB の DNS 名>/ を開いて、WordPressが表示されることを確認します。

http://<EC2サーバr#1,#2のグローバルIP>/ にはアクセスできなくなっている事を確認します。

両方のサーバにリクエストがバランシングされるか確認

WEB サーバー #1、WEBサーバー #2 のそれぞれにセッションマネージャでログインし、以下のコマンドを実行してアクセスログを表示させることが可能です。

ALB の定期的なヘルスチェックが実行されたり、WordPress でページをリロードするたびに双方の EC2 へアクセスされている状況を確認できます。

# tail -f /var/log/nginx/access.log | grep "favicon.ico"

Ctrl + C で終了

【オプションハンズオン】ALB + Web x 2 + DB x 2 構成（サーバ 4 台構成）

◆拡張性：高

データベースが Multi-AZ 構成になります。Active で動作する DB サーバは変わらず１台ですが、インスタンスタイプの変更時は先にスタンバイ側を変更してからフェイルオーバーする動作になるため変更時の停止時間を短く抑えることができます。

◆冗長性：高

DB サーバがアベイラビリティゾーンにまたがって 2 台構成となり、障害時には自動的にフェイルオーバする構成となり、冗長性が高まります。

Option：RDS を Multi-AZ 構成に変更

本フェーズでの作成範囲

Aurora を Multi-AZ 構成に変更する

[サービス] をクリックし、[データベース] をクリックして [RDS] を選択します。

RDS の管理ページに遷移したら、左側のメニューペインにある [データベース] をクリックします。

作成したデータベースを選択して、[アクション] ボタンから [リーダーの追加] ボタンをクリックします。

[リーダーの追加] ウィザードに遷移するので、[DB インスタンス識別子] を指定します。

ここでは aurora-mysql-db-reader とします。

[接続] のセッションまで進み、アベイラビリティゾーンを [ap-northeast-1c] に変更します。

ページ下部にある [Add reader] ボタンをクリックします。

リーダーインスタンスが追加されるのを待ちます。(約 10 分)

AWS マネジメントコンソールリージョン移動 - 東京

10 分ほど経過すると、対象の Aurora インスタンスが全て [利用可能] のステータスに変わります。

リージョンと AZ が a と c に分かれて 2 ゾーンになっていることを確認してください。

Aurora のフェイルオーバーを実施する

フェイルオーバーする前に事前に各クラスターのIPアドレスを取得し、メモします。

上記のライターインスタンスとリーダーインスタンスのエンドポイントをコピーし、

セッションマネージャーからEC2インスタンスにログインして以下コマンドを実行してください。

ライターインスタンスとリーダーインスタンスの応答されたIPアドレスをメモします。

# dig aurora-mysql-db.cluster-cfqns4hpf8id.ap-northeast-1.rds.amazonaws.com
※上記は例の為、自分のライターインスタンスのDNS名でdigを叩いてください

<省略>

aurora-mysql-db-instance-1.cfqns4hpf8id.ap-northeast-1.rds.amazonaws.com. 5 IN A 10.0.2.247


# dig aurora-mysql-db.cluster-ro-cfqns4hpf8id.ap-northeast-1.rds.amazonaws.com
※上記は例の為、自分のリーダーインスタンスのDNS名でdigを叩いてください

<省略>

aurora-mysql-db-reader.cfqns4hpf8id.ap-northeast-1.rds.amazonaws.com. 5 IN A 10.0.3.253

対象の Aurora のインスタンス側にチェックを入れ、アクションからフェイルオーバーを選択してください。

フェイルオーバーをクリックします。

フェイルオーバー実施後、改めてライターインスタンスとリーダーインスタンスのIPアドレスを改めて確認し、フェイルオーバーによってIPアドレスが変更され、インスタンスが移動している事を確認する。

# dig aurora-mysql-db.cluster-cfqns4hpf8id.ap-northeast-1.rds.amazonaws.com

<省略>

aurora-mysql-db-instance-1.cfqns4hpf8id.ap-northeast-1.rds.amazonaws.com. 5 IN A 10.0.3.253


# dig 
aurora-mysql-db.cluster-ro-cfqns4hpf8id.ap-northeast-1.rds.amazonaws.com

<省略>

aurora-mysql-db-reader.cfqns4hpf8id.ap-northeast-1.rds.amazonaws.com. 5 IN A 10.0.2.247

ハンズオン構築ここまでお疲れ様でした！

ここからは、一旦、WordPress を考慮せずに一般的な更に拡張性を高める方法を解説します。

Web サーバーとしての拡張性

▼ Auto Scaling を実装して負荷調整を自動で行う

Auto Scaling は CPU 負荷やリクエスト数上昇などをトリガーに、需要に合わせてインスタンスを自動で起動したり、削除したりする機能です。

フェーズ2 で作成した Amazon マシンイメージを使って、インスタンスを起動することができます。

▼ 静的コンテンツに Amazon S3 の Web サイト希望を使用する

Amazon S3 はオブジェクトストレージとしてファイルを保存するだけでなく、静的ウェブホスティング html ファイルといった静的コンテンツを使って Web サイトを配信できます。

Amazon S3 は 99.99% の可用性があり、堅牢なサイトを低コストで提供できます。静的ウェブホスティングは s3 バケットのプロパティにあります。

▼ CloudFront でコンテンツをキャッシュする

CloudFront は Web サーバーの前段でコンテンツをキャッシュする CDN (コンテンツデリバリーネットワーク) サービスです。

世界中にある Amazon の Edge サーバーにてコンテンツをキャッシュするので、高速で安全なウェブサイトを提供できます。

ALB の前段に配置することで、ALB と EC2 へのアクセス負荷を軽減することができますし、ALB や EC2 に直接アクセスするルートを遮断して、CloudFront からの経路に限定することでオリジンコンテンツを保護できます。

データベース接続に IAM 認証を利用する

監視を行う

CloudWatchで監視

サードパーティ製品・サービスで監視

CloudTrail で監査ログを残す

本ハンズオンで構築したアーキテクチャでは、複数台構成の WordPress を適切に使用できない点があります。

アップロードしたファイルの表示

アップロードされたメディアファイルは各サーバのローカルに保存されます。

例えば、以下の図のようにユーザーがクライアント PC から写真をアップロードしたとします。このとき、1 台の WordPress サーバーにデータをアップロードされますが、もう一台の WordPress サーバーには写真がない状態になります。

この状態でクライアント PC からブラウザでページにアクセスすると、画像が表示されたり、されなかったりといった不具合が起きます。

AWS マネジメントコンソールサインイン画面

解決法としては以下が挙げられます。

WordPress のプラグインを利用する
「Amazon S3 and Cloudfront」などの WordPress プラグインを使って、メディアファイルを S3 に保管するような仕組みを導入します。
EFS を利用する
Amazon EFS を利用して、各サーバで共有ストレージとしてマウントします。
この方法は読み込みのオーバーヘッドが発生するため、キャッシュ設定を考慮する必要があります。
EBS 間で rsync を実装する
EC2 サーバーで rsync を設定して、別サーバーにデータを送信するようにします。
この場合は、データが削除された場合の考慮が必要です。

サーバー間のアップグレードが同期できない

各サーバーの WordPress 管理画面からプラグイン、テーマのバージョンアップや変更を行えますが、変更内容が各サーバーのローカルディスク上に反映されて、そのサーバー以外の全サーバーに適用されない課題があります。解決方法としては、以下が挙げられます。

Web サーバ間のローカルディスクを同期する仕組みを実装する
例えば、管理機能部分を特定の Web サーバー 1 台に Proxy して、rsyncd + lsyncd で残りのサーバーに配布する方法が考えられます。
ALB のルールで管理画面の URL パス (/wp-admin/*) が含まれた場合はマスターサーバーにルーティングする。といった実装も可能です。
変更したプログラム・コンテンツをイメージとして別途作成してデプロイする方式にする
ゴールデンイメージを作成して、展開する方法です。手間ですが、Auto Scaling を実装する場合は有効です。
Amazon EFS を利用して、各サーバで共有ストレージをマウントする
こちらも読み込みのオーバーヘッドを考慮して、キャッシュ設定を考慮する必要があります。

WordPress の cron 機能が全体で実行されてしまう

ハンズオンで作成したリソースを以下の手順で削除します。そのままにしておくと課金が発生するものがあるため確実に作業を実施してください

EC2 の管理ページから

左ペインよりロードバランサーの管理ページに移動。作成したロードバランサー(alb-handson) を右クリック → 「削除」
同様にターゲットグループの管理ページに移動。作成したターゲットグループ(alb-target) にチェックを入れて、「アクション」 →「削除」
左ペインよりインスタンスの管理ページに移動。作成したインスタンス(handson-ec2-wordpress-1、handson-ec2-wordpress-2) にチェックを入れる。「インスタンスの状態」→「インスタンスを終了」
「インスタンスの状態」が「terminated」になっていることを確認。
左ペインより Elastic IP に移動。使用していた IP アドレス (handson-ec2-wordpress-1) にチェックを入れて [アクション] ボタンから [Elastic IPアドレスの関連付けの解除]
※ Elastic IP アドレスの関連付けを解除できませんでした。が表示された場合は、既に関連付けが解除されています。画面を更新して [Elastic IP アドレスの解放] を選択してください。
左ペインより AMI に移動。作成した AMI (handson-ec2-wordpress-image) にチェックを入れて [アクション] ボタンから [AMI を登録解除] を実施
左ペインより [Elastic Block Store] の下部にある [スナップショット] を選択して移動。作成したスナップショットにチェックを入れて [アクション] ボタンから [スナップショットの削除] を実施

RDS の管理ページから

左ペインのデータベースを選び、リーダインスタンス (aurora-mysql-db-instance-1) にチェックを入れて [アクション] ボタンから [削除] を選択します。本当に削除して良いか確認のため、入力ボックスに、delete me と入力します。(削除は 5 分程度かかります)
ライターインスタンス (aurora-mysql-db-reader) にチェックを入れて、アクションから削除を選択します。バックアップのため、「最終スナップショットを作成しますか?」と表示されますが、今回は不要なのでチェックボックスを外し、「インスタンスの削除後、システムスナップショットとポイントインタイムの復元を含む自動バックアップが利用不可となることを了承しました。」のチェックにチェックを入れて、テキストボックスには delete me と入力して [削除] ボタンをクリック。
ライターインスタンスとリーダーインスタンスが削除されると、リージョン別クラスターも自動で削除が実行されます。
完全に削除が完了すると以下のような表記になります。課金を避けるためにも必ず時間をおいて全ての DB 識別子が削除されていることを確認しましょう。

左ペインのサブネットグループを選び、当ハンズオンで作成した「db-subnet」にチェックを入れて [削除]ボタンを選択します。本当に削除して良いかの確認が出ますので、再度 [削除]ボタンを選択します

IAM 管理ページから

(課金対象ではないので、リソースを再利用したい方は実施しなくても問題ありません)

左ペインより [ロール] を選択します。
検索ボックスにフェーズ1で作成したロール名 handson-ec2-role を入力します。
チェックボックスにチェックを入れて削除をクリックします。
削除を確認するモーダルが開きますので、ロール名を再び入力

VPCコンソールから

(課金対象ではないので、リソースを再利用したい方は実施しなくても問題ありません)

左ペインより [VPC] を選択します。
作成した VPC を選択して、[アクション] から [VPCの削除] を選択します。
VPC 内にあるセキュリティグループ、サブネット、ルートテーブル、インターゲットウェイが同時削除対象として表示されます。
削除して問題なければ入力ボックスに [削除] と入力してから右下の [削除] をクリックして実行してください。

MySQL / MariaDB の root パスワードを忘れた場合の復旧方法

MySQL / MariaDB の root パスワードを忘れた場合は、以下の手順で root パスワードを更新できます。

MariaDB が稼働しているサーバーにログインして、以下の通り、セーフモードで起動します。

# systemctl stop mariadb.service
# mysqld_safe --skip-grant-tables &

MySQL に接続して、root のパスワードを変更します。

$ mysql -u root
> use mysql;
> update user set password=PASSWORD("ここに新しいパスワードを指定") where User='root'; mysql> commit;
> flush privileges;
> ¥q

MariaDB を再起動します。

# systemctl stop mariadb.service
# systemctl start mariadb.service

プロンプトの表示について

セッションマネージャーの黒い画面にて

となっている場合は、root ユーザーに昇格できていません。一般的な操作ではありませんが、本ハンズオンは root に昇格して操作をしてください。

と表示された場合は、root ユーザーに昇格できています。

の場合は mysql コマンドのプロンプトが表示されています。今、どの操作を行なっているのかよく分からなくなった場合は

> exit;

か、または

> \q

を入力して、[ENTER] キーを押下して抜けてください。

セキュリティグループが見つからない場合の対処方法

フェーズ 2 以降でセキュリティグループが表示されなくなった場合 (セキュリティグループを見失った場合) は、セキュリティグループの一覧から VPC ID とセキュリティグループ ID を確認してください。

まず、VPC の管理ページか、EC2 の管理ページにアクセスして左側のペインからセキュリティグループを開きます。

探しているセキュリティグループが見つかりましたら、本ハンズオンで作成した VPC と VPC ID が同一か確認してください。異なる場合は再作成してください。

VPC ID が問題ない場合は、セキュリティグループ ID を控えておき、入力時にセキュリティグループ ID を入力して見つけてください。

準備事項

リージョン

VPCとサブネットについて

パブリックサブネット

プライベートサブネット

インバウンド

アウトバウンド

Network Access Control List

インバウンド

アウトバウンド

IAM ポリシーで必要最小限のみ付与

AWS アカウント (ルートアカウント) の保護

IAM アカウントの保護

ハンズオンの流れ

フェーズ 1

フェーズ 2

Web + DB (サーバー 2 台構成)

フェーズ 3

オプション

最終構成図

【補足】無料利用枠 (個人アカウントでご参加の方向け)

<1年間、以下範囲が毎月無料で利用できます>

スクリーンキャプチャに表示されている情報について

GUI インターフェイスデザインの変更について

コマンドライン

サーバー 1 台構成

拡張性: 低

冗長性: 低

AWSマネジメントコンソールへのログイン

リージョンを変更する (シンガポール)

リージョンを変更する (シドニー)

リージョンを変更する (東京)

デフォルトリージョンを設定する

VPC コンソールにアクセス

VPC ウィザードで VPC コンポーネントを作成する

VPC ウィザード - 全貌

VPC ウィザード - 名前タグ

VPC ウィザード - IPv4 CIDR ブロック

VPC ウィザード - アベイラビリティーゾーン

VPC ウィザード - NAT ゲートウェイ、VPC エンドポイント

ウィザードで作成された VPC を確認

ウィザードで作成されたサブネットを確認

ウィザードで作成されたルートテーブルを確認

EC2 インスタンスにアタッチする IAM ロールを作成する

EC2 コンソールを開く

ステップ1: 名前とタグ

ステップ2: アプリケーションおよび OS イメージ (Amazon マシンイメージ)

ステップ3: インスタンスタイプ

ステップ4: キーペア（ログイン）

ステップ5: ネットワーク設定

ステップ5: ストレージを設定

ステップ6: 高度な詳細

ステップ7: 概要

セッションマネージャー経由で EC2 インスタンスにアクセスする

ユーザーデータで行う処理

セッションマネージャーによる接続

セッションマネージャーによる接続がうまくいかない場合

Elastic IP (EIP) を取得

MySQL と Nginx が動いていることを確認

作成した MySQL の DB 設定に基づき、設定します。

WordPress ログイン画面

WordPress 管理者画面

ブログの起動確認

フェーズ2の作成範囲について

フェーズ2：Web + DB (サーバー 2台構成)

DB 用のセキュリティグループ

DB 用のセキュリティグループを作成

RDS 管理ページを開く

DB サブネットグループを作成

Aurora インスタンスを作成

作成した Aurora インスタンス を確認

作成した Aurora DB への接続確認

EC2 上の MariaDB データをエクスポート

MariaDB からエクスポートしたデータを Aurora にインポート

WordPress の DB 接続設定を削除

WordPressの再設定

フェーズ3 の作成範囲

フェーズ3：ALB + Web × 2 + DB 構成

EC2 管理ページを開く

WEB サーバの AMI 作成

作成した Aurora インスタンスを確認