「すまほ風鈴」制作裏話/バックエンド的な事

2013.09.03
fuurinbk.png

こんにちは。フロントエンドの村山です。

8月20日に公開された SINAP SUMMER PROJECT 2013 すまほ風鈴 でバックエンドを担当しました。
環境構築、APIの基本設計やフロント担当との調整等を行っていました。
今回はこのSUMMERの開発秘話、というか小話みたいな話をご紹介します。

Node.jsで複数人に動きのあるサービス

開発が始まったのは丁度jsCafeという勉強会でNode.jsに手をつけ始めた頃でした。調べたり勉強会でNode.jsに詳しい方に聞いたりしながらの試行錯誤すること数日、ようやくWebSocketを使ってブロードキャスト処理を行えるようになりました。

このNode.jsですが、Node.js自体はサーバサイドで動作するjavascriptで、実際に複数人に同時に動作を起こしたり出来るのはWebSocket技術によるものです。今回はNode.jsのWebSocketライブラリであるSocket.IOを導入しています。

使いごこちを重視したAPI設計

API(Application Programming Interface)は「こう呼び出したらこう処理する」といった感じのプログラム間のやりとりのお約束事みたいな物なのですが、これをどういう風に作るか悩みました。

具体的にはクライアント(利用者のブラウザ)から「新しく入るよー」とか「この風鈴ならしたよー」というメッセージがきたら、それを接続中のクライアントに「ID:XXXXが新しく追加されたよー」とか「ID:XXXXがID:AAAAをならしたよー」と教えてあげるのですが、この時、接続中の全てのクライアントに対して教えるのか、ID:XXXX以外のクライアントに教えるのか、という部分です。

風鈴をならした時、前者の場合は一旦サーバにメッセージを送り自分に帰ってきたメッセージをキーにして風鈴を鳴らし、後者の場合はまずその風鈴をならした後サーバにメッセージを送ります。先にならすか、後でならすかの違いですが、ネットワークを通じる事で若干のラグが発生し、押した際にすぐにならない「気持ち悪さ」になると考え、後者を採用しています。

ただ全ての部分がそうではなく、触ったらすぐ反応が欲しい部分を後者、それ以外の部分は前者にして処理の簡略化をはかっています。

サーバの分離と負荷テスト

当初は1サーバ完結で構築していたのですが、公開にあたり既存のWebサイトと混成させるためフロントサーバとソケットを管理するサーバに分離しました。ソケットサーバの方にアクセスしてもリダイレクトされるのであしからず。

うまく分離も出来た所でどれほどの負荷に耐えられるのかという話になり負荷テストを行いました。

負荷テスト素人でどうした物かと調べたものの、マッチする方法が見つからなくテスト用に大量のセッションを張るスクリプトを用意しました。調査したのは何セッションまで脹れるのか、高セッション数を維持したままブロードキャストできるのか、といった事です。数千セッションは確立でき、その状態から100程度の同時ブロードキャストも動作する事を確認できました。 200セッションくらいが上限なのかと思ってたので予想を遥かに超える結果でした。
また動かなくなる原因も見えてきて、チューニングでまだまだ余地がある事がわかりました。

私の持ってる小話だとこんな所でしょうか。
環境構築が主だったためちょっと淡々とした話しか持ってなくてぐぬぬ。。。です。
以上、バックエンドを担当した村山でした!

SINAP SUMMER2013 「すまほ風鈴」

スマートフォンで下記のサイトにアクセスしてください。

http://summer.sinap.jp/
この記事をシェアする
このサイトでは、利用状況の把握などのために、プライバシーポリシーに基づき、Cookieを使用してアクセスデータの取得・利用等を行います。