詳しくは公式サイトを。
自分が拝聴したのは 17-A-4「大規模Webサービスのためのデータベース技術の現在・未来」というもので、
以前MySQLの中の人だった人で今はDeNAの松信嘉範氏 ( @matsunobu )による講演だ。
ものすごくテンポの早い講演で、持ち時間45分の中に2時間分のボリュームを詰め込んでもらったくらいの感覚。
話の主軸はやはりMySQL。そして時間を割いて説明してもらったのは主にハードウェアのこと。
少しメモったので備忘録的にまとめる。
テーマ
今後の「大規模Webサービスを支えるデータベースにはクリアすべき課題が3つある」課題1 パフォーマンスの維持
データ量が大規模になると1台のサーバーではまわせなくなる。そこで水平分割をする。
分割には剰余を使う方法もあるが、これからはマッピングテーブルを使う。
キーワードは Spiderストレージエンジン や MySQL Cluster
( Spiderストレージエンジンは奥野氏のブログに詳しい。)
課題2 ハードウェアコスト
台数を単純に増やそうとすると資金が必要になる。その解決には「1台あたりの性能を上げる」のが効果的。
ここで昔話。
32ビットOS時代はMyISAM + HDDが主流だったが、64ビットOS+大容量メモリの時代になり、InnoDBが台頭。
バッテリバックアップ式ライトキャッシュもあり、オンメモリで使えるようになった。
こうなると今度は1台あたりの更新量も増え、レプリケーションの遅延が課題になった。
そこでスレーブにSSDを使うようになってきた。
(中略)
これからはPCI Express x8のSSDを使う。
マスターHDD + スレーブ複数インスタンスのPCIeSSD ならサーバー台数自体を減らせる。
ディスクI/Oの課題がクリアされると今まで気にならなかった他の課題が表に出てくる。
ネットワークボトルネック
当然100MBではダメなので1GBイーサ。
そして新しいLinuxコアを使う。ネットワークの通信にCPUコアをマルチで使える。
CPUボトルネック
SQLの実行には解析~結果の返却までに少なからず時間がかかる。
単純なクエリならやっぱりNoSQL。ということで出ました Handler Socket Plugin。
データベース接続コスト
Webアプリではユーザーアクションごとに接続をして切断をするのが主流だった。
今後のキーワードはパーシステントコネクション、Proxy型コネクションプール。
課題3 人的コスト
アプリの規模が大きくなってサーバーを10倍にしたからといって、サーバー管理者を10倍にできるものではない。一人のサーバー管理者が担当できるサーバー数を増やす必要がある。
・故障率を下げる
・作業時間を減らす。
・手動によるフェイルオーバーをなくす。
・マスターのフェイルオーバーを自動化する。
・スレーブの差分復旧の実装。
今後のトレンド
まとめると、今までハードウェアのボトルネックだった部分がどんどん改善され、今まで表面化しなかった新たな課題が出てくる。性能よりも、機能、可用性、耐障害性、自動化などが注目されてゆくに違いない。
メッセージ
「先を見通すべし」「見る目を養うべし」
最後のほうは聞くのに夢中でメモしきれなかった。
他に印象に残っている言葉としては、「ベンチマークの数字を信用するな」というものがある。
中盤と後半2回に渡って登場した言葉であり、語気を強めていたので忘れられない。
公表されているベンチマークの数字は一番よい状態の数値であり、平均値ではない。
意外にパフォーマンス低下があったりしてサービスレベルが低かったりする場合もある。
コレばっかりはちょっとテストしただけではわからない。
まさにDeNAの中の人ならではの濃い内容で、半休を取ってまで行ったかいがあった。
今の自分の仕事とはかなりかけ離れていて有用ではないが、個人的には有益な時間だったと思う。
いずれ松信氏がスライドを公開してくれると思うのでもう一度読みながら思い出したい。
講演の中でも紹介されていた氏の著書。
.
0 件のコメント:
コメントを投稿
注: コメントを投稿できるのは、このブログのメンバーだけです。