soogleの日記

internet week2008に参加してきたので、

備忘録を書いておく。わからない単語も結構でていたので、

そこはいつか直す。

所感としては、どこもサーバのルート権限がないとできないような

ことをとことんやっていて、とてもうらやましく思った。

いや、むしろルート権限がないほうがおかしいので、常に検証できる

ような仕組みをつくっていくあるいはしいておく必要があると思った。

また、冗長化、軽量化が大きな話題となっている気がしており、

RIAになってづかづか通信していく世の中だから、よりストレスフリーな

ものが求められていることを実感した。

このような催しはこれからも積極的に参加していこうと思う。

■第一回

・フレームワークがURLを判定する。

- restfulにする

- セキュリティ的にうまくあてはまれば使ってもいい。

・認証はフレームワークでほぼ実装されている

- mod_auth_*のようなサーバ系の認証がある場合は要注意

・apache側でも認証系の処理が増えてきているので、フレームワークかサーバ側か

　方針を先にきめたほうがいい。

・mod_proxy_balancer/sticky_session

- sessionとロードバランシングの設定の指針は先にきめる必要あり。

■第二回 冗長化 KLab

・やること

- 障害予測/対応方法検討/機材購入

・ネットワークの冗長化

- インターネット回線 [障害あんまりおきない]

- ルータ [冗長化プロトコル] →ホットスタンバイ

- L2スイッチ [買っておくだけでもいいかも] →コールドスタンバイ

・webサーバの冗長化

- アクセスカウンタ DBサーバ/NFSサーバ/memcached

・本質

- 冗長化すべきは機材ではなくデータ

- インフラとアプリケーションの設計を綿密に考える

■サーバサイドのプログラミング言語

・特徴

- 開発期間は短納期

- いかに目新しさをもとめられる 新奇性

・歴史

- C/Perl/VB

- Java(struts)/PHP (便利な関数)

- Ruby on Rails（必要最低限のみかく。フレームワークの徹底）

・もうひとつの言語

- 設定ファイル

- CSV/ini/XML

- 簡単だが、自由度も低いから、DSLを使うのがいいかも

→言語のように見える汎用設定ファイル

・今後

- マルチコア・分散処理→earlang?

- RESTful対応

→クライアントサイドのリッチ化に対応したクライアントサイド言語が増えていく

■フレームワーク編

・struts前・後

- XML多い、DBアクセス面倒

・rails以降

- フルスタック指向(rails likeな実装)

→大規模サービス、DBアクセスまわりの改善を模索

・webフレームワーク

- wiki/xoops

- Ajax

- javascriptライブラリの進化

- javascriptによるフレームワーク実装(progression)

・最近のフレームワーク

- 多極化してる

- 言語の上に言語 Jruby

- TESTもフレームワーク内に実装

- クラウドサービスとそれに対応するフレームワーク

- RESTful

- OPENID/GAdget

・フレームワークの負の側面

・フレームワークの選び方

- ある程度はやってるもの(google trends)

・フレームワークの勉強方法

・お勧めフレームワーク

- rails

- Django

- SAStruts

- Kahua

■データベース編

・トランザクションはDBMSに正しく依存しておく

・独自クラスタ構成

・スケールアウトクラスタ？

・webバックエンドで求められること

- とにかくとまらないこと

・OSS-DB

- DBMSソフトの比較は単体ではほぼ変わらない

- クラスタ構成をくんだときにパフォーマンスの差がでてくる　real application cluster

- インメモリ　データベース

・SQL　は問い合わせ言語 SQLで書く？ ORマッピングで書く？

- SQL

- ORマッピング

+ インピーダンスミスパッチがないほうが楽

+ フレームワークで組み込まれている

+ ただしSQLの直書きもできるよになってる

・DB設計動向

- 使われなくなってきたもの

- ストアドプロシージャ、じかがき

■memcached

・バイナリオブジェクトを扱える。

・livejournalからうまれた

すべてのクエリがDBにあつまってきた

loadが20から0.Xに下がった

・トラフィック == 人気の値段

→コンテンツを表示しないと、ゲームオーバー

・X万qps

- mixiは3万qpsをさばいている

・キャッシュデータのinvalidationが大切

・開発コミュニティがアクティブである

■repcached

- 分散ハッシュ

- ユーザのセッションデータをmemcachedにいれたりする

- 3台以上の構成を組むことができない

■memcachedをどうつかっていくか？

GREEでつかっているもの

- memcache

- Q4M

・key-value starage

- xeon 2,1G メモリ8G / 6万qps出せてる

・よくないところ

- key にホワイトスペースを使えない

・GREEのどこでつかってるのか？

- CSRFトークン

- 新着情報のキャッシュ

- 各ユーザのホーム

- mysqlでつかう

- flare

■東京タイラント

- mixiの最終更新時間

+ 一度に何万件もinsertできないの、memcachedにつっこんでオリジナルのDBにいれる

- memcached

- lua拡張

- mixi engineerブログ

■memcachedにのぞんでいること

- pluggableにする

- SSD?

- protcol??

- 言語間の問題 シリアライズの方法

- memcachedでincrement機能もある key = vakueがたのデータももってる

- 一台からでも使うべき　webサーバ間内でしか動かないので、

別でたてる必要がやはりあるのか。