もう1つはFacebookのMyRocksです。Facebookはシステム規模の大きさから、インフラも自社でまかなっています。AWSやMicrosoft Azureなどのパブリッククラウドサービスは使いません。そしてメインとなるデータベースはMySQLを用いています。
Facebookのインフラ規模は非公開ですが、相当な規模と想像できます。当然、生じるコストも大規模です。Facebookとしては、サーバの台数を減らすことができれば、大きなコスト削減となります。近年、Facebookは運用コスト削減を目指して、データサイズを縮小することに挑戦しています。その中心にいるのが日本のMySQLコミュニティーで有名な松信嘉範氏です。同氏は2012年から、アメリカのFacebookで働いています。
これまでFacebookでは、MySQLのストレージエンジンにInnoDBを用いていました。ストレージエンジンとしてはデフォルトであり、完成度の高いものとなっています。しかしデータ圧縮して用いてもなお、耐障害性機能などを理由としてストレージ使用量が増えてしまいがちでした。
そこでFacebookが目を付けたのが、Googleが開発したLevelDBです。ベースはキーバリュー型NoSQLデータベースで、データを階層化して圧縮することでストレージ使用量を減らします。イメージとしては、今週の新聞がたまったら圧縮して、それが1カ月たまったら、またまとめて圧縮して、さらに1年たまったらまたまとめて圧縮します。
古いデータほど何度も圧縮されているため、読み込み効率は落ちます。しかしLevelDBには「ブルームフィルタ」という技術があるのと、Facebookでは古いデータが読まれる頻度は低いので、このデメリットがあまり深刻にはなりません。データ圧縮効率の高さの方が、Facebookにははるかに魅力的となります。
ただし、LevelDBはNoSQLデータベースです。FacebookとしてはMySQLを用いているため、データベースを違うものにするのは大きな労力やリスクが伴います。しかしMySQLにはストレージエンジンが選べるという特徴があります。FacebookではLevelDBをMySQLのストレージエンジンとして改造すると決断しました。それがMyRocksです。
「db techshowcase OSS 2017」における、松信氏の講演によると、ストレージエンジンをInnoDBからMyRocksに変更することで、ストレージ使用量を半減できたそうです。正確に言うと、オリジナルのInnoDBのデータを圧縮することで、データが半分になります。これが通常のFacebookでの運用です。MyRocksを用いると、圧縮されたInnoDBに比べて約半分のサイズになるとの検証結果が得られました。そのため、実運用でストレージ使用量が半分になると期待できます。Facebookほどの規模のサイトでデータが半減できたら、サーバも半減とまではいかなくてもかなり減らせます。そのコスト削減効果はとても大きいのです。
実際にFacebookでは段階的にInnoDBをMyRocksに置き換えているところです。最初の置き換えをするときはレプリケーションのスレーブの1台(InnoDB)を止めてダンプを取り、新しいスレーブ(MyRocks)にリストアします。後はレプリケーションで同期を再開させます。なおFacebookではInnoDBとMyRocksで同じようにデータがレプリケーションされているかチェックするツールも自作したそうです。
このMyRocksは、オープンソースで公開されています。MyRocksにしてもLevelDBにしても、データ圧縮効率はとても高いので、「とにかくストレージの使用量を減らしたい」という要望には応えられるかもしれません。オンプレにしても、クラウドにしてもストレージを使えば使うほどお金がかかります。データ量が多過ぎて困っているシステムには有効かもしれません。
Copyright © ITmedia, Inc. All Rights Reserved.