bpstudy#25に行ってきた - なんとなく日記

恵比寿で．やっぱり迷いました・・・・

最初のプレゼン

ここ遅刻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 の間に入るような構成になればいい
  - ほんとのキャッシュとして使う

まとめ

懇親会は~~怖かったので~~マイルのために欠席．
結構色んなクラスタの人が来ていた模様．
次回も参加で(怖くなければ)懇親会にも行きたいなと．