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 は実は早い¹
    • 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 もそれなりにスケールさせられるはず？

comments powered by Disqus