blog.katsuma.tv

最近は仕事でgitを使うケースがSubversionと比べて圧倒的に多いので、個人的にGoogle Codeでホスティングしていたコードもgithubに移すことにしました。

git-svn

移行作業にはgit-svnが必要になります。MacOSXでgit-svnを使うには、git-coreをmacportsで入れるときに、+svnのvariantsをつけてインストールしてあげるとOK。ぼくはすでにgit-coreをインストールしていたので、次のようにしてインストールしなおしました。

sudo port deactivate git-core
sudo port install git-core +svn

作業用ディレクトリの作成

作業用の適当なディレクトリを作ります。

mkdir ~/Desktop/git
cd ~/Desktop/git

authors.txtの作成

次のような内容のauthors.txtを作成。(no author)はGoogle Codeの初期設定で、名無しさんがtrunk, branches, tagsを作成しているようなので、この２行が必要になります。左辺はGoogleアカウント名、右辺はgithubに登録した名前とメールアドレスです。

ryo katsuma = ryo katsuma <katsuma@gmail.com>
(no author) = ryo katsuma <katsuma@gmail.com>

移行用レポジトリを作成

githubで移行用のレポジトリを作成します。作成はここから。

移行

ここまでくるとあとは簡単。

git svn clone -s -A ./authors.txt http://svn_repo.googlecode.com/svn repo
cd repo/
git remote add origin git@github.com:katsuma/new_repo.git
git push origin master

まとめ

Google Codeからgithubの移行は、実作業はauthors.txtを用意するくらいで、全体としてそんなに複雑なものではなかったと思います。 ちなみに今回の作業を通してTokyo-Joggingのコードを全部githubに移しました。 コード管理はもちろん、サイト全体の操作性なんかもGoogle Codeと比べてgithubの方が優れていると思うので、移行して正解だったかなーと感じています。

株式会社学びingの五十嵐学様より「よくわかるAmazonEC2/S3入門」を献本いただきました。

本書は、EC2, S3を中心とするAWSの導入、運用方がをボリュームよくまとまったかなりの良本です。

目次

• ■第1章　クラウドコンピューティングへの招待
  • 1-1 クラウドコンピューティングの隆盛
  • 1-2 クラウドコンピューティングとは何か
  • 1-3 サービス提供側から見るクラウドコンピューティング
  • 1-4 クラウドコンピューティングの3つの分類
  • 1-5 クラウドコンピューティングの主要プレイヤー
• ■第2章　Amazon EC2/S3で何をするのか
  • 2-1 Amazon EC2
  • 2-2 Amazon EC2
  • 2-3 Amazon S3
  • 2-4 料金体系
• ■第3章　Amazon EC2/S3導入手順詳細
  • 3-1 Amazon EC2/S3を使うまでの準備
  • 3-2 GUIツールからの操作（AWS Management Console）
  • 3-3 コマンドラインからの操作
  • 3-4 Amazon S3を利用する
• ■第4章　Amazon EC2使用方法
  • 4-1 Amazon EC2でLinuxを使う
  • 4-2 Amazon EC2でWindowsを使う
• ■第5章　Amazon EC2/S3の応用例
  • 5-1 Amazon EC2のオプション
  • 5-2 Amazon S3のオプション
  • 5-3 その他のオプション
  • 5-4 Amazon EC2/S3　ツール集
• ■第6章　AWSにおける運用管理
  • 6-1 運用上における物理サーバとAmazon EC2の違いとは
  • 6-2 サーバ種類別の考察
  • 6-3 AMIをゼロから作る
• ■第7章　Amazon EC2/S3ができること，できないこと
  • 7-1 相性が良い想定利用シーン
  • 7-2 相性が悪い想定利用シーン
  • 7-3 当社で起きた特殊な事件
  • 7-4 その他注意点
  • 7-5 Amazon EC2/S3は使えるのか？
• ■Appendix　コマンドリファレンス

AWS導入検討時は何よりまず読むべき

一通り読んでみて感じたことは、「僕がAWSを初めてまともに使った１年前にこの本があれば。。。」と、いうこと。導入にあたってのアカウントの作成方法、料金計算方法、Webインターフェースとコマンドツールの細かな説明から運用上の諸注意まで全部一通り掲載されてあって、AWS日本語公式サイトがまだ存在しない今だと、へたに検索して１つ１つ調べるよりよっぽど有益な情報を効率よく収集できます。

個人的に一番よかったのは、６章「AWSにおける運用管理」と７-3「当社でおきた特殊な事件」。AWSの実運用事例はまだまだ国内では少ないので、このあたりの実際に使ってみてはじめて分かる、目の当たりにする困難な点は情報として絶対量もまだまだ多くありません。その点で、これらの章は使った人にとっては「あるある！！」と思える点ばかりで、AWSユーザ視点での生の声が集まったかなり貴重な章と言えると思います。あと、Auto ScalingやElastic Load Balancingなんかは、まだ使ったことがなかったので、そのあたりの情報は普通にかなり参考になりました。

と、いうわけでAWSの導入を検討している人は当然のこと、AWSのサービスを断片的には使っているもののサービス間の連携についての知識が不十分だと思える人にとって、本書は必須な本だと思います。かなりオススメ！

NoSQLの話題が周りで盛り上がっているので、有名どころのライブラリのset/getのベンチマークを取ってみることにしました。対象はmemcached, TokyoCabinet, TokyoTyrant, Redisの４種類。gemで入れたruby用のバインディングを利用して1000件のデータをset, getしています。結果はこんなかんじ。

当然のごとくmemcachedが最速だろう。。。と思いきや、そうでもない結果に。むしろ一番遅い結果に。なんだこれーーーと思って調べ続けていたのですが、バインディングのgemのコードを追いかけるかぎり、どうもこれはmemcache-clientの実装が原因のよう。

これは、memcache-clientの実装はpure-rubyで実装されているのに対して、TokyoCabinet/TokyoTyrantのバインディングの実装はnativeコードで実装されてあるのが原因のようです。事実、TokyoTyrantはmemcacheプロトコルを実装しているので、memcache-clientを利用してTokyoTyrantにアクセスすると両者はこんな結果になりました。

TokyoTyrantのアクセス速度は一気に遅くなりました。やっぱりRuby実装に引きづられているみたいですね。。

ちなみに、Redisもsetに限るとmemcacheプロトコルと同じプロトコルを利用できるので、そのベンチをとってみると

と、なってmemcacheクライアントを利用したときのmemcached, TokyoTyrantと比較しても圧倒的に高速だということがわかりました（おもしろい！）

まとめ

• オンメモリだからmemcachedが高速、とは限らない
• memcache-clientは遅いので注意
• 各ライブラリのオリジナルのバインディングを利用した場合、高速順に並び替えるとTokyoCabinet, TokyoTyrant, Redis, memcachedになる

と、いうわけで、memcachedが高速なことを確認するためにベンチマーク取ってみたのですが、実装によってはまったく異なる結果になることが分かって、なかなかおもしろかったです。なお、今回利用したコードはgistに掲載しています。

Clouderaの提供しているAMIはバージョン１(CDH1)から３(CDH3)まであるのですが、それぞれ梱包されてあるHadoopとその上モノのHive, Pigのバージョンは異なります。

CDHは常にupdateしていて、現在の最新リリースであるCDH3も2010年5月5日現在ではテスト版扱いですが、これもじきにStable版としてリリースされることになるかと思います。

さて、そうるとClouderaのAMIを使っていて、特定のバージョンに上げたい、というのは結構自然な流れかと思います。このとき、バージョンを上げる流れとしては次のような流れになります。

1. Hadoopとその上モノであるHive, Pigなどをパッケージ管理ツールを利用して全てアンインストール。
2. パッケージ管理ツールのレポジトリを追加
3. パッケージ管理ツールを利用してHadoopをインストールし直し
4. パッケージ管理ツールを利用してHive, Pigなどをンストールし直し

要するに、全ソフトウェアのバージョンをまとめて上げるのではなく、Hadoopかまたはそれ以外の特定のソフトウェアについて、パッケージ管理ツールを利用してバージョンを上げる、ということが可能になります。このとき、Hadoopについては新たに設定項目がかなり多かったり、AMIを作りなおさないと試すことができなかったりと面倒なことが多いのですが、逆にHiveやPigなどHadoopの上モノについては、AMIを作り直すこともなく、その場でバージョンを上げることも結構簡単にできます。

たとえば、HiveのバージョンをCDH1→CDH2に上げる場合は次のような手順で可能です。

まず、既存にインストールされてあるHiveをアンインストールします。たとえばFedoraベースの　AMIの場合は、パッケージ管理ツールとしてはyumを利用することが可能です。

yum remove hadoop-hive

次に、CDH2用のyumのレポジトリを追加します。あとえばCDH2用のレポジトリを追加するときは、こんなかんじ。CDH3用のレポジトリを追加したい場合は、URLの最後をcloudera-cdh3.repoに変更ください。

cd /etc/yum.repos.d/
wget http://archive.cloudera.com/redhat/cdh/cloudera-cdh2.repo

これで、最新のパッケージを扱える状態になりました。ここでHiveだけCDH2仕様のver0.40系にしてみましょう。

yum -y install hadoop-hive

これで、0.40.xのHiveがインストールされました。また、設定ファイル(/etc/hive/conf/hive-site.xml)は、オリジナルのものに戻ってしまっているので、適宜直しておきましょう。ぼくは以下の箇所を変更、追加しました。

• javax.jdo.option.ConnectionURL
• javax.jdo.option.ConnectionDriverName
• javax.jdo.option.ConnectionUserName
• javax.jdo.option.ConnectionUserPassword

いかがでしたでしょうか？Hiveについては、アップグレードは非常に簡単だったかと思います。同じように、PigについてもHadoopの上モノなので同様の手順でアッグレード可能になります。これなら割と気軽にバージョン上げたりパッチ当てたりなんかもできそうですね。

また、Hadoop本体のアップグレードについても、次回は挑戦してみたいと思います。

4月16, 17日に京都で「アグレッシブなクラウドの使い方」というタイトルで、会社でのクラウドの取り組みについて話してきました。

話の中身としては、僕とsasata299さんがいろんなところで話してきたクラウド系の話の総集編みたいなものになっています。あと、RDSとかPigについて話したのは今回が初になります。

発表の後のTwitterでのTLを追いかけてると、「内容がちょっと分かりづらかった」という声もちらほらあったようですが、たしかにそれは間違っていなくて、AWS系のサービスの内容とHadoopについての仕組みが一通り理解できている前提での内容でしたので、かなり難解だった方も多かったかと思います。と、いうわけで参加されていた方々は、もう一度キーワードレベルで見直していただくなりして、内容を再確認いただければ幸いです。

前回のつづき。

課題の1つに挙げてた中で、「Followした瞬間に、そのユーザの過去のTweetを自分のTLに追加できていない」というのがありましたが、こんなかんじでいいのかな。自分のTLに他人のTLを混ぜて、sortしてstoreし直し。(redis-rbが0.2.0じゃないと動かないかも)

  def merge_timeline(user_id)
    my_id = @login_user[:id]
    return if @redis.type?("uid:#{user_id}:posts") == "none"

    user_statuses = @redis.lrange("uid:#{user_id}:posts", 0, 100)
    user_statuses.each do |status|
      @redis.lpush("uid:#{my_id}:home", status)
    end
    @redis.sort("uid:#{my_id}:home", :order => "desc alpha", :store => "uid:#{my_id}:home")
  end

でも、そうしたあとにremoveしたときにまた再構築し直さないと駄目なことに気づいた。。と、いうかremove面倒ですねぇ、どうするんだろう。泥臭く全statusを走査し直しなのか、それとも順序付Setとか使えば楽にremoveできるのかな。また考え直しです。

あと、このupdateについて、github上のRedTweetのコードもpushし直してますので、興味ある方はご確認ください。

前回「Mac OSXにredisをインストール」で、redisを動かす環境まではできたので、せっかくなんでテスト的に何かサービスを作ってみよう、ということでTwitterクローンのRedTweetを作ってみました。

• RedTweet

redisを使ったTwitterクローンは、PHP版のRetwisと、それをSinatraで書き直したRetwis-RBがあるのですが、サンプルコードはいくらっても世の中に少しは役立つだろうと思ってRails版で実装してみました。オンラインで動作できる環境はないので、git cloneしてscript/serverで手元の起動で確認ください、、と投げやり気味ですみません。とりあえず次の項目は一通り実装しています。

1. ユーザID発行
2. Login / Logout
3. Follow / Remove
4. 自分のTimeline, Public Timeline, 各ユーザのTimelineの閲覧

ちなみにRedTweetって名前はRedisとTweetを混ぜて直感でつけた名前で、git pushしたあとで同じ名前のサイトがあることが発覚したくらい直感でつけた名前です。

目的

さて、今回はまじめにTwitterクローンを作ることが目的ではなくて、実際は、次の項目を目的として実装してみました。

1. Retwisのデザインを読んで、それに従って一通り実装してみる
2. redisのAPIの仕様を学ぶ
3. RDBを一切使わない、NoSQLでWebサービスを作るためのノウハウを身につける

結局全て似通った話になるのですが、上記のデザイン仕様書はTwitter的なサービスを作り上げることで、KVSをどのように利用すればいいのか、がかなり分かりやすく説明されてあるので、いい勉強になりました。また、ユーザ情報はString, 各TLはList, Following/FollowerをSetで管理することで、redisの主要なAPIを網羅できたことも、redisの学習に役立ちました。

と、同時に課題もすでに見えていて、

1. スケーリングがどこまでできるかはまだ手元で理解できていない
2. やっぱりActiveRecord的にラップしたライブラリは必須
3. Followした瞬間に、そのユーザの過去のTweetを自分のTLに追加できていない

なんかが今の段階で挙げられます。1.はテストデータを作ることで解決するはず。2.はやっぱりmustだなぁ、と思えるところまでははっきりした理解で、ユーザ名をIDから引くときなど毎回決まったprefixがついたkeyから探索するのは冗長すぎてやってられません。OhmというHashとObjectのマッピングライブラリもあるので、このあたりも１度使ってみたほうが良さそうだな、というところ。3.はFollowした瞬間に一定数TweetをListにLPUSHして、そのlistの中でSORTすればいいのかな？？正直、SORTまだよくわかってません。

まとめ

というわけで、課題は多いものの、redisとRailsで最低限の動作をするものは実装できました。NoSQLでもサービスを作り上げることは理解できたので、Ohmなど、他のライブラリも使ったりすることで、 redisの利点をもっと伸ばして理解を深めたいな、というところですね。