2011年7月31日日曜日

SUZ-LAB謹製 CentOS AMI (6.0.0 64bit ap-northeast-1)

スズキです。

AMIを「suz」で検索してもらえれば、
811118151095/suz-lab_ebs_centos-core-x86_64-6.0.0
として見つかるはずです。

作成手順は下記で紹介したものほぼ同じです。
"SUZ-LAB謹製 CentOS AMI 6.0.0"の作り方

64bit用に変更した部分は下記の三点です


作業インスタンス(EC2)のOSはRHEL-6.0

下記のAMIを利用しました。
ID: ami-2268c223
Source: 309956199498/RHEL-6.0-Starter-EBS-x86_64-11-Hourly


"yum.conf"で指定する"yumリポジトリ"を64bit(x86_64)のものに

[base]
name=CentOS-6 - Base
baseurl=http://mirror.centos.org/centos/6/os/x86_64/
[updates]
name=CentOS-6 - Updates
baseurl=http://mirror.centos.org/centos/6/updates/x86_64/


AMI作成(登録)スクリプトを64bit(x86_64)のものに

require_once("/opt/aws/php/sdk.class.php");

define("AWS_KEY"       , "AAAAAAAA");
define("AWS_SECRET_KEY", "XXXXXXXX");

$ec2 = new AmazonEC2();
$ec2->set_region(AmazonEC2::REGION_APAC_NE1);

$response = $ec2->register_image(array(
    "Name"               => "suz-lab_ebs_centos-core-x86_64-6.0.0",
    "Architecture"       => "x86_64",
    "KernelId"           => "aki-ee5df7ef",
    "RootDeviceName"     => "/dev/sda1",
    "BlockDeviceMapping" => array(
        array(
            "DeviceName" => "/dev/sda1",
            "Ebs"        => array(
                "SnapshotId" => "snap-f5db769e"
            )
        )
    )
));

var_dump($response);


作成したAMIからEC2インスタンスを立ち上げログインすると、
下記のように、"CentOS 6.0"の64bit(x86_64)であることが確認できます。

# cat /etc/redhat-release 
CentOS Linux release 6.0 (Final)
# uname -a
Linux ip-10-150-90-118 2.6.32-71.29.1.el6.x86_64 #1 SMP Mon Jun 27 19:49:27 BST 2011 x86_64 x86_64 x86_64 GNU/Linux

次は全リージョン対応...
--------
http://www.suz-lab.com

2011年7月29日金曜日

"SUZ-LAB謹製 CentOS AMI 6.0.0"の作り方

スズキです。

下記の通り、久しぶりに「0」からAMIを作成したので、
SUZ-LAB謹製 CentOS AMI (6.0.0 32bit ap-northeast-1)
作り方をメモしておきます。

EC2の起動とAMI作成イメージ用EBSの作成&アタッチ

まずは作業をするEC2を起動しますが、
いろいろと参考になる下記のRHEL-6.0で起動しておきます。


そして"CentOS 6.0"のイメージとなるEBSを下記のように作成してアタッチします。



ここでは、"/dev/sdb1"でアタッチしてますが、
RHEL-6.0では"/dev/xvdb1"となっているので注意が必要です。


EBS(/dev/xvdb1)にファイルシステム(ext4)を作成

アタッチしたEBS(/dev/xvdb1)を下記のように
"mkfs.ext4"を使ってファイルシステムを作成します。

# ls /dev/xvdb1 
/dev/xvdb1

# mkfs.ext4 /dev/xvdb1 
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
393216 inodes, 1572864 blocks
78643 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1610612736
48 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 31 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.


EBS(/dev/xvdb1)をマウントしてデバイスファイルを作成

上記のEBS(/dev/xvdb1)を適当なディレクトリにマウントして、
その中に下記のようにデバイスファイルを作成します。

# mkdir /mnt/ami

# mount -t ext4 /dev/xvdb1 /mnt/ami/

# /sbin/MAKEDEV -d /mnt/ami/dev -x console
MAKEDEV: mkdir: File exists
MAKEDEV: mkdir: File exists

# /sbin/MAKEDEV -d /mnt/ami/dev -x null

# /sbin/MAKEDEV -d /mnt/ami/dev -x zero

# ls /mnt/ami/dev/
console  null  tty  zero


"/etc/fstab"を作成して"proc"ファイルシステムをマウント

下記のように"/mnt/ami/etc/fstab"を作成し、
"/mnt/ami/proc"に"proc"ファイルシステムをマウントします。

# mkdir /mnt/ami/etc

# cat /mnt/ami/etc/fstab
/dev/xvda1  /         ext4    defaults        1 1
none        /proc     proc    defaults        0 0
none        /sys      sysfs   defaults        0 0
none        /dev/pts  devpts  gid=5,mode=620  0 0
none        /dev/shm  tmpfs   defaults        0 0

# mkdir /mnt/ami/proc

# mount -t proc none /mnt/ami/proc


"yum"で"CentOS 6.0"のパッケージ(Core)とカーネルをインストール

"CentOS 6.0"用の"yum.conf"を作成して、"yum"でCoreパッケージをインストールします。
また、"User Provided Kernel"で利用するカーネルもインストールしておきます。

# mv /etc/yum.repos.d /etc/yum.repos.d.bak

# yum clean all
Loaded plugins: amazon-id, security
Cleaning up Everything

# cat /mnt/yum.conf
[base]
name=CentOS-6 - Base
baseurl=http://mirror.centos.org/centos/6/os/i386/
[updates]
name=CentOS-6 - Updates
baseurl=http://mirror.centos.org/centos/6/updates/i386/

# yum -c /mnt/yum.conf --installroot=/mnt/ami/ -y groupinstall Core

# cp /mnt/ami/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 /etc/pki/rpm-gpg/

# yum --installroot=/mnt/ami/ -y install kernel


"User Provided Kernel"の設定(/boot/grub/menu.lst)

上記のカーネルを利用するように"/mnt/ami/boot/grub/menu.lst"を
下記のように記述します。

下記のカーネルイメージ(AKI)を利用すると"/boot/grub/menu.lst"に記載された、
ユーザーが提供するカーネルが利用されます。
pv-grub-hd0_1.02-i386.gz.manifest.xml
# cat /mnt/ami/boot/grub/menu.lst
default=0
timeout=0
hiddenmenu
title SUZ-LAB CentOS 6
root (hd0)
kernel /boot/vmlinuz-2.6.32-71.29.1.el6.i686 ro root=/dev/xvda1
initrd /boot/initramfs-2.6.32-71.29.1.el6.i686.img


ネットワークの設定

ネットワークの設定は、下記のようにDHCPを利用するようにし、IPv6は無効にします。

# cat /mnt/ami/etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=localhost.localdomain

# cat /mnt/ami/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=on

# cat /mnt/ami/etc/hosts
127.0.0.1   localhost localhost.localdomain


SELinuxの設定

SELinuxは下記のように無効にしておきます。

# cat /mnt/ami/etc/sysconfig/selinux
SELINUX=disabled
SELINUXTYPE=targeted


SSHの設定

起動時にAWSから公開鍵を取得し、事前に作成した秘密鍵でログインできるようにします。
"sshd"の設定も秘密鍵でしかログインできないようにしておきます。

cat /mnt/ami/etc/rc.local
...
# For AWS
PUB_KEY_URI=http://169.254.169.254/1.0/meta-data/public-keys/0/openssh-key
PUB_KEY_FROM_HTTP=/tmp/openssh_id.pub
ROOT_AUTHORIZED_KEYS=/root/.ssh/authorized_keys
curl --retry 3 --retry-delay 0 --silent --fail -o $PUB_KEY_FROM_HTTP $PUB_KEY_URI
if [ $? -eq 0 -a -e $PUB_KEY_FROM_HTTP ] ; then
    if ! grep -q -f $PUB_KEY_FROM_HTTP $ROOT_AUTHORIZED_KEYS
    then
        cat $PUB_KEY_FROM_HTTP >> $ROOT_AUTHORIZED_KEYS
        echo "New key added to authrozied keys file from parameters" | logger -t "aws"
        dd if=/dev/urandom count=50 | md5sum | passwd --stdin root
        echo "The root password randomized" | logger -t "aws"
    fi
    chmod 600 $ROOT_AUTHORIZED_KEYS
    rm -f $PUB_KEY_FROM_HTTP
fi

# cp -r /root/.ssh /mnt/ami/root/

# cat /mnt/ami/root/.ssh/authorized_keys 

# cat /mnt/ami/etc/ssh/sshd_config
...
PermitRootLogin without-password
PasswordAuthentication no
UseDNS no
...


アンマウントとスナップショットの取得

上記で作成したEBSをAMI作成用のスナップショット取得のため下記のようにアンマウントし、
EBSをEC2からデタッチして、スナップショットを取得します。
(デタッチとスナップショットは"AWS Management Console"で実施しました)

# umount /mnt/ami/proc

# umount /mnt/ami


AMIの作成(登録)

上記で作成したスナップショット(snap-951eb8fe)を指定して、
下記PHPスクリプトにてAMIを作成(登録)します。

require_once("/opt/aws/php/sdk.class.php");

define("AWS_KEY"       , "AAAAAAAA");
define("AWS_SECRET_KEY", "XXXXXXXX");

$ec2 = new AmazonEC2();
$ec2->set_region(AmazonEC2::REGION_APAC_NE1);

$response = $ec2->register_image(array(
    "Name"               => "suz-lab_ebs_centos-core-i386-6.0.0",
    "Architecture"       => "i386",
    "KernelId"           => "aki-ec5df7ed",
    "RootDeviceName"     => "/dev/sda1",
    "BlockDeviceMapping" => array(
        array(
            "DeviceName" => "/dev/sda1",
            "Ebs"        => array(
                "SnapshotId" => "snap-951eb8fe"
            )
        )
    )
));

var_dump($response);

カーネルID(AKI)も上記で紹介した"pv-grub-hd0_1.02-i386.gz.manifest.xml"
(aki-ec5df7ed)を指定します。

上記のカーネル(AKI)はリージョン、プラットフォームごとにIDが違うので、
下記にまとめておきました。
"User Provided Kernel"で使う"pv-grub-hd0/00"が1.02になってた
下記のように"AWS Management Console"で確認できれば成功です。


同じ手順で"x86_64"版も作らないと...
--------
http://www.suz-lab.com

"User Provided Kernel"で使う"pv-grub-hd0/00"が1.02になってた

スズキです。

下記のように、"User Provided Kernel"で使うカーネル(AKI)のバージョンが
アップデート(1.02)されてました。
pv-grub-hd0_1.02-i386.gz.manifest.xml
pv-grub-hd0_1.02-x86_64.gz.manifest.xml
pv-grub-hd00_1.02-i386.gz.manifest.xml
pv-grub-hd00_1.02-x86_64.gz.manifest.xml
このAKIは先日公開した、下記の"CentOS 6.0 AMI"で利用しています。
SUZ-LAB謹製 CentOS AMI (6.0.0 32bit ap-northeast-1)
ですので、全リージョン、全プラットフォームに対応するときのために、
このAKIを下記のようにまとめておきました。

ap-northeast-1 ap-southeast-1 us-west-1 us-east-1 eu-west-1
hd0 i386 aki-ec5df7ed aki-a4225af6 aki-83396bc6 aki-805ea7e9 aki-64695810
hd0 x86_64 aki-ee5df7ef aki-aa225af8 aki-8d396bc8 aki-825ea7eb aki-62695816
hd00 i386 aki-e85df7e9 aki-a0225af2 aki-87396bc2 aki-525ea73b aki-8a6657fe
hd00 x86_64 aki-ea5df7eb aki-a6225af4 aki-81396bc4 aki-8e5ea7e7 aki-60695814

AMIの全リージョン公開スクリプトも、そろそろ作らないと...
--------
http://www.suz-lab.com

SUZ-LAB謹製 CentOS AMI (6.0.0 32bit ap-northeast-1)

スズキです。

AMIを「suz」で検索してもらえれば、
811118151095/suz-lab_ebs_centos-core-i386-6.0.0
として見つかるはずです。

今回は久しぶりに0から、AMIを作成しました。
(作成方法は別途詳しく紹介します)

ログインすると、下記のように、"CentOS 6.0"であることと、
カーネルが、2.6.32系であることがわかります。

# cat /etc/redhat-release 
CentOS Linux release 6.0 (Final)
# uname -a
Linux ip-10-152-37-251 2.6.32-71.29.1.el6.i686 #1 SMP Mon Jun 27 18:07:00 BST 2011 i686 i686 i386 GNU/Linux

インストール内容は、いつものごとく、最小構成です。
("yum"の"groupinstall"で「Core」を指定しています)

また、カーネルは"User Provided Kernel"としており、
"yum install kernel"でインストールされたもの(上記)を利用しています。

Enjoy!
--------
http://www.suz-lab.com

2011年7月28日木曜日

EC2上でRHEL-6.1を使ってみた

スズキです。

そろそろ、"CentOS 6.0"のAMIを作成しようと思っているので、
その前に、本家の"RHEL-6.1"を少しいじってみました。

AMIは"redhat"から下記のように用意されています。
(価格はコチラの通り他の無料Linuxより割高となっています)


早速ログインすると、下記のように確かに"RHEL-6.1"で、カーネルは2.6.32です。

# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.1 (Santiago)
# uname -a
Linux ip-10-150-178-26 2.6.32-131.0.15.el6.i686 #1 SMP Tue May 10 15:42:28 EDT 2011 i686 i686 i386 GNU/Linux

EBSは一つ(/dev/xvde1)で、"_/"のラベルがついています。

# ls /dev/xvd*
/dev/xvde1
# e2label /dev/xvde1 
_/

"/etc/fstab"は下記のようになっており、
ルートのファイルシステムが"ext4"であることがわかります。
(xvda2,xvda3は上記の通り存在しないので有効になっていません)

# cat /etc/fstab 
LABEL=_/   /         ext4    defaults        1 1
/dev/xvda2 /mnt      ext3    defaults,context=system_u:object_r:usr_t:s0  0 0
/dev/xvda3 swap      swap    defaults        0 0
none       /proc     proc    defaults        0 0
none       /sys      sysfs   defaults        0 0
none       /dev/pts  devpts  gid=5,mode=620  0 0
none       /dev/shm  tmpfs   defaults        0 0

さらにカスタムカーネルを利用しており、"/boot/grub/menu.lst"は以下の通りです。

# cat /boot/grub/menu.lst 
default=0
timeout=5
splashimage=(hd0)/boot/grub/splash.xpm.gz
hiddenmenu
title RHEL6.1-20110510.1-Server-i386-starter-ec2 (2.6.32-131.0.15.el6.i686)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-131.0.15.el6.i686 ro root=LABEL=_/ 
        initrd /boot/initramfs-2.6.32-131.0.15.el6.i686.img

そして下記のようにEBSを"/dev/sdb1"で追加してみると、


次の通り、"/dev/xvdf1"として認識されています。

# ls -1 /dev/xvd*
/dev/xvde1
/dev/xvdf1

つまり、
sda1 -> xvde1
sdb1 -> xvdf1
とマッピングされています。(ちょっとびっくりしました)

"Cent OS 6.0"のAMI、作るぞ。
--------
http://www.suz-lab.com

"Route 53"&"R53 Fox"で"Google Apps"のメール設定

スズキです。

下記に続き、今回は"Google Apps"のメール設定です。
"Route 53"&"R53 Fox"でBloggerを独自ドメインに


ドメイン所有権の確認

"Google Apps"の設定を進めていくと、まずはドメイン所有権の確認する必要があります。
やり方はいくつかあるのですが、今回は下記のDNSレコードを追加する方法で進めます。
以下の TXT レコードを fuwafuwabon.com の DNS 設定に追加します。
google-site-verification=xxxxxxxxxxx-xxxxxxxxxxx-xxxxxxxxxxxxxxxxxxx

こちらも"Route 53"&"R53 Fox"を利用することで簡単にレコード追加できます。

注意点として、TXTタイプのレコードを追加するときはVALUEの値を
ダブルクウォートで囲む必要があります。


下記のように確認できれば、OKです。

$ nslookup -type=TXT fuwafuwabon.com
Server:  192.168.11.1
Address: 192.168.11.1#53
Non-authoritative answer:
fuwafuwabon.com text = "google-site-verification=xxxxxxxxxxx-xxxxxxxxxxx-xxxxxxxxxxxxxxxxxxx"

この状態で、"Google Apps"上でドメイン所有権の確認処理を進めることができます。


MX(Mail Exchange)レコードの設定

下記のように設定します。

MXサーバーアドレス       優先順位
ASPMX.L.GOOGLE.COM.            10
ALT1.ASPMX.L.GOOGLE.COM.       20
ALT2.ASPMX.L.GOOGLE.COM.       20
ASPMX2.GOOGLEMAIL.COM.         30
ASPMX3.GOOGLEMAIL.COM.         30
ASPMX4.GOOGLEMAIL.COM.         30
ASPMX5.GOOGLEMAIL.COM.         30

"R53 Fox"では下記のように設定すればOKです。

注意点として、MXタイプのレコードを追加するときはVALUEの値に複数追加し、
さらに優先順位を前に置き、スペースの後、DNS名を記述します。


下記のように確認できれば、OKです。

$ nslookup -type=MX fuwafuwabon.com
Server:  192.168.11.1
Address: 192.168.11.1#53
Non-authoritative answer:
fuwafuwabon.com mail exchanger = 20 alt1.aspmx.l.google.com.
fuwafuwabon.com mail exchanger = 20 alt2.aspmx.l.google.com.
fuwafuwabon.com mail exchanger = 30 aspmx2.googlemail.com.
fuwafuwabon.com mail exchanger = 30 aspmx3.googlemail.com.
fuwafuwabon.com mail exchanger = 30 aspmx4.googlemail.com.
fuwafuwabon.com mail exchanger = 30 aspmx5.googlemail.com.
fuwafuwabon.com mail exchanger = 10 aspmx.l.google.com.

この状態で、"Google Apps"のメール機能を有効にできます。


迷惑メール防止のためのSPFレコードを設定

"Google Apps"のヘルプに下記のように記載されているので、
以下のテキストを含む TXT レコードを作成します: v=spf1 include:_spf.google.com ~all
"R53 Fox"で次のように設定します。

注意点として、すでに"ドメイン所有権の確認"でTXTタイプのレコードが
追加済みなので、下記のように同じVALUEの値に"ドメイン所有権の確認"と
SPFレコードを記述する形となります。


実際にメールを送って、下記のようなヘッダがついていればOKです。

Received-SPF: pass (google.com: domain of suzuki@fuwafuwabon.com designates 209.85.216.48 as permitted sender) client-ip=209.85.216.48;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of suzuki@fuwafuwabon.com designates 209.85.216.48 as permitted sender)


メールのURLを変更

デフォルトでは、メール機能のURLは、
http://mail.google.com/a/fuwafuwabon.com
ですが、これを、
http://mail.fuwafuwabon.com/
でアクセスできるようにします。

こちらは下記のように、"mail.fuwafuwabon.com"のCNAMEレコードを、
"ghs.google.com"と設定すればOKです。


下記のように確認できれば、OKです。

$ nslookup mail.fuwafuwabon.com
Server:  192.168.11.1
Address: 192.168.11.1#53
Non-authoritative answer:
mail.fuwafuwabon.com canonical name = ghs.google.com.
ghs.google.com canonical name = ghs.l.google.com.
Name: ghs.l.google.com
Address: 74.125.153.121

この状態で、"Google Apps"側も下記のように設定すれば、
"mail.fuwafuwabon.com"でメール機能にアクセスできるようになります。


一時間、遅れてしまった...
--------
http://www.suz-lab.com

2011年7月27日水曜日

"Route 53"&"R53 Fox"でBloggerを独自ドメインに

スズキです。

以前、下記で簡単に"R53 Fox"を紹介しましたが、
"R53 Fox"(新機能に対応済み)を利用してみた
今回は、本ブログでも利用しているBloggerを"Route 53"&"R53 Fox"で
独自ドメイン化する方法を紹介します。


ドメインの作成

まずは、ドメインの作成です。左下の"Create"ボタンから行います。





独自ドメインの登録

次に、独自ドメインのDNS名の登録です。
CNAMEで"ghs.google.com"を指定する必要があります。
下記に詳しく書かれています。
ブログでカスタム ドメイン名を使用する




ネームサーバの変更

そして、ドメインに対するネームサーバを"Route 53"のものに変更します。
ネームサーバはNSタイプのレコードの詳細から、下記のように確認できます。


今回は"VALUE DOMAIN"でドメインを取得しているので、
下記のように、確認したネームサーバを登録します。


次のように確認できれば、今までの設定が無事反映されたことになります。

$ whois fuwafuwabon.com
...
nameserver: ns-1530.awsdns-63.org
nameserver: ns-1829.awsdns-36.co.uk
nameserver: ns-211.awsdns-26.com
nameserver: ns-576.awsdns-08.net
...

$ nslookup blog.fuwafuwabon.com
Server:          192.168.11.1
Address:     192.168.11.1#53
Non-authoritative answer:
blog.fuwafuwabon.com     canonical name = ghs.google.com.
ghs.google.com     canonical name = ghs.l.google.com.
Name:     ghs.l.google.com
Address: 74.125.153.121


Bloggerでカスタムドメインの設定

最後にBloggerの管理画面でカスタムドメインの設定です。
「設定」→「公開」→「カスタム ドメイン」→「詳細設定に切り替え」
から下記のように設定します。


これで、指定した独自ドメインでBloggerにアクセスできます。

次は"Google Apps"もやってみよう。
--------
http://www.suz-lab.com

2011年7月26日火曜日

AWStatsの結果(CloudFrontのログ)を静的なコンテンツとして出力

スズキです。

下記でCloudFrontのログの解析までできたので、
AWStatsでCloudFrontのログを解析
次は解析結果を静的なコンテンツとして出力してみます。

今回はMacではなくCentOS上で行ったので、準備として下記を実施しておきます。

# yum install awstats

コマンドのパスがMacの場合と違うので、
設定ファイル(/etc/awstats/awstats.cloudfront.conf)も下記の項目を変更しておきます。

LogFile="/usr/bin/logresolvemerge.pl /tmp/log/*.gz |"
※あとは下記で紹介した設定ファイルと同じです。
AWStatsでCloudFrontのログを解析

この状態で下記を実行すると、解析結果の静的なコンテンツが出力されます。

# awstats_buildstaticpages.pl
> -config=cloudfront
> -update
> -lang=jp
> -month=02
> -year=2011
> -awstatsprog=/var/www/awstats/awstats.pl
> -diricons=./icon
Launch update process : "/var/www/awstats/awstats.pl" -config=cloudfront -update -configdir=
Build main page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output
Build alldomains page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=alldomains
Build allhosts page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=allhosts
Build lasthosts page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=lasthosts
Build unknownip page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=unknownip
Build allrobots page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=allrobots
Build lastrobots page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=lastrobots
Build session page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=session
Build urldetail page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=urldetail
Build urlentry page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=urlentry
Build urlexit page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=urlexit
Build osdetail page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=osdetail
Build unknownos page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=unknownos
Build browserdetail page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=browserdetail
Build unknownbrowser page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=unknownbrowser
Build refererse page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=refererse
Build refererpages page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=refererpages
Build keyphrases page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=keyphrases
Build keywords page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=keywords
Build errors404 page: "/var/www/awstats/awstats.pl" -config=cloudfront -staticlinks -diricons=./icon -lang=jp -month=02 -year=2011 -output=errors404
20 files built.
Main HTML page is 'awstats.cloudfront.html'.

"icon"ディレクトリをコピーすれば、ディレクトリ内は下記のようになり、

# cp -r /var/www/awstats/icon ./
# ls -1
awstats.cloudfront.alldomains.html
awstats.cloudfront.allhosts.html
awstats.cloudfront.allrobots.html
awstats.cloudfront.browserdetail.html
awstats.cloudfront.errors404.html
awstats.cloudfront.html
awstats.cloudfront.keyphrases.html
awstats.cloudfront.keywords.html
awstats.cloudfront.lasthosts.html
awstats.cloudfront.lastrobots.html
awstats.cloudfront.osdetail.html
awstats.cloudfront.refererpages.html
awstats.cloudfront.refererse.html
awstats.cloudfront.session.html
awstats.cloudfront.unknownbrowser.html
awstats.cloudfront.unknownip.html
awstats.cloudfront.unknownos.html
awstats.cloudfront.urldetail.html
awstats.cloudfront.urlentry.html
awstats.cloudfront.urlexit.html
icon

次のように、ブラウザで解析結果(awstats.cloudfront.html)を確認することができます。


上記は、特にクラスター(エッジサーバ)の結果となっています。

cloudpackに組み込もう...
--------
http://www.suz-lab.com

2011年7月25日月曜日

AWStatsでCloudFrontのログを解析

スズキです。

下記のログのマージ&ソート(日付)をやりましたが、
CloudFrontのログとAWStatsを使ったログのマージ&ソート(日付)
引き続き、AWStatsでの解析も試してみます。

といっても、下記のように設定ファイルを作成し、

$ su -
Password:
# cd /opt/local/etc/awstats/
# cp awstats.model.conf awstats.cloudfront.conf

設定項目を下記のようにし、

LogFile="/opt/local/www/awstats/tools/logresolvemerge.pl /Users/suzuki/Temp/*.gz |"
LogFormat="%time2 %cluster %bytesd %host %method %virtualname %url %code %referer %ua %query"
LogSeparator="\t"
SiteDomain="dhisjetezncwd.cloudfront.net"
HostAliases="dhisjetezncwd.cloudfront.net"
DNSLookup=1
ShowClusterStats=1

下記のように実行すれば解析され、結果が"awstats.pl"と同じディレクトリ内に
"awstats042011.cloudfront.txt"のようなファイルとして出力されます。

# /opt/local/www/awstats/cgi-bin/awstats.pl -config=cloudfront
Create/Update database for config "/opt/local/etc/awstats/awstats.cloudfront.conf" by AWStats version 6.9 (build 1.925)
From data in log file "/opt/local/www/awstats/tools/logresolvemerge.pl /Users/suzuki/Dropbox/suz-lab/common/tmp/log/*.gz |"...
Phase 1 : First bypass old records, searching new record...
Searching new records from beginning of log file...
Phase 2 : Now process new records (Flush history on disk after 20000 hosts)...
Jumped lines in file: 0
Parsed lines in file: 135
 Found 0 dropped records,
 Found 0 corrupted records,
 Found 0 old records,
 Found 135 new qualified records.

ここでのポイントは、とにかく設定項目なので一つずつ説明していきます。

LogFile
LogFile="/opt/local/www/awstats/tools/logresolvemerge.pl /Users/suzuki/Temp/*.gz |"

ログファイルを指定します。
ここでは下記のような複数のCloudFrontのログファイルをマージする必要があるので、
下記の内容を反映した形にします。
CloudFrontのログとAWStatsを使ったログのマージ&ソート(日付)

LogFormat
LogFormat="%time2 %cluster %bytesd %host %method %virtualname %url %code %referer %ua %query"

ログのフォーマットを指定します。実際のCloudFrontのログファイルは下記の通りです。
(詳しくは下記を参考にして下さい)
Log File Format

#Version: 1.0
#Fields: date time x-edge-location sc-bytes c-ip cs-method cs(Host) cs-uri-stem sc-status cs(Referer) cs(User-Agent) cs-uri-query
2010-07-20 10:05:00 NRT4 570 219.117.209.225 GET dhisjetezncwd.cloudfront.net /img/test.jpg 304 - Mozilla/5.0%20(Macintosh;%20U;%20Intel%20Mac%20OS%20X%2010_6_4;%20en-US)%20AppleWebKit/533.4%20(KHTML,%20like%20Gecko)%20Chrome/5.0.375.99%20Safari/533.4 -
2010-07-20 10:05:00 NRT4 872 219.117.209.225 GET dhisjetezncwd.cloudfront.net /favicon.ico 404 - Mozilla/5.0%20(Macintosh;%20U;%20Intel%20Mac%20OS%20X%2010_6_4;%20en-US)%20AppleWebKit/533.4%20(KHTML,%20like%20Gecko)%20Chrome/5.0.375.99%20Safari/533.4 -

ですので次のようにマッピングする必要があります。

date time       : %time2       : タイムスタンプ (yyyy-mm-dd hh:mm:ss)
x-edge-location : %cluster     : 複数マシンを利用している場合のマシンID
sc-bytes        : %bytesd      : レスポンスのバイト数
c-ip            : %host        : クライアントのIP
cs-method       : %method      : HTTPメソッド (GET/POST/...)
cs(Host)        : %virtualname : バーチャルホスト名
cs-uri-stem     : %url         : アクセスパス
sc-status       : %code        : ステータスコード
cs(Referer)     : %referer     : リファラー
cs(User-Agent)  : %ua          : User Agent (IE/Firefox/...)
cs-uri-query    : %query       : Query String (アクセスパスの?の後ろ)

※ここでは、どのエッジサーバにアクセスされたか?が記録される、
"x-edge-location"に"%cluster"を割り当ててみました。

LogSeparator
LogSeparator="\t"

CloudFrontのログはタブ区切りなので、上記のように指定します。

SiteDomain / HostAliases
SiteDomain="dhisjetezncwd.cloudfront.net"
HostAliases="dhisjetezncwd.cloudfront.net"

解析対象のドメイン(ホスト)名を指定しています。

DNSLookup
DNSLookup=1

IPアドレスの名前解決を行います。(行わない場合は0です)

ShowClusterStats
ShowClusterStats=1

クラスタ(%cluster)に関する統計情報を表示します。

実際に出力結果(awstats042011.cloudfront.txt)を確認すると、

...
# Cluster ID - Pages - Hits - Bandwidth
BEGIN_CLUSTER 7
JFK1 1 2 871
LAX1 4 4 5285
AMS1 2 2 3546
STL2 2 2 3546
MIA3 3 4 4417
FRA2 114 114 118076
NRT4 7 7 11556
END_CLUSTER
...

といった感じで、エッジサーバごとの統計も確認できることがわかります。

でも、なぜかHTMLファイルには反映されない...
--------
http://www.suz-lab.com

CloudFrontのログとAWStatsを使ったログのマージ&ソート(日付)

スズキです。

下記のようにCloudFrontはログを出力することができます。



CloudFrontのログが、選択したS3バケットのプレフィックスで指定したディレクトリに
出力されていることがわかります。

実際のログファイル名は下記のようになっており、gzipで圧縮もされています。
{Bucket}.s3.amazonaws.com/{Optional Prefix You Choose}/{Distribution ID}.{YYYY}-{MM}-{DD}-{HH}.{Unique ID}.gz
詳しくはコチラを参照して下さい。
File Naming and Timing of File Delivery

そして下記のCloudFrontログファイルを、AWStatsのツールでマージ&ソート(日付)です。

$ ls -1
XXXXXXXXXXXXXX.2011-04-13-21.55w2iVnZ.gz
XXXXXXXXXXXXXX.2011-04-14-09.s8Bk8mlo.gz
...

ファイルの中身は下記の通りです。

#Version: 1.0
#Fields: date time x-edge-location sc-bytes c-ip cs-method cs(Host) cs-uri-stem sc-status cs(Referer) cs(User-Agent) cs-uri-query
2010-07-20 10:05:00 NRT4 570 219.117.209.225 GET dhisjetezncwd.cloudfront.net /img/test.jpg 304 - Mozilla/5.0%20(Macintosh;%20U;%20Intel%20Mac%20OS%20X%2010_6_4;%20en-US)%20AppleWebKit/533.4%20(KHTML,%20like%20Gecko)%20Chrome/5.0.375.99%20Safari/533.4 -
2010-07-20 10:05:00 NRT4 872 219.117.209.225 GET dhisjetezncwd.cloudfront.net /favicon.ico 404 - Mozilla/5.0%20(Macintosh;%20U;%20Intel%20Mac%20OS%20X%2010_6_4;%20en-US)%20AppleWebKit/533.4%20(KHTML,%20like%20Gecko)%20Chrome/5.0.375.99%20Safari/533.4 -
...

今回はAWStatsをMacPortsからインストールしており、コマンドは下記の通りです。
("logresolvemerge.pl"を利用しています)

$ sudo port install awstats
$ /opt/local/www/awstats/tools/logresolvemerge.pl ./*
2011-04-21      13:14:54        MIA3    666     66.249.71.67    GET     dhisjetezncwd.cloudfront.net    /suz-lab.gif    304     -       Googlebot-Image/1.0 -
2011-04-23      03:57:47        FRA2    2681    95.108.241.252  GET     dhisjetezncwd.cloudfront.net    /       200     -       Mozilla/5.0%20(compatible;%20YandexBot/3.0;%20+http://yandex.com/bots)       -
...

これで複数のCloudFrontのログをマージ&ソート(日付)することができました。

次は実際にAWStatsで解析してみます。
--------
http://www.suz-lab.com

2011年7月20日水曜日

SimpleDBのConsistentReadオプションを試してみた

スズキです。

SimpleDBでデータを取得するとき、デフォルトでは"Eventually Consistent"と呼ばれ、
常に最新のデータが取得できるわけではありません。

必ず最新のデータを取得したい場合は、ConsistentReadオプションを利用します。

というわけで、下記のコードで試してみました。
(ConsistentReadの値は論理値ではなく文字列"true"/"false"なので注意が必要です)

define("AWS_KEY"       , "AAAAAAAA");
define("AWS_SECRET_KEY", "SSSSSSSS");
require_once("/opt/aws/php/sdk.class.php");
$sdb = new AmazonSDB();
$sdb->set_region(AmazonSDB::REGION_APAC_NE1);
$consistency = "true"; // or false
for($i = 0; $i < 10; $i++) {
    $response = $sdb->put_attributes("log", "key", array(
        "message" =>$i 
    ), true);
    $response = $sdb->get_attributes(
        "log",
        "key",
        null,
        array("ConsistentRead" => $consistency)
    );
    print($i . " " . $response->body->GetAttributesResult->Attribute->Value . "\n");
}

まずは、ConsistentReadが"false"、つまりデフォルトの場合です。

0 0
1 1
2 1
3 2
4 4
5 4
6 5
7 7
8 7
9 8

書き込んだ値と読み取った値がずれている場合があることがわかります。

次に、ConsistentReadが"true"の場合です。

0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9

書き込んだ値と読み取った値が同じになっていることがわかります。

"Conditional put and delete"っていうのも確認しておこう。
--------
http://www.suz-lab.com

"resize2fs"でEBSの容量を増やす

スズキです。

今まで、EBSの容量を増やすには、より大きな容量のEBSをマウントして、
移行元のEBSから移行先のEBSに内容をコピーして、シンボリックリンクを変更したり、
移行先のEBSのマウントポイントを移行元EBSのものに変更したりしていました。

今回はスナップショットを利用した方法を紹介します。

とりあえず、下記のように"/dev/sdf"にアタッチされた1GのEBSが、
"/vol"にマウントされているとします。

# df -h
Filesystem          サイズ  使用  残り 使用% マウント位置
...
/dev/sdf             1008M   34M  924M   4% /vol

内容も下記の通りです。

# ls /vol/
lost+found  test.txt

まずはアンマウントからなのですが、"/dev/sdf"が利用されてないことを確認します。

利用されている場合は、こんな感じに出力されます。
アンマウントするには、何も利用していない状態にしないと行けないので、
すべてのプロセスを終了します。

# lsof /dev/sdf 
COMMAND   PID USER   FD   TYPE DEVICE SIZE NODE NAME
bash    19087 root  cwd    DIR   8,80 4096    2 /vol
lsof    19255 root  cwd    DIR   8,80 4096    2 /vol
lsof    19256 root  cwd    DIR   8,80 4096    2 /vol

利用されてない場合は、何も出力されなくなります。

# lsof /dev/sdf

そしてアンマウントです。

# umount /vol

ここからは、いったん、"AWS Management Console"での作業です。

早速、EBSをデタッチして、


スナップショットを作成して、


スナップショットからボリュームを作り直して、


そのときにサイズを増やして、


EC2にアタッチしなおします。


再度、EC2のターミナルに戻って、マウントします。

# mount /dev/sdf /vol

しかし、このままでは、元のディスクの容量のままです。

# df -h
Filesystem          サイズ  使用  残り 使用% マウント位置
...
/dev/sdf             1008M   34M  924M   4% /vol

増やした容量にするためには、下記のように"resize2fs"を利用します。

# resize2fs /dev/sdf 
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/sdf is mounted on /vol; on-line resizing required
Performing an on-line resize of /dev/sdf to 1310720 (4k) blocks.
The filesystem on /dev/sdf is now 1310720 blocks long.

すると、ちゃんと増やした容量分、使えるようになります。

# df -h
Filesystem          サイズ  使用  残り 使用% マウント位置
...
/dev/sdf              5.0G   35M  4.7G   1% /vol

ディスクの内容も、もとのままです。

# ls /vol/
lost+found  test.txt

今度のディスク増量は、こっちのやり方でやろう。
--------
http://www.suz-lab.com

CloudWatchでSQSのメトリクスが取得可能に

スズキです。

七夕のお願いが叶ったので、レポートしておきます。

SQSのキューのサイズがCloudWatchで見れますように。(カスタムメトリクスじゃなくて) #AWS77 #jawsugless than a minute ago via Tweet-Watch Favorite Retweet Reply



"AWS Management Console"の"CloudWatch"タブを確認すると、
左のメニューの下部に"SQS"の項目があることがわかります。


クリックすると、下記のメトリクスが取得できていることもわかります。
  • NumberOfMessagesSent
  • SentMessageSize
  • NumberOfMessagesReceived
  • NumberOfEmptyReceives
  • NumberOfMessagesDeleted
  • ApproximateNumberOfMessagesVisible
  • ApproximateNumberOfMessagesNotVisible
各メトリックスはこんな感じです。(詳しくは下記を参照してください)
Amazon SQS Dimensions and Metrics
サンプルグラフも入れてますが、これは、一気にキューに500程度メッセージを入れ、
そのメッセージを10インスタンスのEC2で処理(5分程度)し続けたものです。

NumberOfMessagesSent (個数)
キューに追加されたメッセージ数

いっきに500程度のメッセージが追加されていることがわかります。

SentMessageSize (バイト数)
キューに追加されたメッセージのバイト数

NumberOfMessagesReceived (個数)
"ReceiveMessage API"で取得したメッセージ数

5分で15メッセージ程度を処理していることがわかります。

NumberOfEmptyReceives (個数)
"ReceiveMessage API"でメッセージが取得できなかった数

NumberOfMessagesDeleted (個数)
キューから削除されたメッセージ数

メッセージを取得して処理して削除しているので、
「取得したメッセージ数」とほぼ同じグラフです。

ApproximateNumberOfMessagesVisible (個数)
キューから取得可能なメッセージ数

最初の500程度のメッセージ数から順調に減少していることがわかります。

ApproximateNumberOfMessagesNotVisible (個数)
クライアントに送信されてもまだ削除されてないメッセージや
可視状態に戻っていないメッセージの数

Visibilityも含めた詳しい説明は下記が参考になります。
Amazon SQSってなんじゃ?(その1 Scratchpad編)

ということで、SQSのキューのメッセージ数をトリガーにした、"Auto Scaling"や
"SNS"のアクションがカスタムメトリクス無しで、できるようになりました。
--------
http://www.suz-lab.com

2011年7月19日火曜日

VarnishからオリジンサーバにHostヘッダを変更してアクセス

スズキです。

久しぶりのVarnishネタです。

前回は下記のように、リダイレクト専用のWebサーバの設定をしました。
Varnishでリダイレクト専用Webサーバの構築

今回は単純なキャッシュサーバですが、オリジンサーバへのアクセス時に、
ユーザーがリクエストしたときのHostヘッダではなく、
任意のHostヘッダに変更してアクセスする設定です。

ユーザーがリクエストしたときのHostヘッダのままで、
オリジンサーバ(origin.suz-lab.com)にアクセスする場合は、
単に"/etc/varnish/default.vcl"を下記のようにするだけでOKです。

backend default {
    .host = "origin.suz-lab.com";
    .port = "80";
}

しかし、バーチャルホストのからみなどで、Hostヘッダを変更してアクセスする場合は、
下記のように"vcl_recv"の"req.http.host"に変更したいホスト名を設定します。

backend default {
    .host = "origin.suz-lab.com";
    .port = "80";
}
sub vcl_recv {
    set req.http.host = "origin.suz-lab.com";
    return (lookup);
}

これで、オリジンサーバはバーチャルホスト(origin.suz-lab.com)の
コンテンツを返してくれるようになります。

今月も早いなー...、多分、AWSのアップデートが多すぎるのが原因だけど...
--------
http://www.suz-lab.com

JAWS-UG山口第2回勉強会にいってきました

スズキです。

下記の勉強会に参加しました。
JAWS-UG Yamaguchi 【第2回勉強会】

タイムテーブルが多少変更になり、発表は下記の通りでした。
「AmazonWebServicesについて」( Serverworsk 大石さん)
「ヌーラボのAWSの使いかた」( ヌーラボ 山本さん)
「RDS(MySQL)の利用と注意点」(cloudpack 鈴木)
「SimpleDBを使った業務ソフト作成とハマリどころ」(ビジロジ 野村さん)
「JAWS-UG山口これからの取組」(JAWS-UG山口代表 藤崎さん)

「AmazonWebServicesについて」
( Serverworsk 大石さん)
とりあえず結論は
できるだけEC2を使わない!
でした。これは、僕もAgreeで、そこそこAWS使ってる人は、
みんなそう思っているのではないか、と思ってるくらいです。

AWSの利用にあたり、おそらく最初に扱うプロダクトはEC2(仮想サーバ)で、
仮想サーバゆえに、今まで通りにEC2にさまざまなサーバアプリケーションを導入して、
今まで通りに運用していくパターンが、やはり多いのでは、と思います。

しかしAWSには、そのサーバアプリケーションの機能もサービスを提供しており、
できるだけ、そのサービスを利用し、EC2で運用する機能を減らしましょう、
というお話でした。

さらに、AWSが用意しているサービスの中で、
Route53: 世界中で分散しているSLA100%のDNSサービス(BIND使うな!)
S3: 入出力がすべてHTTPのWebストレージ(S3の受信データ転送料は金がかかる!)
CloudFront: CDN(EC2並べる前にCloudFrontを検討しよう!)
を詳しく掘り下げてくれてました。

「ヌーラボのAWSの使いかた」
( ヌーラボ 山本さん)
BacklogやCacooが有名ですが、受託開発も半々程度でやっているようです。

特にCacooはlifehackerやTechCrunchで取り扱われ、海外ユーザーの激増を経験し、
今回は、そのときのAWS移行でのノウハウのお話となります。

海外ユーザーからの不満は、結局はFlash(swf)のダウンロードが遅いということで、
そもそも60%が海外ユーザーで、さらにUSユーザーが最大のため、
USのAWSとCloudFrontの利用を検討することになったようです。

ただ、この時点ではCloudFrontはHTTPSに対応していないため、...
と思っていたら対応してしまったため、移行することになりました。

実際、日本-米国間でのFlash(swf)のダウンロードに20秒かかっていたものが、
CloudFrontだた2秒になり、劇的に改善したようです。

移行に関しては、やはり、一番の注意点はデータ移行で、
PostgreSQLのベースバックアップとアーカイブログを用いて差分的な移行を行い、
400GBのデータ量でも30分程度の停止時間で移行できています。

最後にデータ移行で大切なこととして、
  • 綿密な手順
  • リカバリープラン
  • リハーサル
  • 丁寧な担当者
を挙げてくれ、この辺りは業務で頻繁にAWSへの移行を行うものとしては、
非常に参考になりました。

「RDS(MySQL)の利用と注意点」
(cloudpack 鈴木)
僕の発表です。資料は下記となります。
JAWS-UG山口第2回勉強会LT資料「RDS(MySQL)の利用と注意点」
結構、概要は簡単にして、細かいところを話してしまったので、
わかりにくかっただろうなー、と反省がいっぱいでした...

何かありましたら、ブログのコメントやTwitterなどで連絡していただければ、
と思います。

「SimpleDBを使った業務ソフト作成とハマリどころ」
(ビジロジ 野村さん)
SimpleDBはあまり使う機会がないので、いい復習になりました。
下記がポイントとなります。
  • リージョンを指定しないとUS東海岸になってしまう。
    (気づかないとSimpleDB遅い...ってことに)
  • データの追加と更新はputのオプション(true/false)していする。
    (trueだと更新、falseだと追加)
  • ConsistentRead(読み取り一貫性)がきかない!?
    (アプリで0.5秒待たせてる... → SUZ-LAB的に確認しておこう)

  • ソートキーはWHERE句で登場していなければならない...
    (select * from TEST where TEST1 is not null order by TEST1)
「JAWS-UG山口これからの取組」
(JAWS-UG山口代表 藤崎さん)
最後にJAWS-UG山口代表の藤崎さんから、山口界隈のAWSの利用に関する状況と、
今後の取り組みに関してお話がありました。

僕のまわりはAWS一色ですが、やはり、AWSというかクラウドの普及は
まだまだこれからで、皆さんと一緒にがんばっていかなければ、と思った次第です。

懇親会も非常に楽しく、ためになりました。フグのおいしい時期にまた行きます!
--------
http://www.suz-lab.com

2011年7月15日金曜日

JAWS-UG山口第2回勉強会LT資料「RDS(MySQL)の利用と注意点」

スズキです。

下記で紹介した勉強会(東京)のLT資料です。
"AWS User Group (東京/山口)"でLTします

予備の資料も作っておこう。
--------
http://www.suz-lab.com

2011年7月14日木曜日

JAWS-UG東京第9回勉強会LT資料「雲(AWS)に願いを!」

スズキです。

下記で紹介した勉強会(東京)のLT資料です。
"AWS User Group (東京/山口)"でLTします

山口もつくらないと...
--------
http://www.suz-lab.com

2011年7月13日水曜日

"Oracle RDS"でトレースファイルを取得

スズキです。

下記で、アラートログとリスナーログの取得を紹介したので、
"Oracle RDS"のアラートログとリスナーログを確認
今回はトレースファイルの内容の取得です。
(トレースファイルは、エラーなどの発生状況をより詳細に記録したファイルです)

まずは下記のように準備します。

SQL> exec rdsadmin.manage_tracefiles.refresh_tracefile_listing;
PL/SQLプロシージャが正常に完了しました。

こんなビューができて、

SQL> desc rdsadmin.tracefile_listing;
名前      型                                       
--------  -------------
FILENAME  VARCHAR2(400)
TYPE      VARCHAR2(12)
FILESIZE  NUMBER
MTIME     VARCHAR2(400)

内容はこんな感じです。

SQL> select FILENAME from rdsadmin.tracefile_listing; 
FILENAME
----------------------------
...
alert_SUZLAB.log.2011-07-09
SUZLAB_m000_30430.trc
SUZLAB_j000_19395.trm
...

トレースファイルの内容は、上記でリスティングしたトレースファイル名を、
下記のように指定してPL/SQLプロシージャを実行し、"tracefile_table"をSELECTすることで確認できます。

SQL> exec rdsadmin.manage_tracefiles.set_tracefile_table_location('SUZLAB_m000_30430.trc');
PL/SQLプロシージャが正常に完了しました。
SQL> select * from tracefile_table;
TEXT
--------------------------------------------------------------------------------
Trace file /rdsdbdata/log/diag/rdbms/suzlab_a/SUZLAB/trace/SUZLAB_m000_30430.trc
Oracle Database 11g Release 11.2.0.2.0 - 64bit Production
ORACLE_HOME = /rdsdbbin/oracle
System name: Linux
Node name: ip-10-146-1-184
Release: 2.6.18-238.el5xen
Version: #1 SMP Sun Dec 19 14:42:02 EST 2010
Machine: x86_64
VM name: Xen Version: 3.4 (PVM)
Instance name: SUZLAB
Redo thread mounted by this instance: 1
Oracle process number: 28
Unix process pid: 30430, image: oracle@ip-10-146-1-184 (M000)
...

"hanganalyze"情報が欲しい場合は下記のようにします。

SQL> exec rdsadmin.manage_tracefiles.hanganalyze;
PL/SQLプロシージャが正常に完了しました。
SQL> exec rdsadmin.manage_tracefiles.set_tracefile_table_location('SUZLAB_ora_18585_HANGANALZE.trc');
PL/SQLプロシージャが正常に完了しました。
SQL> select * from tracefile_table;
TEXT
--------------------------------------------------------------------------------
...

"systemstate"情報が欲しい場合は下記のようにします。

SQL> exec rdsadmin.manage_tracefiles.dump_systemstate;
PL/SQLプロシージャが正常に完了しました。
SQL> exec rdsadmin.manage_tracefiles.set_tracefile_table_location('SUZLAB_ora_18810_SYSTEMSTATE.trc');
PL/SQLプロシージャが正常に完了しました。
SQL> select * from tracefile_table;
TEXT
--------------------------------------------------------------------------------
...

@kaz_gotoさん、使えるところは使ってください。
--------
http://www.suz-lab.com

2011年7月12日火曜日

AWSの認証と認定

スズキです。

2011/07/12の時点です。

PCI DSS Level 1
クレジットカード情報および取り引き情報を保護するために策定された
グローバルセキュリティ基準。
(参考)
PCI データセキュリティ基準

ISO 27001
組織内の機密情報を漏洩させないことを目的とした
社内体制を整備するための国際規格。
(参考)
ISO27001 ISMS 情報セキュリティマネジメントシステム

SAS 70 Type II
業務の外部委託先で内部統制の仕組みが存在し
適切に運用されているかを評価。
(参考)
クラウド・コンピューティングで重要な用語の一つ「SAS 70 Type II」を探ってみよう!

忘れたころに必要になるので、自分メモとして。
--------
http://www.suz-lab.com

"Oracle RDS"のアラートログとリスナーログを確認

スズキです。

Oracleは基本的にアラートログやリスナーログはファイルに書き出され、
ファイルを閲覧することで確認することができます。

しかし、RDSはファイルにアクセスすることができません。
そのため、RDSではログ用のテーブルが用意され、
そのテーブルにログが書き込まれるようになっています。

アラートログはこんな感じです。

SQL> desc alertlog;
 名前                        型
 --------------------------  ---------------------------
 ADDR                        RAW(8)
 INDX                        NUMBER
 INST_ID                     NUMBER
 ORIGINATING_TIMESTAMP       TIMESTAMP(3) WITH TIME ZONE
 NORMALIZED_TIMESTAMP        TIMESTAMP(3) WITH TIME ZONE
 ORGANIZATION_ID             VARCHAR2(64)
 COMPONENT_ID                VARCHAR2(64)
 HOST_ID                     VARCHAR2(64)
 HOST_ADDRESS                VARCHAR2(46)
 MESSAGE_TYPE                NUMBER
 MESSAGE_LEVEL               NUMBER
 MESSAGE_ID                  VARCHAR2(64)
 MESSAGE_GROUP               VARCHAR2(64)
 CLIENT_ID                   VARCHAR2(64)
 MODULE_ID                   VARCHAR2(64)
 PROCESS_ID                  VARCHAR2(32)
 THREAD_ID                   VARCHAR2(64)
 USER_ID                     VARCHAR2(64)
 INSTANCE_ID                 VARCHAR2(64)
 DETAILED_LOCATION           VARCHAR2(160)
 PROBLEM_KEY                 VARCHAR2(64)
 UPSTREAM_COMP_ID            VARCHAR2(100)
 DOWNSTREAM_COMP_ID          VARCHAR2(100)
 EXECUTION_CONTEXT_ID        VARCHAR2(100)
 EXECUTION_CONTEXT_SEQUENCE  NUMBER
 ERROR_INSTANCE_ID           NUMBER
 ERROR_INSTANCE_SEQUENCE     NUMBER
 VERSION                     NUMBER
 MESSAGE_TEXT                VARCHAR2(2048)
 MESSAGE_ARGUMENTS           VARCHAR2(128)
 SUPPLEMENTAL_ATTRIBUTES     VARCHAR2(128)
 SUPPLEMENTAL_DETAILS        VARCHAR2(128)
 PARTITION                   NUMBER
 RECORD_ID                   NUMBER
 

実際のログメッセージはこんな感じです。

SQL> select MESSAGE_TEXT from alertlog where ROWNUM >= 1 and ROWNUM <= 10;
MESSAGE_TEXT
--------------------------------------------------------------------------------
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Shared memory segment for instance monitoring created
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on.
IMODE=BR
ILAT =32
LICENSE_MAX_USERS = 0
SYS auditing is disabled
 

リスナーログはこんな感じです。

SQL> desc listenerlog
 名前                        型                     
 --------------------------  ---------------------------
 ADDR                        RAW(8)
 INDX                        NUMBER
 INST_ID                     NUMBER
 ADR_PATH_IDX                VARCHAR2(445)
 ADR_HOME                    VARCHAR2(445)
 ORIGINATING_TIMESTAMP       TIMESTAMP(9) WITH TIME ZONE
 NORMALIZED_TIMESTAMP        TIMESTAMP(9) WITH TIME ZONE
 ORGANIZATION_ID             VARCHAR2(67)
 COMPONENT_ID                VARCHAR2(67)
 HOST_ID                     VARCHAR2(67)
 HOST_ADDRESS                VARCHAR2(49)
 MESSAGE_TYPE                NUMBER
 MESSAGE_LEVEL               NUMBER
 MESSAGE_ID                  VARCHAR2(67)
 MESSAGE_GROUP               VARCHAR2(67)
 CLIENT_ID                   VARCHAR2(67)
 MODULE_ID                   VARCHAR2(67)
 PROCESS_ID                  VARCHAR2(35)
 THREAD_ID                   VARCHAR2(67)
 USER_ID                     VARCHAR2(67)
 INSTANCE_ID                 VARCHAR2(67)
 DETAILED_LOCATION           VARCHAR2(163)
 UPSTREAM_COMP_ID            VARCHAR2(103)
 DOWNSTREAM_COMP_ID          VARCHAR2(103)
 EXECUTION_CONTEXT_ID        VARCHAR2(103)
 EXECUTION_CONTEXT_SEQUENCE  NUMBER
 ERROR_INSTANCE_ID           NUMBER
 ERROR_INSTANCE_SEQUENCE     NUMBER
 MESSAGE_TEXT                VARCHAR2(2051)
 MESSAGE_ARGUMENTS           VARCHAR2(131)
 SUPPLEMENTAL_ATTRIBUTES     VARCHAR2(131)
 SUPPLEMENTAL_DETAILS        VARCHAR2(131)
 PARTITION                   NUMBER
 RECORD_ID                   NUMBER
 FILENAME                    VARCHAR2(515)
 PROBLEM_KEY                 VARCHAR2(67)
 VERSION                     NUMBER
 

実際のログメッセージはこんな感じです。

SQL> select MESSAGE_TEXT from listenerlog where ROWNUM >= 1 and ROWNUM <= 10;
MESSAGE_TEXT
--------------------------------------------------------------------------------
Create Relation ADR_CONTROL
Create Relation ADR_INVALIDATION
Create Relation INC_METER_IMPT_DEF
Create Relation INC_METER_PK_IMPTS
System parameter file is /rdsdbbin/oracle/network/admin/listener.ora
Log messages written to /rdsdbbin/oracle/log/diag/tnslsnr/ip-10-146-1-184/l_suzlab_001/alert/log.xml
Trace information written to /rdsdbbin/oracle/log/diag/tnslsnr/ip-10-146-1-184/l_suzlab_001/trace/ora_2564_47782949792496.trc
Trace level is currently 0

Started with pid=2564
 

次はトレースファイル...
--------
http://www.suz-lab.com

"AWS User Group (東京/山口)"でLTします

スズキです。

7/14の東京勉強会と7/15の山口勉強会でLTします。

東京勉強会では、「#AWS77」についてLTさせてもらいます。(@kaz_gotoもLTします)
LT(5分)の内容は、
  • #AWS77の経緯
  • 結果発表
  • その他AWSに関わる諸々
を考えています。

山口勉強会では、「RDS(MySQL)の利用と注意点」についてLTさせてもらいます。
LT(10分)の内容は、
  • RDS(MySQL)の概要
  • よく利用するTIPS
  • 導入・運用上の注意点
を考えています。

資料は本ブログ(実際は"slideshare")に事前に公開できるようにがんばります。

それでは、皆様、当日よろしくお願いいたします。
--------
http://www.suz-lab.com

2011年7月11日月曜日

#AWS77の結果でリコメンデーション(Mahout)

スズキです。

下記で、"Elastic MapReduce"上で"Mahout"を利用して簡単なリコメンデーションを試したので
"Elastic MapReduce"で"Mahout"使ってリコメンデーション
今度は、もう少しリアリティがあるデータで試してみたいと思います。

ちょうど、#AWS77の集計結果があるので、そのデータから、おすすめの「願い事」を
特定のユーザー(@suz_lab, @kaz_goto, @shouhei, @bond_honey)に対して計算してみました。

まずはリコメンデーションの計算に利用するデータの作成です。
#AWS77の集計結果から、下記のプログラムで作成しました。

▼ group_by_user.php: Tweet単位のデータをUser単位に集計
$url = "http://www.suz-lab.com/aws77/tweet.json";
$tweets = json_decode(file_get_contents($url), true);
$id = 1;
$output = array();
foreach($tweets as $tweet) {
  if(!isset($output[$tweet["tweet_user"]])) {
    $output[$tweet["tweet_user"]] = array("id" => $id, "tweets" => array());
    $id++;
  }
  array_push($output[$tweet["tweet_user"]]["tweets"], $tweet["tweet_id"]);
  foreach($tweet["retweet_users"] as $retweet) {
    if(!isset($output[$retweet["retweet_user"]])) {
      $output[$retweet["retweet_user"]] = array("id" => $id, "tweets" => array());
      $id++;
    }
    array_push($output[$retweet["retweet_user"]]["tweets"], $tweet["tweet_id"]);
  }

}
print(json_encode($output));

上記を実行すると下記のようなファイルが作成されます。
./group_by_user.php > group_by_user.json
{
    ...
    "suz_lab":{"id":12,"tweets":[
        "81281819516997632",
        "81277810991300608",
        "81313605047418880",
        "82765546730438656"
    ]},
    "shouhei":{"id":13,"tweets":[
        "81281819516997632",
        "81313605047418880"
    ]},
   ...
}

このファイルを下記のプログラムでMahout用のデータにします。

▼ vote_data.php: "User ID,Tweet ID"の形式に
$file = "group_by_user.json";
$users = json_decode(file_get_contents($file), true);
foreach($users as $user) {
  foreach($user["tweets"] as $tweet) {
    print($user["id"] . "," . $tweet . "\n");
  }
}

上記を実行すると下記のようなファイルが作成されます。
./vote_data.php > vote.txt
...
12,81281819516997632
12,81277810991300608
12,81313605047418880
12,82765546730438656
13,81281819516997632
13,81313605047418880
13,86608704149004289
13,86045577703456768
...

さらに、今回はおすすめ「願い事」を計算する対象ユーザーも限定するので、
下記のようなユーザーIDを記述したファイルを
"s3n://emr.suz-lab.com/input/aws77/user.txt"に配置します。
12
13
15
46

そして、下記で紹介したように、"Elastic MapReduce"です。
"Elastic MapReduce"で"Mahout"使ってリコメンデーション
今回指定した"Jar Arguments"は下記となります。
org.apache.mahout.cf.taste.hadoop.item.RecommenderJob
-Dmapred.output.dir=s3n://emr.suz-lab.com/output/aws77
-Dmapred.input.dir=s3n://emr.suz-lab.com/input/aws77/vote.txt
--usersFile s3n://emr.suz-lab.com/input/aws77/user.txt
--similarityClassname SIMILARITY_COOCCURRENCE
--booleanData true

結果は下記のようになりました。

12 [81297382536515585:21.0,81294622684495872:19.0,83106534015516672:18.0,81297425146458113:15.0,88869226823172096:14.0,88854630196453376:13.0,83076098203725824:10.0,81278165409988608:10.0,88588223273635840:9.0,88769415855882240:9.0]
13 [82765546730438656:12.0,81277810991300608:12.0,81278229155028992:10.0,82584012752830464:9.0,88869044358356992:8.0,88863566211465216:8.0,81277731974811648:8.0,82923122696781824:7.0,88825952167145473:7.0,83853092373798912:7.0]
15 [81277810991300608:23.0,88863566211465216:16.0,83853092373798912:15.0,82923122696781824:15.0,86608704149004289:15.0,88825952167145473:15.0,88869044358356992:13.0,81297323505889280:11.0,81278116756078593:11.0,86045577703456768:10.0]
46 [81281819516997632:7.0,82765546730438656:6.0,81277731974811648:6.0,81313605047418880:5.0,83853092373798912:4.0,82584012752830464:4.0,88825952167145473:4.0,81277810991300608:4.0,81278116756078593:4.0,81297323505889280:4.0]

つまり、おすすめの「願い事」は、

@suz_lab (ID:12)

「SecurityGroupでホスト名(Route53で管理されている物に限定)が指定出来るようになりますように」 #AWS77 #jawsugless than a minute ago via YoruFukurou Favorite Retweet Reply



@shouhei (ID:13)

ELBでsorry画面出せますように(出せないよね?) #AWS77 #jawsugless than a minute ago via Twitter for iPhone Favorite Retweet Reply



@kaz_goto (ID:15)

PostgreSQLのRDSが始まりますように #AWS77 #jawsugless than a minute ago via Janetter Favorite Retweet Reply



@bond_honey (ID:46)

VPCが東京リージョンにきますように。 #AWS77 #jawsugless than a minute ago via web Favorite Retweet Reply



ということになります。

そろそろLTの準備をするか。。。
--------
http://www.suz-lab.com