Distributed Hoge - 分散なんとか勉強会 codecheck.in at Fusic
分散なんとか勉強会
5月30日に株式会社Fusicさんの会議室で行われた、codecheck.in主催の「分散なんとか」勉強会に参加してきました。
Fusicさんいつも場所を提供して頂き、本当にありがとうございます。
Fusicさんいつも場所を提供して頂き、本当にありがとうございます。
当日の模様はustreamで配信されており、以下から見る事ができます。
codecheck.in
[CakePHP][MySQL]動画サービスの負荷分散 (id:rytich)
Speaker: (株)マダガスカル rytich氏CentOS+CakePHP+MySQLで構築された（セクシーな）動画サイトの負荷がもの凄かったので、負荷を下げるまでのお話。
深夜0時〜2時などの、皆が感極まる時間帯になるとロードアベレージが200等になっていた。（200万PV/Day）
サーバ、ネットワーク、DB、PHPそれぞれでパフォーマンス測定して、解決していった。
詳しくは後日資料をあげられるそうなので、そちらを参照。
↓
分散なんとか勉強会 発表資料 - rytich's diary
エロと笑いを交えつつのおもしろtechトークで、場があたたまりました。
[LVS]負荷分散してみたよって話をメインにだらだらと (pudding)
Speaker: (株)Fusic pudding(a.k.a debility)氏ロードバランサとは
リクエストを複数サーバに分散
ダウンしたら分散対象から外す
ロードバランサは高い （１４０万とか）
メリット
安価で導入できる
貧弱なマシンでも問題無い
Linuxなので応用が利く
sessionの問題（セッションを切らない為の施策）
案１.persistance_timeout
案２.NAS
案３.repcached
コンテンツの同期（複数サーバへのデプロイ）
案１.手動で頑張る
案２.rsync
案３.makuosan
案４.DRBD
リスクを減らす
SPOF (single point of failure)
（そこで止まってはいけない）１００％故障しないはありえない
n台あればリスクは 1/n になるのではなく、
1/n * 2 になる。（営業トークでどうぞ）
（ここでpuddingMIXIアプリと、Fusic社内弁当注文アプリが登場。特にこの弁当注文アプリで今日一番の盛り上がりを見せる。Flexを使用したというこのアプリの完成度は非常に高かった！但し、皆から注文を受け付けるだけで、最後はpudding氏がお店に電話で注文しないといけない）
弁当アプリの今後が楽しみでした。
[lifehacks]「技術とは、人生と似たようなものだ」 (pudding)
Speaker: (株)Fusic pudding(a.k.a debility)氏「PHP書くのに、Emacsがないとダメだよ」といってるようではダメ！
秀丸でもIDEでもメモ帳でも書けるよ！ってのがいいんじゃないか。といった話。
柔軟かつ臨機応変に対応できる人は強い。
[CouchDB] (cohtan)
Speaker: cohtan氏（freerance programmer）CouchDB relax
（半構造DB）
資料はこちらで公開されています。
http://blog.cohtan.org/2009/06/couchdb-relax.html
CouchDBとは？
Erlangで実装された半構造DB
ドキュメント指向
通信は全てRESTfulAPI
問い合わせはSQLではなくMapReduce
N-Master Replication
もともと分散処理に強い言語
最初からマルチコア対応
0.9.0のソースコードはたったの11067行
Document Oriented
RDBのようにスキーマは存在しない
１レコードをJSONフォーマットで表現
JSONの定義はいつでも好きなように追加、変更、削除が可能
多次元構造も可能
RESTful API
MapReduce Framework
javascriptでMapReduce
MapはJSONドキュメントの中から情報を抽出する
MapReduce Replication
超簡単！レプリケーションのコストが低い！
CouchApp
SOFA
WebApplicationにfitしやすそう
RESTfulとJSONなので言語を選ばない
スキーマレスという自由
プロトタイプを作るときに最適
RoR/Cake における Scaffold 以来の衝撃
key-value界隈で最近話題騒然！
cohtan氏のCouchDB周辺のブクマは以下（頼りになります先生）
Chrome Web Store
[Git] (cohtan)
Speaker: cohtan氏（freerance programmer）Gitを使い出して何がうれしくなったか
資料はこちらで公開されています。
http://blog.cohtan.org/2009/06/subversion-svk-git.html
非バージョン管理時代
コミットに楽しさを感じる
ガシガシ使うもコンフリクトしたらお手上げ
まだバージョン管理していない人を極端にDISる（ごめんなさい）
SVK時代
Perlでできたコマンド
非ネットワークでもコミットできる
そこそこ素早いマージ
diff, logをバリバリ使うようになる
元リポジトリがとんでも誰かしらバックアップを持っている
まだSVKにしていない人を極端にDISる（ごめんなさい）
やたらとスタバなど外でコーディングする回数が増える（いやなやつ）
Git時代
作法を理解するまで若干苦労
リポジトリの初期化とインポートが楽
Branch爆速、Merge爆速
git-svnでSubversionとの併用も可能
まだGitに(ry
分散する事のメリット・デメリットが理解できるようになっていく
運用方法によってはまだSVNの方が向いている場合がある？
ただ、メリットの方が大きいと思う
GUIフロントエンドが充実していない？
現状あるのは、GitExtensions(+msysGit)(win)、TortoiseGit(win)くらい？ → 今後に期待
WebDB Press Vol.50は必読！
[git-svn] (k1LoW)
Speaker: (株)Fusic k1LoW氏git-svn?
利点
リポジトリが一つなので、ソースの作業履歴が一つにまとまる
欠点
commitは一つのリポジトリにしかできない
（commit権限を持たない人は作業履歴をリポジトリに持たす事ができない）
Git
利点
それぞれがリポジトリをもつので、それぞれが作業履歴を残す事ができる
（みんな平等）
欠点
どれがマスターのリポジトリか分からなくなる事がなる
（運用でカバーしないといけない）
SVNでのワークフロー
#．SVNリポジトリを作成→メンバーに知らせる
#．リポジトリからチェックアウト
#. 作業
#. tagsに残す
#. commit履歴が細かすぎてコミットログを汚染
(詳しくはust参照)
Git(Github)でのワークフロー
Github = Gitのプロジェクトホスティングサービスでありソーシャルサービス
#. Githubでリポジトリを作成
#. リモートリポジトリからclone
#. テーマを決めてbranchを作成
#. git branch rdb
#. 作業
#. 良い感じになってきたらローカルのマスターリポジトリにまとめてmerge
#. マスターリポジトリにコミット
#. branch作ってマスターにマージ
(詳しくはust参照)
git-svnでのワークフロー
#. svnリポジトリを作成→メンバーに作成
#. svnリポジトリからgit svn clone
#. ローカルのマスターリポジトリにまとめてマージ
#. svnにコミット
Gitを使ってみて思ったこと
ブランチ祭りが楽しい
git checkoutの時に一気にソースコードが変わる様は楽しい
git-svnはリポジトリの考え方は１８０度変えないとGitには慣れない
[github] ハンズオン
Speaker: (株)Fusic k1LoW氏皆でGithubでアカウント作ってみよう!のコーナー
The world’s leading software development platform · GitHub
とりあえずGithubサイトにチュートリアルがあるので、それ通りにアカウント作成。
sshの公開鍵を作らないといけない。手順も丁寧に用意してあります。
Connecting to GitHub with SSH - GitHub Help
「アカウント名.github.com」というリポジトリ作れば、自分のサブドメ貰えます。
とりあえずindex.html作って、push。僕のアカウントは以下。
http://taketin.github.com
forkとかもやると楽しそう。ソーシャルコーディングって面白いですね。
ぜひ皆さんもいかがでしょうか。
まとめ
とりあえず、GitをやるならWebDB Press Vol.50（開発者自らの解説が掲載）は必読！CouchDBは今後要注目！
