第3回 AWS User Group - Japan 勉強会 で 発表します

本日開催の第3回 AWS User Group - Japan 勉強会で「AWSによるソーシャルアプリ運用事例」という題で、発表してきます。

gumiが運用しているソーシャルゲームの実際のサーバ構成やどうしてAWSを使うに至ったのかというような話をできればと思ってます。

Amazon RDS で肥大化したslow_logテーブルをクリアする方法

以前AmazonRDSでslow queryを出力するようにする方法にてRDSでslow_logを出力するように設定すると、mysqlデータベースのslow_logテーブルにログが保存されるようになるのですが、このテーブルに保存されたデータは、RDSで作成できるユーザーの権限では削除することができません。

mysql> delete from slow_log;
ERROR 1556 (HY000): You can't use locks with log tables.
mysql> truncate table slow_log;
ERROR 1044 (42000): Access denied for user 'xxxx'@'%' to database 'mysql'

このことはgeneral_logにも言えるのですが、
これに対して、Amazonから以下のストアドプロシージャが提供されています。

mysql.rds_rotate_general_log
mysql.rds_rotate_slow_log 

この2つのストアドプロシージャは新規、既存のものを含めて全てのRDSインスタンスで使用可能で、以下のようにCALL文により実行できます。

CALL mysql.rds_rotate_general_log;
CALL mysql.rds_rotate_slow_log; 

プロシージャの中身はこんな感じです。

mysql> show create procedure rds_rotate_slow_log \G
*************************** 1. row ***************************
           Procedure: rds_rotate_slow_log
            sql_mode: 
Create Procedure: CREATE DEFINER=`rdsadmin`@`localhost` PROCEDURE `rds_rotate_slow_log`()
    READS SQL DATA
    DETERMINISTIC
BEGIN
  CREATE TABLE IF NOT EXISTS mysql.slow_log2 LIKE mysql.slow_log;
  DROP TABLE IF EXISTS mysql.slow_log_backup;
  RENAME TABLE mysql.slow_log TO mysql.slow_log_backup, mysql.slow_log2 TO mysql.slow_log;
END
character_set_client: latin1
collation_connection: latin1_swedish_ci
  Database Collation: latin1_swedish_ci

slow_logと同じスキーマのテーブル、slow_log2を作成し、既存のslow_logテーブルをslow_log_backupに、slow_log2をslow_logにリネームするという作業を行っています。
この際、slow_log_backupテーブルがすでに存在していればDROPしているので、この関数を2回呼ぶと、1回目にバックアップしたデータはなくなってしまうので注意が必要です。

また上記の2つのプロシージャの他にKILL、KILL QUERYを実行できる以下の2つも用意されています。

mysql.rds_kill
mysql.rds_kill_query

Python × Django × AWSで作るソーシャルアプリ～3日に1つアプリをリリースできた理由～

今日の19:30から「Python × Django × AWSで作るソーシャルアプリ～3日に1つアプリをリリースできた理由～」という題目で話をしてきます。


まだ空いてますので、お暇な方はぜひ!
http://atnd.org/events/4846

第2回 AWS User Group - Japan 勉強会 で LTします。

今日行われる
第2回 AWS User Group - Japan 勉強会 - 6/14(月)
で「RDS multi AZ 早速試しました」というタイトルで、RDSとMulti-AZについて話をしてきます。

Mult-AZ機能が搭載されて、実運用にも十分耐えれるようになったRDSについて、簡単に話をしようと思ってます。

もう止まらない。Amazon RDS Multi-AZ Deployments機能をリリース

本日、Amazon RDSの新機能、 Multi-AZ Deploymentsがリリースされました。

Release: Amazon Relational Database Service on 2010-05-17

これにより、RDSのダウンタイムがほぼ0になるという素敵な機能です!

Multi-AZ deploymentを有効にするとプライマリDBとは別のAvailability Zoneにホットスタンバイとしてレプリカが作成されます。
レプリカはプライマリDBと同期していて、プライマリDBが止まると自動的にレプリカにスイッチします。
フェイルオーバーの仕組みはシンプルで、CNAMEレコードを変更し、スタンバイDBに向けるだけです。

スタンバイDBに切りかわるタイミングは以下のとおりです。

• Availabilyty Zoneが落ちた時


• プライマリDBが落ちた時


• DBのスケールを変更した時


• ソフトウェアにパッチを当てている時

DBのバックアップ時に発生していたI/Oフリーズもなくなるようです。たぶんレプリカの方でバックアップを取るようになるのでしょう。

また、レプリカには直接アクセスすることができないので、Read Onlyなクエリをレプリカに逃がすというスケールアウト的な使い方はできません。

忘れてはならないコストですが、利用料は倍になります。
インスタンスが二つになるのでしょうがないと言えばしょうがないですね。


Multi-AZを適用する方法はすごく簡単です。

まずは以下から最新版のコマンドラインツールをダウンロードして使えるようにします。

Amazon RDS Command Line Toolkit

バージョンが1.1.004ならOKです。

$ rds-version
Relational Database Service CLI version 1.1.004 (API 2010-01-01)

あとは以下のコマンドを叩くだけで既存のインスタンスにMulti-AZ 機能を適用できます。

$ rds-modify-db-instance dbname --multi-az true

既存のインスタンスに適用すると、適用中に数分DBがダウンすると書かれているので、実行するタイミングには注意が必要です。

実際試してみたところ、このコマンドを実行するとインスタンスにPending MultAZフラグが立ちます。(rds-describe-db-instancesコマンドで確認できます。)
僕の環境ではコマンド実行から数時間経過しましたがまだPending状態のままです。
PendingからMulti-AZが有効の状態になるにはかなり時間がかかりそうです。

Pendingの状態でもDBには接続できているので、準備ができて、実際に適用するタイミングでちょっとばかりアクセスできなくなるんだと思います。

また、新規作成の際も--multi-azオプションを指定してやるだけみたいです。

これでますますRDSが手放せなくなりそうです。

RDS バックアップから復旧する方法

fooというRDSのインスタンスのバックアップからbarという新規インスタンスを作成する場合、以下のコマンドを実行する。

$ rds-restore-db-instance-to-point-in-time bar -s foo -l

-sでソースにする元のインスタンスの名前(ここではfoo)を指定し、-lで復元可能な最新の時刻のバックアップから復元することを指定する。

復元時刻を指定する場合は、-rオプションを使用する。
指定する時刻はUTC

$ rds-restore-db-instance-to-point-in-time bar -s foo -r 2010-05-04T09:20:00Z

リストア可能な最終時間はrds-describe-db-instancesに--show-longを指定することで確認できる。

$ rds-describe-db-instances --show-long --headers
DBINSTANCE,DBInstanceId,Created,Class,Engine,Storage,Master Username,Status,Endpoint Address,Port,AZ,Backup Retention,PendingBackupRetention,PendingClass,PendingCredentials,PendingStorage,DB Name,Mainte
nance Window,Backup Window,Latest Restorable Time
DBINSTANCE,foo,2010-02-22T10:07:04.933Z,db.m2.4xlarge,mysql5.1,20,owner,available,foo.xxxxxxx.us-east-1.rds.amazonaws.com,3306,us-east-1a,1,(nil),(nil),(nil),(nil),(nil),tue:05:00-mon:09:00,
19:00-21:00,2010-05-06T08:45:00Z

見づらいが、一番最後の2010-05-06T08:45:00Zが復元可能な最終時刻になる。

バックアップが行われるのは1日1回だけだが、バックアップ後のトランザクションが全部保存されているので、それを元に直近1分前程度の状態を復元可能。
このため、バックアップから時間が経過していればしているほど、復元する際に時間がかかる。
特にDBの更新が頻繁だと復元に時間がかかる。
150 updates/sec程度の更新量で5時にバックアップを行っていた場合、9時に復元したところ、1時間程度、19時頃復元したところ、5時間くらいかかった。

EC2のインスタンスにpingを通すためのセキュリティグループの設定

ec2-authorize  -P icmp -t -1:-1 -s 0.0.0.0/0