AWS学習の第2弾として以下の内容で試験的にLAMPアプリを構築してみました！

目次

HLD
・プロジェクト名
・目的
・対象ユーザー
・全体構成概要
・使用サービス一覧
・ユースケース
・非機能要件
・想定トラフィック
・成果物

簡単な作業概要

エラー発生ポイント

感想・改善案

次回予告

プロジェクト名

LAMPアプリ構築

目的

Webアプリ開発の為のLAMPアプリの構築（EC2 + ALB + RDS + VPC + Auto Scaling）

対象ユーザー

Webアプリ開発者（user）
LAMPアプリの管理者（Admin）

全体構成概要

ALB → EC2(Auto Scaling) → RDS、VPCにて全体を管理

使用サービス一覧

EC2　仮想サーバーの構築・管理
ALB　 Webサイトへのトラフィックの負荷分散用のロードバランサー
RDS　 RDBのセットアップ、運用、スケーリング、バックアップ等を自動化
VPC　 AWS上での仮想ネットワークのサブネット構成やグループによるアクセス制御
Auto Scaling　サーバー負荷に応じて、自動的にクラウドサーバーの増減を行う

ユースケース

ユーザーがWebブラウザからEC2にアクセス
リクエストはALBに到達し、負荷分散の上EC2インスタンスへ転送
EC2はPHPアプリケーションを実行し、データはRDSから取得
高負荷時はAuto ScalingによりEC2を増減させる

非機能要件

可用性　　　　　Auto ScalingおよびRDSのAZ切り替え機能による冗長構成
コスト最適化　　 Auto Scalingでの環境の最適化によるコスト削減
セキュリティ　　VPCによりパブリック／プライベートを分離し、アクセス制御を実現
拡張性　　　　　Auto ScalingおよびVPC構成により拡張に柔軟に対応

想定トラフィック

低トラフィック（テスト環境）

成果物

開発及び公開が可能なWebアプリを作成するための基盤

簡単な作成概要

① VPC作成 --------------
1つのカスタムVPCを作成（名前：vpc）
パブリックサブネット（ALB, EC2用）＋プライベートサブネット（RDS用）
NAT Gatewayはコスト削減のためなし

② RDS（DB）作成 --------------
プライベートサブネットに配置（インターネット非公開）

③ EC2（Webアプリ）作成 --------------
パブリックサブネットに配置
ALB経由でHTTPトラフィックを受け取る
Elastic IPにてパブリックIPv4を設定

④セキュリティグループの作成と設定 --------------
EC2用セキュリティグループ（HTTP、HTTPS、SSH対応の無制限のアクセス）
RDS用セキュリティグループ（SSH、MySQL通信対応、SG - EC2-WebSGからのみのアクセス）
それぞれをRDSとEC2に設定

⑤ ALB作成 --------------
パブリックサブネットに配置
EC2をターゲットに登録（ターゲットグループにEC2のIDを追加）
ドメインはALBのDNS名

⑥SSHを行うための準備 --------------
PCのコンソールからEC2作成時にダウンロードした.pemファイルを使い、
SSH認証カギを登録
ユーザーにてRDBに設定したIPアドレスを用いSSHを行い、echoにて文字列を保存

⑦ 確認ポイント --------------
外部アクセスはALB経由（http://）でアクセス
シークレットモードからRDSに接続できる（⑥で保存した文字列が表示される）ことを確認

エラー発生ポイント

②でのRDS作成時エラー発生
エラーメッセージ：
The DB subnet group doesn't meet Availability Zone (AZ) coverage requirement. Current AZ coverage: us-east-1a. Add subnets to cover at least 2 AZs.
訳：DBサブネットグループがアベイラビリティゾーン（AZ）カバレッジ要件を満たしていない。
現在のAZカバレッジ：us-east-1a。少なくとも2つのAZをカバーするようにサブネットを追加してください。
→最初に行ったVPCの構築では、AZを一つにして設定を行っていたが、
　RDSの作成のためには、最低二つのAZが無ければエラーが出るらしい
　再度AZを二つにしてVPCを作り直し、エラー解消

⑦にてALBのドメインを利用して検索すると502エラーが発生
→REC2作成時にパブリックIPv4アドレスの設定ができておらず、通信が正常に行われなかったことが原因
Elastic IPにて対象のネットワークボーダーグループにパブリックIPv4を設定し事象が改善。
　

感想

今回は事前に学習していたCCNAおよび、Linux関連の知識がかなり活きた構築だったのかなと
具体的には、サブネット関連の話であったり、ネットワークインターフェースの設定
linux関連の知識では、SSH認証カギの登録等
エラーもエラーが発生したのちに、作った環境を見返すとおかしい所がすぐに見つかったので、構築中は特に苦労していませんでした。
ただ、事前に知識がないと、詰まる部分が多いのかなといった印象だったかと思います。
今回は踏み台環境を用意することが面倒で私用PCのPowerShellで確認を行ったのですが、
PowerShellでの作業は意外とコマンドの記憶に頼る部分が多く、特にディレクトリ移動など基本操作に手間取りました。次回からは専用の踏み台を用意して、Linux環境にて作業効率を上げたいと思います。

改善案

感想にも書きましたが踏み台を用意する！
わかる方ですと作成概要の順番が少しづつおかしかったと思います。
セキュリティグループを後で作っていたり、EC2作成時にパブリックIPv4アドレスを振っていなかったり、
構築する内容は事前に決めていて、どこを外部ネットとつなげるか等もすべて決めていたのにこれでした。
途中で気づいたのはよかったものの、次回からは先に作っておくと、設定がスムーズに進みますね。
理想の構築順序：

VPC・サブネットの作成（2AZ分）
セキュリティグループの設計
RDSの作成（プライベートサブネット）
EC2の作成（パブリック＋Elastic IP）
ALBの構成とターゲットグループへの登録
動作確認とデバッグ

今回はALBのドメインを直接入力しましたが、前回のRoute53にて、固有ドメインと
ALBのドメインを紐づけることによって、固有ドメインにて閲覧できるようにすることも
できるようです。（前回はCloud Flontにて固有ドメインを使うためには、httpsを利用する必要があり証明書を発行しましたが、今回の場合はALBをhttpで利用することができるため、証明書の発行はいらないとのこと）

次回予告

CRUD APIを構築予定です！
軽く調べた感じユーザー関連の基本操作を提供するものらしい？
もし興味がございましたら、次回もご覧いただければと！