hbstudy#11

雑記

概要

URL http://heartbeats.jp/hbstudy/2010/04/hbstudy11.html
日時 2010/05/14 19:00 - 21:00
場所 ハロー貸会議室 新宿A(新宿三葉ビル6F)
twitterハッシュタグ #hbstudy
Ust録画 http://www.ustream.tv/recorded/6903324

MaatKitの紹介

講演者 吉田晃典(株式会社はてな) id:marqs @marqs
資料 http://www.slideshare.net/marqs/maatkit-4098945

MaatkitというMySQL用のツール群の紹介。
ツールの数が多いので、この講演ではよく使うツール数個について説明されていた。

特徴
  • ドキュメントもあるし、オプション例もある
  • Facebookを始め多数の企業に導入されている
  • 商用サポートもあるらしい
  • rpmなどもあり、導入は簡単
  • しかし日本語の情報はほとんどないらしい、というか日本ではほとんど使われてないらしい
  • はてなではMySQLサーバ構築時に一緒にインストールする
  • 最近は memcached,postgresql にも対応しているらしいが未検証
mk-find
  • GNU find っぽくテーブル情報を検索できる。正規表現ももちろんOK
    • 例 4GB以上のテーブルをすべて出力
  • 抽出したテーブルに対し処理を実行することも可能
mk-slave-restart
  • エラーで止まったmysqldをリスタートする。エラー番号指定可能
mk-kill
  • 特定条件にマッチしたクエリをkillする。条件指定が豊富
    • 例 バッチサーバから本番DBに間違って投げられた参照クエリを kill
mk-slave-move
mk-query-digest
  • クエリ解析ツール。解析できるデータ形式が豊富。
  • 出力は mysqldumpslow ライク
  • はてなでは毎日cronでmk-query-digestを流してクエリ改善の指標としているらしい
  • あるサーバへのクエリのうちselectだけを別サーバに向けるなんてこともできる
その他

SSDの話

講演者 村松雄介(株式会社はてな) id:halfrack @muranet
資料 http://halfrack.g.hatena.ne.jp/keyword/hbstudy11?mode=presentation
はてなでの歴史
    • 2008/8/28にSSD購入
    • 2009/2/26 X25M導入
    • 現在 53ホスト
SSDのメリット
  • alter table 速い
    • どのくらい速いかというと、RAID上でalter tableするより、RAID から tar + ncat でSSDに持ってきて、alter table してから再度 tar + ncat で RAID に戻す方が速い、というぐらい
SSDの用途
サーバ構成
  • メモリ8GB、シングル(非RAID)
  • ファームウェアバージョンもファイルシステムアラインメントも気にしない
SMARTの見方
  • Media Wearout Indicatior が write量と強い相関
    • 大量に書き込むと減る。0が寿命だと言われているが、0になっても動くものもある
    • write性能が著しく劣化する模様
その他
  • よれよれのSATA使うとread性能劣化
  • AHCIにしないと性能劣化
  • 通常使ってる分にはベンダサーバRAID×3台より速い
  • 50以上のホストで使ってるがトラブルが起きたことがない。一方でRAIDはRAIDカードのコンデンサが爆発したりと、トラブルはちょこちょこ発生
    • そのせいでトラブル対処の経験がない
  • SSDがあまりに速すぎるせいでEC2等のクラウド環境に持っていけない
  • X25EだとオーバースペックなのでX25Mで十分
  • SSDはルートディレクトリから乗っけてる
  • はてなではXenを使った仮想化をしている。Dom0並べておいて、使い道はあとで考える感じ

インフラエンジニアのための Cassandra 入門

講演者 桑野章弘(株式会社サイバーエージェント) id:akuwano @kuwa_tw
資料 http://www.slideshare.net/akuwano/cassandra-4098052
CassandraはMySQLより分散処理の管理が楽
  • MySQLの分散処理は大変
    • カラム分割やハッシュテーブルなど使っても、メンテナンスが結構手間
  • Cassandra でできること
    • パフォーマンス
      • r/w ともに MySQL より 250/23倍速い( 300/300 ms -> 0.12/15 ms) ※公式wikiより
    • 分散実装
      • マスタなし。全てノード(後述)
    • 冗長性
    • データ構造
  • Cassandra でできないこと
    • 整合性の確保
      • できるが厳しい(後述)
    • 動的カラム変更
      • 次のバージョンからは可能な模様
Gossip プロトコル
  • 直近のノードのみでデータのやりとりをすることで、クラスタ全体にデータを伝搬させるためのプロトコル。
    • (説明には用語としてでてなかったが、要するにクラスタ全体で木構造をとるということ。だからノードN個のデータ転送量はN-1倍するだけで済む。N**2などのオーダーにならないということ)
  • ノードが死んだことを検知したら、別のノードとの通信に切り替える。
  • ポーリング間隔は1秒固定。
  • データの転送量が急激に増えることはないが、その性質上クラスタ全体での整合性をとることが困難
    • 整合性とることを優先するオプションもあるが、パフォーマンスは著しく低下する
Cassandra 上のデータ構成要素
  • memtable
    • 通常はここにデータを保持
  • sstable
    • 古くなったデータはディスク上のこのファイルに書き込まれる
  • commitlog
  • sstable と commitlog は IO分割した方がいい(パーティション分割とかディスクを分けるとか)
データ操作
  • cassandra -cli でok
サーバ追加
  • 設定ファイルのSeedという項目に追加しておけばいい
nodetoolコマンド
  • データの再配置(めちゃ重い)
  • サーバ監視
    • tpstats
    • cfstats
  • バックアップ/リストア
    • snapshot コマンド。
    • 使うときは flush して memtable の情報を全て書き出してから
データのインポート/エクスポート
  • json　<-> sstable が可能
ロードマップ
  • 0.7
    • 動的カラム追加
    • Avro対応
  • 0.8
    • Index実装
    • VectorClock実装
問題点
  • 動作不安定。高負荷時に落ちる
    • まだ本番環境には使うの怖い
  • クライアントの冗長/分散は必要
    • kumofs の kumo-gateway みたいなのはない
  • 仕様がちょこちょこ変わる
    • 0.6の設定ファイルはXML なのに、0.7は YAML


以上

関連記事

自作サーバカンファレンス - 科学と非科学の迷宮