- 恵比寿で．やっぱり迷いました・・・・
##最初のプレゼン
- ここ遅刻orz
##Scaling?
- 演算速度
- ムーアの法則で高速化される
- フラッシュメモリ
- 12ヶ月で2倍になってきてる
- HDD
- 2年で倍ぐらいになっている
- インターネット回線
- 高速化されている
- スケールしないものもある
- HDDのレイテンシ
- 回転速度は20年で2倍ぐらいにしかならない
- インターネットのレイテンシ
- 東京～サンフランシスコは8300km
- 光の速度 55ms よりは早くならない
- 4Gbps って速いの？
- スイッチングハブが12Gbps
- Perl で書いたHTTPサーバ
- 10Gbps も出るらしい
- HDD からのランダムリード
- 0.5GB/s -> 2000台いるかも！
- 遅いのはHDD
- RDBMS/ファイルストレージ
- SSDは部分的解決策
- 他に CPU intensive な処理もある
- なぜスケールアウトが流行るのか
- スケールアウトは 2000 年代のトレンド
- パッケージからサービスへ
- マスメディア(Yahoo!)からコミュニケーションツールへ(mixi)
- 多人数間の疎なソーシャルグラフ
- 従来よりも，スケールアウトしやすくなっている状況
- 代表的なスケールアウト技術
- RDB Shading
- MapReduce/Hadoop
- KVS(Key Value Store)
- Message Queue
- 3層構成
- HTTPサーバ
- アプリケーションサーバ
- ここにプログラマは注力する
- ストレージ
- 規模の拡大 vs ムーアの法則
- スケールアウトにはバランスが重要
##Incline & Pacific
- 大規模ウェブサービスの課題
- データベースのスケールアウト
- 一般的には RDBMS のパーティショニング
- アプリケーションレベルのパーティショニング
- id 毎のパーティショニング
- もしくは KVS
- RDBMS のパーティショニング
- 複数の RDBMS サーバの連携
- サーバが安いから台数を増やしやすい
- 問題点
- 事前の分割設計が難しい
- 運用開始後の再分割が困難
- 分散KVS
- 利点
- 動的にサーバ追加
- 高可用性や自動構成など
- 欠点
- RDBMS にしかない機能が使えない
- Range Query/Transaction/Relation/Secondary Index/etc.
- 一貫性が薄い場合がある
- データの局所性がない
- CAP 定理
- Consistensy, Avalability, Partition-tolerance のうち，同時に満たせるのは「２つ」
- P2P は Partition-tolerance をあきらめる
- データセンター内では？ Partition-tolerance をあきらめる？
- ネットワークは冗長化できる
- ノード舞に HA クラスタを組めたり
- Incline & Pacific の目指すところ
- RDBMS と 分散 KVS のいいところ取り
- RDBMS の動的パーティショニング技術
- Range-based partitioning
- 関連データの局所化による障害の影響の局所化
- SQL による柔軟なクエリ
- 様々な更新手法
- 局所的なトランザクション
- 同一ユーザならトランザクションとか
- Inclune & Pacific は O/R Mapper ではない
- Include はノード間のデータ同期
- strong consistency なら 2 phase commit
- Pacific は RDBMS の Shading に専念
##A Clever Way to Slace-out a Web Application
- RDB shading
- 非正規化は必須になる
- 相互にアクセスするので，分散されにくい
- shading を update する2つの方法
- eventual consistensy
- worker process を使って非同期更新
- 高速でスケールしやすいが，維持が大変
- 2-phase commit
- 時間がかかる可能性がある
- 問題点
- クエリーが複雑になる
- 絶えず複数のDBからになる
- ノード間の一貫性の維持が大変
- 動的にスケールすることの複雑さ
- データベースのトリガー
- SQL のフックとかコールバックとかみたいな
- Incline
- eventual consistency の2つの問題の解決
- 複雑なクエリの改善
- 非正規化テーブルの維持
- 基本的にはトリガーを使う
- どうやってるのか1
- 同一データベースはそのまま更新
- 他のデータベースにはキューに入れて，転送プロセスに転送させて実行する
- どうやっているのか2
- キューには同一トランザクションになっている
- キューの転送は fault-tolerant になっている
- あくまで非同期処理
- eventual consistensy
- details
- 定義ファイルからトリガー生成
- 同一ノード内ではトリガーで同期
- ノード間は daemon が非同期に転送
- helper は C++ 製
- Pacific
- Range-based shading vs. hash-based
- Range-based is better
- 範囲クエリーが使える
- 手動で分割，追い出し出来る
- 負荷が高いものを分散できる
- hash-based は全てのマシンの負荷が同じになる．機材調達に難あり
- tools
- mysqld_jumpstart
- MySQLのインスタンスをセットアップして起動してくれるツール
- daemontools で監視してくれる
- master/slave それぞれのセットアップが簡単
- slave 作成のためのバックアップもやってくれる
- hot-backup の XtraBackup を使っている
- pacific_devide
- MySQL shard の分割
- 分割後の問題
- ダウンタイムを短く
- データの整合性を保ちたい
- fail-safe
- ダウンタイムを短く
- 10秒以内
- 具体的にどうやる？
- スレーブを作って
- ユーザが書き込みできないようにして
- 同期して
- トリガー更新して
- 新しいユーザ作って
- shard 定義を更新して
- 終わり？
- DBIx::SHardManager
- 自動設定のリロード
- drizzle などで複数同時問い合わせなど
- 今後
- Incline
- 複数キー on MySQL
- データ脳復旧
- Pacific 名付けがちょっと混乱するかも
- Q&A
- 複数ノード間の JOIN はやめたほうがいい
- 分割するときにキューははけて無くてもいい
- 集計する場合などの解決策は，バッチ処理に逃げるしかないのかなーという印象
- キューに入った順に処理されるので，更新は絶えず上書きされるなどで，fault-tolerant を実現
- キューが独立して動作するので，完全な Consistency は保証されないが，eventual consistency ではある
- いつプロダクションにかは，皆さん次第です！
- fail-over をやることは考えてない．DRBD とかを使えばいいんじゃないかと
##デモ
- master から slave のセットアップはかなり簡単にできる
- trigger を使って，面倒な更新がお手軽に
##A Better Cached
- Membached の利点
- RDB 読み込み負荷低減とスケールアウトするところ
- 欠点
- 一貫性維持が面倒
- 問い合わせが複雑
- データがあふれる可能性がある
- うっかり session_id と入れるとやばい？
- 前提
- RDBMS がスケールしない -> から，キャッシュを使う
- なら Pacific & Incline で
- 残る派同時接続数
- SQL パーサーを外せば！
- mycached
- mysqld が memcached プロトコルを話す
- 読み込みのみ
- memcached プロトコルを使って，MySQL からデータを取得できる
- デモ
- 利点とか
- 整合性を気にせずに，高速化される
- 問題とか
- 負荷が分散するわけではない
- よりよいアプローチとして
- App Server と RDBMS の間に入るような構成になればいい
- ほんとのキャッシュとして使う
##まとめ
- 懇親会は
怖かったのでマイルのために欠席． - 結構色んなクラスタの人が来ていた模様．
- 次回も参加で(怖くなければ)懇親会にも行きたいなと．
