cloudpackエバンジェリストの吉田真吾(@yoshidashingo)です。
毎週水曜日18:30-21:30に新宿WAVEさんをお借りして開催している「新宿鮫:AWSもくもく勉強会」もすでに第7回を向かえました。
もくもく勉強会は、自習スタイルで自分のペースで学習を進めながら、時々分からないことがあれば周りの人にサポートしてもらいながら行う勉強スタイルです。主催者としても手間がかからないので非常に楽です。
今回、自分のテーマは、ハンズオン用の資料のために情報をまとめておく作業です。
- WordPress の EC2 インスタンスを作成する
- ログを fluentd で S3 に格納させる
- ログは一定期間後に Glacier にアーカイブさせる
- 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バケットを指定します。
手順としては以上です。ハンズオン資料のためにもう少し詳細な記述と、画面キャプチャを用意して資料化&公開していきたいと思います。