2011年10月31日月曜日

SESってなんじゃ?(AWSコンソールにSESが登場)

今回はSESについてです。
アプリケーションを開発する際、ユーザーにメールを一斉送信するような場合が多い時に、メールサーバーの負荷やパフォーマンスに対するコストは忘れがちですが意外とかかり、そのため外部のメール配信専用のサービスを利用することも多いかと思います。
SESは一括メール送信のためのサービスで、EC2でEメールを配信する際には是非つかいたいサービスです。


そのSESがAWSコンソール上で管理できるようになりました。
早速触ってみたいと思います。


AWSコンソールを開くと、右側にSESのタブが表示されていることがわかります。
SESタブを選択すると、SESのダッシュボードが表示されます。



まずは、メールの送信者のメールアドレスを登録します。
「DashBoard」から「Verify a New Sender」のボタンを押すと、下のようにダイアログが表示されるので、送信者のEメールアドレスを入力して「Submit」を押します。


すると、入力したメールアドレスに、確認用のメールが送られる旨のメッセージが表示されます。


AWSサービスから、入力したメールアドレス宛に送信者確認のリンクが記載されたメールが届くので、リンクをクリックしてメールアドレスの実在確認を行います。


リンクをクリックすると、AWSサービスの画面がブラウザに表示され、認証が完了します。


AWSコンソールに戻り、左ペインの「Verified Senders」メニューをクリックすると、右ペインに先ほど登録した送信者のアドレスが表示されています。



 送信者アドレスの右に「Send Test Email」というテスト送信が出来るリンクがあるのでクリックしてみます。
すると、テスト送信用のダイアログが表示されます。
SESでのテスト送信は登録した送信者宛にしか送信できません。
ここでは、先ほどの認証された送信者アドレスの一覧から送信先を選択します。
また、件名と本文を入力し、「Send Test Email」をクリックします。


無事送信者アドレスに、メールが届きました。


 アプリケーションで動的にユーザーに送信するときなど、登録されていないメールアドレスに送信する場合には、「Dash Board」から、「Request Production Access」のボタンを押し、プロダクション環境での利用申請を行うことで、未登録アドレスへの送信が可能になります。





 また、「Dash Board」でメールの使用状況などの統計がわかり、管理しやすくなりました。
本日は以上です。


2011年10月27日木曜日

シェルってなんじゃ?(ワンライナー編1 全文検索)

日々お世話になっている便利なシェルのワンライナーを紹介していきたいと思います。
このシリーズが出たときはネタに困ったときだと思ってください。。


以下は、特定のディレクトリ以下のパターンにマッチしたすべてのファイルから全文検索し、結果を色付けするワンライナーです。

find ディレクトリ -name "パターン" -print | xargs grep "検索ワード" --color=auto

実際に実行してみます。

find ./ -name '*.txt' -print | xargs grep "pack" --color=auto
./src/git/node/CMakeLists.txt:find_package(PythonInterp 2 REQUIRED)
./src/git/node/CMakeLists.txt:# package
./src/git/node/CMakeLists.txt:include("cmake/package.cmake")
./src/s3cmd-1.0.1/files.txt:/usr/lib/python2.4/site-packages/S3/__init__.py
./src/s3cmd-1.0.1/files.txt:/usr/lib/python2.4/site-packages/S3/S3Uri.py
./src/s3cmd-1.0.1/files.txt:/usr/lib/python2.4/site-packages/S3/Progress.py
./src/s3cmd-1.0.1/files.txt:/usr/lib/python2.4/site-packages/S3/AccessLog.py
./src/s3cmd-1.0.1/files.txt:/usr/lib/python2.4/site-packages/S3/Utils.py
./src/s3cmd-1.0.1/files.txt:/usr/lib/python2.4/site-packages/S3/CloudFront.py
./src/s3cmd-1.0.1/files.txt:/usr/lib/python2.4/site-packages/S3/PkgInfo.py
./src/s3cmd-1.0.1/files.txt:/usr/lib/python2.4/site-packages/S3/S3.py
./src/s3cmd-1.0.1/files.txt:/usr/lib/python2.4/site-packages/S3/SortedDict.py
....

おおっ。
色もついて便利ですね。

以上です。

2011年10月21日金曜日

SQSってなんじゃ?(遅延送信、一括送信機能が追加)


SQSに新機能が登場しました。今回追加されたのは、大きく分けて

  • メッセージの一括送信、削除
  • キューとメッセージの遅延送信

の2つです。

さっそく試してみましょう


キューとメッセージの遅延送信

遅延送信機能はコンソールから確認できるので、コンソールを見てみます。
まずはキューの遅延送信設定を確認してみます。
コンソールのSQSから「Create New Queue」ボタンでキューを作成します。

すると、下記のキュー設定ダイアログが表示されます。
赤枠の部分に「Delivery Delay」があり、ここで最大15分まで遅延時間を設定できます。
たとえばここで遅延時間を45秒に設定すると、このキューで送信したメッセージはデフォルトで送信後45秒後から受信可能になります。



次に、そのキューで「SendMessage」してみると、メッセージ送信ダイアログが表示されます。
赤枠のとおり、メッセージでも個別に遅延時間を設定できます。
デフォルトでは、キューで設定した遅延時間がセットされています。なにもせずに送信すると、キューの遅延設定時間で遅延し、ここで別の時間にセットすると、その時間だけ遅延します。

ここでは3分に設定して、メッセージ送信してみます。




ここで、「Queue Action」から「View/Delete Messages」を選び、キューのメッセージ一覧ダイアログが表示され、「Start Polling Messages」を数回押してみますが、しばらくは(3分以内)メッセージが受信されません。




3分経過すると、先程のメッセージが受信されます。メッセージ情報のSentとFirst Receivedの間が3分以上あいているのが確認できます。




また、メッセージダイアログで何も設定せずに送信すると、キューで設定した45秒間は受信できず、45秒経過後に受信されるようになります。



このようなメッセージの遅延は、仕様やアプリケーションの他の処理との兼ね合いなどで必要になるシーンがあるので、バッチなどのバックエンド処理には重宝しそうです。



メッセージの一括送信、削除



APIにSendMessageBatchDeleteMessageBatchという関数が用意されました。メッセージの送信、削除を同時に10メッセージまで操作できるようです。ただし、通常のSendMessageなどは1つのメッセージ容量が65KBまででしたが、この一括送信では10個で65KBまでという制限があるようです。
この機能の利点は、10個までのメッセージの操作を1リクエストで行えるため、リクエストごとの課金を抑えることができます。


現時点(2011/10/21 18:00)では、メッセージの一括送信、削除の機能は、APIまでの対応でSDKではまだ未サポートのようです。

SQSのAPIリファレンス
http://docs.amazonwebservices.com/AWSSimpleQueueService/latest/APIReference/

こちらはSDKがサポートされたらまた報告したいと思います。


以上です。




2011年10月20日木曜日

WebSocketってなんじゃ?(Node編4 MongoDBってなんじゃ?)

今回はMongoDBの話題です。
MongoDBはいわゆるNoSQLで、BSONというJSONのバイナリ版のような形式でデータの入出力を行い、クエリなどのデータ操作をjavascriptで行うため、サーバーサイドJavascriptと非常に相性がよく、node.jsとともによく利用されているようです。

今回はこのMongoDBをnode.jsから操作してみます。

MongoDB公式サイトにあるように、yumでインストールするために、MongoDB用のyumリポジトリを追加します。
以下のファイルを作成します。
/etc/yum.repos.d/10gen.repo
[10gen]
name=10gen Repository
baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/i686
gpgcheck=0


さっそく、yumでインストールします。
yum install mongo-10gen mongo-10gen-server -y


インストールが終了したら、mongodが/etc/init.d/以下にできるので、起動します。
/etc/init.d/mongod start


MongoDBのコンソールを立ち上げてみます。
$ mongo

MongoDB shell version: 2.0.0
connecting to: test
testというdbにつながったようです。
helpと入力すると、いくつかのコマンドが紹介されています。DBの一覧を見てみます。
> show dbs
local (empty)
test (empty)
localとtestというDBがあり、中身はまだ空になっています。

MongoDBは基本的にはスキーマを定義することなく、いきなりデータを保存できます。データが保存された時点でそれがスキーマになります。
以下のように、hogeというデータを保存、その直後にhogeを参照してみます。
> db.hoge.save({id:"1", name:"HOGE"});
>
> db.hoge.find();
{ "_id" : ObjectId("4e9f8ced316d58abc218dc43"), "id" : "1", "name" : "HOGE" }

このように、クエリにあたるものもすべてjavascriptで行い、結果はJSON形式で表示されます。いかにもnodeと相性がよさそうです。


それでは、このMongoDBにnode.jsからアクセスしてみます。
node.jsからMongoDBにアクセスするには、MongoDB用のパッケージモジュールを入れる必要があります。
Mongo用のモジュールはいくつかあるのですが、今回はMongooseを利用してみます。
mongooseはnpmでインストールします。
# npm install -g mongoose

> mongodb@0.9.6-22 install /usr/local/lib/node_modules/mongoose/node_modules/mongodb
> bash ./install.sh

================================================================================
=                                                                              =
=  To install with C++ bson parser do <npm --mongodb:native="" install="" mongodb="">   =
=  the parser only works for node 0.4.X or lower                               =
=                                                                              =
================================================================================
Not building native library for cygwin
Using GNU make
mongoose@2.3.5 /usr/local/lib/node_modules/mongoose
├── colors@0.5.0
├── hooks@0.1.9
└── mongodb@0.9.6-22


以下のようにmongoにデータを投入するコードを書いてみます。
#!/usr/local/bin/node

var mongoose = require('mongoose');
mongoose.connect('mongodb://localhost/memorycraft');

var Schema = mongoose.Schema;
var ItemSchema = new Schema({title:String, auther:String, price:Number, date:Date});
var Item = mongoose.model('Item', ItemSchema);

var item = new Item();
item.title = "体脂肪計タニタの社員食堂 ~500kcalのまんぷく定食~";
item.auther = "タニタ";
item.price = 1200;
item.date = new Date(2010, 1, 21);

item.save(function(err){
  if(err){
    console.log(err.message);
  }
  else{
    console.log("保存しました");
  }
});


これを実行します。
$ ./hello_mongo.js
保存しました


ここで、実際にデータが投入されているか再度mongoのコンソールで確認してみます。
$mongo
> show dbs
local (empty)
memorycraft 0.0625GB
test 0.0625GB
>
> use memorycraft
switched to db memorycraft
>
> show collections
items
system.indexes
>
> db.items.find()
{ "date" : ISODate("2010-02-20T15:00:00Z"), "price" : 1200, "auther" : "タニタ", "title" : "体脂肪計タニタの社員食堂 ~500kcalのまんぷく定食~", "_id" : ObjectId("4e9f98394699a3fb40000001") }

memorycraftというdbが増えていて、投入したデータが入っていることが確認できました。

ここで、mongodb+nodeがいいのは、データの保持の時点でJSONなので、取得結果もJSONになっていることです。
そして、上記のコードを書いたようにアクセスの結果がすべてコールバックで記述できるので、とても柔軟にコード記述ができます。
例えば以下のように別途WEBフレームワークなどを使用した場合、取得したデータをそのままレスポンスに返すことで余計な変換処理が必要なくなります。
Item.find({}, function(err, items) {
  if(!err) {
    res.json(items);
  }
});

ほんの少し触れただけですが、とても便利なことがわかりました。
まだまだいろいろいじってみようと思います。
本日は以上です。

2011年10月19日水曜日

WebSocketってなんじゃ?(Node編3 node.jsでサーバーサイドjQuery)

再びnodeの話題です。 前回紹介したSocket.IOのように、node.jsにはnpmで管理される多数のパッケージモジュールがあり、それらをインストールすることでnodeの機能を拡張します。

今回は、jsdomというモジュールを使用してみます。
これはDOMのJS実装を、モジュール化したもので、node上でJSによるDOM解析と操作をサーバーサイドで行うことが可能です。

それでは早速試してみます。
まずnpmでjsdomをインストールしてみます。
$ npm install -g jsdom

> contextify@0.0.6 preinstall /usr/local/lib/node_modules/jsdom/node_modules/contextify
> node-waf clean || true; node-waf configure build

Nothing to clean (project not configured)
Setting srcdir to                        : /usr/local/lib/node_modules/jsdom/node_modules/contextify 
Setting blddir to                        : /usr/local/lib/node_modules/jsdom/node_modules/contextify/build 
Checking for program g++ or c++          : /usr/bin/g++ 
Checking for program cpp                 : /usr/bin/cpp 
Checking for program ar                  : /usr/bin/ar 
Checking for program ranlib              : /usr/bin/ranlib 
Checking for g++                         : ok  
Checking for node path                   : not found 
Checking for node prefix                 : ok /usr/local 
'configure' finished successfully (0.026s)
Waf: Entering directory `/usr/local/lib/node_modules/jsdom/node_modules/contextify/build'
[1/2] cxx: src/contextify.cc -> build/Release/src/contextify_1.o
[2/2] cxx_link: build/Release/src/contextify_1.o -> build/Release/contextify.node
Waf: Leaving directory `/usr/local/lib/node_modules/jsdom/node_modules/contextify/build'
'build' finished successfully (0.789s)
jsdom@0.2.8 /usr/local/lib/node_modules/jsdom 
├── htmlparser@1.7.3
├── cssom@0.2.0
├── request@2.1.1
└── contextify@0.0.6_
インストールが完了しました。


確認のために、自ら作成したDOMの一部を抽出するスクリプトを実行してみます。

hello_dom.js
#!/usr/local/bin/node

var jsdom    = require("jsdom").jsdom;
var document = jsdom("<html><head></head><body><div id='greeting'>hello world</div></body></html>"),
var window   = document.createWindow();

console.log(window.document.getElementById("greeting").innerHTML);
実行
$ chmod 755 hello_dom.js
$ ./hello_dom.js
hello world
うまく出力されました。

様々な言語にDOMを操作するライブラリがありますが、最も有名で最も使いやすいのはやはりjQueryだと思います。
ここではせっかくjavascriptを使っているので、jQueryを利用してみます。

jsdomはjQueryを実行するときに便利なenvメソッドを用意しています。 envメソッドは、ロードしたHTMLソースにscriptタグを追加し、そのscriptがDOMにロードされた後に引数のコールバック関数を呼び出します。
以下のスクリプトは、memorycraftのブログ(このブログです)のトップページから、記事のタイトルをjQueryで抽出してコンソールに出力する、いわゆるスクレイピングを行います。

hello_jquery.js
#!/usr/local/bin/node

var jsdom = require("jsdom");

jsdom.env("http://www.memocra.blogspot.com", [
  'http://code.jquery.com/jquery-1.5.min.js'
],
function(errors, window) {
  var $ = window.$;
  $("h3 a").each(function(){
    console.log($(this).text());
  });
});
実行
$ chmod 755 hello_jquery.js
$ ./hello_jquery.js
EC2でMySQL(世界編2 Spiderとレプリケーションで高速負荷分散)
EC2でMySQL(世界編1 Spiderとレプリケーションで世界進出)
SQSってなんじゃ?(AWSコンソールにSQS登場)
S3ってなんじゃ?(サーバー側でファイルのAES256暗号化)
WebSocketってなんじゃ?(Node編2 Socket.IOでプッシュ通信)

おお!うまく出力できました。

このようにjQueryをサーバーサイドで利用することで、クライアントとサーバーサイド両側で同じ方法でHTMLをコントロールすることができ、とても便利です。

WebSocket関係なくなっちゃいましたが、本日は以上です。

2011年10月14日金曜日

EC2でMySQL(世界編2 Spiderとレプリケーションで高速負荷分散)

前回のつづきです。

前回はSpiderとレプリケーションで、リージョン間での高速なデータ分散を紹介しました。前回で少し触れましたが、この構成ではたとえばEU側のDBにJPのデータの書き込みには対応できません。

それを解決し、どちらのリージョンからもすべての商品を投入できるようにしてみたいと思います。
構成は以下のとおりです。



SpiderノードのDBで、書き込みと読み込みでそれぞれ別々のテーブルを用意し、別々のデータノードにそれぞれシャーディングを行います。

データノードの作成とレプリケーションの設定は前回と同じなので割愛します。

Spiderノード

spider_ja
CREATE TABLE item_r (
  id int(11) NOT NULL AUTO_INCREMENT,
  name varchar(256) DEFAULT NULL,
  shop_id int(11) DEFAULT NULL,
  region_id int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (id, region_id)
) ENGINE=SPIDER DEFAULT CHARSET=utf8
CONNECTION=' table "item", user "remote_user", password "remote_pass" '
PARTITION BY LIST (region_id) (
  PARTITION ja_ja VALUES IN (1) COMMENT = 'host "111.111.0.1", port "3306"',
  PARTITION ja_eu VALUES IN (2) COMMENT = 'host "111.111.0.2", port "3306"'
)
;

CREATE TABLE item_w (
  id int(11) NOT NULL AUTO_INCREMENT,
  name varchar(256) DEFAULT NULL,
  shop_id int(11) DEFAULT NULL,
  region_id int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (id, region_id)
) ENGINE=SPIDER DEFAULT CHARSET=utf8
CONNECTION=' table "item", user "remote_user", password "remote_pass" '
PARTITION BY LIST (region_id) (
  PARTITION ja_ja VALUES IN (1) COMMENT = 'host "111.111.0.1", port "3306"',
  PARTITION eu_eu VALUES IN (2) COMMENT = 'host "222.222.0.2", port "3306"'
)
;

spider_eu
CREATE TABLE item_r (
  id int(11) NOT NULL AUTO_INCREMENT,
  name varchar(256) DEFAULT NULL,
  shop_id int(11) DEFAULT NULL,
  region_id int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (id, region_id)
) ENGINE=SPIDER DEFAULT CHARSET=utf8
CONNECTION=' table "item", user "remote_user", password "remote_pass" '
PARTITION BY LIST (region_id) (
  PARTITION eu_ja VALUES IN (1) COMMENT = 'host "222.222.0.1", port "3306"',
  PARTITION eu_eu VALUES IN (2) COMMENT = 'host "222.222.0.2", port "3306"'
)
;

CREATE TABLE item_w (
  id int(11) NOT NULL AUTO_INCREMENT,
  name varchar(256) DEFAULT NULL,
  shop_id int(11) DEFAULT NULL,
  region_id int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (id, region_id)
) ENGINE=SPIDER DEFAULT CHARSET=utf8
CONNECTION=' table "item", user "remote_user", password "remote_pass" '
PARTITION BY LIST (region_id) (
  PARTITION ja_ja VALUES IN (1) COMMENT = 'host "111.111.0.1", port "3306"',
  PARTITION eu_eu VALUES IN (2) COMMENT = 'host "222.222.0.2", port "3306"'
)
;


item_wに対して書き込んでみます。
mysql> INSERT INTO item_w (name, shop_id, region_id) VALUES('おいしい水', 1, 1), ('おしゃれなバッグ', 2, 1), ('Cool Watch', 3, 2),('Cute Ring', 4, 2);
Query OK, 4 rows affected (1.95 sec)
Records: 4  Duplicates: 0  Warnings: 0


書き込みが成功しました。
item_wで参照すると、
mysql> select * from item_w;
+----+--------------------------+---------+-----------+
| id | name                     | shop_id | region_id |
+----+--------------------------+---------+-----------+
|  1 | おいしい水          |       1 |         1 |
|  2 | おしゃれなバッグ |       2 |         1 |
|  3 | Cool Watch               |       3 |         2 |
|  4 | Cute Ring                |       4 |         2 |
+----+--------------------------+---------+-----------+
4 rows in set (1.96 sec)
正しく投入されていることがわかりますが、レスポンスはやはり悪いです。

そこでitem_rで参照してみます。
mysql> select * from item_r;
+----+--------------------------+---------+-----------+
| id | name                     | shop_id | region_id |
+----+--------------------------+---------+-----------+
|  1 | おいしい水          |       1 |         1 |
|  2 | おしゃれなバッグ |       2 |         1 |
|  3 | Cool Watch               |       3 |         2 |
|  4 | Cute Ring                |       4 |         2 |
+----+--------------------------+---------+-----------+
4 rows in set (0.01 sec)
高速で読み込みできています。

これで、どちらのリージョンからも全リージョン用のデータの書き込みができ、なおかつ読み込みスピードを維持することが出来ました。

書き込み時は他方のリージョンにSpiderでアクセスするので、少し時間がかかります。
前回のように基本はJPのデータはJPリージョンから投入するようにルール化すれば書き込みスピードが損なわれることはありません。
すべてmicroインスタンスでの確認ということもあり、もしかしたらSpiderのサーバーやテーブルパラメータをいじることで他リージョンへのSpiderアクセスも速くなるかもしれません。それは今後の課題にしたいと思います。

以上です。

2011年10月13日木曜日

EC2でMySQL(世界編1 Spiderとレプリケーションで世界進出)

ふたたびSpiderの話題です。

WEBアプリを世界展開する場合、要件の1つとして、世界各国のユーザーは全てのデータを参照する必要があるが、データの登録は各国、地域の担当者が各自のデータを登録したい、というケースが多いと思います。

たとえば、商品のサイトで、EUと日本にそれぞれ管理者がいるとします。
その場合のユースケースとしては、

  • EUの管理者はEUの商品を登録する
  • 日本の管理者は日本の商品を登録する
  • ユーザーは全ての商品を閲覧できる

となります。

このとき、DBがどのリージョンにあるかによって、ユーザーや管理者の間で、レスポンススポードに差がでます。
DBを日本に置くとEUのユーザーや管理者には遅いシステムとなってしまい、EUに置くとその逆になります。
そのため、各リージョンに全てのリージョンで登録した商品データを用意し、ユーザーのロケーションに関わらず、DBアクセスをユーザーと同じリージョン内で済ませる必要があります。管理者がアクセスするDBも管理者のいるリージョン内で済ませる必要があります。




これをSpiderとレプリケーションで実現してみます。
上図をみると想像できるかも知れませんが、方法としてはEUとJPそれぞれのリージョンに属する商品マスタに対して書き込み、EUではJPの、JPはEUのスレーブをもち、それぞれをSpiderでシャーディングします。
DBの図で表すと、下記のようになります。


それでは実際に試してみます。

データノード

CREATE TABLE item (
  id int(11) NOT NULL AUTO_INCREMENT,
  name varchar(256) DEFAULT NULL,
  shop_id int(11) DEFAULT NULL,
  region_id int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (id, region_id)
) ENGINE=SPIDER DEFAULT CHARSET=utf8
;


Spiderノード

spider_ja
CREATE TABLE item (
  id int(11) NOT NULL AUTO_INCREMENT,
  name varchar(256) DEFAULT NULL,
  shop_id int(11) DEFAULT NULL,
  region_id int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (id, region_id)
) ENGINE=SPIDER DEFAULT CHARSET=utf8
CONNECTION=' table "item", user "remote_user", password "remote_pass" '
PARTITION BY LIST (region_id) (
  PARTITION ja_ja VALUES IN (1) COMMENT = 'host "111.111.0.1", port "3306"',
  PARTITION ja_eu VALUES IN (2) COMMENT = 'host "111.111.0.2", port "3306"'
)
;

spider_eu
CREATE TABLE item (
  id int(11) NOT NULL AUTO_INCREMENT,
  name varchar(256) DEFAULT NULL,
  shop_id int(11) DEFAULT NULL,
  region_id int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (id, region_id)
) ENGINE=SPIDER DEFAULT CHARSET=utf8
CONNECTION=' table "item", user "remote_user", password "remote_pass" '
PARTITION BY LIST (region_id) (
  PARTITION eu_ja VALUES IN (1) COMMENT = 'host "222.222.0.1", port "3306"',
  PARTITION eu_eu VALUES IN (2) COMMENT = 'host "222.222.0.2", port "3306"'
)
;


レプリケーション

ja-eu
$ mysql -u root
mysql> CHANGE MASTER TO
  MASTER_HOST='222.222.0.2',
  MASTER_USER='remote_user',
  MASTER_PASSWORD='remote_user',
  MASTER_PORT=3306;

eu-ja
$ mysql -u root
mysql> CHANGE MASTER TO
  MASTER_HOST='111.111.0.1',
  MASTER_USER='remote_user',
  MASTER_PASSWORD='remote_user',
  MASTER_PORT=3306;


※各ノード間のアクセス権限やサーバーIDの登録、セキュリティグループの設定などは以前の記事に書いたので割愛します

ポイントはregion_id(1:ja, 2:eu)のLISTパーティションにするため、プライマリキーをidとregion_idの複合キーにするところです。INSERT時には、登録したリージョンの region_idをセットします。
※登録したリージョンではないregion_idをセットするとパーティションに含まれず、シャーディング対象にならないので、注意が必要です。

spider-ja
mysql> INSERT INTO item (name, shop_id, region_id) VALUES('おいしい水', 1, 1), ('おしゃれなバッグ', 2, 1);
Query OK, 2 rows affected (0.02 sec)
Records: 2  Duplicates: 0  Warnings: 0


spider-eu
mysql> insert into item(name,shop_id,region_id) values('Cool Watch', 3, 2),('Cute Ring', 4, 2);
Query OK, 2 rows affected (0.03 sec)
Records: 2  Duplicates: 0  Warnings: 0

すると、
それぞれのspiderノードですべてのitemがselectできます。
mysql> select * from item;
+----+--------------------------+---------+-----------+
| id | name                     | shop_id | region_id |
+----+--------------------------+---------+-----------+
|  1 | おいしい水          |       1 |         1 |
|  2 | おしゃれなバッグ |       2 |         1 |
|  1 | Cool Watch               |       3 |         2 |
|  2 | Cute Ring                |       4 |         2 |
+----+--------------------------+---------+-----------+
4 rows in set (0.01 sec)


このように、リージョンが分かれていても、アクセス速度を気にすること無くシャーディングができました。
以上です。

2011年10月7日金曜日

SQSってなんじゃ?(AWSコンソールにSQS登場)

SQSがAWSコンソールで利用可能になりました。 いままでキューに入ったメッセージを確認する手段がプログラム経由だったので、管理がしづらかったのですが、これでメッセージの状態がわかりやすくなると思います。 AWSコンソールを開くと、まずSQSのタブが増えていることに気づきます。
SQSタブをクリックすると、SQSのキュー一覧画面が表示され、いままで作ったキューが表示されているのがわかります。




まずはキューの作成をしてみます。



「Create New Queue」ボタンをクリックします。
すると、キュー作成のダイアログが開きます。


ここで、
  • Queue Name:キュー名
  • Default Visibility Timeout:読み込み後、他のクライアントから秘匿する秒数のデフォルト値、メッセージ送信時に指定しないとこれが使用される
  • Message Retention Period:メッセージの保持期間
  • Maximam Message Size:メッセージの最大サイズ
を指定して、「Create Queue」ボタンをクリックします。
すると、キュー一覧画面にもどり、キューのメッセージ数が1つ増えているのがわかります。


キューのメッセージを確認するには、キューを選択して、「Queue Action」から「View/Delete Messages」を選択します。
すると、メッセージ詳細ダイアログが立ち上がります。



「Start Polling Messages」を押すと、メッセージのフェッチが始まります。下のプログレスバーが終了すると全てのメッセージがチェックされ、一覧に表示されます。またフェッチを途中で中止した場合は右上の「Stop Now」を押します。
メッセージの詳細を見たい場合は、メッセージの「 More Details」を押すとメッセージ全文と付帯情報を確認できます。



キューの一覧にもどり、下部ペインの「Permission」タブで、各キューのパーミッションを設定できます。


ここでは各アクションごとに細かく権限ポリシーを設定でき、また「Edit Policy Document」ボタンでポリシーファイルのJSON的な書き方でも設定が可能です。

いままでプログラムで送信したキューの状態を知るにはそのプログラムを書かないといけないため、なんとなくブラックボックスになりがちだったSQSですが、このように、可視化されることでSQSがぐっと身近に感じられるようになり、管理も簡単になりました。とても助かります。

本日はここまで。

2011年10月5日水曜日

S3ってなんじゃ?(サーバー側でファイルのAES256暗号化)

S3がサーバーサイドでのファイル暗号化に対応しました。

ファイルのアップロード時、"x-amz-server-side-encryption"ヘッダに"AES256"を指定することで暗号化が自動的に行われ、配信時に自動的に複合してくれるそうです。 

まずはコンソール上で試してみます。
 AWSコンソールのS3タブで「Upload」ボタンを押し、アップロードダイアログを使って、普通にファイルを選択します。

「Set Details..」で次の画面を表示すると、RSSのチェックボックスの下に、「Use Server Side Encryption」という項目が追加されているのがわかります。


これにチェックを入れて、あとは通常通りアップロードします。
これだけでファイルが暗号化されて保持されます。簡単ですね。

次は、APIを利用して暗号化をしてみます。
ドキュメントを見るかぎり現在のところ、REST、Java、.NETで対応しているようです。
ここではJavaのSDKでの例を紹介します。
AmazonS3 s3client = new AmazonS3Client(
  new BasicAWSCredentials("XXXXXXXXXXX",  "YYYYYYYYYYY"));
 
File file = new File("hoge.txt");
PutObjectRequest putRequest = new PutObjectRequest("hoge-bucket", "hoge.txt", file);
            
ObjectMetadata objectMetadata = new ObjectMetadata();
objectMetadata.setServerSideEncryption( 
  ObjectMetadata.AES_256_SERVER_SIDE_ENCRYPTION );     
putRequest.setMetadata(objectMetadata);

PutObjectResult response = s3client.putObject(putRequest);


このように、通常のアップロードリクエストにメタデータを追加してあげるだけです。
本日はここまで。

WebSocketってなんじゃ?(Node編2 Socket.IOでプッシュ通信)

前回Node編1で、スタンドアローンのHTTPサーバーをつくり、HTTP通信を行いました。

今回は、WebSocketを使用した通信を行ってみます。 WebSocketとは、ブラウザとサーバーの双方向通信のプロトコル規格で、現在標準化団体が仕様を策定中の技術です。chromeやsafariなど、いくつかのモダンブラウザがサポートしており、これが一般的に使用されると、いままでのサーバーアプリケーションの作り方が大きく変わってくる可能性がある、注目の技術です。

ここで使用するのは、Socket.IO というnode.jsのモジュールです。 node.jsはモジュールという単位でライブラリを管理しており、npmというモジュール管理ツールで簡単にいろいろなモジュールを追加削除できます。これはrubyでいうgemのようなものです。
Socket.IOはただnode.jsでWebSocketを実装しているだけではなく、モダンブラウザ以外のWebSocketを使用できないブラウザでも、AjaxやFlashなど他の代替手段があるかどうかを自動的に検知して通信方式を自動で選択されるので、ブラウザの対応をあまり気にしなくてもよくなっています。
また、Socket.IOは WebSocketとその代替手段において、クロスドメイン通信を可能にしています。

早速実践してみます。 まず最初にnpmをインストールします。
$ curl http://npmjs.org/install.sh | sh
$ npm install -g socket.io


socket.ioのインストールでエラーが出る場合がありますが、その場合はtarが古いので、tarを最新にしておきます。
$ cd /usr/local/src
$ wget http://ftp.gnu.org/gnu/tar/tar-1.26.tar.gz
$ tar xzvf tar-1.26.tar.gz
$ cd tar-1.26
$ ./configure
$ make
# make install


socket.ioをインストールします。
$ curl http://npmjs.org/install.sh | sh
$ npm install -g socket.io

※エラーになる場合は curl -L http://npmjs.org/install.sh | sh とやると良いようです。

これで実装の準備が整いました。
それでは実装を始めます。
今回は、メッセージを送信したら見ている全員にメッセージを表示させる、簡単なチャットの仕組みを作ってみます。

サーバー側

/opt/memorycraft/node/socketsample.js
require.paths.push('/usr/local/lib/node_modules');

var server = require('http').createServer(function(req, res){
  res.writeHead(200, {'Content-Type': 'text/html'});
  res.end('server connected');
});
server.listen(1337);

var io = require('socket.io').listen(server);
io.sockets.on('connection', function (socket) {
  socket.emit('info', { msg: 'welcome' });
  socket.on('msg', function (msg) {
    io.sockets.emit('msg', {msg: msg});
  });
  socket.on('disconnect', function(){
    socket.emit('info', {msg: 'bye'});
  });
});


サーバー側では任意のポート(ここでは1337)を開放したhttpサーバーにsocket.ioをつなげてリスン状態にします。
通信の確立(connection)や切断(disconnect)などのビルトインイベントや、自分のアプリケーションで使用したいオリジナルのイベント(ここではmsg)のイベントハンドラを定義します。
このコードでは接続したときに"welcome"、切断したときに"bye"をそのユーザーに、あるユーザーから"msg"というイベントが送られたら全員に"msg"というイベントを、それぞれプッシュ送信しています。

クライアント側

/var/html/www/test/node/index.html
<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js" type="text/javascript" charset="utf-8"></script>
  <script src="http://xxx.xxx.xxx.xxx:1337/socket.io/socket.io.js"></script>
  <script type="text/javascript">
  $(function(){
    var socket = io.connect('http://xxx.xxx.xxx.xxx:1337/');
    socket.on('connect', function() {
      $("#log").html($("#log").html() + "<br />" + 'connected');
      socket.on('info', function (data) {
        $("#log").html($("#log").html() + "<br />" + data.msg);
      });
      socket.on('msg', function(data){
        $("#log").html($("#log").html() + "<br />" + "<b>" + data.msg + "</b>");
      });
      $("#send").click(function(){
        var msg = $("#msg").val();
        if(!msg){
          alert("input your message");
          return;
        }
        socket.emit('msg', msg);
      });
    });
  });
  </script>
  <title>nodetest</title>
</head>
<body>
  <input id="msg" type="text" style="width:400px;"></input>
  <input id="send" type="button" value="send" /></br >
  <div id="log" style="width:400px;height:400px;overflow:auto;border:1px solid #000000;"></div>
</html>

クライアント側からはサーバー側の1337ポートに接続しますが、サーバー側は実際にファイルを自分で配置しなくてもSocket.IOが勝手にクライアント側のライブラリを/socket.io/socket.io.jsとして配信してくれます。
そのファイルをscriptファイルでロードするようにし、あとは接続部分とサーバーからのイベントのハンドラを定義します。また、ボタンを押したらテキストをサーバー側に送信するように記述します。


それでは、サーバー側のコードを実行してみます。
$ node /opt/memorycraft/node/socketsample.js
   info  - socket.io started

ブラウザでhtmlを表示します。

サーバー側からの"welcome"メッセージが表示されていることがわかります。
また、メッセージを入力して送信すると、

メッセージ欄にサーバーから送られてきているのがわかります。

別のブラウザでも開いておき、そちらからメッセージを送信するともう一方のブラウザにメッセージが表示されることが分かります。


このように、socket.ioを利用することで多くのブラウザで簡単にWebSocketを実現することができます。
WebSocketは通信内容が少なく、コネクションやリソースの消費が少ないので、ゲームやソーシャルサイトなどのマルチユーザーアプリや、クライアントのログ集計など、様々な分野での利用が期待できます。
今日はここまで。