読者です 読者をやめる 読者になる 読者になる

Re:boot!

35歳からのエンジニアWay

【AWS勉強】EC2+RDSを使った基本構成を構築してWordPressを立ち上げてみる。その1

まずは勉強の手始めとして、EC2+RDSを使ってWordPressを立ち上げてみたいと思います。アプリケーションサーバ+データベースサーバという、WEBでは最も基本的な構成ですね。

私も仕事でAWSを少しは触ったことがあるとはいえ、一から構築はしたことはありません。実際のところDBも普通にEC2インスタンスMySQLをインストールして運用していたので、何気にRDSを使ったこともなかったりします。まあ、言ってしまえば初心者レベルですね。

とはいえEC2?RDS?VPC?といったド素人レベルでもないわけですが、せっかくなので「AWSを使うのはホントに初めて」くらいの人も意識して、捕捉を入れながら説明してみたいと思います。

構成図

f:id:yusan09:20170105001327p:plain

細かい部分は置いておくとして、まずは作ろうと思っている構成を説明したいと思います。今回は図の様にパブリック用のサブネットとプライベート用のサブネットを用意して、WordPressを動かします。この図を見て何をする必要があるのかパッと挙げられる人は、初心者レベルはクリアしてると言っても良いのではないでしょうか。

では早速ですが、構成と利用するサービスについて触れていきたいと思います。用意するサーバは2つです。

EC2は仮想ホストを作る事が出来るサービスです。簡単に言えば管理画面からポチポチするだけでサーバが用意できるサービスですね。OSも様々なものから選べます。

aws.amazon.com

EC2のインスタンス(仮想サーバ)を1つ用意して、WordPressが動く環境を作ります。また、Wordpress用のデータベースをとしてRDSを利用して、MySQLを立ち上げます。

aws.amazon.com

RDSは(リレーショナル)データベースの立ち上げに特化したサービスです。EC2を使って自分でMySQLを運用することもできますが、RDSならセットアップやスケール、バックアップ、冗長化などが非常に手軽に出来るようになっています。さらにAWSが独自開発したMySQL互換のDB「Amazon Aurora」が使えるのも大きな特徴です。

aws.amazon.com

ネットワークはVPCを利用して作ります。VPCはアカウントごとに独立した仮想論理ネットワークで、他のアカウントやAWS自体のネットワークに影響を受けません。

docs.aws.amazon.com

今回は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を提供してくれるサービス、インターネットゲートウェイはインターネット接続するための(デフォルト)ゲートウェイを用意してくれるサービスです。

docs.aws.amazon.com

docs.aws.amazon.com

後者の方法はNATゲートウェイを作って外とアクセスする方法です。ユーザからアクセスを受ける必要がなく、サーバから外に出る必要がある場合に利用できます。例えばyumでインストールを行う場合などに必要ですね。

以前はNAT用のインスタンスを立ち上げゲートウェイにするしかなかったようですが、2015年12月よりマネージドなNATゲートウェイサービスも開始されているので、今はこちらを利用するのがベストプラクティスではないでしょうか。

docs.aws.amazon.com

プライベートなネットワークにあるDBサーバなどは、WANのアドレスは振らずNATゲートウェイを通して外に出るのが一般的でしょう。今回の場合であればRDSインスタンスが該当しますね。

さて、おおまかな構成はこの辺りにして実際に構築する手順を説明していきたいと思います。

ネットワーク(VPC・サブネット)の作成

まずはAPサーバ(EC2)、DBサーバ(RDS)用のネットワークを作成です。

EC2インスタンスもRDSインスタンスもネットワークに所属しなければ何もできないので、インスタンスを作る前にVPC作成しておく必要があります。

やるべき作業は大まかに4つです。

  • VPCを作成する
  • 作成したVPCに属するサブネット3つを作成する
  • インターネットゲートウェイを作成し、VPCにアタッチする
  • 必要なルートテーブルを作成し、各サブネットに割り当てる

それでは順番に見ていきましょう。

VPCを作成する

まずはVPCを作成します。VPCは仮想スイッチ、この後作るサブネットはVLANだと思えば概念的には近い気がします。

AWSのマネージメントコンソールにログインして、左上の「メニュー」から「VPC」を選びます。

f:id:yusan09:20161230233902j:plain

左のサイドバーメニューの中から「VPC」を選びます。

f:id:yusan09:20161230234211j:plain

上のメニューから「VPCの作成」を選びます。

f:id:yusan09:20161230234459j:plain

必要なパラメータを入力します。今回は以下の様にしました。

f:id:yusan09:20161230235204j:plain

  • ネームタグ: vpc-wordpress
  • CIDRブロック: 10.0.0.0/16
  • テナンシー: デフォルト

テナンシーではデフォルトの他に「ハードウェア専有」を選ぶ事ができます。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)のサブネットを作る手順を説明したいと思います。

左のサイドバーメニューの中から「サブネット」を選びます。

f:id:yusan09:20161231000221j:plain

上のメニューから「サブネットの作成」を選びます。

必要なパラメータを入力します。

f:id:yusan09:20161231001532j:plain

VPCには先程作った vpc-wordpress を選択します。

vpc-db-subnet1、vpc-db-subnet2の2つも同様の手順で作成すればOKです。

インターネットゲートウェイを作成し、VPCにアタッチする

次はインターネットゲートウェイの作成と、ルートテーブル(ルーティング)の編集をします。

物理ネットワークの場合と同じで、WANに疎通のあるルータを用意してデフォルトゲートウェイを指定する感じです。

本来ならホスト毎にルーティングを設定しないといけない所ですが、AWSではVPC単位でルーティングを制御するようです。この辺りは少し慣れが必要そうですね。

左のサイドバーメニューの中から「インターネットゲートウェイ」を選びます。

f:id:yusan09:20161231101132j:plain

上のメニューから「インターネットゲートウェイの作成」を選びます。

f:id:yusan09:20161231102456j:plain

必要なパラメータを入力します。

f:id:yusan09:20161231103535j:plain

インターネットゲートウェイは作成しただけでは意味がなく、VPCにアタッチする必要があります。

物理ネットワークで言えば、ルータを既存のネットワークにLANケーブルでつなぐイメージでしょうか。

上のメニューから「VPCにアタッチ」を選びます。

f:id:yusan09:20161231102854j:plain

アタッチ先として、さきほど作った vpc-wordpress を選択します。

f:id:yusan09:20161231103955j:plain

必要なルートテーブルを作成し、各サブネットに割り当てる

アタッチしたインターネットゲートウェイを通して外への疎通が出来る様にします。

左のメニューから「ルートテーブル」を選択します。

f:id:yusan09:20161231111045j:plain

VPCを作成した時点で既にvpn-wordpressに関するルートテーブルが出来ているので選択します。

さらに下の窓の「ルート」タブを押し、「編集」を選択します。

f:id:yusan09:20161231111343j:plain

インターネットゲートウェイをデフォルトルートとするルーティングを追加します。

ターゲットはIPアドレスで指定する必要はなく、インターネットゲートウェイの名前で指定します。

ターゲットのフォームをフォーカスすると選択肢が表示されるので、特にメモをしておく必要もありません。

続いてルートテーブルとサブネットの紐付けをします。

下の窓の「サブネットの関連付け」から「編集」を押します。

f:id:yusan09:20170104224925j:plain

WANからのアクセスを受けるのはAPサーバのみなので、vpc-wordpress-subnet1にのみチェックをいれ保存を押します。

f:id:yusan09:20170104225401j:plain

これでWANに出るためのルーティングに関してもOKです。

vpc-db-subnet1, vpc-db-subnet2に関しては「10.0.0.0/16 local」のみを持つルートテーブルを別途作成し、同様の方法で関連付けすればOKです。

これでネットワークの設定に関しては終了です。

EC2インスタンスの準備

ネットワークが出来たのでAPサーバ用のEC2インスタンスを作っていきます。

まずはサービスから「EC2」を選択します。

f:id:yusan09:20161231120835j:plain

画面中央下の「インスタンスの作成」を選択します。

f:id:yusan09:20161231121942j:plain

ステップ 1: Amazon マシンイメージ(AMI)

まずはAMI(Amazonマシンイメージ)の選択画面が表示されます。

AMIはインスタンス上に展開されるOSのイメージファイルです。

アプリケーションも含めたOSの初期テンプレートファイルだと思えばいいでしょう。

docs.aws.amazon.com

AWSが用意した物の他にも、自分で作成したもの、サードパーティー(企業)が用意したもの、他のAWSユーザ公開しているものなどから選べます。

今回はスタンダードなAmazonLinuxのAMIを選択します。

f:id:yusan09:20170101144016j:plain

ステップ 2: インスタンスタイプの選択

次に「インスタンスタイプ」を選択します。

インスタンスタイプごとに仮想マシンのスペックや、利用料金が異なります。今回は「t2.micro」を選びます。

f:id:yusan09:20170101144359j:plain

ステップ 3: インスタンスの詳細の設定

続いてインスタンスの詳細を設定します。様々な設定項目がありますが、今回は基本的にデフォルトのままで進めます。

VPCとサブネットの設定のみ先程作った「vpc-wordpress」「vpc-wordpress-subnet1」を選ぶ様に変更します。

これで今から作るインスタンスは先程作ったVPCネットワーク内に作られる事となります。

f:id:yusan09:20170101145146j:plain

ステップ 4: ストレージの追加

次にAMIをインストールするストレージを選びます。AWSではEC2インスタンスが直接ストレージ(SSD・HDD)をマウントするわけではなく、EBSと呼ばれるストレージをネットワーク越しに接続して利用します。

EBSは自動的にレブリカが作られるため可用性が高いだけでなく、容量を拡張したりスナップショットを取ったりと、一般的な物理ストレージで悩みどころとなる点を解決してくれる、様々な便利 が備わっています。

今回はデフォルトのまま8GBのストレージを利用します。

aws.amazon.com

ステップ 5: Add Tags

次にタグの追加を行います。タグはEC2インスタンスの管理をしやすくするためのメタ情報ですね。

Nameに「ap-wordpress1」を入力しておきます。

f:id:yusan09:20170101150831j:plain

ステップ 6: セキュリティグループの設定

次はセキュリティーグループの設定です。

セキュリティーグループはインスタンスへのin,outをネットワーク、ポート単位で制御できるAWS独自のファイアウォール機能ですね。

言ってしまえば複数インスタンスにまとめて設定できるiptablesって感じでしょうか。結構便利な機能です。

docs.aws.amazon.com

WEBアプリケーション向けにセキュリティグループを一つ新規作成しておきます。次回から似た用途のインスタンスを作成した場合は、同じセキュリティーグループを適用すればOKです。

新規作成する場合、最初からSSHは許可されてます。今回はpingでの確認とWEBサーバとして動かすためのルールを追加しておきます。

f:id:yusan09:20170101173844j:plain

最後に作成するインスタンスの設定確認画面が表示され、作成を行おうとするとSSHキーの選択画面(新規作成画面)が表示されます。

作成はキーペア名を入力して「キーペアのダウンロード」ボタンを押すだけです。

f:id:yusan09:20170101174713j:plain

ボタンを押すとpemファイル(秘密鍵)がダウンロードされます。公開鍵は自動的にインスタンスに配置されるので、特に何かをする必要はありません。

これでAPサーバ用のEC2インスタンスの作成は終了です。

WANからアクセス出来るようにする

APサーバ用のインスタンスはできましたが、今のままではグローバルIPがなく、WANに疎通が取れない状態です。もちろん、HTTPでのアクセスも、SSHでのアクセスも出来ません。

そこで、Elastic IPを利用してグローバルIPを紐付け、SSHでアクセスをしてみます。

まずは左メニューから「Elastic IP」を選択します。

f:id:yusan09:20170102174254j:plain

最初は利用できるグローバルIPが0個なので、AWSからアドレスを割り当ててもらう必要があります。

「新しいアドレスの割当」を選択します。

f:id:yusan09:20170102174651j:plain

割当が終了すると取得済みのアドレス一覧が表示されます。取得したアドレスはまだどのインスタンスにも紐付いていないので、先程作ったEC2インスタンスにアタッチする必要があります。

一覧から取得アドレスにチェックを入れ、上のメニューから「アドレスの関連付け」を選択します。

f:id:yusan09:20170102175208j:plain

アタッチするインスタンスを選択します。

インスタンス名とIPアドレスを選択する必要がありますが、プルダウンで選択する事が出来るのでさほど手間ではないはずです。

f:id:yusan09:20170102175456j:plain

これで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サービス」内の左メニュー「セキュリティーグループ」から行います。

f:id:yusan09:20170104231352j:plain

上部の「セキュリティーグループの作成」を選択します。

f:id:yusan09:20170104231818j:plain

ssh, ICMP他、APサーバ、mysqlクライアントでのアクセスを考慮して、同一VPC内から3306ポートのアクセスを許可しておきます。

f:id:yusan09:20170104233327j:plain

RDS用のサブネットグループの作成

もう1つの事前準備がRDS用サブネットグループの作成です。

RDS用というのが肝なのですが、RDSには(VPC内に作った)単一のサブネットを割り当てることは出来ません。

そのためDB用のサブネットを作った時にも軽く触れた様に、異るAZにある複数のサブネットをグループ化し、割り当てる必要があります

最初はこれがわからずに躓きました。やっぱり実際に触ってみないとわからないものですね。

では手順を説明していきます。

サービスメニューから「RDS」を選択します。

f:id:yusan09:20170102223326j:plain

左のメニューから「サブネットグループ」を選びます。

f:id:yusan09:20170104234349j:plain

上のメニューから「DBサブネットグループの作成」を選びます。

f:id:yusan09:20170104234416j:plain

VPCの中に作ったAZの異る2つのDB用サブネットを割り当てます。マルチAZを利用しない場合も必ずこの手順は必要です。

f:id:yusan09:20170104234724j:plain

  • 名前: wordpress-db-subnet
  • 説明: subnet for db
  • VPC ID: vpc-wordpress
  • サブネットグループに追加するサブネット:
    • vpc-db-subnet1 (ap-northeast-1a, 10.0.2.0/24)
    • vpc-db-subnet2 (ap-northeast-1c, 10.0.3.0/24)

RDSインスタンスの作成

これで下準備が整ったので、やっとRDSインスタンスの作成に入ります。

エンジンの選択

まずは使用するデータベースエンジンの選択です。

エンジンには色々なものが利用できますが、今回は(無料だし)スタンダードな「MySQL」を使ってみます。「Amazon Aurora」もそのうち使ってみたいですね。

f:id:yusan09:20170102224524j:plain

稼働環境の選択

次は環境選択のメニューが出てきました。今回はただの勉強用なので「開発/テスト」を選びましたが、無料枠が終わってしまえば出ない選択肢なのでしょうか?

f:id:yusan09:20170102224854j:plain

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

f:id:yusan09:20170102232208j:plain

f:id:yusan09:20170102232220j:plain

その他の設定

次は「ネットワーク&セキュリティ」「データベースの設定」の設定です。

まずは「ネットワーク&セキュリティ」の設定内容を書き出してみます。

f:id:yusan09:20170105000221j:plain

DBはプライベートセグメントに置きたいので、「パプリックアクセス可能」は「いいえ」にしてあります。

DB用のサブネットは先程作った「wordpress-db-subnet」を選択しています。VPCセキュリティーグループも同様に事前に作った「db(VPC)」を選択します。

次は(MySQL上の)データベースの設定です。

f:id:yusan09:20170102233804j:plain

  • データベースの名前: wordpress
  • データベースのポート: 3306
  • DBパラメータグループ: default.mysql5.6
  • オプショングループ: default:mysql-5-6
  • タグをスナップショットへコピー: チェックなし
  • 暗号を有効化: いいえ

RDSではいわゆるmy.cnfが直接変更できないので「DBパラメータグループ」を使ってパラメータ変更を行う様です。

同様にMySQLのオプション機能も「オプショングループ」を使って設定を行います。

詳しくは以下で説明されています。

docs.aws.amazon.com

docs.aws.amazon.com

今回はとりあえず変更なしのデフォルト値を指定しています。

残りは「バックアップ」「モニタリング」「メンテナンス」の設定です。

f:id:yusan09:20170102234941j:plain

  • バックアップの保存期間: 7日
  • バックアップウィンドウ: 指定なし
  • 拡張モニタリングを有効にする: いいえ
  • マイナーバージョン自動アップグレード: はい
  • メンテナンスウィンドウ: 指定なし

値は全てデフォルトのままです。ウィンドウ(メンテナンス時間)を指定して「バックアップ」「マイナーバージョン自動アップグレード」が出来るのはマネージドならではの機能ですね。

また「拡張モニタリング」を有効にすれば、より多くのシステムリソースをチェックできる様になるようです。

詳しくは以下が参考になります。

dev.classmethod.jp

まとめ

かなり長くなってしまいましたが、以上で必要なネットワーク、インスタンスの設定までが終わった(はず)です。

といってもまだWordpressもインストールしてませんし、HTTPでのアクセス、RDSへの接続も確認できていません。

次回はこの辺りの作業をしたいと思います。