新宿鮫：第7回AWSもくもく勉強会を開催しました（WordPress+fluentd+S3+Glacier+Sorryページのホスティング）

AWS

cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。

毎週水曜日18:30-21:30に新宿WAVEさんをお借りして開催している「新宿鮫：AWSもくもく勉強会」もすでに第7回を向かえました。

もくもく勉強会は、自習スタイルで自分のペースで学習を進めながら、時々分からないことがあれば周りの人にサポートしてもらいながら行う勉強スタイルです。主催者としても手間がかからないので非常に楽です。

今回、自分のテーマは、ハンズオン用の資料のために情報をまとめておく作業です。

  1. WordPress の EC2 インスタンスを作成する
  2. ログを fluentd で S3 に格納させる
  3. ログは一定期間後に Glacier にアーカイブさせる
  4. WordPress が落ちた場合に S3 でホスティングする Sorry ページを表示するように設定する

網元の WordPress AMI でインスタンスを作成する

WordPress を EC2 でホスティングするにあたり、いちいちミドルウェアをインストールするのは大変なので、すでに網元から提供されている、チューニング済みの WordPress AMI を利用します。

網元の WordPress AMI を指定する

網元 にアクセスして「超高速 AMI 網元を今すぐ使う！」を押下します。

EC2 Management Console からインスタンスを作成する
  • VPC by Default でない（2013年3月？以前にアカウントを作った）人は EC2-Classic に、
  • VPC by Default の人は Launch into 「VPCのデフォルトサブネット」に、

EC2インスタンスを起動します。

無料使用枠の期間が expire してる人は、スポットリクエストで起動すると安上がりに利用できます。Pricing History を確認して、高値づかみにならないヤツを選びましょう。

セキュリティグループは ssh(22) と http(80) が外部のIPアドレス（source）から開いているものを指定します。

WordPress をインストールする

インスタンスが起動完了したら、EC2 Management Console で、起動した EC2 インスタンスの Public DNS を確認し、ブラウザからアクセスします。WordPressのインストール画面が表示されるので、サイト名や管理者情報を入力して「インストール」を押下します。

Elastic IPs を割り付けておく

あとでDNSサービスである「Route53」からIPアドレス指定のヘルスチェックを行いたい（DNSフェイルオーバーしたい）、EC2 Management Console の ElasticIPs のパネルから、IPv4アドレスを新規でAllocateして、WordPressのインスタンスにAssociateしておきます。

nginxのログ設定変更

nginxのログ設定やフォーマットを変更します。

ログフォーマットをLTSV形式に変更

出力されるログフォーマットを最近主流の LTSV形式 に変更します。

# vi /etc/nginx/nginx.conf

「既存の log_format の定義がされている直後の部分」に以下を挿入してください。

    # 追記
    log_format  ltsv  'time:$time_local\t'
                      'host:$remote_addr\t'
                      'request:$request\t'
                      'status:$status\t'
                      'size:$body_bytes_sent\t'
                      'referer:$http_referer\t'
                      'ua:$http_user_agent\t'
                      'reqtime:$request_time\t'
                      'upsttime:$upstream_response_time';
 
   #access_log  /var/log/nginx/access.log  ltsv;

access_log をコメントアウトしてますが、買い手も書かなくても効いてないようなので（詳細調べてないけど）、気にしなくていいです。

ログファイル名を変更します。以下のように変更してください。

# vi /etc/nginx/conf.d/default.conf

「access_log 定義をコメントアウトして下に ltsv を指定する行を追加」してください。

    #access_log  /var/log/nginx/{instance-id}.access.log  main;
    access_log  /var/log/nginx/access.log  ltsv;
nginx を再起動する
# service nginx stop
# service nginx status
# chmod 644 /var/log/nginx/access.log
# service nginx start
ログフォーマットが変更されたか確認

すると、以下のようなフォーマットで出力されていたアクセスログ（/var/log/nginx/access.log）が、

121.116.xxx.xxx - - [29/May/2013:20:14:46 +0900] "GET /?p=1 HTTP/1.1" 200 3706 "http://ec2-x-x-x-x.ap-northeast-1.compute.amazonaws.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36" "-"

こんな感じに出力されるようになります。

time:29/May/2013:20:32:06 +0900	host:121.116.xxx.xxx	request:GET /?p=1 HTTP/1.1	status:200	size:3706	referer:http://ec2-x-x-x-x.ap-northeast-1.compute.amazonaws.com/?p=1	ua:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36	reqtime:0.083	upsttime:0.083

IAMユーザーの作成

EC2 上のプロセスから S3 のバケットにファイルをアップロードしたいので、専用のユーザーを作成し、そのユーザーのセキュリティクレデンシャルを使います。

IAMユーザーを作成する

AWS Management Console で「IAM」というサービスにアクセスします。
左側のダッシュボードの「Users」を押下し「Create New Users」を押下します。1.に適当なユーザー名を入力し、下部のチェックはそのままに Create を押下すると1ユーザ作成されます。

「Show User Security Credentials を選択して表示されるAccess Key ID と Secret Access Key をメモっておく」あるいは「Download Credentials でCSVをダウンロード」しておいてください。

S3へのアクセス権を付与する

作成したユーザーを選択し、Permission タブから Attach User Policy で、S3 Full Access のポリシーをテンプレートから選択して Apply します。

S3バケットの作成

バケット作成→バケット名をメモしておく

Tokyo リージョンにバケットを作成し、バケット名をメモしておいてください。

バケット内に logs フォルダを作成する

td-agent のインストール

fluentd に ruby の実効環境まで付属した td-agent を使います。

yumリポジトリの設定
# vi /etc/yum.repos.d/td.repo

[treasuredata]
name=TreasureData
baseurl=http://packages.treasure-data.com/redhat/$basearch
gpgcheck=0
yum で td-agent をインストール
# yum install td-agent
td-agent の設定変更
# vi /etc/td-agent/td-agent.conf

以下をファイルの最終行に追加し、aws_key_id に「Access Key Id」、aws_sec_key に「Secret Access Key」を入力してください。s3_bucket にはさきほど作ったS3のバケット名を入力します。 

<source>
  type tail
  format ltsv
  path /var/log/nginx/access.log
  tag nginx.access
  pos_file /var/log/td-agent/nginx.access.log.pos
</source>

<match nginx.access>
    	type s3
        aws_key_id  YOUR_AWS_KEY
        aws_sec_key  YOUR_AWS_SECRET
	s3_bucket YOUR_BACKET_NAME
      	s3_endpoint s3-ap-northeast-1.amazonaws.com
        path logs/
        buffer_path /var/log/td-agent/buffer/s3
        time_slice_format %Y/%m/%d/access_log-%Y%m%d-%H
        time_slice_wait 10m
</match>

path ディレクティブで格納するバケット内のフォルダを指定、time_slice_formatでフォルダの分け方を制御できるので色々試すと面白いと思います。

また、設定ファイル内にIAMユーザーのクレデンシャルを直接記述する形式になってますので、外だしにしたい場合は、pitというのが使えて、fluentdから使えるプラグインをnaoyaさんが公開しているみたいです。※今回は未検証

td-agent の再起動
# service td-agent stop
# service td-agent status
# service td-agent start

/var/log/td-agent/td-agent.log にエラーが出力されてなければ、td-agentが正常にnginxのログをtailしはじめてます。

Glacier の設定

格納されたログを Glacier にアーカイブする設定
対象のバケットの「Lifecycle」でオブジェクトの作成日時から一定期間経過したものを「Move to Glacier」する設定をしておくと、S3に比べて1/10の費用でログの長期保存が可能になります。

Route 53 の設定

ここを参考にしてください。

ヘルスチェックの設定

フェイルオーバーの判定に使用するヘルスチェックを作成します。EC2に割り付けた固定IPで指定しておきます。

Primary サイトの設定

Primaryサイトは EC2に割り付けた固定IPをAレコードに設定します。

Secondary サイトの設定

Secondaryサイトは Webサイト機能を有効にしたS3バケットを指定します。


手順としては以上です。ハンズオン資料のためにもう少し詳細な記述と、画面キャプチャを用意して資料化＆公開していきたいと思います。