はじめに

今回ご紹介するハンズオンは実際に弊社新卒社員の研修資料として使用したものです。AWSサービスを使った可用性のあるアーキテクチャを実際に作り、その動作を確認することが目的のハンズオンです。

Amazon EC2を構築したことはあるけど、そこからさらにマネージドサービスであるAmazon RDSやApplication Load Balancer (ALB)を使った可用性のある構成、AutoScalingを用いたスケーラビリティのある構成を組んでみたことがない。興味はあるけど必要な資料を探しつつ1から学んでいくの面倒…。あるいはAWSの人気資格AWS Certified Solutions Architect – Associate (SAA)を目指している方や取得済みの方でも、実際に触ったことがない方が多いのではないでしょうか。
本ハンズオンでは可用性やスケーラビリティといった、AWSのベストプラクティスの柱の1つ『信頼性』にも関連しています。SAAの勉強はもちろん、実業務でもお役に立てる場面が多いかと思いますので、ぜひ！最後まで読んで頂きたいです！！

想定読者

• ハンズオン実施が可能
• PublicまたはPrivate IPアドレスの差がわかる
• SAA取得を目指している
• EC2やRDSなどを実際に構築してみたい
• 可用性のあるアーキテクチャを構築してみたい

今回実現したいこと

• 実用的なWordPress環境を構築する
  1. 単一AZ障害への耐性があること
  2. 管理画面、テーマ有効化、画像添付が問題なく利用出来ること
  3. 負荷上昇に対して自動でスケールすること

目標構成図

今回実現したいことを構成図にしたものです

構成の意図

• 単一AZ障害への耐性があること
• 管理画面、テーマ有効化、画像添付が問題なく利用出来ること
  • 実現方法
    • EC2
      → WEBサーバとして利用する

    • RDS ※ マネージド型のデータベース
      → 作成時にMulti-AZを選択することで簡単に冗長構成を組める

    • ALB ※ マネージド型のロードバランサ
      → 複数のEC2に対してバランシングできる

    • EFS ※マネージド型のファイルストレージサービス
      → 複数のEC2間でデータを共有できる

• サーバ負荷に対し自動でEC2をスケールする
  • 実現方法
    • AWS AutoScaling
      → 今回はサーバ負荷(CPU使用率)を起点としてEC2を自動で増減させる

障害発生時

単一の障害、またはAvailability Zone規模の障害が起きても、問題なくサービスが継続できる構成となります

ハンズオン手順

こちらの手順書(pdf)を参照しながら進めてください。

注意事項

• VPC , EC2 , RDS , EFS , ALB , AutoScaling などが作成できるユーザでログインしている
• 本ハンズオンは構築未経験の方の場合、スムーズに進んでも3時間程度を想定してます
• 今回作成するEC2 , RDS , ALB , AMI , EFS は課金対象です
• EC2 , RDS , ALB は起動時間に応じて料金が発生します
• 長時間作業を中断する際はEC2やRDSは一旦停止することをお勧めします
  ALBに停止機能はない為、長時間中断する場合は一度削除しておくことをお勧めします
• 最後の後片付けも確実に実施お願いします

各リソースの料金について

2022年8月22日現在 ※東京リージョンかつ資料内のサービスを選択した場合
• EC2: 0.0152 USD/h + EBSは3時間～4時間程度なら料金はほぼ発生しません
• RDS: 0.050 USD/h + EBSは3時間～4時間程度なら料金はほぼ発生しません
• ALB: 0.0243 USD/h + 利用に応じて
• EFS: 1GB 0.36 USD/月 + 利用に応じて
  → WordPressデータ＋検証用の画像ファイルとテーマを利用しても1GBも使わない想定

手順書内のポイントやハマりどころ

手順書を見ながらハンズオンを実施して頂きますが、補足や重要なポイント、ハマった箇所などを下記に紹介していきます。

STEP2 ～ネットワークの範囲を作成～

• ネットワークの範囲はVPCの範囲内にサブネットを作る必要がある
• サブネットの中にEC2などのリソースを設置していく

STEP3 ～ ルートテーブルの設定 ～

• サブネットに必ずルートテーブルがある
• 外部との出入口であるInternet Gatewayが含まれている、含まれていないサブネットを使い分ける
  • 割と見落としがちで、これを見落とすと外部と疎通できず原因解明に時間を要する場合がある
  • 外部に晒したくないサーバを意図せず設置する可能性がある

STEP6 ～RDSを作成しよう ～

• 手順書の通りテンプレートは「開発/テスト」を選ぶ
• ストレージタイプが汎用SSD gp2 であることしっかり確認する(IOPSは料金が高い)

STEP8 ～ 構築してみよう ～

• コピーミスがないよう気を付けてください
• コマンド冒頭にある「#」「>」はコピー不要です
• 差分確認にて「-」「+」の差異が手順書記載通りでしたら大丈夫です

STEP11 ～ EFSをマウントしよう ～

• マウント後で「/efs」が出力されていることを確実に確認してください
• P41「サーバ起動時に自動でマウントする」,P43「起動順を変える」を忘れず実行してください
  • EC2再起動時などでEFSを正常に読み込む為に必要です

STEP16 ～ スケーリングを確認しよう ～

• 最後の「負荷収束後の挙動を見てみる」について
  • 1つ前の「サーバ負荷に対しサーバが増加するか確認」実施の際に希望台数が 2 → 3 に上がります
  • 負荷収束してから台数が2になるまで、タイミングもありますが30分程度かかります
  • 待ちきれない場合は手動で希望台数を2に戻してもよいです
    • 作成したAutoScalingグループを選択
    • 詳細タブの「グループの詳細」の編集から希望する台数を2へ
    • 更新

目標構成図からさらに…

今回のハンズオンでは可用性やスケーラビリティのあるアーキテクチャを実際に作成しました。しかしながらこの構成にも課題はあります。例えばEFSを利用していますが、EFSへデータを読みにいく時間はEC2内のデータを読む時間よりどうしても遅くなります。サービスによってはより早いレスポンスを求める場合も出てくるかと思います。その場合はOPcache というキャッシュを利用することで改善する場合があります。詳しくはAWS公式のブログにもEFSを使用したパフォーマンスの最適化について取り上げられてますので、気になる方はご一読いただければと思います！
Amazon EFS を使用して WordPress のパフォーマンスを最適化する
キャッシュといえばAmazon CloudFrontやAmazon S3を使って静的コンテンツを高速化する方法も考えられます。目的によって今の構成からさらに発展させることができます！

また、今回はAmazon RDS for MySQLを利用している都合上、データベースの冗長性はあるものの自動スケールはしない構成です。Amazon Auroraを利用すると Aurora Serverless v2 など、自動でスケールさせる仕組みが利用できますが、負荷の傾向によっては料金面の優劣が異なる為、どちらを利用するかは検討が必要です。

最後に

手順書の後片付けまで無事終わりましたでしょうか。EC2ひとつ作成するにも実際に触ってみることで、VPCやサブネット、セキュリティグループをどう結び付けていくかイメージが付きやすくなるかと思います。知識として理解してはいても、実際に構築してみると思いもよらない箇所が原因で疎通が通らなかったり、意図した通りに連携されなかったりしました。触ってみないとわからないものですねー(経験談)
実際に構築する機会があった時やSAA受験の際に、そういえばあのハンズオンで触ったなーなどお役に立てられれば幸いです。

今後も今更聞けないような基本的なことから、ニッチなポイントなど幅広くご紹介できたらと思います。ここまで読んで下さりありがとうございました！