-
-
WebSocketでチャットアプリを作る with Redis&Node.js
どうも。営業部の伊藤です。
もともとHTML5の仕様の一部として策定が進められていたWebSocketについて勉強するため、Node.jsを利用して簡単なチャットアプリを作ってみました。(目指せブラウザ版LINE！)
今回はデータベースとしてRedisを採用しましたので、まずはRedisのインストールとコマンドラインを使った簡単な動作確認までを書きます。
まず、Redisをインストールします。
yumでもインストールはできますが、最新をインストールするため、ソースからインストールします。
※2012年9月頃# wget http://redis.googlecode.com/files/redis-2.4.16.tar.gz
# tar zxvf redis-2.4.16.tar.gz
# cd redis-2.4.16
# make
# make installあっという間です。
RedisはANSI-Cで実装されているため、インストール時に依存ライブラリなどのインストールが不要です。
よって、コンパイルは上記ステップで完了となります。既知の情報だと思いますが、念のため。
RedisはインメモリベースのKVSです。
KVSはRDB(リレーショナルデータベース)のJOINのように複雑、且つ高負荷なSQLは発行せず、高速化／拡張性に趣をおいたNoSQLのデータベース管理システムとなります。
いわゆる分散型データ保管技術の1つです。
同様のデータベースにはGoogle検索で採用されているBigtable(ビッグテーブル)、Amazonで採用されているDynamo(ダイナモ)、有名どころだとmemcachedなど様々な種類があります。
また、RDBのような複雑なシステムではないため、サービス(mixi、Amazonなど)や大学の研究で独自のKVSが開発／採用されているケースも多々あります。そんなKVSですが、KVSごとの特徴は？ということで、今回選定したRedisの特徴をいくつか記載します。
1. 永続化機構
通常メモリ上でデータを管理しているため、memcachedのように障害時、再起動時にはデータを喪失してしまいますが、Redisは定期的にデータのスナップショットをダンプファイルにし、再起動時にこのファイルをメモリに読み込むことでデータを復元する仕組みを備えています。
定期的という事で不安を抱く方も多いと思いますが、”Append Only File”という仕組みを利用することで全ての更新コマンドを管理しておき、再起動時にこのコマンドを読み込むという方法もあります。これであればデータの喪失は最小限に食い止めれます。
注意すべきなのは、永続化機構といってもあくまでもインメモリベースのため、最大容量はRAMに依存します。
RAM容量より多くのデータを保存したい場合はスワップファイルを利用し、一部のデータをHDDに退避させる必要があります。(RedisVM)2. 豊富なデータ型とコマンド
Redisはハッシュ(HASH)以外の型もサポートしており、リスト型(LIST)、集合型(SET)、順序付き集合型(SORTED SET)などのデータ構造が扱えます。
また、コマンドが非常に豊富、且つアトミックに操作が可能なため、CAS操作などトランザクションを考慮した処理が不要です。
ただし注意すべき点として、アトミック実行(MULTI／EXEC)は一般的なトランザクションとして実行されている訳ではないため、実行中にエラーが発生した場合にROOLLBACKはされません。残りの処理も実行されます…ここは要注意です！
(値を設定＆取得くらいのアトミック操作であれば”GETSET”という1つのコマンドで対応可能)
KVSの利用用途としてはデータの整合性よりもスピード重視の利用用途が多いと思いますので、トランザクションを考慮する機会は少ないと思いますが、アトミックに操作が可能な事でデータ管理方法の幅が広がります。3. レプリケーション
Redisはマスター／スレーブのレプリケーションが設定ができ、スケールアウトが非常に容易です。
設定は簡単で、スレーブ側の設定ファイルに以下項目を追加するだけです。# cp redis.conf redis_slave.conf
# vi redis_slave.conf
…
# port 7000 <= スレーブはポート7000番で稼働
# slaveof localhost 6379 <= slaveofにマスターのホスト名とポート番号を指定
…
# redis-server redis_slave.conf設定できているか否かの確認はinfoコマンドを実行するか、実際に値を設定して確認します。
infoコマンドの場合、実行後に「role」を確認してください。# redis-cli -p 6379 -h localhost <= マスターに接続
redis 127.0.0.1:6379>info
…
role:master
…役割がマスターになっていますね。次にスレーブに接続します。
# redis-cli -p 7000 -h localhost <= スレーブに接続
redis 127.0.0.1:7000>info
…
role:slave
…役割がスレーブになっていますね。無事設定できているようです。
最後に、実際にレプリケーションできているかを確認するため、マスターにデータを登録し、その後スレーブでデータを取得してみます。
# redis-cli -p 6379 -h localhost
redis localhost:6379> set test “test-data”
OK
redis localhost:6379> get test
“test-data”
redis localhost:6379>exit# redis-cli -p 7000 -h localhost
redis localhost:7000> get test
“test-data”
redis localhost:7000>問題なさそうです。
4. Publish/Subscribe型(Pub/Sub型)の通信をサポート
今回DBにRedisを採用したのはこの「Pub/Sub型通信」をRedisがサポートしているためです。
送信側と受信側がトピックを介して”多対多”で通信できるモデルのため、Redisを中継サーバとしてWebSocketサーバを冗長化する事ができます。
Node.jsについて説明できていないため順番が前後しますが、Nodeを利用してPub/Sub通信の動きを確認してみます。nodeのコンソールを起動し、以下スクリプトを実行します。
# node
> var sys = require(“sys”);
> var redis = require(“redis”);> var subscriber = redis.createClient(6379, “localhost”);
> subscriber.subscribe(“I am subscriber”);
> subscriber.on(“message”, function(channel, message){
> sys.puts(channel + “に「” + message + “」というメッセージが送信されたようです。”);
> });> var publisher = redis.createClient(6379, “localhost”); //publisherは敢えて作る必要ないです。var subscriberを使って問題無いですが、分かりやすくするため！
> publisher.publish(“I am subscriber”, “I am publisher”);6379番ポートのredisの「I am subscriber」というトピックに対して配信を申し込み(subscribe)、配信があればコンソール上に受信内容を出力するようにします。
その後、6379番ポートのredisの「I am subscriber」というトピックに対して”I am publisher”というメッセージを配信します。上記スクリプトを実行すると、以下メッセージが表示されます。
> I am subscriberに「I am publisher」というメッセージが送信されたようです。Pub/Sub通信のイメージ湧きましたでしょうか？
分かり辛いですね…なんというか…自作自演ってな感じですね。という事で、上記コンソールはそのままにしておき、別コンソールを起動して以下コマンドを実行してみます。
# redis-cli -p 6379 -h localhost
redis localhost:6379> publish “I am subscriber” “I am publisher”するとnodeコンソール上に先ほどと同様に以下メッセージが表示されます。
> I am subscriberに「I am publisher」というメッセージが送信されたようです。これこそがPub/Sub型の配信モデルです。
node側ではトピック「I am subscriber」を購読(subscribe)状態のため、
別イベントで「I am subscriber」にメッセージが登録されたと同時にメッセージをお知らせしてもらっています。今回は受信／購読者(Subscriber)、発行／公表者(Publisher)共に単一で確認しましたが、前述したように多対多の通信モデルのため、複数のSubscriber、またはPublisherでも上記通信が可能となります。
WebSocketサーバーを冗長化した際に各々のサーバーでsubscribeしておき、連携したいデータをpublishすればサーバー間連系はこの中継サーバーに委ねられます。
単一であればWebSocketでブロードキャストすればいいだけですが、冗長化を考えるとPub/Sub型を利用できるredisは非常に便利です。
エンドポイントはWebSocketで管理しているため、サーバー間はPub/Sub型じゃなくてTriggerでもいいんじゃない？という方も居ると思いますが、サービス独自の特殊な通信制御が必要でない限りはPub/Sub型通信モデルの方が便利だと思います。Redisの準備は一旦ここまでとし、次はNodeの準備を進めます。
少し長くなってしまったため、Nodeと各種ライブラリ(Socket.IOやExpressなど)のインストールについては
次回ブログで投稿させていただきます。
-
究極のUX
UXとかUIとか大好き竹内です。こんにちは。
究極のUXって多数決でしかない様な気がするのは気のせいですかね。元々は何用語なんでしょうか？詳しいことはわかりませんが、WEB界隈ではかなり頻繁にこの言葉を目にしたり聞いたりする様になりました。
仕事柄、WEBサイトのUIや、サービスフローや動きに関するUXなどにはいつも「なんで？」「どうして？」と疑問を抱きながら接するようにしています。もちろんそれはPCやスマートフォンの画面の中だけではないです。
「どうしてここは引き戸なんだろう？」「どうして左が登りで右が下りなんだろう？」「手すりがここで終わってるのは何でなんだろう？」「こっちにもあれば便利なのにな」「どっちがどっちかわからないよ」「なんで何も書いてないの？」「一見お洒落なだけで使いにくいね」･･･などなど、それがUXとかUIとかいう言葉で括られる物とは特に意識しなくても生活していれば色々と感じるものです。そんな中、先日、ちょっと「おやっ？」と思う蛇口に出会いました。
皆さんは蛇口は「ひねる（まわす）もの」という感覚が強いですよね？
もちろん他にも上下に上げ下げするものや、自動で出るものなどもありますが、多くの人が蛇口と言えば「ひねる（まわす）」と思うのではないでしょうか。
ではそんな決め付けの文章を書いた後ですが、皆さんはこんな水道を見たらどうしますか？
自分だったら上にあげます。
こんな水道だったらどうでしょう？もう「ひねる（まわす）」と思う人は少ないと思います。
では、この白い部分が蛇口の両サイドに付いていたらどうでしょうか？
（今、写真を撮ってこなかったを猛烈に後悔しています）
いかにも「上にあげる」と思われる形のものが蛇口の両サイドにある場合、人は慣習的に「ひねる」のか「あげる」のか？ちなみにその蛇口は「ひねる」のが正解でした。
何度かその洗面台を使ったのですが、自分は無意識に「あげる」操作をしようとしていて少しイラついたのを覚えています。蛇口だとそれほど違和感のあるものへの遭遇機会は少ないと思いますが、ドアの取っ手（ドアノブ）などであれば遭遇機会はそこそこあるのではないかと思います。
「まわす」のか「下におろす」のか、「押す」のか「引く」のか「横にスライドさせる」のかなどなど。
横へスライドして開けるドアにまるいドアノブが付いている所を想像してもらえればかなりの違和感を想像できるのではないでしょうか。
上の蛇口については全然伝わらなかったと思いますが、このドアの例と同じくらいの違和感でした。実生活での体感も、画面の中での体感もそれほど大きくは変わらないはずですので、ユーザに不便や違和感や気持ち悪さを感じさせないものづくりをして行けたらなと思いました。
-
RoRと格闘中
-
「インターフェースデザインの心理学」読了
ミステリー小説が大好き竹内です。こんにちは。
森博嗣の作品が大好きですが最近のはまったく読めていません。そんな中、先日、インタフェースデザインの心理学という本を本屋で見かけて購入しました。
もともとUI/UXには興味関心が強いのでこういった読み物は大好きです。書評が出来るほど沢山の本を読んでいる訳でもないですし、知識がある訳でもないのでただの感想になりますが、読み物として非常に面白かったです。
人間はインプットをどの様に解釈して、脳はどの様に理解し、それをどの様にアウトプットするのか？そんなことが各章毎にテーマ別に書かれていますので、興味のある章だけつまみ読みする事も出来ます。
自分が特に面白いなと思ったのは以下の項目でした。031 人はシステムを使うときメンタルモデルを作る
043 ある事態に対する注意力は頻発が予想されるか否かで決まる
052 ドーパミンが情報探索中毒を招く
074 データより物語のほうが説得力がある
087 エラーはすべてが悪いとはかぎらないそれぞれに説明すると長くなってしまうのとネタばれになってしまうので解説はしませんが、どれもこれもなるほどなぁと思える内容でした。
「当たり前じゃん」と切り捨てようと思えば切り捨てられる項目もあるのですが、その部分に再度注目することで意識が高まるので良かったです。
「当たり前」の中にこそ真理はあり、「当たり前」は決して外す事はできず、そして「当たり前」の事を「当たり前」にやるのがどれだけ難しい事かを再認識する良い機会になったと思います。この本はリファレンス本ではないのですが、コンテンツを制作する上で迷った時にはたま～に目次に目を通して参考にできそうです。
あまり遠くの人には貸せませんが、社内であれば誰でもお貸ししますので、興味があれば一言かけて貰えればと思います。
次は何読もうかなぁ～。
-
レスポンシブウェブデザインについて思ふ
