8月1日から、このサイトの WordPress を置いているサーバーを Amazon Web Services（以下 AWS）の Elastic Compute Cloud（以下 EC2）に移してみました。

ちょっぱやになってるけど、でも導入難しいんでしょう？なんてぼくが半年前に思っていたような声が聞こえてきそうですが、AWS の導入自体はさして難しいものではありません。

この記事では、ぼくでもできる、あなたでもできる AWS + 網元の導入についてご紹介します。

Table of Contents

• AWS って何？
• 網元って？
• AWS のアカウントを作成する
• AWS コンソールにログインする
• EC2 のリージョンを選ぶ
• Key Pairs を作成する
• Security Groups を作成する
• サーバーインスタンスを立ち上げる
• Elastic IPs を設定する
• WordPress のセットアップに必要な情報を確認する
• ドメイン名でバーチャルホストを設定したい場合
• WordPress のお引越し1 : wp-content 以下をコピーする
• WordPress のお引越し2：MySQL のデータを移行する

AWS って何？

AWS（Amazon Web Services）は、Amazon.com が保有する大量のコンピューター群をリモート操作で利用できるように、切り売りしてくれるコンピューティングサービスです。中の人が薄利多売と言い切るほど安価な価格で、非常に高性能のサービスを受けることができます。

AWS ではネットワークサービス、ストレージサービスなど多種多様なサービスが提供されていますが、WEB サーバー用途としては、Amazon EC2（Elastic Compute Cloud）を使用します。

網元って？

Amazon EC2 では、すでにセットアップされたマシン環境のイメージ AMI（Amazon Machine Image）を用いて（借りて）簡単にサーバー用マシンをセットアップすることができます。

本来ならば必要なソフトウェアを選定し、依存関係に気をつけながらインストールし、なおかつ適切に設定しなければいけないものが、もうすべて済んでしまっているのです。これは助かる！

網元は DigitalCube が研究に研究を重ねて作った AMI。いわば技術の決勝結晶。今のところ t1.micro 用にチューニングされたものが無償で公開されています。
超高速 AMI サービス網元 | WordPresss ハイパフォーマンスチューニング AMI

こちらを用いると、CentOS 6.2・nginx 1.2.2、PHP 5.3.14 with APC、Percona 5.5.24 と WordPress 3.4.1-ja が一気にインストールされます。ヤバい！エロい！

ではでは、さっそく AWS に WordPress をセットアップしていきましょう！

AWS のアカウントを作成する

まずはここから。

クラウド プラットフォーム活用を支援するアマゾン ウェブ サービス | AmazonのIaas, Paas型クラウド

AWS にアクセスして、サインアップを選択します。

Amazon.com のアカウントを持っていればそれに AWS を紐付けることができます。AWS の支払いはクレジットカードになるため、クレジットカードの登録が必要になります。

ログインできるようになるまでここで多少時間がかかる人もいるようです。

AWS コンソールにログインする

Amazon Web Services Sign In

上記リンクから AWS のコンソールにログインします。アカウントはさきほど登録したものです。

AWS には様々なサービスがありますが、本件で使う EC2 を選択します。

EC2 のリージョンを選ぶ

EC2 では、AWS のクラウド環境に立ち上げる仮想のサーバーをインスタンスないしはサーバーインスタンスと呼んでいます。プログラマーさんなどにはオブジェクト指向でおなじみ、実体のことを指すインスタンスであり、オンラインゲームを遊ぶ方には即時に生成されるエリアのことを指す、あのインスタンスです。

AWS はアメリカ西海岸をはじめ、複数のデータセンターにより提供されています。基本的に、サイトにアクセスしてくれる人（お客様、利用者）とデータセンターの距離が近いほうがサイトは早く表示されます。したがって、サイトにアクセスすると想定される層を想像してデータセンターのあるリージョンを選び、そこにサーバーインスタンスを立ち上げることが望ましいです。

コンソールの左カラムの一番上に、Region （リージョン）選択のプルダウンがあります。

日本人に住む人が見るサイトであれば、Asia Pacific (Tokyo) を選べば OK です。

Key Pairs を作成する

EC2 では、ユーザ ID とパスワードによる認証方式ではなく、公開鍵と秘密鍵を用いた公開鍵暗号方式での認証を用いるようになっています。

サーバーを立ち上げるにあたって、公開鍵と秘密鍵のペア（Key Pairs）を作っておきましょう。

コンソールの左カラムの下から2番目、Key Pairs を選択します。

続いて、Create Key Pair を選び、Key Pair Name （キーペアーの名前）を入力します。名前はなんのための Key Pairs か分かればなんでも構いません。ぼくはサイト名にしました。

Key Pair Name を入力して Create ボタンを押下すると、秘密鍵のファイルダウンロードがはじまります。pem という拡張子のファイルが秘密鍵になります。

EC2 のサーバーに対して、FTP や SSH で接続するためには、この秘密鍵のファイルが必要になりますので、大切に保管するとともに、絶対に公開しないようにしましょう。

秘密鍵をダウンロードした Mac 以外の Windows パソコンなどでも、EC2 にアクセスすることもあるので、WordVolcano の際に教えていただいたアドバイスにしたがって Dropbox に秘密鍵を置いておくことにしました。

※Mac や UNIX 環境でバックアップしておいた秘密鍵のファイルは、644 のパーミッションとなっていると、SSH の際に警告が出てしまいます（他人がアクセスできる状態にするな、という意味で）。あらかじめ、600 あたりに変更しておきましょう。

[sh]chmod 600 your-secret-key-name.pem[/sh]

Security Groups を作成する

Security Groups はこれから立ち上げるサーバーのファイアウォール設定と思ってもらえればよいでしょう。

デフォルトのままではどの通信であっても、どこからもサーバーにアクセスできない（つまり誰もサイトを見られない）ので、穴を開けてあげる必要があります。

HTTP と SSH で接続できる、といった形で設定を決め、後からサーバーインスタンスと紐付けます。

コンソールの左カラムにある Security Groups を選びます。

次に、Create Security Group を選択。

Security Group の Name （名前）と Description （説明）を入力します。サーバーにのせるサイトの名前とかで良いでしょう。ASCII 文字でないといけないので、アルファベットで入力してください。VPC は noVPC で構いません。

次に、どの通信を通すのか（許可するのか）を決めます。Inbound タブにあるプルダウンから通信を選びます。HTTP と SSH、メールを送受信するなら SMTP を追加するくらいでいいでしょう。

Source は 0.0.0.0/0 のままにしておけば、あらゆるところからの通信が許可されます。HTTP はこのままで良いと思いますが、SSH で接続できる IP アドレスを限定するのであれば、その IP アドレスを設定します。最後は、Apply Rule change をクリックします。

なお、この Security Groups は通信の許可のみ設定でき、拒否は設定できないようです←これでだいぶハマった。

サーバーインスタンスを立ち上げる

コンソールの EC2 Dashboard （ダッシュボード）に戻り、Launch Instance を選択します。

Classic Wizard をチェックして、Continue をクリックします。

次に Community AMIsのタブを選び、Viewing と書かれたところの右横のフォームに「 ami-cab507cb 」と入力します。これが網元の AMI です。

Select をクリックします。

現在公開されている網元は、t1.micro というもっとも小規模向けのインスタンスに対して最適化された AMI になります。でもお高いんでしょう？と言いたいところですが、t1.micro であれば現在1年分無料となっているので、安心して利用できるはず。

Number of Instances に、立ち上げるインスタンスの数（デフォルトは 1）、Instance Types に Micro (t1.micro, 613 MiB) を選択、Availability Zone を No Preference とし、Continue をクリックします。

インスタンスの停止には stop と termination の2種類があります。stop はサーバーの停止、termination はシュワちゃんがサーバーを抹殺する、といったイメージです。stop したサーバーは再開できますが、termination したサーバーは無くなってしまいます。

安易に termination してしまっては危険極まりないので、Prevention against accidental termination （事故による termination を防ぐ）にチェックを入れると、いきなり terminate されることがなくなります。

残りはデフォルトのままにして、Continue をクリックします。

インスタンスの Storage 容量を決めます。デフォルトは 6 GiB となっており、変更する場合は Edit を選びます。

安価とはいえ、容量が多いほどお値段も上がるため、ぼくはデフォルトのまま進めました（運用中の現在の残り容量は42％ほどです）。

サーバーインスタンスに対して、Key と Value を設定できます。数多くのインスタンスを管理する人のためのタグのようなものです。

デフォルトで Name が入っているので、Value に対してインスタンスの名前を入力しましょう。

次にインスタンスと Key Pairs を紐付けます。

さらにインスタンスと Security Groups を紐付けます。

これでインスタンスが「立ち上げ中」になります。ステータスは「立ち上げ中」なので、立ち上がらないとつかえません。

きっちり3分ではないですが、インスタントラーメンでも作って待ちましょう。

インスタンスを確認

インスタンスが立ち上がったら、CentOS やnginx、PHP、Percona などなどがすべてセットアップされ、立ち上がった状態になっています。

WordPress もまたセットアップされ、アクセスすると初期設定がはじまる状態になっています。

コンソールの Instances をクリックすると、アカウントに紐付いたインスタンスの一覧が出てきます。さきほど立ち上げたインスタンスにチェックを入れると、画面下部にインスタンスの情報が表示されます。

その中の Public DNS のアドレス：ec2-hoge.ap-fuga-piyo.compute.amazonaws.com をブラウザにコピー＆ペーストしてアクセスすると、WordPress の初期設定画面が現れると思います。

はじめて立ち上げるサイトであればこのまま、ドメインで運用したかったり、既存のサイトをお引越しする場合は、データをワイプして使うことになります。

Elastic IPs を設定する

立ち上げたばかりのインスタンスは ec2-hoge.ap-fuga-piyo.compute.amazonaws.com という URL を持っているだけで、グローバル IP アドレスがありません（プライベート IP アドレスはあるのですが、これは AWS の中でのみ使われるもので、この IP アドレスに対して外部からアクセスすることはできません）。

ここでは Elastic IPs という機能を使って、インスタンスに対してグローバル IP アドレスを割り当てる必要があります（特に、DNS に A レコードとして設定したい場合は必須の設定となります）。

Elastic IPs は IP アドレスを紐付けている時には課金されず、IP アドレスを紐付けたインスタンスを停止している時に課金されるようになっているそうです。駐車料金みたいなものですね。

コンソール左カラムから Elastic IPs を選び、Allocate New Address をクリックします。

Yes, Allocate をクリックします。

Associate New Address をクリックします。

プルダウンから IP アドレスに紐付けるインスタンスを選択し、Yes, Associate をクリックします。

これでサーバーインスタンスに対して、グローバル IP アドレスが紐付けられました。ネームサーバーでこの IP アドレスを指定することで、IP アドレスへのアクセスがサーバーインスタンスに向かうようになります。

まずは、ネームサーバーは変えず、お使いのコンピューターの hosts を書き換えて、IP アドレスにドメインを割り当てて、WordPress のセットアップ作業をすることをおすすめします。

WordPress のセットアップに必要な情報を確認する

まず、IP アドレスはさきほど紐付けた Elastic IPs で確認できます。

SSH や SFTP する際のユーザー名：root になります。一般ユーザーはデフォルトでは作成されていません。パスワードの代わりに最初に Key Pairs のところでダウンロードした秘密鍵を使ってくださいね（公開鍵暗号認証方式に対応した SSH/SFTP クライアントが必要です） 。

一応 SSH の仕方はこんな感じで↓

[sh]ssh -l root -p 22 -i /PATH/TO/SECRET_KEY/your-secret-key.pem GLOBAL.IP.ADD.RESS[/sh]

root ユーザーの MySQL パスワード：無し。適宜設定してください。

MySQL ユーザー情報：wp-config.php に記述されているので参照してください。

WordPress の場所：/var/www/vhosts/{Instance_name}/

WEB サーバーの設定ファイル：/etc/nginx/

サイトの設定ファイル：/etc/nginx/conf.d

アクセスログ：/var/log/nginx/{instance_name}.access.log

エラーログ： /var/log/nginx/{instance_name}.error.log;

ドメイン名でバーチャルホストを設定したい場合

網元でセットアップした WordPress は /var/www/vhosts/{Instance_name}/ の通り、インスタンス名のディレクトリにインストールされています。

これをドメイン名等にしてバーチャルホストを設定したい場合は、SSH 接続して以下を実行することで、ドメイン名のディレクトリに新たな WordPress が設定されます（MySQL ユーザー情報等も新たに設定されます）。

[sh]# wp-setup example.com[/sh]

実行結果は以下の通り。

[sh]start…

Initialized empty Git repository in /tmp/amimoto/.git/

remote: Counting objects: 173, done.

remote: Compressing objects: 100% (154/154), done.

remote: Total 173 (delta 82), reused 104 (delta 16)

Receiving objects: 100% (173/173), 26.16 KiB, done.

Resolving deltas: 100% (82/82), done.

WordPress install …

————————————————–

MySQL DataBase: example_com

MySQL User: hogehoge

MySQL Password: fugafuga

————————————————–

Success!! http://example.com/

————————————————–

… WordPress installed

…done[/sh]

これで、新たな WordPress の場所は /var/www/vhosts/example.com/ となります。MySQL の接続情報は実行結果または /var/www/vhosts/example.com/wp-config.php を確認してください。

参考：WordPress 専用高速 AMI “網元” はじめました | dogmap.jp

WordPress のお引越し1 : wp-content 以下をコピーする

できるプログラマーは、rsync とか使ってカッコよくキメるところですが、元のサーバーの設定をイジってしまったせいか、rsync がうまくいかなかったので、伝統的な手法に則って、ファイルをアーカイブして scp …もさらに効かなかったので、SFTP でファイルをコピーしました。↓は元のサーバーで。

[sh]# tar cfz tar-wp-content.tar.gz /wp-content [/sh]

で、できあがった、tar-wp-content.tar.gz を SFTP なり SCP なりで EC2 にアップロードします。

[sh]# tar zxvf tar-wp-content.tar.gz [/sh]

これで、旧サーバーから EC2 へと wp-content 以下を移行できました。wp-content 以外にも自前のデータが有る場合は適宜移行します。

WordPress のお引越し2：MySQL のデータを移行する

旧サーバーから新サーバーへと MySQL のデータ（/var/lib/mysql/ など）を直接コピーしてきてもよいのですが、旧サーバーと EC2 の構成があまりにも違ったため、mysqldump を使うことにしました。

旧サーバーにて、

[sh]# mysqldump -uoldserver_db_user -p -hlocalhost –default-character-set=utf8 oldserver_wordpres_db_name > wordpress_db_dump.sql[/sh]

oldserver_db_user には旧サーバーの “MySQL データベースのユーザー名”を、oldserver_wordpres_db_name には旧サーバーの “WordPress のためのデータベース名”を入力してください（ともに wp-config.php 参照）。

出来上がった wordpress_db_dump.sql ファイルを rsync だの scp だので、EC2 に置いてやります。ぼくはどちらも効かなかっ（ｒｙ、素直に SFTP でアップロードしました。場所はどこでも構いませんが、ルートディレクトリに /tmp などというディレクトリを作って作業するとデキる人っぽく見えるようです。

EC2 にて、

[sh]# mysql -uec2_mysql_user -p -hlocalhost –default-character-set=utf8 ec2_mysql_database < wordpress_db_dump.sql[/sh]

ec2_mysql_user には # wp-setup example.com の結果得られた “MySQL User” を、ec2_mysql_database には ”MySQL DataBase” を入力します。

WordPress データベーステーブルの接頭辞 $table_prefix を修正している人は、wp-config.php を適宜旧サーバーで使っていた接頭辞に直してください。

これでデータの移行は完成となります。再度、EC2 にブラウザでアクセスすると、旧サーバーにあったサイトが再現されているはずです。

また、nginx のキャッシュは非常に強力なので、更新が反映しなかったり、モバイルでの表示がうまくいかなかったりします。そのあたりは
網元で Ktai Style とか使う時の注意点 | dogmap.jp
を参考にするとよろしいかと思います。

問題がなければネームサーバーに EC2 の IP アドレスを設定し、EC2 へと切り替えましょう。これで作業は完了です。おつかれさまでした。

※このサイトでは8月1日より EC2 へとお引越ししましたので、1ヶ月が経過した段階でどの程度、AWS のリソース／料金を使っているか、検証してみたいと思います。