OSC2008 Tokyo/Fall に行ってきた．

初日は業務として行かせてもらえました．感謝．

メモと感想

• 仮想化は今後のグリーンITとかエコとかでかなり重要な技術になりそう．
• またラックの省スペース化に貢献できそうなので，積極的に採用すべきだと思った．
• 予想以上に性能が良いようだ．
• ネットワーク越しの RAID1 は便利そう．個人ベースでも利用する価値があるかも．
  • ただし2台も使うかどうかは微妙．
• Memcached はテキストベースだからこそ汎用的に使える．
• そろそろうちも Memcached とか使うかな．
• MySQL と PostgreSQL 単体の性能では，実際それほど差はないのかもしれない．
  • それよりもレプリケーションやクラスタリングなどの分散・冗長化技術の有り無しが効いてくるのかな．

行ってきたセッション

• • 1日目
    • 仮想化環境におけるベンチマーク結果
    • MySQLシステム構成〜高可用性構成編〜
    • ディスクデータ冗長化ソフトウェア DRBDの機能と応用例の紹介
    • やっぱりすごい！Memchaced!!〜最新MySQLサポートツールズのご紹介〜
  • 2日目
    • オープンソースDB性能検証 SMPスケーラビリティを探る

仮想化環境におけるベンチマーク結果

日本仮想化技術株式会社 CEO 宮原さん

• MacBook 使い

仮想化環境の設計手法

• 設計のポイント
  • 目的と優先することを明確化する必要がある
• 性能要因
  • Core数と仮想化支援技術があるかどうか
  • クロック数はあまり気にしない場合が多い
  • メモリ最大搭載容量は多い方が良い
  • ストレージなどのI/Oの帯域にボトルネックが発生しやすい
    • ストレージコントローラのキャッシュ容量，バス，仮想化支援技術など
  • ソフトウェア
    • スケジューラの特性によって，得手不得手がある．
      • 何を求めるかを考える必要がある．
• 選定ポイント
  • CPU は仮想化してもそれほど下がりにくい
    • 特に選ばなくてもいい傾向にある
  • メモリ容量は仮想マシン数に影響を与える
    • 積めるだけ積む
  • 高速なI/Oの装備が必須
    • これが一番のキーポイント
    • I/O仮想化支援技術の搭載かどうかにも気をつける
• 概算での統合計画だと，統合したいサーバのCPU使用率・メモリ容量の総計で見たりする
  • あくまで概算
• ストレージの選定
  • 速度と「どのようなI/Oアクセスがあるのか」を知る必要がある．
  • DRBD「2つのノードでミラーリング環境＆冗長化」

ベンチマークについて

• 汎用的なデータを取得しても，実稼働時とは異なるので，あまり意味のあるデータではない．
  • 何を測定するのか，どう測定するのかを明確化しなければいけない．
• 仮想化で使えるベンチマーク
  • VMmark
    • 様々な仮想サーバをセットにして，ハードウェアのキャパシティを測定する
    • 6タイルのベンチマークするのに，構築3日，実行8時間かかる．
• 注意点
  • 仮想マシン内では時間測定が不正確
    • クロックが不定なので，内部時間が不正確になる
  • 仮想化レイヤーのキャッシュが効く場合があるので，物理サーバよりも高速になる場合もある．

Citrix XenServerのベンチマーク結果解説

• 目的
  • Webサーバ＋DBサーバ
    • いわゆるWeb系で必要とされるサーバ構成
  • 仮想化 != 性能低下の数値的な裏付け
    • 性能低下はそれほどではない，もしくは全く低下しない，という裏付けとしてのベンチマーク
  • 一般的なラックサーバの構成でやっている．
• SPECweb2005
  • 物理サーバのピーク性能と同程度の処理能力が出ている．
    • それ以上はApacheのprefork数やメモリ不足など，さらなる性能調査をしてみないと．
      • 実際に過負荷になったときに，どういう振る舞いをするのかを調査する必要がある．
• pgbench
  • ストレージ性能が低いと，キャッシュのためか，物理サーバよりも性能が良くなった．
    • ストレージがボトルネックになっている．
  • ストレージが高性能になると，2VMで物理性能がピークになる．
    • 「高I/O要求 + I/Oを要求しない」のような組み合わせがいいのではないだろうか．
    • DBサーバとWebサーバの組み合わせなど．
• まとめると
  • 仮想化処理はそれほど重くない．むしろ低い．
  • DB性能はストレージが一番効く．
  • あとメモリ．

MySQLシステム構成〜高可用性構成編〜

• 梶山さん．いつもの MySQL の人．
• サーバシステム設計，特にインフラ観点からのセッション
• Adobe製品の組み込みデータベースエンジンとして採用されていたりする．

データベースインフラ設計

• インフラ設計で考慮すべき項目
  • 高可用性設計
    • 障害体制や障害時の対策など
  • 拡張方式設計(性能/ストレージ)
    • 分散対策など
  • セキュリティ設計
    • 暗号化など
  • バックアップ設計
  • 監視方式設計
    • MySQL Enterprise Monitorなど
  • メンテナンス方式設計(データ/ログ/時刻同期)
    • データの移動や破棄，バックアップして削除などのデータメンテナンス

高可用性設計

• 99.999%の可用性を目指すには？
• 必要な要件は，要求される可用性の順で
  • 管理性
  • レプリケーション技術
  • クラスタリング技術
  • クラスタリング＆地理的冗長性
• MySQL としては以下の順でそれに対応する製品・技術を用意
  • MySQL Replication
  • MySQL & DRBD
  • MySQL + Shared-Disk
  • MySQL Cluster Standard Endition
  • MySQL Cluster Carrier Grade Edition

レプリケーション

• master -> slave
• かなり枯れた技術
• 多数のWebでの実績
• 非同期型
  • Webアプリは 95% が参照，更新が 5% というケースもある．
• 特徴としては
  • 参照性能の向上
  • バックアップ用途
  • 基本的に一方向だが双方向や循環型もあり得る
  • 更新ログ(bin-log)を利用
• 構成パターン
  • シングルマスタ -> シングルスレーブ
  • シングルマスタ -> マルチスレーブ
  • シングルマスタ -> シングルスレーブ(リレーサーバ) -> マルチスレーブ
    • そこそこ更新が多い場合
  • マルチマスタ(マスタ <-> マスタ)
    • アプリケーション側でテーブル・データベースのアクセス分散を行うなど
      • 垂直分割をしない場合の解決法かな
• 仕組み
  • master へ Client から SQL がくる
  • mysqld がデータと binlog に書き込む
  • slave の中継スレッドが master の binlog を参照して中継binlog に書き込む
  • slave の SQL スレッドが中継binlog を監視して，書き込みを実行
• スケールアウト構成
  • Write1台
  • Read 複数台
• DRBD
  • Distributed Replicated Block Device
    • ブロックデバイスの分散レプリケーション
  • 分散ストレージ
  • IPネットワーク上で動作
  • 同期型である．
  • Passive Node に書き込みリクエストを送信してから，Active Node に書き込み，その後レスポンスを返す．
  • Linux 上でのみ利用可能
  • 高可用性を実現
• DRBD + Linux Heartbeat
  • Linux Hearbeat で実現
• MySQL + 共有ディスク
  • アクティブ・パッシブ構成
  • データファイルを共有ディスクに
  • 同期型
  • 仮想IPによるフェイルオーバー
  • MyISAM ならアクティブ・アクティブ構成もあり得る
• レプリケーションマスタの冗長化
  • master を DRBD や共有ディスクでデータの冗長化をする場合が多い．
• MySQL Proxy
  • クライアントサーバ間で稼働する軽量なアプリケーション
  • LUA言語のインタプリタ同梱
  • 用途例
    • ロードバランス
      • 参照クエリのバランシングなど
    • フェールオーバー
    • ロギング
    • クエリの書き換え
    • パーティショニング
      • 要調査
• MySQL Cluster
  • トランザクションが多いが，シンプルなクエリが多い場合に有効
  • Single Point of Failure 無し
  • 高可用性
    • 自動フェイルオーバー
    • データは複数のノードに記録
  • 高性能
    • 負荷分散
    • インメモリデータベース
    • 100,000/sec に耐えられるように
  • 管理性
  • 構成要素
    • データノード
      • MySQL ノードからデータを受ける
    • 管理ノード
      • MySQL ノードとデータノードの受け渡しなど？
    • MySQL ノード
      • アプリからクエリを受け付ける
  • データを全件検索やテーブル結合する場合などは，性能面で問題になる場合もある．
• MySQL Cluster Carrier Grade Edition
  • MySQL Cluster 間のレプリケーションを行うことで，さらなる冗長化を実現する．

ディスクデータ冗長化ソフトウェア DRBDの機能と応用例の紹介

• DRBD
  • Distributed Replicated Block Device
    • 2ノードにまたがって，同期的にセカンダリに複製する，Linux カーネルのブロックデバイスレイヤで動作するプログラム
  • ネットワーク越しの RAID1 のような感じ
  • Linux の LVM の上位レイヤに位置して，2台のサーバ間でこの LVM を同期化・複製・冗長化．
• 基本構成
  • プライマリ + セカンダリ
  • セカンダリからの書き込み完了を待って，プライマリの書き込みが完了する．
    • 完全性というか，同期がとれている状態になる．
  • セカンダリ障害時
    • 処理は停止せず，プライマリにデータは蓄積され続ける．
    • 自動的に切断し，復帰時に同期が取られる．
  • セカンダリとプライマリの交換も可能
  • DRBD Ver.8.2.6 はマルチプライマリ構成が可能
    • GFS/OCFS のみ可能(クラスターファイルシステム)
• クラスタマネージャ
  • マシン・サービスの死活監視
  • 自動・手動でアプリケーションの移動が可能
  • Shared-nothing
    • Single Point of Failure がない
  • 推奨は heartbeat
• バックアップ
  • DRBDはバックアップにもなる
  • LVMのスナップショットを取る
    • もしくは ZFS を使えるとできるかもしれない．
• デモ
  • Primary になって初めて mount できる．
  • Secondary で中身を見る場合は，Primary で unmount して，Secondary に変更．その後， Secondary で Primary になって，mount する．
    • ちょっと面倒だが，Primary/Secondary 構成では仕方ないのかもしれない．
  • バックアップの代わりになるのは個人レベルでも使えるかな
    • リポジトリのバックアップなどに，利用する方法もある

やっぱりすごい！Memchaced!!〜最新MySQLサポートツールズのご紹介〜

• アジェンダっぽいもの
  • MySQL のエコシステム
  • Memcached
  • Enterprise Monitor
  • Workbench
  • Proxy

Memcached

• 汎用の分散キャッシュシステム
• Facebook
  • MySQL サーバ 1800台
  • Memcached 搭載メモリ 15TB
  • MySQL サーバメモリ搭載量 25TB
• なぜ使うか
  • カオスになるから
    • 規模が大きくなると
      • SQLの実行頻度が多いこと
      • データ量が多いこと
  • スケールアップ，スケールアウトして処理をおっつける
    • それでも間に合わない
  • Appサーバが直接 DB サーバにアクセスするのでは，キャッシュが有効活用されていない．
    • キャッシュはあるが，サーバ間で共有できない．
• テキストベースで動作
  • 保存するときはオブジェクトをシリアライズして保存など．
• セキュリティなどはない．
  • 代わりに高速・軽量動作
• 参考文献
  • 勝手に図解するmemcached
  • memcachedを知り尽くす @ gihyo

MySQL Enterprise Monitor

• Agent を各 MySQL サーバに仕込んで監視する
• サブスクリプション Silver 以上で利用可能
  • Premium 以上で Schema Advisor が利用できる．
  • Trial がある．

MySQL Workbench

• DBDesigner のような感じ．と言うか DBDesigner の制作に関わっていた人が関与しているそうだ．
  • ER図の作成が可能なデータベースデザインツール
• Linux 版のα版があるそうだ．
  • その後，Mac 版も出るらしい．
• 有償版でも $99．

MySQL Proxy

• まだアルファ版
• PostgreSQL の pgpool のようなもの．
• MySQL サーバとクライアントの間に入って，いろいろ便利なことをしてくれる・させられるもの．
• Lua で動作の拡張が行える
  • INSTALL_DIR/examples の中にサンプルが入ってる．
• 参照系と更新系のサーバへの振り分けが，MySQL Proxy でロードバランサー的に使えそう．

MySQL Connector/C++ & CMake

• JDBC 3.0 API を実装

オープンソースDB性能検証 SMPスケーラビリティを探る

• データベース性能検証会
  • セミクローズドで開催中らしい
• アジェンダ
  • 背景
  • 前回まで
  • その後
  • UltraSPARC T2
  • 議論

背景

• 方針
  • ベンダー依存ではない独自のベンチマーク
    • より客観的で比較しやすい性能評価のやり方
  • シンプルなテストから複雑なものまで，段階的なテストによるボトルネックを洗い出す
    • データベースの本当の限界値・性能を見極めたい
      • INSERT/UPDATE性能のみの限界
    • ネットワーク越しのアクセス・コネクション性能など
    • 実際のサービス(参照8:更新2)の形態で
  • 再現性のある形で
• テスト項目
  • 単体テスト
    • STORED PROCEDURE, C, Java, PHP
    • INSERT, SELECT, UPDATE, DELETE
    • 機能単体の限界性能
  • 1サーバ 1クライアント
    • C, Java, PHP
    • ネットワーク越しでどこまでパフォーマンスが下がるか
  • 1サーバ マルチクライアント
    • Super Smack
  • シナリオテスト
    • DBT-1 もどき
      • オンラインショップのシナリオテスト
• 検証条件
  • バージョンにこだわらない
  • データとログのディスクを物理的に分ける
    • 性能値を見るために I/O が足かせにならないように．
      • 逆に言うと，これが性能の足かせになるようだ．
  • 各DB毎にそこそこチューニング
  • MySQL は基本 InnoDB
  • PostgreSQL は適宜 VACUUM, ANALYZE

前回の結果を簡単に

• • MySQL
    • カラム数が多いと性能が下がる
      • カラムのハンドリングに時間がかかるようだ
      • ただし他の DB よりは性能劣化は低い
    • INSERT と DELETE はほぼ同性能
    • SELECT 性能は低いようだ
    • 圧倒的に DELETE 性能が低い
      • 4つのテーブルの結合だと MySQL の方が高速
      • LEFT JOIN だと，PostgreSQL 8.3 との比較で，小接続数では MySQL が高速
        • 接続数が多くなると，差は縮まる
    • GROUP BY では MySQL はさらに高速
    • 更新2:参照8 シナリオテストだと MySQL の方が若干高速
    • innodb_thread_concurrency をむやみに大きくしても意味がない
    • InnoDB は MyISAM に比べても十分に早い
    • JOIN は実は早い*1
      • PostgreSQL よりもかなり高速
    • SOCKET 接続は非常に早い
    • ネットワーク接続でもオーバーヘッドが少ない
    • 限界性能を狙うなら UTF-8
      • 内部的に変換が入るから，UTF-8 Native がいい．
      • ただしレコードサイズが増える・大きくなるので，その分を考慮する必要がある．
    • 複雑なクエリだと，PostgreSQL よりも早い
  • PostgreSQL
    • SELECT が非常に早い
      • 単一テーブル・2つのテーブルへの SELECT だと MySQL よりも高速
    • カラム数が増えると INSERT/UPDATE がかなり時間がかかるようになる．
    • DELETE がフラグを立てるだけなので早い
    • VACUUM しないと3割ほど遅くなる
    • 実はかなり早い．
    • シンプルなクエリで多量の結果が返ってくる．
      • SELECT は断然早い
    • プロセスモデルではあるが，同時他接続にも強い
      • 同時 500 接続でもそれほど性能劣化がない
    • 複雑なクエリだと，MySQL に負ける．
  • Firebird
    • INSERT 性能高い
    • ストアドによる単一接続は非常に高速
      • PHP によるネットワーク接続はまだ微妙
      • JDBC はそれなり

その後

• Super Smack を捨てた
  • Super Smack の問題点
    • クライアント単位に違うクエリーを実行できない
    • テスト毎に同じ乱数列を使えない
    • クライアント内で SELECT でとった値を次のクエリーに使えない

UltraSPARC T2 でのテスト

• UltraSPARC T2とは
  • 1 Chip 8 Core
  • 1 Core 8 Thread
  • 1 Chip 64 Thread
  • オンラインで Core/Thread を切り替えられる
  • Clock は高くないので，1 Thread あたりの性能はそれなり
• テスト方針
  • 測定点
    • Thread数 1(1 Core 1 Thread), 8(1C8T), 64(8C8T)
  • MySQL は 5.0 の 64bit バイナリを使う
  • PG 8.3 はビルド
  • FB Classic 1.5 は 64bit バイナリ
  • テスト項目
    • 単純テスト
      • 10万レコード，10/50/500 クライアント
      • DBT-1もどき
        • SELECT 20000 レコード
        • INSERT+UPDATE 5000 レコード
• テスト結果
  • MySQL
    • MySQL の方がクライアント数にかかわらずおおむね高速
    • 8 Thread で性能は頭打ちになる
  • PostgreSQL
    • 他接続になると，パフォーマンスが下がる
    • 16 Thread で性能は頭打ちになる
  • Firebird
    • 8 Thread で性能は頭打ちになる
  • 現行 DB のスケーラビリティは 8 〜 16 Thread 程度まで．

結論

• 1CPU -> 8CPU まではがつんとあがる
• 8CPU -> 16CPU までは，まあまあ，あがる
• 16CPU -> 64CPU までは，それほど変わらん
• CPU が増えると Context Switch のオーバーヘッドが大きいのかな？

議論

• クライアントが同時多接続を送り出せてないのでは？
• Tomcat/Java はしっかりスケールするらしいので，DB もそれなりにスケールさせられるはず？

*1:意外だ