ReSTARTR http://blog.restartr.com PythonとかScalaとか弄ります。 Wed, 28 Dec 2011 12:27:52 +0000 ja hourly 1 http://wordpress.org/?v=3.1.3 EventStatsはherokuとMongoLabとさくらVPSで動いている http://blog.restartr.com/2011/12/28/eventstats-consist-of-heroku-mongolab-and-sakura-vps/ http://blog.restartr.com/2011/12/28/eventstats-consist-of-heroku-mongolab-and-sakura-vps/#comments Wed, 28 Dec 2011 12:27:52 +0000 ReSTARTR http://blog.restartr.com/?p=1174 今月頭にブログ書きましたが、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

  • host: さくらのvps
  • python 2.6
    • フレームワーク: なし
    • mongodb接続: pymongo 1.11
    • テスティングライブラリ: nose
    • その他: BeautifulSoup (partake.inのwebスクレイピングに利用)

4.MongoDBのPaas

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

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

MongoLab

  • $ 0.00/240MB
  • $10.00/0.5GB ($0.020/MB)
  • $20.00/2.0GB ($0.009/MB)

MongoHQ

  • $ 0.00/ 16MB
  • $ 5.00/256MB ($0.019/MB)
  • $15.00/2.0GB ($0.007/MB)

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

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

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

atnd

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

zusaar

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

atndとの違い

  • エントリポイントやデータのキー名が単数形
    • events→event
    • users→user
  • 明確なフィールドとしてのtwitter_idが無い
    • 管理者も参加ユーザーも
  • ハッシュタグがない
  • レスポンスはjson一択

partake.in

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

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

その他の特徴は以下。

  • 複数イベントを特定して一括取得するAPIはない
  • フィールド名がcamelCase形式
  • レスポンスはjson一択
  • 検索パラメータも特殊かつ少数
  • 検索APIで取得できるのはイベントの固定情報のみ
    • 参加枠数はAPIから取得可能
    • 変動するユーザー数は取得不可能
    • →Webページをスクレイピングするしかないという結論

上記をふまえ、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のコードもかなり小規模なものになっています。

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

]]> http://blog.restartr.com/2011/12/28/eventstats-consist-of-heroku-mongolab-and-sakura-vps/feed/ 0 イベントの参加人数の遷移が見れるサービス『EventStats』を作りました。 #atnd #zusaar #partake http://blog.restartr.com/2011/12/10/eventstats/ http://blog.restartr.com/2011/12/10/eventstats/#comments Sat, 10 Dec 2011 09:58:51 +0000 ReSTARTR http://blog.restartr.com/?p=1096 イベント管理サービスについて

勉強会などでよく利用されるのが、イベント管理サービス。
ATNDやZusaar,Partakeなど、様々なサービスがあり、現在も新しいものが生まれている状況。

今や勉強会を開催する上で必須のサービスとなっていますよね。

ですが、主催者や参加者にとってそれらのサービスで閲覧できるのは『今どのような状況か』ということだけです。それまでどのように参加者が増えてきたのか、その後も参加者が増えそうか、ということまでは見ることができません。

「今」ではなく「過去」を知りたい。(by @ReSTARTR)

ということで作りました。

イベントごとに登録数、補欠数、枠数を記録するサービス「EventStats｣

簡単にいうとKloutの勉強会バージョン（のとっかかり）です。 このサービスを使えば、登録数と枠数の推移を時系列のチャートで確認することができます。
5分おきに各イベント管理サービスの情報を取得して蓄積し、情報を表示しているだけのシンプルなサービスです。
(※ SVGベースのチャートのため、androidでは2.4/3.0以降でないと見れません)

あと、2011年11月頭くらいからデータ蓄積開始したのでそれ以前のイベントの履歴は見れない場合があるのと、Partakeの枠数が0人なのも蓄積ミスです。

使い方

  1. ブックマークレットをブラウザに登録する
  2. 履歴を知りたいイベント管理サービスの詳細ページに移動する
  3. ブックマークレットを実行する

技術的なこと

とりあえずHeroku上でScalaのUnfilteredを使って動かしています。
技術的な話しは追々。

今後どう料理するか

実はMA7の締切りぎりぎりに公開してました。（証拠↓）

https://ma7.mashupaward.jp/works/478?locale=ja

が、リソースが足りてないさくらのVPSで動かしていたので、公開したことはとくにアナウンスとかしてませんでした。（MA7には当然のごとく選考漏れでしたが。）で、それからHerokuへの移行を進めつつ機能の修正などをやってたという訳です。

今後は蓄積したデータをもとに、勉強会運営や勉強会への参加の助けとなる数値を加えていければいいなと。 実はテストとか負荷試験とかあんまりできてないのであまりイジメないでください^^;

]]> http://blog.restartr.com/2011/12/10/eventstats/feed/ 0 （もうすぐ）退職します。 http://blog.restartr.com/2011/12/02/dropped-out/ http://blog.restartr.com/2011/12/02/dropped-out/#comments Fri, 02 Dec 2011 12:27:57 +0000 ReSTARTR http://blog.restartr.com/?p=1109 私事ですが現職の会社を退職することになり、本日無事に最終出社を終えてきました。 退職日は年明けですが、これから有給消化期間に入ります。

ということで記念碑的に退職エントリを書いておこうと思います。

有益な退職エントリをご希望の方は下記まとめに移動することをオススメします。

現職のはなし

現職では、2006年に新卒入社してから約5年半、某ポータルサイトの開発全般を担当してました。

1年に1回部署異動が発生するくらい頻繁に体制変更があったおかげで様々な経験をさせてもらい、「自分がやりたいこと」を見つけるにはとても良い環境だったと思います。

入社してすぐ営業研修で外回りとか経験した後、データ入稿まわりを担当。その後1年間で二度のサイトリニューアルプロジェクトを経験。1年間のサイト運用期間を経て、今担当しているログシステムの開発をやりました。 入社から数年はPHP+RDBMSを中心としたWebアプリ開発に従事してましたが、ここ1年くらいはログシステムをHadoop/Hiveにリプレースする担当をやってました。年を経るごとにインフラに近づいていってる感じです。

技術的知見が広がるシロモノ

Hadoopって技術的には上から下まで幅広い知識とか素養が必要なんですよね。 実際のクラスタ構築はインフラチームの担当でしたが、それに至るまでの導入実験とかは自分でもひと通り経験していて、それにを肌で実感していくうちにもっとシステム全般に関わりたいと思うようになりました。現職ではアプリケーションとそれを載せるインフラの担当が明確に分かれていました。そのおかげで我々はアプリケーションの開発に専念できるのですが、一方でインフラにはどうしても疎くなりがちでした。(現在社内ではその垣根を改善する動きが出てきているので今後はもっと良い体制に変わっていくと思います)

そういう意味でHadoopは「技術の交差点」なんだと思います。非常に低いレイヤーからアルゴリズムまでがごっちゃごちゃに混ざったおもちゃ箱のような。それまでPHPのステートレスなシングルスレッド内であれこれするだけしたが、そこでは得られなかったものに興味関心が広がっていきました。Hadoopで実際何を実現するかはさておき、それをひと通り経験することで技術者として一歩前にすすむことができるし、その中でさらに深堀りしたいものを見つけることのできるシロモノだったと思います。

オープンソースコミュニティ

ここ1年ほどは社外のカンファレンスや勉強会へも平日休日問わずよく参加してたのですが、上司にもそれついてよく理解して頂き、本当自分の動きたいようにさせてもらえたことは有難い限りです。 外の世界は自分が想像している以上でした。勉強会で発表を聴いたり懇親会で話しをさせていただいたりすることで、自分の足りないところが嫌でも見えてきました。現職に限らず今後どのように成長したいのか、について改めて考えるきっかけにもなりました。 今はちょっとメンタル的な問題もあって勉強会参加は自粛していますが、年明け以降にまた少しづつ参加させていただこうと思ってます。

さいごに

年明けまでは旅行とか帰省とかしてゆっくり静養しつつ、技術的な取り組みも継続していこうと思います。暇を見つけて開発しているものもあるのですが、それも近々公開できると思います。あと、次の会社も決まっているのですが今後の話しはまたあらためて別の機会に。

（このブログの読者に現職の方がどれくらいいるのかわかりませんが）とにかく現職で関わった皆様には本当に大変お世話になりました。改めて御礼もうしあげます。

約5年半、どうもありがとうございました。

]]> http://blog.restartr.com/2011/12/02/dropped-out/feed/ 0 第二回 #Playframework 勉強会 in Tokyo #play_ja に行ってきた http://blog.restartr.com/2011/10/10/play-framework-study-in-tokyo/ http://blog.restartr.com/2011/10/10/play-framework-study-in-tokyo/#comments Mon, 10 Oct 2011 06:59:13 +0000 ReSTARTR http://blog.restartr.com/?p=1073
  • 第二回 #Playframework 勉強会 in Tokyo #play_ja

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

    勉強会のまとめ記事

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

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

    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!界隈の動向に注目です。

    ]]>     http://blog.restartr.com/2011/10/10/play-framework-study-in-tokyo/feed/ 0     Scalaで設定ファイルを使いたい時どうしたらいいの？ http://blog.restartr.com/2011/08/30/config-libraries-in-scala/ http://blog.restartr.com/2011/08/30/config-libraries-in-scala/#comments Mon, 29 Aug 2011 15:02:15 +0000 ReSTARTR http://blog.restartr.com/?p=1049 2011.08.31 kmizushimaさんから頂いたコメントを元に、下記の記述を修正＆追記しました。

    • Twitterのutil-evalの一時ファイル生成について
    • AkkaのConfigファイルのパース手法について

    TwitterのOAuthの鍵やDB接続情報など、アプリを書く上で環境によって切り替える設定が大抵の場合あると思います。普段使っているPHPの場合、設定を外部ファイルに書きだす場合、ini,yaml,xml,phpのいずれかを使うことが多いのですが、Scalaの場合、設定ファイルってどうするのか気になりました。

    ということで、適当に思いついたライブラリやフレームワークがどのように対応しているのか調査。

    ライブラリ

    propertiesファイル

    • javaの古くから使われている
    • キーと値のみ設定可能
    • 依存関係がないので手軽。
    • すべてが文字列
    • 例えばこんな感じ

    path/to/conf.properties

    1
    hoge = "moge"
    1
    2
    3
    val p = new java.util.Properties()
    val config = p.load(new java.io.FileInputStream("path/to/conf.properties");
    config.get("hoge") // "moge"

    twitterのconfiggy

    twitterのutil-eval

    設定のtraitを定義

    src/main/scala/com/restartr/utilSample/MyConfig.scala

    1
    2
    3
    4
    5
    package com.restartr.utilSample
    trait MyConfig {
      val num: Int
      val str: String
    }

    実際の設定ファイルでは、設定のTraitを継承してインスタンス生成
    ※クラスインスタンスでなくても文字列やリストでもOK。

    path/to/config/MyConfig.scala

    1
    2
    3
    4
    5
    import com.restartr.utilSample.MyConfig
    new MyConfig {
      val num = 1
      val str = "san"
    }

    使いたい場所でEval。

    1
    2
    3
    val conf = Eval[MyConfig](new java.io.File("path/to/config/MyConfig.scala"))
    conf.num // 1
    conf.str // "san"

    configrity

    各種フレームワーク

    以下のフレームワークはすべて独自実装でした。Propertiesじゃ役不足だし、かといってデファクトな設定用ライブラリがないからなのでしょうか。

    akkaのconfig

    • akka.confとかがそれ。
    • 独自パーサーを使用
      • 70行程度のシンプルなパーサー
      • akka.config.ConfigParser
      • 正規表現で定義されてるScalaのパーザコンビネータ(RegexParsersを継承)で定義されている
        • “{“と”}”で階層構造を表現
    1
    2
    3
    4
    5
    akka {
      cluster{
        name = "test-cluster"
      }
    }
    • 使える型
      • 数値
      • 文字列
      • 真偽値（on/off , true/false)
      • リスト [1,2,3] / ["hoge","moge"]

    play!frameworkのconfig

    • 独自パーサー
    • java.util.propertiesを継承したもの。
    • 環境ごとにIDを割り当てられる
      • http://playdocja.appspot.com/documentation/1.2.1/production
      • http://playdocja.appspot.com/documentation/1.2.1/guide11
      • IDごとに%{ID}を頭につければ切り替えてくれるみたい

    Lift

    ざっと調べて使ってみたところ、手軽にやるならProperties、フレームワークを使うならそれに則り、厳密にやるならTwitterのEvalや、設定ファイルを読み書きできる独特なConfigrityなんかがよさそうです。

    XMLは…まぁないでしょうね。

    ]]>     http://blog.restartr.com/2011/08/30/config-libraries-in-scala/feed/ 2     ScalaのORMapperのSquerylを試してみてハマった３つのこと http://blog.restartr.com/2011/08/16/3-things-that-i-was-in-trouble-using-squeryl/ http://blog.restartr.com/2011/08/16/3-things-that-i-was-in-trouble-using-squeryl/#comments Mon, 15 Aug 2011 23:00:15 +0000 ReSTARTR http://blog.restartr.com/?p=1024 ScalaのORMとしてSquerylってのがあります。

    使い方は上記リンク先を見ればだいたいわかります。 あと、@jugyoさんのブログに導入あたりはまとまっていますし、つまづいたらGoogleGroupで検索すれば何か見つかるかもしれません。

    さて、今回はTwitterっぽいものを想定して機能を試してみたのですが、３つほどハマったところを記しておきます。 環境はScala2.9.0.1、Sbt0.7.7、MySQL5.5、Squeryl0.9.4です。
    ソースはgistに登録。それを本文末尾にも掲載しておきました。

    １．プライマリーキーの指定での嵌りどころ

    1つのカラムがPKとなるテーブルスキーマの場合、org.squeryl.KeyedEntity[T]を継承して使います。

    1
    class Users(id: Long, text: String) extends KeyedEntity[Long]

    KeyedEntityにはidというフィールドが用意されていて、継承時に型を指定することで、PKの型に適用させることができます。今回の場合であればLong型のPK「id」ということになります。
    ただし、この場合、PKはautoincrementedになってしまいます。

    コード的には下記のようにKeyedEntity[T]を使わずSchema継承時に定義するのと同等になるわけです。

    1
    2
    3
    4
    5
    6
    7
    class Users(id: Long, text: String)

    class Db extends Schema {
      val users = table[User]("users")
      on(users)(u => declare(
        u.id is (primaryKey, autoincremented))
    }

    これは結構困ります。そんな場合はSchemaを継承するときに定義を上書きすればOK。

    1
    2
    3
    4
    5
    6
    7
    class Users(id: Long, text: String) extends KeyedEntity[Long]

    class Db extends Schema {
      val users = table[User]("users")
      on(users)(u => declare(
        u.id is (primaryKey))
    }

    これはSquerylのGoogleGroupに書いてました。

    ２．DDLのカラムの順番の嵌りどころ

    Db.printDdlを実行した時にカラムの順番が予測できません。
    PKが最初にくるのかと思えばそうでもないみたい。ここは細かく追ってないですが、これもGoogleGroupに答えがありました。

    答えとしては、org.squeryl.internals.DatabaseAdapter:: writeCreateTableあたりをorverrideしてなんとかしてくれとのこと。 https://github.com/max-l/Squeryl/blob/master/src/main/scala/org/squeryl/internals/DatabaseAdapter.scala#L255

    なんか良い方法はないの… とりあえず、printDdlした結果をコピーして、順番だけ書き換えて、手動で直接DBにクエリ発行すればなんとかなるでしょう。

    ３．外部キーの利用でのはまりどころ

    ２つのテーブルにRelationを設定してからDb.createした際、外部キーが設定されない問題がありました。 MySQLは5.5を使っているので外部キーに対応していない訳でもないです。 問題はAdapterの選定にありました。 org.squeryl.adapter.MySQLAdapter をつかっていたのですが、 org.squeryl.adapter.MySQLInnoDBAdapter を使えばOKでした。

    根本の原因は、org.squeryl.adapter.MySQLAdapterに

    1
    override def supportsForeignKeyConstraints = false

    と定義してあり、一方のorg.squeryl.adapter.MySQLInnoDBAdapterには

    1
    override def supportsForeignKeyConstraints = true

    と定義してあります。
    この値がtrueになっていないとForeignKeyの制約がDDLに含まれなくなってしまうので注意です。 Docコメントにも書いてあるので注意です。

    以上、Squerylを弄ってみて嵌ったことをまとめてみました。

    Squerylの使用感

    ちょっと前にTwitterのStreamAPIのデータをMySQLに格納するためにSquerylを使ったのと今回少し弄ってみただけなのでまだまだ知らないことだらけです。他にも機能的はたくさん用意されていると思いますし、APIも割となじみやすいので複雑すぎないテーブル定義の場合には積極的にSquerylを使っていこうと思います。

    ※ドキュメントや本体のソースを追いかけたりしながら使い方を学ぶのは非常に楽しいです:)

    で、ソースは以下です。

    ]]>     http://blog.restartr.com/2011/08/16/3-things-that-i-was-in-trouble-using-squeryl/feed/ 0     Varnish勉強会 #tokyovcl に行ってきた http://blog.restartr.com/2011/06/21/go-to-varnish-study-tokyovc/ http://blog.restartr.com/2011/06/21/go-to-varnish-study-tokyovc/#comments Tue, 21 Jun 2011 14:56:40 +0000 ReSTARTR http://blog.restartr.com/?p=996 IMAG0053

    6/18(土)に開催されたVarnish勉強会 Tokyo.vcl : ATNDに行ってきました。 初のクックパッドさんオフィス訪問です。

    Varnish3のリリースパーティーも兼ねての開催だったようで、ステッカーもいただいてしまいました。
    インフラ屋じゃない上に、Varnish触ったのは前日の晩という超初心者だったので結構不安でしたが、
    ビアバッシュを含め色々な話しが聞けた実りある良い勉強会でした。

    主催の@hmskさんをはじめ登壇者の皆様、ならびにビアバッシュで交流してくださった皆様ありがとうございました。

    雑感

    • Varnishは画像配信の事例が多い
    • HTTPサーバーの前だけじゃなくてSolrのような内部ネットワーク間の通信にも適用できる。
    • Varnish落ちたときにApacheの負荷を避けるためにSquidが使える。
    • 拡張次第でHTTPサーバーにもKVSにも化ける（やりすぎ注意？）。
    • クラウドでの運用はフロンティア。
    • 設定ファイルのvclはもはやプログラム
    • ESIの事例なかったけど使いにくいのかな？
    • とりあえず実戦投入して様子見ないとわからないことが多そう。
    • あ、どれだけ高速化したかについての言及がなかったような…

    各発表メモ

    スライドと、その丸写しみたいな感じのメモをペタペタ。

    VarnishCache3.0新機能とVUPの仕方(@xcir)

    tokyo.vcl発表資料（VarnishCache3.0新機能とVUPの仕方）
    View more presentations from xcir
    • ESIでのgzip
      • ブロックが圧縮されているとESIできなかった(~2）
      • defaultパラメータが改善された
    • stream support
      • 別のストリームは待機させられる（？

    イカ娘も終わったしVarnishでも使うか(@phji)

    イカ娘も終わったしVarnishでも使うか
    • [RAM8G Xeon 4core SSD256GB ] x 20servers
    • pixiv
      • nginx -> (consistent hash) -> quid -> nginx -> apache
      • lookupとかかないとキャッシュされないｗ

    twitter検索(yats)でvarnish使ってみた(@PENGUINANA_)

    • API 7000M req/month
    • PV 150Mreq/month
    • varnish(vps) -> nginx[ webAPI -> varnish -> Solr ]
    • service : cache + failover
    • Solr: slaveのキャッシュクリアーが重いので、その前面にVarnishをおいている(ラウンドロビンとFailover）
    • autocomplete
      • キャッシュと相性よさそう

    EC2とvarnishで画像配信(@mirakui)

    EC2とVarnishで画像配信
    View more presentations from Issei Naruta
    • 失敗談
    • TOFU
      • アップロード時ではなくオンデマンドでリサイズ
      • akamai（CDN)に7000RPSのうち、ELBには700RPSくる。60%受けるリクエストをキャッシュできればApache負荷軽減できるのでは？
        • という導入経緯（からの失敗
      • 1st challenge
        • EC2(M2.XLARGE[17.1GB RAM] + EBS[100GB for swap])
        • 300rps
        • 結果：オンメモリだけなら順調だけど、あふれてきてOSにSWAPさせたとたんLOADAVERAGEが爆発して死亡。
      • 2nd challenge
        • EC2(M2.XLARGE[17.1GB RAM] + EBS[100GB for ext3])
        • “file storage”を使っても結局メモリ容量が大量に必要
      • ec2のxlargeインスタンスには、IO性能「標準」と「高」がある
        • 今回は「標準」を利用して失敗
        • 「高」ならうまくいくかも
    • varnish3
      • hash director
        • consistent hashingができるかも？
        • nginxいらずに複数varnish運用ができるかも？

    Puppetでvarnishもsquidも面倒みる(@ar1)

    • ふつうはvarnishは落ちるのでLBつかって並列で運用
    • varnishおちるとWebサーバーが負荷かかってしまう
      • LB -> varnish -> squid -> apache
      • squidどうしでキャッシュを共有できるので、１つSquidおちてもWebサーバーにききにいかずにすむ。
    • puppet
      • 設定をらくにする
      • cacheのExpire
      • サーバーのぬきさし

    楽天でvarnish(@spchidren)

    • L7 balancingがやりたくてVarnish導入
      • URLによってWebサーバーのグループを切り替えたい
    • akamai -> LB -> varnish(RAM24G[malloc18G/hitrate 75%] -> apache(+mod_thumb)
    • LBからVarnishを切り離すのはどうやる？
    • CDNやVarnishのcache clearをどうやるか
      • 画像登録されたときにMQに登録して、必要に応じて消す
      • CDNは常にExpireされない状態にしておける。
    • ImageMagicおもい
      • varnishにサムネイルをつくるしくみを組み込んでみれば？（FreeImage)
      • cc_commandでインクルードさせて、C言語でサムネイルつくるしくみをくみこむ
    • varnishのいくさき
      • nginxにも近いしredisにもちかづいてきてる
      • どこにいくんでしょ

    TDDでVCL書いてデプロイ(@hmsk)

    • varnishtest
      • RSpecぽい書き方できる
      • xxx.vcltestファイルにケースを記述
    • vmod
      • vclの設定をC言語っぽく描ける
      • パージや圧縮、エラーなどに使える
      • モバイル端末のリストのチェックにもVCLから外出しできる

    関連リンク

    ]]>     http://blog.restartr.com/2011/06/21/go-to-varnish-study-tokyovc/feed/ 0     東京から福島へ一泊二日でボランティアに行ってきた http://blog.restartr.com/2011/06/19/volunteer-at-shinchi-fukushima-pref/ http://blog.restartr.com/2011/06/19/volunteer-at-shinchi-fukushima-pref/#comments Sun, 19 Jun 2011 03:03:20 +0000 ReSTARTR http://blog.restartr.com/?p=970 IMG_5100

    6/11,12の土日を利用して、福島県相馬郡新地町にボランティア活動に行ってきました。

    活動の経緯

    東日本大震災がおきてから、被災地に対して何かできることを、ということでこれまで募金と献血をやってきました。が、それだけでなく何かできることはないかと常々考えていました。
    仕事柄、ITを利用した貢献も考えたのですが、イマイチ現地の状況がわからない。情報を得ようとしても地域やソースによって様々かつ時間とともに大きく変化しているからです。
    また、社会人とはいうものの土日の時間やお金については結構余裕があるので、じゃあ現地でボランティアをすることで現状を知ることができるのではないか、と考えたのが今回の経緯です。 その後、被災地の状況に詳しい元同僚に相談し、その子の母親と友人2名を加えた5名で活動をしてきました。

    活動内容

    IMG_5090

    津波の被害をうけた民家の瓦礫撤去作業を行いました。
    とはいっても大きな物はあらかた自衛隊が撤去しているので、我々の役目は倒れた木の撤去や、瓦・ガラス等の破片の収集、側溝の泥かきなど、担当した民家の敷地内を綺麗にすること。
    計10名程度で、1日かけて行いましたが、天候が曇りだったこともあって順調に作業をすることができました。

    現地に行ってみて

    ボランティアセンターすごい

    現地到着。まだ受付前。

    被災地のボランティアセンターもずいぶん落ち着いてきているようです。
    活動に必要な道具（スコップやマスク）だけでなく、水や活動後のアイスコーヒーなどの提供もして頂きました。
    ボランティア活動自体初めてだったのですが、たとえ不慣れであっても、コーディネーターの方々や一緒に活動する方々の力を借りながら活動することは可能であると実感しました。
    現地でボランティアをしたいと考えているけど踏み出せなかった方は、真夏になる前に一度足を運んでみてはいかがでしょう。

    電波悪い

    SoftBankの黒SIMをDesireSに入れて利用しているのですが、ほぼ繋がりません。
    全然つながらない訳ではないですが、かなり不安定でたまにつながる程度。picplzで写真アップロードしようとしても100%失敗します。
    今回の震災でインターネットが活躍したという話は聞きますが、このような電波状況のままでは欲しい情報も手に入らないでしょう。震災後にこうなったのかもともと電波の弱い地域だったのかわかりませんが、これではインターネットの存在も無意味。

    利用した福島県伊達市（福島市の近く）の宿泊施設で、地震を体験したのですが、電波が皆無だったために震源や地震の規模などの情報が全く手に入りませんでした。

    これまで、インターネットでほしい情報をいつでもどこでもすぐに手に入れられると思っていただけに、手に入らない状況に出くわすとかなりの不安感を覚えます。
    こうなると、頼れるものはテレビやラジオ、町内放送やご近所ネットワークになってくるでしょう。 もちろん有線でのインターネットもあるかもしれませんが、緊急時にわざわざPCを起動したりしないでしょう。

    そう考えると、インターネットの果たすべき役割はリアルタイムに必要な一次的情報ではなく、その後の情報配信とその整理に注力すべきだと実感しました。

    活動内容と現地で聞いたこと

    一日目は新地町でボランティアを行い、宿泊施設はりょうぜん里山がっこうを利用。 二日目は里山がっこうの自然体験をさせてもらい、その後温泉街で足湯につかって帰宅。

    里山がっこうでは、震災後の放射能の影響とその取組みについて色々お話を伺いました。友人のブログにその詳細が書かれていますので、そちらを参照してもらうほうが良いと思います。

    1日目の活動レポートもあります。

    ボランティア活動に必要な情報

    ボランティアバスツアー

    被災地は基本的に交通が整備されていません。 一人暮らしで車も所有していない自分としては、現地の交通手段がネックになります。 幸い、「ボランティアバスツアー」というものがあったのでこれを利用することを考えました。

    これなら一人でも現地に向かうことも可能ですし、そこからはコーディネートしてもらえます。 結局は、冒頭にも書いたとおり、田舎暮らしのマッチングの仕事の関係で被災地にも詳しい友人に相談した結果、彼女のご家族に福島駅から現地まで車をだして頂けることになり、東京ー福島間は夜行バスを利用して、友人4人とともに活動する結果となったのですが。

    ボランティア情報のTwitterアカウント

    定期的にボランディアバスツアーなどの情報は下記Twitterアカウントをフォローしておけば、チェックすることができます。(他にもあるかもしれませんが私はこちらでチェックしています。）

    あとは、健康な体と必要不可欠な装備があれば十分貢献できると思います。

    現地で少しばかり写真を撮ってきたのでFrickrにあげておきました。

    ]]>     http://blog.restartr.com/2011/06/19/volunteer-at-shinchi-fukushima-pref/feed/ 0     DotCloudのMongoDBをScalaから使ってみる http://blog.restartr.com/2011/05/28/access-from-scala-to-mongodb-on-dotcloud/ http://blog.restartr.com/2011/05/28/access-from-scala-to-mongodb-on-dotcloud/#comments Sat, 28 May 2011 11:00:57 +0000 ReSTARTR http://blog.restartr.com/?p=942 DotCloudにDuoStackが買収されて、DotCloudでもMongoDBが使えるようになりましたし、node.jsも使えるしで、ますますDotCloudが魅力的なものになってきました。 ただし、node.jsはサポートされても、WebSocketは正式サポートされていないと公式マニュアルにも書いてありますがWebSocketサポート済みのDuoStack買収によってどう流れるか気になるところです。

    さて今回は、前回作ったものをベースにScalaからMongoDBへアクセスするサンプルをDotCloudで動かすまでを書いておきます。（まぁ、Scalaのコードはオマケみたいなものですけど…）
    前回の記事はこちらです。 * ScalaをDotCloudにアップロードするためのsbtサンプル

    ちなみにDotCloudは下記バージョンにて動作しているみたいです（2011.05.28現在)

    • nginx 0.7.65
    • jetty 6.1
    • mongodb 1.8.1

    作成したサンプルアプリ

    事情により停止する場合があるかもしれませんがご了承を。

    DotCloudにMongoDBサーバーを準備する

    DotCloudのMongoDBマニュアルはこちら

    上記マニュアルにしたがって作成すればMongoDBサーバーを準備できます。
    基本的には、追加したいサーバーを登録して、ユーザーを作成するだけです。
    簡単。

    今回は”example.mongo”という名前で作成する例を記してありますので、
    それぞれ自分の作成したいアプリ名に読み替えて下さい。

    サーバーを作成

    事前に”dotcloud create example”は実行してあるものとします。
    詳しくはこちらのマニュアルを見てください。

    1
    $ dotcloud deploy -t mongo example.mongo
    > Created "example.mongo".

    DB情報を確認（ID/PASS）

    1
    $ dotcloud info example.mongo

    deployコマンド実行してから実際に作成されるまで少し時間がかかります。
    すぐにinfoコマンドを実行すると下記エラーがでます。
    ※正確に測ってませんが数十秒くらい？

    > Sat May 28 08:14:43 Error: couldn't connect to server 127.0.0.1 shell/mongo.js:79
    > exception: connect failed
    > Connection to mongo.example.dotcloud.com closed.
    > Abort.

    作成完了していれば、下記情報が表示されますので、”mongodb_password: ******”に記載されたパスワードをメモしておきます。

    cluster: wolverine
    config:
        mongodb_password: ******
    created_at: 1306570413.6722209
    name: example.mongo
    namespace: example
    ports:
    -   name: ssh
        url: ssh://mongodb@mongo.example.dotcloud.com:5906
    -   name: mongodb
        url: mongodb://root:******@mongo.example.dotcloud.com:5907
    state: running
    type: mongodb

    MongoDBサーバーへログイン

    1
    $ dotcloud run example.mongo mongo

    infoコマンドで表示されたパスワードを使って、”sampledb”というdbにアプリユーザーを追加します。

    > use sampledb
    switched to db sampledb
    > db.getSisterDB("admin").auth("root", "<infoコマンドで表示されるパスワード>");
    1
    > db.addUser("APPUSER_NAME", "APPPUSER_PASS");
    {
         "user" : "APPUSER_NAME",
         "readOnly" : false,
         "pwd" : "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    }
    > exit
    bye
    Connection to mongo.example.dotcloud.com closed.

    ※とりあえず一旦ログアウトしてますが、別に必須じゃないです。

    再度ログインしてテスト操作してみる

    1
    $ dotcloud run example.mongo mongo

    新規作成したユーザーでDB操作が可能か確認してみます。

    # mongo
    Warning: Permanently added '[mongo.example.dotcloud.com]:5906,[174.129.17.131]:5906' (RSA) > to the list of known hosts.
    MongoDB shell version: 1.8.1
    connecting to: test
    > use sampledb;
    switched to db sampledb
    > db.auth("sampleuser", "samplepass");
    1
    > db.sampledb.save({id:1,name:"foo"});  
    > db.sampledb.find();
    { "_id" : ObjectId("4de0b033a1fd29eb0e1522fd"), "id" : 1, "name" : "foo" }

    問題なさそうなので、あとはアプリを”dotcloud push”して動かすだけです。

    scalaからアクセスするサンプル

    サービス名を「example.samplemongo”として作成する例です。

    requirementsはイカのとおり。

    • scala 2.9.0
    • sbt 0.7.7
    • jetty 7.3.1.v20110307
    • casbah 2.1.5.0
    1
    sbt

    で基本ディレクトリを作成したら、下記プロジェクト設定を{root}/project/build/MongoSampleProject.scala”として保存します。

    前回の設定クラスをコピーしてきたので、”sbt dot_create”と”sbt dot_push”も一応使えます。

    ※”example.mongo”の名称は適宜読み替えでお願いします。

    MongodbSampleProject.scala

    配置できたら、

    1
    sbt reload update

    でライブラリを読み込みます。

    あとは下記Servletの実装とweb.xmlを用意したらOK．

    MongodbServlet.scala
    web.xml

    できたら、”sbt dot_push”でdotcloudへアップロードされるはずです。

    最後に、”http:／／samplemongo.exapmle.dotcloud.com”にアクセスして、フォームからデータ登録ができれば成功です。

    RDBMSにくらべてデータ保存・取得までが圧倒的に簡単で、PaaSでもMongoDBはいい感じですね！

    ]]>     http://blog.restartr.com/2011/05/28/access-from-scala-to-mongodb-on-dotcloud/feed/ 0     ScalaをDotCloudにアップロードするためのsbtサンプル http://blog.restartr.com/2011/05/09/sample-sbt-project-for-dotcloud/ http://blog.restartr.com/2011/05/09/sample-sbt-project-for-dotcloud/#comments Mon, 09 May 2011 14:35:43 +0000 ReSTARTR http://blog.restartr.com/?p=914 dotcloudを必要最低限操作するためのactionをsbtに追加してみました。

    sbtのアクション自体はじめてなので作法がよくわかってないので、間違っているかも知れませんが。

    使い方

    ※scalaファイルは最後に掲載しています。 とりあえず下記を作成するサービス名に置き換えればOKです。

    1
    2
      val dotApplicationName = "APPNAME"
      val dotServiceName = dotApplicationName + ".SERVNAME"

    あとは、下記を順に実行すればOK(dot_prepareはdot_pushの前に必ず実行されるので省略可能)

    • “sbt dot_create” : サービスの作成
    • “sbt dot_prepare” : リリース用ディレクトリ作成とwarファイルのコピー
    • “sbt dot_push” : dotcloudへのwarファイルpush

    dotcloud用に注意すべきこと

    “sbt package”を使用すると、”＜projectName＞-＜scala_ver＞-＜app_ver＞.war”の形式でwarファイルが作成されます。 が、dotcloudのドキュメントにはこう書いてあるので、”root.war”で作成するのが望ましいです。

    The java service will make your application available at http://frontend.myapp.dotcloud.com/ if your archive is named root.war or http://frontend.myapp.dotcloud.com/webapp/ if your archive is named webapp.war (../foobar/ if the archive was named foobar.war and so on). So, you can effectively serve multiple web applications with the same java service.

    Java — DotCloud documentation

    さらに、”dotcloud push”はwarファイルを含むディレクトリを指定することになり、それ以下がすべて同期されてしまいます。デフォルトだと、”./target/scala_2.8.1/”以下のすべてが。

    なので、warのみ格納する”release”ディレクトリを作り、 そこに”root.war”としてひとつだけ存在させておきました。 順番に書くと、

    • sbt packageでtarget/scala_2.8.1/＜projectName＞-＜scala_ver＞-＜app_ver＞.warを生成
    • そのwarファイルをtarget/release/root.warにコピー
    • “dotcloud push ＜dotcloud_appname＞ target/release/” でwarのみアップロード

    という方法で対応しました。

    以下、サンプルのプロジェクト設定です。

    参考リンク

    ]]>     http://blog.restartr.com/2011/05/09/sample-sbt-project-for-dotcloud/feed/ 0