Incline & Pacific
なぜ作るのか?
Cybozu Labs, Inc.
Kazuho Oku

大規模ウェブサービスの課題
データベースのスケールアウト
RDBMS のパーティショニングが多数解
アプリケーション毎のパーティショニングが初期の解
ユーザ毎のパーティショニングが次のレベル
RDBMS を捨てて分散キーバリューストア (KVS)
を使うというラディカルなアプローチも
Sep 25 2009 Incline & Pacific - なぜ作るのか 2

RDBMS パーティショニングの手法と利点
複数の RDBMS サーバを連携
ロジックに基づいて、RDBMS を割り当て
例: user_idが 10,000〜20,000 ならサーバA
スケールアップに対するコストと規模の
優位
スケールアウトすることで、安価なサーバを使用
可能
理論的には、スケールの限界はない?
SQL や OR マッパを引き続き使用可能
学習コストが低い & Pacific - なぜ作るのか
Sep 25 2009 Incline 3

RDBMS パーティショニングの問題点
事前の分割設計が難しい
特定のサーバが過負荷になったり
サーバ間の負荷が均等にならない
運用開始後の再分散が困難
分散パラメータの動的な変更がしづらい
再分散時に停止が必要になる可能性
Sep 25 2009 Incline & Pacific - なぜ作るのか 4

分散 KVS の手法と利点
複数サーバを使用するキーバリュースト
ア
Hash(key) の値に基づいて、データの格納先を決
定
複数のサーバに同一データを保存して高可用性確
保
パーティショニングの場合は DB のレプリケーション
を使う
Consistent Hashing による、サーバ追加時の動的
かつ無停止の負荷再分散
Sep 25 2009 Incline & Pacific - なぜ作るのか 5

分散 KVS の問題点
機能が原始的
RDBMSにしかない機能の例: レンジクエリ、トラ
ンザクション、リレーション、セカンダリイン
デックス
開発コストの増加につながる
OR マッパである程度解決可能
Consistency のモデルが弱い (ことが多
い)
データの局所性がない
Sep 25 2009 Incline & Pacific - なぜ作るのか 6

CAP 定理っておいしいの?
Consistency, Availability, Partition-
tolerance のうち、同時に満たせるのは
２つ
Extranet P2P では Partition-tolerance は必須
なので Consistency を諦める
データセンタ内でも Partition-tolerance は必要?
ネットワークは冗長化できる
ノード毎にHAクラスタを組める (or レプリケーション)
↓
Partition tolerance は (実質的に) 不要
Sep 25 2009 Availability と (必要なら)なぜ作るのか Consistency を確保可能
Incline & Pacific - Strong 7

Incline & Pacific の目指すもの
RDBMS と分散 KVS のいいとこどり
RDBMS の動的パーティショニング技術
事前の分割設計が不要
(ほぼ) lock-free なデータの再分散
Range-based partitioning
イテレーション機能
関連データの局所化による障害の影響の局所化
SQL による柔軟なクエリ
様々な更新手法
局所的なトランザクション / 2pc / eventual
consistency
Sep 25 2009 Incline & Pacific - なぜ作るのか 8

Incline & Pacific is not an O-R Mapper
Incline はノード間のデータ同期に専念
strong consistency が必要なら 2pc
Pacific は RDBMS の Shard に専念
ORマッパを使うか SQL を直書きするかは自由
ORマッパの Pacific 対応が課題
Sep 25 2009 Incline & Pacific - なぜ作るのか 9