HP「NonStopサーバー」って？／フェイスブックの中の人に聞いたMySQL 5.6の使い方：Database Watch（2013年12月版）（2/2 ページ）

今月は専用機「NonStopサーバー」の仕掛けと、Facebookの中でのMySQL 5.6への対応状況、使い方をウォッチします。

[加山恵美，＠IT]

フェイスブックはMySQL 5.6をこう活用している

　11月のdb tech showcase 2013では長らくMySQLで活躍している松信嘉範氏の講演もありました。現在、松信氏は米フェイスブックで働いており、アメリカ在住でめったにお目にかかれないこともあり、会場はあっというまに満員となりました。フェイスブックでどのようにMySQLを運用しているのか貴重なお話が聞けました。

11億ユーザーを支えるMySQL採用システムの運用事例

　フェイスブックの発表によると2013年3月末の月間アクティブユーザー数は全世界で月間11.1億人。MySQL利用事例の中でもトップクラスの規模です。松信さんによるとシステムの規模感としては約数千万クエリ/秒ほどあるそうです。フェイスブックではデータベース運用管理チームはもちろん、MySQL本体に機能の追加や改良を行うエンジニアリングチームも持つのが特徴的です。時には本家よりも先にバグ修正することもあるなど、スペシャリストがそろっています。こうしたエンジニアリングチームを抱えるということは人件費が掛かりますが、自社内で機能改善することでサーバーを減らすなど運用コストが削減できるのでコスト的には見合うという判断です。

　現在フェイスブックでは最新版GAとなるMySQL 5.6を運用しています。古いバージョンに独自の機能を足すより、必要な機能が本体にマージされている最新版を使う方が有利だからです。独自に保守しなくてはならないパッチの量が抑えられるほか、5.6では接続数が多い場合の処理が高速であること（ストールしにくい）、性能的な利点やリカバリとフェールオーバーが簡素化されるなど運用面で利点が挙げられます。

　MySQL 5.6にありながらもまだフェイスブックが使っていない機能もあります。例えばパフォーマンススキーマがあります。未採用の理由は性能劣化。性能分析は他の手段で代替しているそうです。それからGTID（Global Transaction ID）とMTS（マルチスレッド・スレーブ）も未使用です。後述するようにGTIDの有効化にはさまざまな準備が必要なことと、GTIDなしではMTSは運用が困難になるためです。

フェイスブック独自の拡張機能実装は？

　フェイスブックのエンジニアリングチームが独自に拡張した機能には非同期MySQLクライアントAPI、高速なテーブルスキャン、（本体より）高速なレプリケーション、より低コストなSemi-Synchronousレプリケーションなどがあります。またフェイスブックではSSDも多用しているため、書き込み量を軽減したり自動でデフラグを行うなどSSDに適した動作となるような改良も行っています。運用の規模が大きいので必要になってくる機能です。

　中でも重要になるのがレプリケーションです。フェイスブックではMySQL 5.7で強化されるレプリケーションの機能をMySQL 5.6に取り入れています。5.7はまだGAになる前なので、いわば機能の先取り。とはいえすんなり行かないこともあります。例えばSemi-SynchronousレプリケーションはBinlogリーダーが多数いるとコミット性能が指数関数的に悪化するため、原因となる内部ミューテックス「plugin_lock」を保持することで対処しているそうです。

　また、I/Oスレッドの安定化と高速化も挙げられます。マスターからスレーブへの転送速度をパラメーターで制御できるようにしています。転送速度が少ないとレプリケーション遅延が発生するためです。バイナリログの読み込みI/O単位は8Kバイトから1Mバイトに変更しています。新規スレーブ作成のために古いバイナリログを読み込むとき、サイズが小さいと効率的ではないからです。

　ストレージエンジンInnoDBも改良しています。本家のInnoDBも近年改良が進んでいるのに、さらに改良を加えているなんてものすごいですね。例えばバックアップやオンラインでスキーマ変更などフルテーブルスキャンを行うとき、テーブルが断片化していると遅くなるためLogical Read Aheadで読み取りを高速化しています。一般的には主キーの順番に読むところを、先にブランチページを読んで対象のリーフを特定し、リーフページを先読みしてバッファプールにキャッシュした上で、主キーを順に読んでいきます。先読みしてデータを整理することで、ランダムアクセスを極力減らして高速化を実現しています。

実稼働中のシステムでは難しいGTID有効化

　この他にも、まだ高度な改良の話がありましたが、このあたりにしておいて、GTIDの有効化に話を移します。MySQL 5.6の本体に搭載されたものの、未使用となっているものにGTIDがあります。GTIDを有効化するのはそう簡単ではありません。実際には「gtid_mode」を変更することになりますが、そのときはスレーブとマスターを全部停止し、一斉に起動し直す必要があるからです。フェイスブックで全サーバーを止めるわけにはいきません。ローリングアップグレード的なこともできません。またGTIDそのものが不安定であったり、新しい機能なのでクラッシュセーフスレーブが機能しないという制限など、いろいろと厄介なようです。現在こうした困難を1つずつ克服しており、GTIDとMTSは間もなく実運用に入れる段階にまで到達したようです。

　最後に松信さんは「フェイスブックでは今後新たに不具合が発生することは想定済み。そうなれば即時にバグフィックスしデプロイできる体制が整っています」と述べていました。恐らく世界でトップレベルとなる高度なMySQL活用環境ではないかと思います。すごさに驚かされっぱなしでした。