Archive for the ‘Scala’ Category

EventStatsはherokuとMongoLabとさくらVPSで動いている

Posted by ReSTARTR - 28/12/11 at 09:12 pm

今月頭にブログ書きましたが、EventStatsという勉強会の参加者の推移が見れるサービスを公開しました。

まぁ自分が欲しかっただけなんですけど、使ってみて頂ければ幸いです。

今回はそのサービスの構成とかについて書いてみます。

アジェンダ

  1. 全体像
  2. システム構成
  3. Gitリポジトリ
  4. MongoDBのPaaS
  5. 各イベント管理サービスAPIの違い
  6. 開発メモ

1.全体像

開発環境も含めて全体像を図にしてみました。(初Cacooですが超べんりですね！)
赤い線がGit操作で、黒い点線がMongoDBへのアクセスです。

全体像

2.システム構成

大きく分けてwebとクローラーの２つです。

webはherokuに、クローラーはさくらのVPSに配置。
まずは優先してデータ蓄積を…ということでクローラーをpythonとmongodbで作成しました。
(サービス的にはやいとこデータためないと意味ないので。)

クローラーは５分おきに起動するのでScalaよりPythonを選択しました。起動コスト重視です。
(Scalaでサクサク開発できる程のスキルではないというのもありますが…)

実行場所はherokuのworkerも考えたましたが、最終的に既に利用していたさくらVPSでcronジョブとして運用することに。
ということでScalaのWebはデータ参照のみで、データの更新はしません。

3.Gitリポジトリ

webとクローラーは分けてGitで管理。リモートリポジトリはどちらもさくらのVPS上においています。
ただし、本番リリースは開発PCからherokuに別途pushします。
※webもさくらVPSにリモートリポジトリを持って、本番データを参照するステージング環境として利用しています。

eventstats-web

eventstats-crawler

4.MongoDBのPaas

herokuプラグインとしてMongoLabとMongoHQの２つが提供されています。どちらも無料枠があるのですが、MongoLabの方が無料で利用できる容量が大きいのでこちらを選択。
月額の利用料金は以下です。（括弧内は1MBあたりの金額の目安です）

これ以上の容量も利用可能ですが個人で払う範囲ではないと思い除外してます。

MongoLab

MongoHQ

5.各イベント管理サービスAPIの違い

まずはatnd, zusaar, partake.inの３サービスに対応。
それぞれ検索APIを提供してくれているのですが、当然ながら規格とかもないのでリクエストもレスポンスも違いがあります。 データ蓄積する際にそのAPIの差異を吸収して、webアプリから参照する際は気にしなくていい戦略をとりました。

APIの違い検索のみに特化して違いをまとめると以下の通りです。

atnd

イベント数も多いので、このAPIをスタンダードに設定。

zusaar

基本的にはatnd準拠っぽい感じだけど細かい違いがあります。

atndとの違い

partake.in

全然違うAPI。APIリストにあっても未実装がほとんどなので、利用する際はソースを確認したほうが良いです。

今回必要になりそうなAPIは２つくらいでした。

その他の特徴は以下。

上記をふまえ、atnd/zusaarはJSON形式でAPIからデータ取得。
partake.inのみイベントのリストをAPIから取得して、ユーザー数はWebページのスクレイピングで対応しました。

6.開発メモ

web(heroku)からもクローラー(さくらのvps)からも離れた場所にある

開発PC上だと気にならなかったのですが、1件1件findしてinsertやupdateをしていると当然遅いです。なのである程度まとめて一気にinsertする方針に変更しました(ベンチ結果はありません ^^;)。

更新はクローラーの１プロセスからのみ実行されるので、トランザクションとか意識しなくて良いです。なので比較的自由な構成がとれます。

ScalaでJSON API

まずはUnfilteredでJSON APIを作成。けど、jsでjson取得〜チャート生成の実行時間が思いの外大きいので、jsonも１枚のHTMLに埋め込む方針に変更。

さいごに

ざっと書きだすとこんな感じです。まぁこんな構成もあるよ、ってくらいにしか言えませんが。
webとクローラーを分けたことで、開発中のスキーマ変更が柔軟に行えたのは良かったのですが、スキーマ定義を共通で管理していないので、そのあたりうまく管理できると良いなと思ったり。

当初はもう少しwebの機能も多かったのですが、効率化をしているうちにシンプルな形に落ち着きました。Scalaのコードもかなり小規模なものになっています。

イベント管理者の方からのご意見ご要望などいただけると嬉しいです :)

Fork me on GitHub

If you enjoyed this article please consider staying updated via RSS. Links to your own social media pages could be added here.

第二回 #Playframework 勉強会 in Tokyo #play_ja に行ってきた

Posted by ReSTARTR - 10/10/11 at 03:10 pm

第一回は大阪開催だったのとそもそも開催を知らなくて参加できませんでしたが、第二回は有難いことに休日に東京で開催されたので行ってきました。運営の皆様、参加者の皆様、懇親会でお話させて頂いた皆様、どうも有難うございました。

勉強会のまとめ記事

下記ブログにありますのでそちらをどうぞ。

なのでここでは、全体的な話しではなく関心の強いところに関してのみ書こうと思います。 ただの感想文です。

Play!の今とこれから

Play!がどのような分野で使われ、どのように変化していくのかが今の大きな関心事であり、今回の参加理由でした。 今回の発表を聞いていると、Java界隈の救世主（候補）的な位置づけとして期待されているという段階なのでしょう。 主催者の@ikeike443さんの会社のシャノンさんでは実際業務でPlay!を使われていたり、@genki_さんは今まさにSI案件で業務アプリケーションにPlay!を導入しようとしているところだそうで。

Play!2.x系による変化

ただ、Play!が今後2.x系でScalaベースでの開発に切り替わるので、それによって今の勢いがどう変わっていくのでしょうか。JavaベースのPlay!1.xにScalaユーザーを引き込むのと、ScalaベースのPlay!2.xにJavaユーザーを引きこむのでは、大きく状況が変わってくると思います。自分はScalaユーザーなのでこの動きは非常に嬉しいですが、もしかしたら勢いが減速してしまうのではとちょっと不安になったり。 （プラグインのサポートがどちらか一方の言語に限定されていて、結局導入を見送るなんてこともあると思います。）

Play!の外部環境

とはいえ、外部環境としてはPlay!のサポートPassSがちょくちょく出てきているので当分は勢いが衰えることはないと思います。単体でサーバーとして動作させることが可能なだけでなく、war化も可能なのでTomcatやJettyに載っけることができる環境なら動かせてしまいます。とくに@hagikuratakeshiさんや@mitsuhiroさんが取り上げていたようにHerokuのPlay!サポートによって趣味プログラミングとして手を出しやすくなってますし。

ScalaのフレームワークとしてのPlay!

Scala界隈ではUnfilteredやBlueEyesのような積極的にScalaの機能を利用したFWが注目されています。（少なくとも私のTwitterのTL上では…)ただし、日本語ベースのScalaのフレームワークのリファレンスや関連記事はまだまだ少ないのが現状です。 Play!の場合は翻訳も積極的に行われていますし、勉強会に100人近く参加するような日本のPlay!コミュニティの存在は正直無視できないと思います。今後のPlay!界隈の動向に注目です。

If you enjoyed this article please consider staying updated via RSS. Links to your own social media pages could be added here.