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

Djangoのパーミッションテーブルを更新するスクリプト

Djangoでproxy modelというものを使って、ひとつのモデルを複数にわけて、
管理するようにした際に、片方のモデルがadminのユーザーパーミッション一覧に
表示されなくて困っていた。

ユーザーパーミッションのテーブルを更新する方法がないかと
調べてみるとこんなページを発見

http://www.djangosnippets.org/snippets/698/

これを参考にパーミッションを更新するスクリプトを書いてみた。

# -*- coding: utf-8 -*-
from django.core.management.base import BaseCommand
from django.contrib.contenttypes.management import update_all_contenttypes
from django.contrib.auth.management import create_permissions
from django.db.models import get_apps


"""
パーミッションを更新する
"""
class Command(BaseCommand):
    def handle(self, *args, **options):

        # Add any missing content types
        update_all_contenttypes()

        # Add any missing permissions
        for app in get_apps():
            create_permissions(app, None, 2)

これをインストール済みのアプリのmanagement/commands/syncpermissions.pyとして保存すれば、以下のコマンドで更新できる。

$ python manage.py syncpermissions

gitでsubversionのようなショートカットを使えるようにする

重い腰をあげて「入門git」を読んでます。

今までsvkと同じような感じでgit commit -aばかり使ってたんですが、
ステージングエリアという概念を今さら知ったり、
ファイルの変更の一部だけコミットできるんだということを知ったり、
これもっと早く読んどけばよかったなーと、ちょっぴり後悔しています。


そんな中でgitコマンドのショートカットの設定方法が書いてあったのでさっそく設定しました。

$ git config --global alias.ci "commit"
$ git config --global alias.stat "status"
$ git config --global alias.co "checkout"

これで、git ci で git commitが、 git stat でgit statusが、git coでgit checkoutが実行できるようになりました。
快適。