Go for it!

はてブロドメインで仮運用中。

BPStudy#25に参加してきた

先週の金曜日に恵比寿で行われたBPStudyに参加してきた。

今回はサイボウズラボのkazuho氏を講師に招いて「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」ということで、データストレージ(RDBMS/KVS)の動向、incline/pacificを利用したデータベースのシャーディングデモなどを聞かせていただいた。

メモ書き程度で申し訳ないですがざっくりと。


“Happy Optimization”

パフォーマンスチューニングに関する話。

パフォーマンスを測定するにはプロファイラ使うべき(当たり前)、「30%はやくなったよ」はダメ。ずっと続けてしまう。コストを投入して回収することを考えるべき。

処理速度は上限があるはず。MIPS、バンド幅(帯域)、アクセスタイム(レイテンシ)

「理論値の70%に到達したよ」は良いパターン。理論値が解ることで事前に処理限界がわかる。

MySQLの話

某つぶやきサイトのデータ構造を例にあげて色々考える。ベンチマークハードウェアの処理限界は2600QPSのはず(3GHz P4)。

予測方法

mysql_timelineはプッシュモデルの値、OS内部はIPCのコストがボトルネック、I/O waitの間に他の処理を加えられる。

性能向上のためのアプローチは、例えば、命令数が足りない→SIMD使う、バンド幅が足りない→圧縮する、アクセスタイムが遅い→グループコミット(個々のトランザクションのレイテンシの隠蔽)。

グループコミットはPostgreSQLでも処理性能改善に寄与している手法。

lock free algorithmを採用したい。何故か?ロックで遅くなる→可能な限りロックしないで頑張る。

Scaling(資料)

ストレージ、ネットワーク、レイテンシについてのスケーリングの話。

ムーアの法則、半導体の集積度が18ヶ月で倍になる。処理性能も。ファンの法則、フラッシュメモリの容量、12ヶ月で倍になる。 ハードディスク(容量の増加率忘れた。89年40MB→2009年2TBとか)。WAN回線。99年、56kbps-128kbps, 09年、1.5Mbps-100Mbps。

HDDのアクセス性能は20年で倍にしかなってない、これからもほとんど向上しないと思われる。WAN回線レイテンシ、東京→SFで光の速度で55msecかかる、物理的な制約。

例えばHDDランダムリードで0.5BG/sec出すには2000台必要。

HDDにアクセスするソフトウェアは、RDBMS、ファイルストレージなど永続化が必要なものにはHDDのようなものが必要。

SSDにしたら解決可能。ただし、価格がネック。

CPU intensiveな処理もある、XMLのパースなど。

「スケールアウト」、2000年代のトレンド。ソフトウェア製品はスケールアップ、サービスはスケールアウトの方向になってる。

スケールアウトのソフトウェア技術、MapReduce/Hadoop, KVS, MessageQueueなど。

規模の拡大 vs ムーアの法則

例えば、mixiのユーザ数が1000倍になったりしない。データ量の増加が一定であれば、ハードウェア性能が追いついて、いつかスケールアップの時代が来る。

データベースのスケールアウト

RDBMSのパーティショニング、テーブルスペース、データベースリンクにより分割。RDBMS捨てちゃえよ→KVSへ

RDBMSパーティショニングの問題。 事前の分割設計が難しい。特定のサーバが過負荷になったり、サーバ間の負荷が均等にならなかったり。

KVSの問題点。 Consistencyモデルが弱い、トランザクションがない(ことが多い)

CAP定理とは?Consistency, Availability, Partition-tolerance。同時に満たせるのはこのうち2つのみ。

Incline & Pacificの目指すもの RDBMSと分散KVSのいいとこどり。Inclineはノード間のデータ同期に専念、PacificはRDBMSのShardに専念、ORマッパつかうかSQL書くかは自由。

RDB sharding eventual consistency→非同期で更新→スケールする→同期を作り込むのが大変。

Incline 同期を作り込むのが大変なので書いた(?)。データベーストリガを利用する。トリガの生成は定義ファイルから。シャーディング方式はrangeベースがいいです。ハッシュはダメ。

Pacific mysqld_jumpstartというユーティリティを提供。daemontools使ってサービス開始してくれる。primary, slave両方セットアップします。バックアップスクリプトもインストールします。動作中のサービスでレンジの分割を自動的にやってくれる。

A better cached RDBMSスケールしない→スケールするキャッシュが欲しい、incline/pacific使えばRDBMSスケールする!→でもSQLは遅い。

mycached MySQLのテーブルにmemcached protocolでアクセスできる→ただしprimary keyにでのgetのみ書き込みはSQLでやってね。レスポンス形式はmemcache native, json, messagepackが使える。

シングルスレッドでイベント駆動している。getは軽いので他の接続はブロックしても大丈夫。ベンチマーク結果は8万QPS(4core opteron)


ウェブアプリケーションはストレージやデータベースの負荷が読みづらいという特性があると思う。そこをシャーディングで解決しようという技術。

シャーディングの方法、ほぼオンラインでの分割(10秒くらい止まるらしい)は、頭では考えつくものの、なかなか実施しづらい。incline/pacificはその辺りを解りやすくまとめたソフトウェアパッケージという印象。

memcacheプロトコルを利用したサーバソフトウェアはたくさんある(memcached, repcached, flareなど)が、MySQLのテーブルに対して適用したのは斬新。

クライアント側でも定義ファイルをincline/pacificのコンフィグをparseしてデータベースに接続する必要があり、汎用的とは言えないが、コンフィグの共有さえ出来れば他の言語でも同様のアプローチが取れるはず。で、python版のPyShardManagerが早速ローンチした!

内容が深くて追いかけるのが大変でした。情熱を感じられる勉強会でした。

[ad#text_wide]