技術的にコアで刺激になるような勉強会はないかなと思っていていたら、BP Study をすすめられた。前から BP Study の存在は知っていて気にはなっていたけど、機会がなくて行ったことがなかった。
今回時間もあったこともあって初参加。
内容は OpenID Authentication 2.0 protocol の解説と XMPP and AMQP の紹介
資料の紹介は BP Study の web にリンクされています : http://beproud.jp/bpstudy/?p=31
どちらも技術的にはニッチかつコアな内容で専門ではないので概略くらいしか理解できなかったが、それだけコアなものに触れられてよかった。細かくはなんだか分からないけど技術的に先端的だったりニッチだけどすごいことが世の中にはあるんだなぁ思うこと、それを感じるのが結構大事なのかと思う。
個人的には後半の AMQP みたいな大量な処理をひたすら効率的にさばくための仕組みは結構興味深かった。Google 内部でもこんなようなひたすら高速に処理するためのシステムが作られて web で紹介されているのはごく一部なんだろう。
全体的な雰囲気としては懐かしの IRI でやっていたエンジニア勉強会に近い感じを受けた。そこそこで技術的コアな情報を知っているエンジニアが集まることでエンジニア集団全体としての幅と厚さが出る。この技術の幅と厚さが価値になる。そう考えると BP Study は結構な幅と厚さのある勉強会になっているので価値は高いな。
# この技術に対する価値の見いだし方がちゃんと理解できている人はなかなか少ない。シリコンバレーではベースとなる考え方になっている
懇親会でも色々な方と面識を作れたのもよかった。ShakeSoul として何か一緒にやれることを見いだせればラッキーだろう。
継続的に参加したい勉強会になりそうだ。
以下、当日とったメモ
090521 BPstudy #21
19:00-21:30
Introduction OpenID Authenticasion 2.0 Revival
- OpenID tech night やった もうちょっと分かりやすくした初心者向け
- OpenID Authentication 2.0 protocol がある
-
ケーススタディ smart.fm
- smart.fm のアカウントあり
- openIDとの関連付け済み
-
OpenID アカウント入れると myopenid.com のサイトにユーザ側でのリダイレクトされた
- これは smart.fm のサーバがクライアントにリクエストしている
-
用語
- Claimed Identifier クライアント側の所属情報
- Relying party 使おうとしているサービス smart.fm
-
User-Suppolied Identifier
- Claimed Identifier と OP Identifier をひとくくりにしたもの
-
コマンド myopenid にアクセスする時 Yadis Discovery
- lwp-request -S -e- d http://zigorou.myopenid.com/ | grep -i xrds
- X-XRDS-Location: http;//zigorou.myopenid.com/?xrds=1
- http;//zigorou.myopenid.com/?xrds=1
- # 色々出てくる
- XRDS 文章を見つけるやりとり
自分メモ
-
大まかに言えば</p>
- smart.fm がクライアントにリダイレクト要求
- クライアントが openid.com にリダイレクト
- 認証をする
- openid.com よりクライアントへリダイレクト要求
- クライアントが最初の smart.fm にリダイレクトする
- という感じの流れのようだ
QA
-
Q1 A1 OpenID ライブラリが出ているようだ</p>
- セキュリティホールがあるようだ バージョン上げる必要があるとのこと
-
Q2 return-to-url が書き換えられる場合は
- どの OP も安全という訳ではない verification でチェックされて促すくらいのやり方
-
Q3 いろいろな OP があって開発めんどい
- めんどいので Google は画一的な画面を出して共通化する動きもある
XMPP and AMQP
- 両方を知っている人少ないのでは、、、
-
XMPP
- XML 実装
- Google Talk のプロトコル
- 非同期な通信
- AMQP
-
Erlang
- 並列処理指向言語、分散処理指向言語、Open Telecom Platform(OTP)
- facebook Online chat, AWS SimpleDB, Apache CouchDB, 分散ハッシュDB Kai / scalaris で使っている
- はてなダイヤリ higepon/20090509/1241863278
- 井上 武 たけまるさんの資料公開されている プログラミング言語 Erlang の動向
XMPP
- RFC にもなっている
- XMLベースのプロトコル
- 動きはメールサーバと一緒
- TCPコネクション張りっぱなし
-
XMPP Server 接続、友人、状態を管理
- クライアント間は直接メッセージ通信する
-
基本的には NAT を通らない
- Google は UDP Hole panching をするライブラリを適用している
- プッシュ型のメッセージ交換 張りっぱなし
XMPP サーバの動き
- ログイン、IDとIP情報を伝える
- 相互認証になる ブロックしたい相手には情報を送らない
セキュリティ
- SSL/TLSm DNSの逆引きチェック、SASL。。(シンプルな認証のようだ）
- 複数チャットも可能
ejabberd
- Erlang による XMPP 実装
- Group Chat も実装済み、部屋が作れる
- 大量のコネクションが来ても大丈夫
Ejabberd Cloud Editon
- AWS の SDB と S3 においてしまう
- スケールすることを
AWS import/Export
- HDD を Amazon へ送る
- S3 にインポート
- 1TB HDD 1TB転送して 1万円くらい
- バックアップ HDD を送ってもらう
AMQP
- Advanced Message Queue Protocol
- 今年中に 1.0 が公開されるはず
- メッセージ指向ミドルウエア
- アプリケーション間の通信プロトコル
- 5億くらいのメーッセージをさばく
- 非同期なのにトランザクション
- TCP であることを利用
- マルチキャスト
- ルーティングキーが一致するところに送る
- 大規模向けすごい負荷がかかるところを抜けるためのソリューション
RabbitMQ
- Erlang による AMQP 実装
- 130万/sec リクエスト可能
- 3億メッセージ/日
- AMQP 0.8 まで実装済み
- ニュース配信、ラジオとか 情報がとにかく出すところが使っている
Kay
- Google App Engine Python 専用フレームワーク作ってます
AMQP サイトがある
- 送る側とクライアントの作り込で設けているようだ
- 送る部分はオープンソースにしている
etc
- アーラン
- Tokyo キャビネット
etc : Google libjingle
- Google Code より
- techtalk もある コアエンジニアが話しているらしい
- xmpp.org にも libjingle
- 95%は Google 社外に出てないらしい