【AWS勉強】EC2+RDSを使った基本構成を構築してWordPressを立ち上げてみる。その1
まずは勉強の手始めとして、EC2+RDSを使ってWordPressを立ち上げてみたいと思います。アプリケーションサーバ+データベースサーバという、WEBでは最も基本的な構成ですね。
私も仕事でAWSを少しは触ったことがあるとはいえ、一から構築はしたことはありません。実際のところDBも普通にEC2インスタンスにMySQLをインストールして運用していたので、何気にRDSを使ったこともなかったりします。まあ、言ってしまえば初心者レベルですね。
とはいえEC2?RDS?VPC?といったド素人レベルでもないわけですが、せっかくなので「AWSを使うのはホントに初めて」くらいの人も意識して、捕捉を入れながら説明してみたいと思います。
構成図
細かい部分は置いておくとして、まずは作ろうと思っている構成を説明したいと思います。今回は図の様にパブリック用のサブネットとプライベート用のサブネットを用意して、WordPressを動かします。この図を見て何をする必要があるのかパッと挙げられる人は、初心者レベルはクリアしてると言っても良いのではないでしょうか。
では早速ですが、構成と利用するサービスについて触れていきたいと思います。用意するサーバは2つです。
EC2は仮想ホストを作る事が出来るサービスです。簡単に言えば管理画面からポチポチするだけでサーバが用意できるサービスですね。OSも様々なものから選べます。
EC2のインスタンス(仮想サーバ)を1つ用意して、WordPressが動く環境を作ります。また、Wordpress用のデータベースをとしてRDSを利用して、MySQLを立ち上げます。
RDSは(リレーショナル)データベースの立ち上げに特化したサービスです。EC2を使って自分でMySQLを運用することもできますが、RDSならセットアップやスケール、バックアップ、冗長化などが非常に手軽に出来るようになっています。さらにAWSが独自開発したMySQL互換のDB「Amazon Aurora」が使えるのも大きな特徴です。
ネットワークはVPCを利用して作ります。VPCはアカウントごとに独立した仮想論理ネットワークで、他のアカウントやAWS自体のネットワークに影響を受けません。
今回は10.0.0.0/16のVPCを用意します。実際にホストが参加するネットワークは図のように、別途サブネットとしてVPCの中に作ります。
役割 | サブネット |
---|---|
public netowrk | 10.0.1.0/24 |
private network | 10.0.2.0/24 |
WANに足を持つサブネットとして10.0.1.0/24、プライベート用のネットワークとして10.0.2.0/24を用意します。同一のVPCの中にあるサブネット(に所属するホスト)同士は、特に意識せずともルーティングが追加されお互いに疎通がとれるようです。
ただしWANに足を持つといっても10.0.1.0/24はプライベートなアドレスです。当然その中にあるインスタンス(仮想ホスト)に割り当てられるアドレスも、プライベートなアドレスとなってしまいます。これはAWSの制約なのですがグローバルIPを直接インスタンスに割り振ることはできないようです。
では、どうやってWANにつなぐのかというと、やり方は大きくわけて2通りあるようです。(ELBを使うなど他にも方法はあるかも)
前者の方法はグローバルIPを用意し、EC2インスタンスのプライベートアドレスにNATをする方法です。ユーザから直接アクセスを受けるAPサーバはこの方法を使ってインターネットと接続します。
Elastic IPがNAT用のグローバルIPを提供してくれるサービス、インターネットゲートウェイはインターネット接続するための(デフォルト)ゲートウェイを用意してくれるサービスです。
後者の方法はNATゲートウェイを作って外とアクセスする方法です。ユーザからアクセスを受ける必要がなく、サーバから外に出る必要がある場合に利用できます。例えばyumでインストールを行う場合などに必要ですね。
以前はNAT用のインスタンスを立ち上げゲートウェイにするしかなかったようですが、2015年12月よりマネージドなNATゲートウェイサービスも開始されているので、今はこちらを利用するのがベストプラクティスではないでしょうか。
プライベートなネットワークにあるDBサーバなどは、WANのアドレスは振らずNATゲートウェイを通して外に出るのが一般的でしょう。今回の場合であればRDSインスタンスが該当しますね。
さて、おおまかな構成はこの辺りにして実際に構築する手順を説明していきたいと思います。
ネットワーク(VPC・サブネット)の作成
まずはAPサーバ(EC2)、DBサーバ(RDS)用のネットワークを作成です。
EC2インスタンスもRDSインスタンスもネットワークに所属しなければ何もできないので、インスタンスを作る前にVPC作成しておく必要があります。
やるべき作業は大まかに4つです。
それでは順番に見ていきましょう。
VPCを作成する
まずはVPCを作成します。VPCは仮想スイッチ、この後作るサブネットはVLANだと思えば概念的には近い気がします。
AWSのマネージメントコンソールにログインして、左上の「メニュー」から「VPC」を選びます。
左のサイドバーメニューの中から「VPC」を選びます。
上のメニューから「VPCの作成」を選びます。
必要なパラメータを入力します。今回は以下の様にしました。
テナンシーではデフォルトの他に「ハードウェア専有」を選ぶ事ができます。AWSは基本的に仮想ホストが使われるため、一つの物理サーバに複数の企業のインスタンスが生成される可能性があります。コンプライアンス上、他社と物理的に同居が出来ない場合などに利用されるようです。
作成したVPCに属するサブネット3つを作成する
作成したVPCに属するサブネットを3つ作ります。
具体的にはAPサーバ用(10.0.1.0/24)1つと、DBサーバ用(10.0.2.0/24, 10.0.3.0/24)2つです。表にしてまとめると以下の通りです。
Name tag | CIDR block | アベイラビリティーゾーン | 用途 |
---|---|---|---|
vpc-wordpress-subnet1 | 10.0.1.0/24 | ap-northeast-1a | APサーバ |
vpc-db-subnet1 | 10.0.2.0/24 | ap-northeast-1a | DBサーバ |
vpc-db-subnet2 | 10.0.3.0/24 | ap-northeast-1c | DBサーバ |
アベイラビリティーゾーン(略してAZ)は一言でいえば物理サーバの(置かれているデータセンタの)場所ですね。ap-northeast-1aは東京に当たります。AWSは東京以外にも世界各地にデータセンタがあります。
そのため、マルチAZ(複数のアベイラビリティゾーンを利用して)でシステムを構築することで、たとえ1つのAZが完全にダウンしたとしてもサービスを続けられます。
マルチAZによる冗長性は、AWS上でのシステム構築のベストプラクティスとされています。
今回の構成図には10.0.3.0/24はありませんでしたが、RDSを利用するにはマルチAZ用に、異るAZに属するサブネット2つを用意する必要があります。
なので、実際には利用しませんがDB用のサブネットを2つ作成し、この2つのサブネットは「1a」「1c」と異なったAZを指定してあります。
前置きが長くなりましたが、例としてvpc-wordpress-subnet1(10.0.1.0/24)のサブネットを作る手順を説明したいと思います。
左のサイドバーメニューの中から「サブネット」を選びます。
上のメニューから「サブネットの作成」を選びます。
必要なパラメータを入力します。
- ネームタグ: vpc-wordpress-subnet1
- VPC: vpc-xxxxxxx|vpc-wordpress
- アベイラビリティーゾーン: ap-northeast-1a
- CIDRブロック: 10.0.1.0/24
VPCには先程作った vpc-wordpress を選択します。
vpc-db-subnet1、vpc-db-subnet2の2つも同様の手順で作成すればOKです。
インターネットゲートウェイを作成し、VPCにアタッチする
次はインターネットゲートウェイの作成と、ルートテーブル(ルーティング)の編集をします。
物理ネットワークの場合と同じで、WANに疎通のあるルータを用意してデフォルトゲートウェイを指定する感じです。
本来ならホスト毎にルーティングを設定しないといけない所ですが、AWSではVPC単位でルーティングを制御するようです。この辺りは少し慣れが必要そうですね。
左のサイドバーメニューの中から「インターネットゲートウェイ」を選びます。
上のメニューから「インターネットゲートウェイの作成」を選びます。
必要なパラメータを入力します。
- ネームタグ: igw-wordpress
インターネットゲートウェイは作成しただけでは意味がなく、VPCにアタッチする必要があります。
物理ネットワークで言えば、ルータを既存のネットワークにLANケーブルでつなぐイメージでしょうか。
上のメニューから「VPCにアタッチ」を選びます。
アタッチ先として、さきほど作った vpc-wordpress を選択します。
必要なルートテーブルを作成し、各サブネットに割り当てる
アタッチしたインターネットゲートウェイを通して外への疎通が出来る様にします。
左のメニューから「ルートテーブル」を選択します。
VPCを作成した時点で既にvpn-wordpressに関するルートテーブルが出来ているので選択します。
さらに下の窓の「ルート」タブを押し、「編集」を選択します。
インターネットゲートウェイをデフォルトルートとするルーティングを追加します。
ターゲットはIPアドレスで指定する必要はなく、インターネットゲートウェイの名前で指定します。
ターゲットのフォームをフォーカスすると選択肢が表示されるので、特にメモをしておく必要もありません。
続いてルートテーブルとサブネットの紐付けをします。
下の窓の「サブネットの関連付け」から「編集」を押します。
WANからのアクセスを受けるのはAPサーバのみなので、vpc-wordpress-subnet1にのみチェックをいれ保存を押します。
これでWANに出るためのルーティングに関してもOKです。
vpc-db-subnet1, vpc-db-subnet2に関しては「10.0.0.0/16 local」のみを持つルートテーブルを別途作成し、同様の方法で関連付けすればOKです。
これでネットワークの設定に関しては終了です。
EC2インスタンスの準備
ネットワークが出来たのでAPサーバ用のEC2インスタンスを作っていきます。
まずはサービスから「EC2」を選択します。
画面中央下の「インスタンスの作成」を選択します。
ステップ 1: Amazon マシンイメージ(AMI)
まずはAMI(Amazonマシンイメージ)の選択画面が表示されます。
AMIはインスタンス上に展開されるOSのイメージファイルです。
アプリケーションも含めたOSの初期テンプレートファイルだと思えばいいでしょう。
AWSが用意した物の他にも、自分で作成したもの、サードパーティー(企業)が用意したもの、他のAWSユーザ公開しているものなどから選べます。
今回はスタンダードなAmazonLinuxのAMIを選択します。
ステップ 2: インスタンスタイプの選択
次に「インスタンスタイプ」を選択します。
インスタンスタイプごとに仮想マシンのスペックや、利用料金が異なります。今回は「t2.micro」を選びます。
ステップ 3: インスタンスの詳細の設定
続いてインスタンスの詳細を設定します。様々な設定項目がありますが、今回は基本的にデフォルトのままで進めます。
VPCとサブネットの設定のみ先程作った「vpc-wordpress」「vpc-wordpress-subnet1」を選ぶ様に変更します。
これで今から作るインスタンスは先程作ったVPCネットワーク内に作られる事となります。
ステップ 4: ストレージの追加
次にAMIをインストールするストレージを選びます。AWSではEC2インスタンスが直接ストレージ(SSD・HDD)をマウントするわけではなく、EBSと呼ばれるストレージをネットワーク越しに接続して利用します。
EBSは自動的にレブリカが作られるため可用性が高いだけでなく、容量を拡張したりスナップショットを取ったりと、一般的な物理ストレージで悩みどころとなる点を解決してくれる、様々な便利 が備わっています。
今回はデフォルトのまま8GBのストレージを利用します。
ステップ 5: Add Tags
次にタグの追加を行います。タグはEC2インスタンスの管理をしやすくするためのメタ情報ですね。
Nameに「ap-wordpress1」を入力しておきます。
ステップ 6: セキュリティグループの設定
次はセキュリティーグループの設定です。
セキュリティーグループはインスタンスへのin,outをネットワーク、ポート単位で制御できるAWS独自のファイアウォール機能ですね。
言ってしまえば複数インスタンスにまとめて設定できるiptablesって感じでしょうか。結構便利な機能です。
WEBアプリケーション向けにセキュリティグループを一つ新規作成しておきます。次回から似た用途のインスタンスを作成した場合は、同じセキュリティーグループを適用すればOKです。
新規作成する場合、最初からSSHは許可されてます。今回はpingでの確認とWEBサーバとして動かすためのルールを追加しておきます。
最後に作成するインスタンスの設定確認画面が表示され、作成を行おうとするとSSHキーの選択画面(新規作成画面)が表示されます。
作成はキーペア名を入力して「キーペアのダウンロード」ボタンを押すだけです。
ボタンを押すとpemファイル(秘密鍵)がダウンロードされます。公開鍵は自動的にインスタンスに配置されるので、特に何かをする必要はありません。
これでAPサーバ用のEC2インスタンスの作成は終了です。
WANからアクセス出来るようにする
APサーバ用のインスタンスはできましたが、今のままではグローバルIPがなく、WANに疎通が取れない状態です。もちろん、HTTPでのアクセスも、SSHでのアクセスも出来ません。
そこで、Elastic IPを利用してグローバルIPを紐付け、SSHでアクセスをしてみます。
まずは左メニューから「Elastic IP」を選択します。
最初は利用できるグローバルIPが0個なので、AWSからアドレスを割り当ててもらう必要があります。
「新しいアドレスの割当」を選択します。
割当が終了すると取得済みのアドレス一覧が表示されます。取得したアドレスはまだどのインスタンスにも紐付いていないので、先程作ったEC2インスタンスにアタッチする必要があります。
一覧から取得アドレスにチェックを入れ、上のメニューから「アドレスの関連付け」を選択します。
アタッチするインスタンスを選択します。
インスタンス名とIPアドレスを選択する必要がありますが、プルダウンで選択する事が出来るのでさほど手間ではないはずです。
これでWANからSSHでのアクセスが可能となっているはずです。試しに手元からsshでログイン出来るか試してみます。
$ ssh -i .ssh/aws-wordpress.pem ec2-user@52.xxx.xxx.xxx
秘密鍵にはEC2インスタンス作成時に生成したキーペアを指定し、ユーザにはec2-userを指定します。Amazon Linx以外のOSの場合は、デフォルトユーザが異るようなので注意が必要でしょう。
RDSを立ち上げる
WordPressをインストールするにはデータベースが必要なので、先にRDSの準備を進めていきます。
RDSを触るのは初めてだったので少し苦戦しましたが、色々いじって整理しなおした手順をまとめてあります。
設定の流れは以下の通りです。
- DB用のセキュリティーグループの作成
- RDS用のサブネットグループの作成
- RDSインスタンスの作成
- エンジンの選択
- 稼働環境の選択
- DBの詳細設定
- その他の設定
DB用のセキュリティーグループの作成
RDSインスタンスを作る前には事前にやっておく作業が2つあります。
まずはその内の1つDB用のセキュリティーグループを作成します。
セキュリティーグループの作成は「EC2サービス」内の左メニュー「セキュリティーグループ」から行います。
上部の「セキュリティーグループの作成」を選択します。
ssh, ICMP他、APサーバ、mysqlクライアントでのアクセスを考慮して、同一VPC内から3306ポートのアクセスを許可しておきます。
RDS用のサブネットグループの作成
もう1つの事前準備がRDS用サブネットグループの作成です。
RDS用というのが肝なのですが、RDSには(VPC内に作った)単一のサブネットを割り当てることは出来ません。
そのためDB用のサブネットを作った時にも軽く触れた様に、異るAZにある複数のサブネットをグループ化し、割り当てる必要があります。
最初はこれがわからずに躓きました。やっぱり実際に触ってみないとわからないものですね。
では手順を説明していきます。
サービスメニューから「RDS」を選択します。
左のメニューから「サブネットグループ」を選びます。
上のメニューから「DBサブネットグループの作成」を選びます。
VPCの中に作ったAZの異る2つのDB用サブネットを割り当てます。マルチAZを利用しない場合も必ずこの手順は必要です。
RDSインスタンスの作成
これで下準備が整ったので、やっとRDSインスタンスの作成に入ります。
エンジンの選択
まずは使用するデータベースエンジンの選択です。
エンジンには色々なものが利用できますが、今回は(無料だし)スタンダードな「MySQL」を使ってみます。「Amazon Aurora」もそのうち使ってみたいですね。
稼働環境の選択
次は環境選択のメニューが出てきました。今回はただの勉強用なので「開発/テスト」を選びましたが、無料枠が終わってしまえば出ない選択肢なのでしょうか?
DBの詳細設定
次はDBの詳細設定で、容量やDBのバージョンの設定を行います。今回は無料枠内でためしているので、残念ながら使えないオプションもあるようです。例えば容量に上限があったり、マルチAZが使えないといった内容です。
今回は使えませんが、マルチAZは後々勉強するために使ってみたい所ですね。
以下、設定の内容です。
- ライセンスモデル: General Public License
- DBエンジンのバージョン: 5.6.27
- DBインスタンスのクラス: db.t2.micro
- マルチAZ配置: いいえ
- ストレージタイプ: 汎用(SSD)
- ストレージ割り当て: 5GB
- DBインスタンス識別子: db-wordpress
- マスターユーザの名前: wordpress
- マスターパスワード: xxxxxxxx
- パスワードの確認: xxxxxxxx
その他の設定
次は「ネットワーク&セキュリティ」「データベースの設定」の設定です。
まずは「ネットワーク&セキュリティ」の設定内容を書き出してみます。
- VPC: vpc-wordpress
- サブネットグループ: wordpress-db-subnet
- パプリックアクセス可能: いいえ
- アベイラビリティーゾーン: ap-northeast-1a
- VPCセキュリティーグループ: db(VPC)
DBはプライベートセグメントに置きたいので、「パプリックアクセス可能」は「いいえ」にしてあります。
DB用のサブネットは先程作った「wordpress-db-subnet」を選択しています。VPCセキュリティーグループも同様に事前に作った「db(VPC)」を選択します。
次は(MySQL上の)データベースの設定です。
- データベースの名前: wordpress
- データベースのポート: 3306
- DBパラメータグループ: default.mysql5.6
- オプショングループ: default:mysql-5-6
- タグをスナップショットへコピー: チェックなし
- 暗号を有効化: いいえ
RDSではいわゆるmy.cnfが直接変更できないので「DBパラメータグループ」を使ってパラメータ変更を行う様です。
同様にMySQLのオプション機能も「オプショングループ」を使って設定を行います。
詳しくは以下で説明されています。
今回はとりあえず変更なしのデフォルト値を指定しています。
残りは「バックアップ」「モニタリング」「メンテナンス」の設定です。
- バックアップの保存期間: 7日
- バックアップウィンドウ: 指定なし
- 拡張モニタリングを有効にする: いいえ
- マイナーバージョン自動アップグレード: はい
- メンテナンスウィンドウ: 指定なし
値は全てデフォルトのままです。ウィンドウ(メンテナンス時間)を指定して「バックアップ」「マイナーバージョン自動アップグレード」が出来るのはマネージドならではの機能ですね。
また「拡張モニタリング」を有効にすれば、より多くのシステムリソースをチェックできる様になるようです。
詳しくは以下が参考になります。
まとめ
かなり長くなってしまいましたが、以上で必要なネットワーク、インスタンスの設定までが終わった(はず)です。
といってもまだWordpressもインストールしてませんし、HTTPでのアクセス、RDSへの接続も確認できていません。
次回はこの辺りの作業をしたいと思います。