2011memorycraft更新とか絶対忘れるから。2011年10月31日月曜日SESってなんじゃ?(AWSコンソールにSESが登場)今回はSESについてです。アプリケーションを開発する際、ユーザーにメールを一斉送信するような場合が多い時に、メールサーバーの負荷やパフォーマンスに対するコストは忘れがちですが意外とかかり、そのため外部のメール配信専用のサービスを利用することも多いかと思います。SESは一括メール送信のためのサービスで、EC2でEメールを配信する際には是非つかいたいサービスです。そのSESがAWSコンソール上で管理できるようになりました。触ってみたいと思います。AWSコンソールを開くと、右側にSESのタブが表示されていることがわかります。SESタブを選択すると、SESのダッシュボードが表示されます。メールの送信者のメールアドレスを登録します。Sender」のボタンを押すと、下のようにダイアログが表示されるので、送信者のEメールアドレスを入力して「Submit」を押します。すると、入力したメールアドレスに、確認用のメールが送られる旨のメッセージが表示されます。AWSサービスから、入力したメールアドレス宛に送信者確認のリンクが記載されたメールが届くので、リンクをクリックしてメールアドレスの実在確認を行います。リンクをクリックすると、AWSサービスの画面がブラウザに表示され、認証が完了します。Senders」メニューをクリックすると、右ペインに先ほど登録した送信者のアドレスが表示されています。Email」というテスト送信が出来るリンクがあるのでクリックしてみます。すると、テスト送信用のダイアログが表示されます。SESでのテスト送信は登録した送信者宛にしか送信できません。ここでは、先ほどの認証された送信者アドレスの一覧から送信先を選択します。Email」をクリックします。無事送信者アドレスに、メールが届きました。Access」のボタンを押し、プロダクション環境での利用申請を行うことで、未登録アドレスへの送信が可能になります。Board」でメールの使用状況などの統計がわかり、管理しやすくなりました。全文検索)日々お世話になっている便利なシェルのワンライナーを紹介していきたいと思います。このシリーズが出たときはネタに困ったときだと思ってください。以下は、特定のディレクトリ以下のパターンにマッチしたすべてのファイルから全文検索し、結果を色付けするワンライナーです。--color=auto実際に実行してみます。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....おおっ。色もついて便利ですね。追加)SQSに新機能が登場しました。今回追加されたのは、大きく分けてメッセージの一括送信、削除キューとメッセージの遅延送信の2つです。コンソールから確認できるので、コンソールを見てみます。キューの遅延送信設定を確認してみます。Queue」ボタンでキューを作成します。すると、下記のキュー設定ダイアログが表示されます。Delay」があり、ここで最大15分まで遅延時間を設定できます。ここで遅延時間を45秒に設定すると、このキューで送信したメッセージはデフォルトで送信後45秒後から受信可能になります。次に、そのキューで「SendMessage」してみると、メッセージ送信ダイアログが表示されます。赤枠のとおり、メッセージでも個別に遅延時間を設定できます。デフォルトでは、キューで設定した遅延時間がセットされています。なにもせずに送信すると、キューの遅延設定時間で遅延し、ここで別の時間にセットすると、その時間だけ遅延します。ここでは3分に設定して、メッセージ送信してみます。Messages」を数回押してみますが、しばらくは(3分以内)メッセージが受信されません。3分経過すると、先程のメッセージが受信されます。Receivedの間が3分以上あいているのが確認できます。メッセージダイアログで何も設定せずに送信すると、キューで設定した45秒間は受信できず、45秒経過後に受信されるようになります。このようなメッセージの遅延は、仕様やアプリケーションの他の処理との兼ね合いなどで必要になるシーンがあるので、バッチなどのバックエンド処理には重宝しそうです。メッセージの一括送信、削除APIにSendMessageBatchとDeleteMessageBatchという関数が用意されました。メッセージの送信、削除を同時に10メッセージまで操作できるようです。通常のSendMessageなどは1つのメッセージ容量が65KBまででしたが、この一括送信では10個で65KBまでという制限があるようです。この機能の利点は、10個までのメッセージの操作を1リクエストで行えるため、リクエストごとの課金を抑えることができます。18:00)では、メッセージの一括送信、削除の機能は、APIまでの対応でSDKではまだ未サポートのようです。SQSのAPIリファレンスhttp://docs.amazonwebservices.com/AWSSimpleQueueService/latest/APIReference/こちらはSDKがサポートされたらまた報告したいと思います。MongoDBってなんじゃ?)今回はMongoDBの話題です。MongoDBはいわゆるNoSQLで、BSONというJSONのバイナリ版のような形式でデータの入出力を行い、クエリなどのデータ操作をjavascriptで行うため、サーバーサイドJavascriptと非常に相性がよく、node.jsとともによく利用されているようです。今回はこのMongoDBをnode.jsから操作してみます。MongoDB公式サイトにあるように、yumでインストールするために、MongoDB用のyumリポジトリを追加します。以下のファイルを作成します。Repositorybaseurl=http://downloads-distro.mongodb.org/repo/redhat/os/i686gpgcheck=0さっそく、yumでインストールします。-yインストールが終了したら、mongodが/etc/init.d/以下にできるので、起動します。startMongoDBのコンソールを立ち上げてみます。testtestというdbにつながったようです。helpと入力すると、いくつかのコマンドが紹介されています。DBの一覧を見てみます。(empty)localとtestというDBがあり、中身はまだ空になっています。MongoDBは基本的にはスキーマを定義することなく、いきなりデータを保存できます。データが保存された時点でそれがスキーマになります。以下のように、hogeというデータを保存、その直後にhogeを参照してみます。}このように、クエリにあたるものもすべてjavascriptで行い、結果はJSON形式で表示されます。nodeと相性がよさそうです。それでは、このMongoDBにnode.jsからアクセスしてみます。node.jsからMongoDBにアクセスするには、MongoDB用のパッケージモジュールを入れる必要があります。Mongo用のモジュールはいくつかあるのですが、今回はMongooseを利用してみます。mongooseはnpmでインストールします。mongodb@0.9.6-22以下のようにmongoにデータを投入するコードを書いてみます。}});これを実行します。./hello_mongo.js保存しましたここで、実際にデータが投入されているか再度mongoのコンソールで確認してみます。}memorycraftというdbが増えていて、投入したデータが入っていることが確認できました。ここで、mongodb+nodeがいいのは、データの保持の時点でJSONなので、取得結果もJSONになっていることです。上記のコードを書いたようにアクセスの結果がすべてコールバックで記述できるので、とても柔軟にコード記述ができます。以下のように別途WEBフレームワークなどを使用した場合、取得したデータをそのままレスポンスに返すことで余計な変換処理が必要なくなります。}});ほんの少し触れただけですが、とても便利なことがわかりました。いじってみようと思います。node.jsでサーバーサイドjQuery)再びnodeの話題です。前回紹介したSocket.IOのように、node.jsにはnpmで管理される多数のパッケージモジュールがあり、それらをインストールすることでnodeの機能を拡張します。今回は、jsdomというモジュールを使用してみます。これはDOMのJS実装を、モジュール化したもので、node上でJSによるDOM解析と操作をサーバーサイドで行うことが可能です。それでは早速試してみます。npmでjsdomをインストールしてみます。contextify@0.0.6_インストールが完了しました。確認のために、自ら作成したDOMの一部を抽出するスクリプトを実行してみます。worldうまく出力されました。様々な言語にDOMを操作するライブラリがありますが、最も有名で最も使いやすいのはやはりjQueryだと思います。ここではせっかくjavascriptを使っているので、jQueryを利用してみます。jsdomはjQueryを実行するときに便利なenvメソッドを用意しています。envメソッドは、ロードしたHTMLソースにscriptタグを追加し、そのscriptがDOMにロードされた後に引数のコールバック関数を呼び出します。以下のスクリプトは、memorycraftのブログ(このブログです)のトップページから、記事のタイトルをjQueryで抽出してコンソールに出力する、いわゆるスクレイピングを行います。Socket.IOでプッシュ通信)おお!うまく出力できました。このようにjQueryをサーバーサイドで利用することで、クライアントとサーバーサイド両側で同じ方法でHTMLをコントロールすることができ、とても便利です。WebSocket関係なくなっちゃいましたが、本日は以上です。Spiderとレプリケーションで高速負荷分散)前回のつづきです。前回はSpiderとレプリケーションで、リージョン間での高速なデータ分散を紹介しました。前回で少し触れましたが、この構成ではたとえばEU側のDBにJPのデータの書き込みには対応できません。それを解決し、どちらのリージョンからもすべての商品を投入できるようにしてみたいと思います。構成は以下のとおりです。SpiderノードのDBで、書き込みと読み込みでそれぞれ別々のテーブルを用意し、別々のデータノードにそれぞれシャーディングを行います。データノードの作成とレプリケーションの設定は前回と同じなので割愛します。"3306"');item_wに対して書き込んでみます。0書き込みが成功しました。sec)正しく投入されていることがわかりますが、レスポンスはやはり悪いです。そこでitem_rで参照してみます。sec)高速で読み込みできています。これで、どちらのリージョンからも全リージョン用のデータの書き込みができ、なおかつ読み込みスピードを維持することが出来ました。書き込み時は他方のリージョンにSpiderでアクセスするので、少し時間がかかります。前回のように基本はJPのデータはJPリージョンから投入するようにルール化すれば書き込みスピードが損なわれることはありません。すべてmicroインスタンスでの確認ということもあり、もしかしたらSpiderのサーバーやテーブルパラメータをいじることで他リージョンへのSpiderアクセスも速くなるかもしれません。それは今後の課題にしたいと思います。Spiderとレプリケーションで世界進出)ふたたびSpiderの話題です。WEBアプリを世界展開する場合、要件の1つとして、世界各国のユーザーは全てのデータを参照する必要があるが、データの登録は各国、地域の担当者が各自のデータを登録したい、というケースが多いと思います。商品のサイトで、EUと日本にそれぞれ管理者がいるとします。その場合のユースケースとしては、EUの管理者はEUの商品を登録する日本の管理者は日本の商品を登録するユーザーは全ての商品を閲覧できるとなります。このとき、DBがどのリージョンにあるかによって、ユーザーや管理者の間で、レスポンススポードに差がでます。DBを日本に置くとEUのユーザーや管理者には遅いシステムとなってしまい、EUに置くとその逆になります。そのため、各リージョンに全てのリージョンで登録した商品データを用意し、ユーザーのロケーションに関わらず、DBアクセスをユーザーと同じリージョン内で済ませる必要があります。管理者がアクセスするDBも管理者のいるリージョン内で済ませる必要があります。これをSpiderとレプリケーションで実現してみます。上図をみると想像できるかも知れませんが、方法としてはEUとJPそれぞれのリージョンに属する商品マスタに対して書き込み、EUではJPの、JPはEUのスレーブをもち、それぞれをSpiderでシャーディングします。DBの図で表すと、下記のようになります。それでは実際に試してみます。2:eu)のLISTパーティションにするため、プライマリキーをidとregion_idの複合キーにするところです。region_idをセットします。※登録したリージョンではないregion_idをセットするとパーティションに含まれず、シャーディング対象にならないので、注意が必要です。0すると、それぞれのspiderノードですべてのitemがselectできます。sec)このように、リージョンが分かれていても、アクセス速度を気にすること無くシャーディングができました。spider2011年10月7日金曜日SQSってなんじゃ?(AWSコンソールにSQS登場)SQSがAWSコンソールで利用可能になりました。いままでキューに入ったメッセージを確認する手段がプログラム経由だったので、管理がしづらかったのですが、これでメッセージの状態がわかりやすくなると思います。AWSコンソールを開くと、まずSQSのタブが増えていることに気づきます。SQSタブをクリックすると、SQSのキュー一覧画面が表示され、いままで作ったキューが表示されているのがわかります。キューの作成をしてみます。Queue」ボタンをクリックします。すると、キュー作成のダイアログが開きます。Queue」ボタンをクリックします。すると、キュー一覧画面にもどり、キューのメッセージ数が1つ増えているのがわかります。Messages」を選択します。すると、メッセージ詳細ダイアログが立ち上がります。Messages」を押すと、メッセージのフェッチが始まります。下のプログレスバーが終了すると全てのメッセージがチェックされ、一覧に表示されます。Details」を押すとメッセージ全文と付帯情報を確認できます。キューの一覧にもどり、下部ペインの「Permission」タブで、各キューのパーミッションを設定できます。Document」ボタンでポリシーファイルのJSON的な書き方でも設定が可能です。いままでプログラムで送信したキューの状態を知るにはそのプログラムを書かないといけないため、なんとなくブラックボックスになりがちだったSQSですが、このように、可視化されることでSQSがぐっと身近に感じられるようになり、管理も簡単になりました。