Lab 5

Lab5：バックアップ・リストア

概要

このラボでは、Amazon Elastic Compute Cloud (Amazon EC2) と Amazon Relational Database Service (Amazon RDS) のバックアップを取得し、別リージョンで AWS CloudFormation を利用してアプリケーション環境全体をリストアします。

目標

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

  • Amazon EC2 インスタンスのバックアップを取得、コピーする
  • Amazon RDS インスタンスのバックアップを取得、コピーする
  • CloudFormation を使用して、アプリケーション環境全体を自動的に構築する
  • 最終的には、次の図で示すようなアプリケーション環境を構築する

前提条件

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

  • Microsoft Windows、Mac OS X、または Linux（Ubuntu、SUSE、または Red Hat）が搭載されているノートパソコンで、Wi-Fi アクセスが可能です
  • ラボ環境には iPad またはタブレット端末でアクセスできませんが、受講者ガイドにはこれらの端末からアクセスできます
  • Microsoft Windows ユーザーの場合は、コンピュータへの管理者アクセスできます
  • Chrome、Firefox、Internet Explorer 11（これより前のバージョンの Internet Explorer はサポートされていません）などのインターネットブラウザが利用できます

時間

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

各タスクへのリンク

Lab5-Task1: DB サーバーのスナップショットを別リージョンへコピー

このセクションでは、DB サーバーのスナップショットを別リージョンへコピーします。

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

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

  3. Lab3 で作成したスナップショット (wpdbbackup-lab3) を選択し、[アクション] から [スナップショットをコピー] をクリックします。

  4. [スナップショットをコピー] ページで以下のように指定します。
    送信先リージョン Asia Pacific (Singapore)
    新しい DB スナップショット ID chapter5
    ターゲットオプショングループ (オプション) 指定なし（デフォルトのまま）
    暗号化 [レ]暗号を有効化（デフォルトのまま）

  5. [スナップショットをコピー] をクリックします。

  6. AWS マネジメントコンソール右上の 東京▼ をクリックして、アジアパシフィック(シンガポール) をクリックします。

  7. コピーした DB スナップショット chapter5 の [ステータス] が [pending] もしくは [作成中] になっていることを確認します。

    ※時間が経過すると、[利用可能]になります。それまでの間に次の Task を進めます。

Lab5-Task2: WordPress サーバーの AMI を別リージョンへコピー

このセクションでは、WordPress サーバーの AMI を別リージョンへコピーします。

  1. AWS マネジメントコンソール右上のリージョンを [シンガポール] から [東京] へ変更します。

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

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

  4. Lab3 で作成した AMI (myAMI-Lab3) を右クリックして [AMI をコピー] を選択します。

  5. [AMI をコピー] ウィンドウで以下のように指定します。
    送信先リージョン Asia Pacific (Singapore)
    名前 myAMI-Lab3
    説明 myAMI-Lab3 copy from ap-northeast-1
    暗号化 [ ] ターゲット EBS スナップショットの暗号化(デフォルトのまま)

  6. [AMI をコピー] をクリックします。

  7. [完了] をクリックします。

  8. AWS マネジメントコンソール右上のリージョンコードを [東京] から [シンガポール] に変更し、コピーしたスナップショットの [状態] が [pending] になっていることを確認します。

    数分程時間が経過すると、[available]になります。それまでの間に次のTaskに進みます。

Lab5-Task3: CloudFormation によるインフラ環境のリストア

このセクションでは WordPress が稼働するためのインフラストラクチャを、CloudFormation を使用してシンガポールリージョンにリストアします。

  1. AWS マネジメントコンソールで、右上のリージョンを 東京 から シンガポール に変更します。

  2. [サービス] から [CloudFormation] をクリックします。

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

  4. ステップ 1. 以下の値を入力します。

    ・テンプレートの準備 : テンプレートの準備完了 を選択 ・テンプレートソース : Amazon S3 URL を選択 ・Amazon S3 URL : https://awsj-tc-training-public.s3.ap-northeast-1.amazonaws.com/psw-v1-1/cfn/psw_lab5_restore_infrastracture.cfn.yml

    ヒント : Amazon S3 URL が画面から見切れていることがあります。先頭の “https://” から末尾の “.yml” まですべてコピーしてください

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

  6. ステップ 2. 以下の値を入力します。

    スタックの名前
    スタックの名前 Infra-Stack
    パラメータ
    EnvironmentName psw-lab5
    S3bucketName *自分の名前(フルネーム)yyyymmdd-lab5 を入力
    例：awstaro20200101-lab5

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

  8. ステップ 3. すべてデフォルトのままにします。[次へ] をクリックします。

  9. ステップ 4. 設定値を確認して、[スタックの作成] をクリックします。

    以上の操作で CloudFormation によって WordPress が稼働するためのインフラストラクチャの構築が開始されました。 通常、3～5 分程度でリストアが完了します。 リストア完了を待たずに次の Task に進んで、リストア中にシンガポールリージョンで何が起こっているのか確認してみましょう。

Lab5-Task4: リストアされた WordPress 環境の確認

このセクションでは、CloudFormation によってどのようにリストアが行われたのか確認していきます。

  1. Infra-Stack のイベント一覧が表示されているはずです。

    更新ボタンを押してください。 イベント一覧が表示されていない方は [サービス] > [CloudFormation] > 画面左側のナビゲーションペインの [スタック] > [Infra-Stack] > [イベント] タブの順にクリックしてください。

  2. イベント一覧を参照すると、様々な AWS リソース(VPC、ALB、Security Group)が次々に作成されている様子が表示されています。

    これらの AWS リソースは Lab4 終了時点の東京リージョンの WordPress 環境とほぼ同一です。 つまり、Lab1 ～4 で行ってきた手動操作を、CloudFormation がシンガポールリージョンで みなさんに代わって、自動的に実行 していることになります。

  3. [テンプレート] タブをクリックしてください

  4. CloudFormation Template が表示されます。

    これは、Task3 で CloudFormation の作成時に指定した URL からダウンロードされたファイルに記載されている内容です。 CloudFormation Template には"各種 AWS リソースが、最終的にどのような設定になっているか" という状態 (設定値) が記載されています。CloudFormation は、このテンプレートに従って AWS リソースを作成しています。

  5. [デザイナーで表示] をクリックします。

  6. CloudFormation Template に記載されている AWS リソース群の論理的な関係性が図として表示されています。 AWS リソースのアイコンをクリックすると、CloudFormation Template でどのような設定になっているのか参照できます。

  7. [閉じる] をクリックします。

    “このサイトを離れますか？” というポップアップが表示される場合は このページを離れる をクリックしてください。

Lab5-Task5: CloudFormation による WordPress のリストア

このセクションでは Task1、2 でコピーした WordPress サーバー の AMI と DB サーバーのスナップショットを使用し、CloudFormation によってアプリケーション環境をリストアします。

  1. AWS マネジメントコンソールで、右上のリージョンを 東京 から シンガポール に変更します。

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

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

  4. Lab3 で作成した AMI (myAMI-Lab3) を選択します。

  5. [詳細] タブの AMI ID をコピーして、エディタにメモしておきます。 AMI ID は ami-070a7dce069154321 のような文字列です。

  6. [サービス] から [CloudFormation] をクリックします。

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

  8. [Infra-Stack] が CREATE_COMPLETE になっていることを確認してください。 “CREATE_COMPLETE” になっていない場合は、1-2 分ほど待ってからリロードボタンをクリックしてください。

  9. [スタックの作成] > [新しいリソースを使用] をクリックします。

  10. ステップ 1. 以下の値を入力します。

    ・テンプレートの準備 : テンプレートの準備完了 を選択 ・テンプレートソース : Amazon S3 URL を選択 ・Amazon S3 URL : https://awsj-tc-training-public.s3.ap-northeast-1.amazonaws.com/psw-v1-1/cfn/psw_lab5_restore_app-db.cfn.yml

    ヒント : Amazon S3 URL が画面から見切れていることがあります。先頭の “https://” から末尾の “.yml” まですべてコピーしてください

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

  12. ステップ 2. 以下の値を入力します。

    スタックの名前
    – スタックの名前 AppDB-Stack
    パラメータ
    – EnvironmentName psw-lab5（デフォルトのまま）
    – InfrastructureStackName Infra-Stack（デフォルトのまま）
    – WordPressAmiID Task2 でコピーした AMI ID を入力
    例：ami-0ee439d98f6612345
    – DBSnapshotID chapter5（デフォルトのまま）

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

  14. ステップ 3. すべてデフォルトのままにします。[次へ] をクリックします。

  15. ステップ 4. 設定値を確認して、[スタックの作成] をクリックします。

    以上の操作で CloudFormation による WordPress サーバー（Auto Scaling で稼働する EC2 インスタンス）とデータベース（RDS DB インスタンス）のリストアが開始されました。

    通常、20～30 分程度でリストアが完了します（RDS の Multi-AZ 配置に 20～25 分を要します） CloudFormation の実行完了を待たずに、次の手順に進んでください。

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

  17. 左側のナビゲーションペインで [インスタンス] をクリックします。 EC2 Auto Scaling によって、EC2 インスタンスが起動するまで、更新ボタンをクリックしながら待ちます。 AppDB-Stack 作成開始から 4 ～ 5 分程度で EC2 インスタンスが起動してくるでしょう。

  18. [サービス] から [CloudFormation] をクリックします。

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

  20. [Infra-Stack] をクリックします。

  21. [出力] タブをクリックします。

  22. [キー] 列で WordPressReadme を探し、右側の [値] 列に記載れている URL をクリックします。

    以下は URL の例になります。
    http://WordPressLB-55192789.ap-southeast-1.elb.amazonaws.com/readme.html/

    ヒント : WordPressのReadme ページが表示されない場合は、CloudFormation > AppDB-Stack > イベント にて 論理 ID “AutoScalingGroup” のステータスが “CREATE_COMPLETE” になっているか確認してください。確認できない場合は数分お待ち下さい。

    【考えてみよう!】 現在の状態で、シンガポールリージョンの WordPress 環境にアクセスすると、ブログは参照できますか？ ブログを参照するには、CloudFormation > Infra-Stack > 出力 > WordPressToppage の URL をクリックしてください

    ヒント：WordPress は データベースにブログのデータを格納しています。そして、Lab1 の WordPress の初期設定時に、接続先のデータベース情報 (DB サーバーのホスト名、ポート番号、データベース名など) を WordPress サーバーのローカルファイルに保持しています。

Lab5-Task6: WordPress の接続先データベースの変更

このセクションでは、WordPress がアクセスするデータベースを変更します。

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

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

  3. chapter5 をクリックします。

  4. [接続とセキュリティ] の エンドポイント をエディタにメモします。

    DB エンドポイントの例: chapter5.coj06nchnabc.ap-southeast-1.rds.amazonaws.com

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

  6. 左側のナビゲーションペインで、[インスタンス] をクリックします。 EC2 インスタンスが 1 台起動しています

  7. 起動しているインスタンスの、左のチェックボックスをクリックします。

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

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

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

  11. 次のコマンドを実行し、ec2-user として操作を行います。 Session Manager 上でのペーストは “Ctrl” + “Shift” + “v” の 3 つのキーを同時に押します。

    sudo su ec2-user
cd
pwd

  12. WordPress の設定ファイル “wp-config.php” を、ファイル名 “wp-config.php.old” としてバックアップします。

    sudo cp /var/www/html/wp-config.php /var/www/html/wp-config.php.old

  13. wp-config.php を nano (エディタ) で開きます。 vi など他のエディタを使い慣れている方は、適宜お好みのエディタを利用してください。

    sudo nano /var/www/html/wp-config.php

  14. nano で wp-config.php を編集します。

    ・データベースホスト名を、東京リージョンの DB エンドポイントからシンガポールリージョンの DB エンドポイントに書き換えます。 ・F6 キー を押してから chapter1 と入力してください。東京リージョンの DB エンドポイントの記載箇所にジャンプします。 ・Task6 Step4 でコピーしたシンガポールリージョンの DB エンドポイントに書き換えます。

    変更前）chapter1.<ランダム文字列>.ap-northeast-1.rds.amazonaws.com
変更後）chapter5.<ランダム文字列>.ap-southeast-1.rds.amazonaws.com

    ・Ctrl+x キー、y キー、Enter キーの順に押して、ファイルを保存します。

  15. wp-config.php をバックアップファイルと比較して、データベースホスト名が書き換わっていることを確認します。

    sudo diff -u /var/www/html/wp-config.php.old /var/www/html/wp-config.php

  16. 設定を反映させるため、Apache httpd をリロードします。

    sudo systemctl restart httpd.service

Lab5-Task7: ブログサイトの動作確認

このセクションでは、リストアした ALB の DNS 名にブラウザでアクセスし、WordPress の動作を確認します。

  1. [サービス] から [CloudFormation] をクリックします。

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

  3. [Infra-Stack] をクリックします。

  4. [出力] タブをクリックします。

  5. [キー] 列で WordPressToppage を探し、右側の [値] 列に記載されている URL をクリックします。

    以下は URL の例になります。
    http://WordPressLB-55192789.ap-southeast-1.elb.amazonaws.com/

  6. 以前に投稿した記事が確認できれば、WordPress サーバーと DB サーバーのリストアは完了です。

    【考えてみよう!】 ここまでの操作で、シンガポールリージョン (ap-southeast-1) の WordPress 環境のブログが参照できるように思えます。しかし、ブラウザのアドレスバーには "ap-northeast-1" と東京リージョンを示す URL が表示されているはずです。 表示されているブログのデータ (テキスト文章や画像) はどこに保存されていますか？

Lab5-Task8: WordPressアドレス、サイトURLを変更する

このセクションでは、リストアしたロードバランサー (ALB) の DNS 名にブラウザでアクセスし、Blog 投稿時の動作を確認します。

これまでの設定で、シンガポールリージョンの WordPress サーバー と DB サーバーの SQL 接続はできるようになりましたが、WordPress の “WordPress アドレス” と “サイトURL” が東京リージョンのままなのでリダイレクトされてしまいます。 WordPress の設定をシンガポールリージョン用に変更しましょう。

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

  2. 左側のナビゲーションペインで、[インスタンス] をクリックします。 EC2 インスタンスが 1 台起動しています

  3. 起動しているインスタンスの、左のチェックボックスをクリックします。

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

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

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

  7. 次のコマンドを実行し、ec2-user として操作を行います。
    Session Manager 上でのペーストは “Ctrl” + “Shift” + “v” の 3 つのキーを同時に押します。

    sudo su ec2-user
cd
pwd

  8. 次のコマンドで RDS DB インスタンスに接続する。

    mysql -u wpuser -p -h RDSのDBエンドポイント

    以下がコマンドの例です mysql -u wpuser -p -h chapter5.cj4gyof9abc5.ap-southeast-1.rds.amazonaws.com

  9. Lab1 で設定した DB ユーザ “wpuser” のパスワードを入力します。 手順通りに実施している場合は、wppassword です。

  10. 次の SQL を実行します。

    USE wordpress;
SELECT option_value
FROM wp_options
WHERE option_name = 'siteurl' or option_name = 'home';

    東京リージョンの ALB の DNS 名が表示されました。

  11. 次のコマンドをテキストエディタにコピーします。 “シンガポールの ALB の DNS 名"を書き換えて、次の SQL を実行します。

    UPDATE wp_options set option_value = 'http://シンガポールのALBのDNS名'
WHERE option_name = 'siteurl' or option_name = 'home';

    上記 SQL コマンドを実行すると、WordPress の “WordPress アドレス” と “サイトURL” を書き換えます。

    このオペレーションは、Lab2b で EC2 インスタンス単体の環境から、ALB を利用した環境に変更する際にも実施しました。 先程、シンガポールリージョンの WordPress へアクセスするとリダイレクトされたのは、 WordPress アドレス、サイト URL が東京リージョンの ALB を指していたためです。

  12. 次の SQL を実行し、WordPress アドレス、サイト URL が変更されていることを確認します。

    SELECT option_value
FROM wp_options
WHERE option_name = 'siteurl' or option_name = 'home';

  13. [サービス] から [CloudFormation] をクリックします。

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

  15. [Infra-Stack] をクリックします。

  16. [出力] タブをクリックします。

  17. [キー] 列で WordPressAdmin を探し、右側の [値] 列に記載れている URL をクリックします。

    サイトの URL は、http://<シンガポールリージョンの WordPressLB の DNS名>/wp-admin となっています。

    以下は URL の例になります。
    http://WordPressLB-55192789.ap-southeast-1.elb.amazonaws.com/wp-admin

    WordPress アドレス、サイトURL を変更したので、東京リージョンにはリダイレクトされません。

    Lab1 で設定した WordPress 管理者ユーザ名とパスワードを入力して管理者ページにログインしてください。 WordPress 管理者 ID・パスワードは、手順通りに進めている場合 ユーザ名：admin パスワード：(名前) + (今日の日付) + !（例: Suzuki20210115!） です。

    WordPress の管理者 (admin) パスワードを忘れてしまった場合は こちらをクリック して復旧させましょう。

Lab5-Task9: ブログ画像のアップロード先を変更する

このセクションでは、リストアした WordPress がブログ画像をシンガポールリージョンの S3 Bucket へ格納するようにします。

  1. 管理者画面の左下の [設定] > [Offload Media Lite] > [Bucket] > [Change] を選択します。

  2. [Browse existing buckets] をクリックします。

  3. Task3 で入力した S3 バケットを選択します。 S3 バケット名の末尾が”-lab5"になっているはずです。

  4. [Save Selected Bucket] をクリックします。

  5. ブログを新規投稿して、画像の保存先を確認します。

    【考えてみよう 1】 CloudFormation によってネットワーク、サーバー、ミドルウェア、アプリケーションのリストアは自動化できました。 しかし、Task6～9 で実施したように各種 Configuration の一部は、手動での修正が必要になりました。 何が要因となって、手動での修正が必要になってしまったのでしょうか？　手動での修正を最小化する工夫はできないでしょうか？

    ヒント：Lab3 で ”値” そのものと、“値” を利用した設定を分離していませんでしたか？ そのようなアプローチの適用範囲を広げられませんか？

    【考えてみよう 2】 ここまでの設定で新規ブログ投稿はシンガポールリージョンに保存されることになりました。 リストアをより完全な形にするためには、どのような変更が必要ですか？

    ヒント：可用性の向上、”シンガポールリージョン以外に存在しているデータ” 等を考慮してみましょう！

Lab5-Challenge Task1: WordPressサーバーの可用性向上

このタスクでは、シンガポールリージョンで稼働している WordPress サーバーの可用性を向上させます。 これまでのタスクと異なり、詳細な手順はありません。Lab1 ～ Lab5 で学んだ知識と経験を使って解決してみましょう。

  1. 以下の条件を満たすように、WordPress サーバーを 1 台から 2 台に増やして高可用性構成にしてください。

    • それぞれの WordPress サーバーは異なる AZ に配置される
    • WordPress サーバーへの高い負荷が一定の期間継続すると、3 台目、4 台目の WordPress サーバーが自動的に生成される
    • WordPress サーバーへの低い負荷が一定の期間継続すると、WordPress サーバーは自動的に停止 (terminate) される。ただし、最低でも 2 台の WordPress サーバーは維持される
    • どの WorsPress サーバーにアクセスしても、Blog コンテンツをシンガポールリージョン上で参照、投稿する事ができる。

終了

このラボでは、Amazon EC2 と Amazon RDS のバックアップを取得し、別リージョンで CloudFormation を利用してアプリケーション環境全体をリストアしました。

お疲れさまでした。これで Lab5 は終了です。

補足：WordPress の管理者用パスワードの復旧手順

  1. Web Server01 に Session Manager でログインする。

  2. 次のコマンドで RDS に接続する。

    mysql -u wpuser -p -h  RDSのエンドポイント

    DB エンドポイントはお手元のメモを参照してください DB の password は手順通りに設定してある場合はwppasswordです。

  3. 次の SQL コマンドを実行する。

    show databases;
use wordpress;
select user_login, user_pass from wp_users;
update wp_users set user_pass = md5('NEWPASSWORD') where user_login = 'admin';

    NEWPASSWORD の箇所を、任意の文字列に置き換えて下さい。

  4. こちらをクリック して、もとの Task に戻る