ここから本文です

「使ってもいいよ」、あの「Webの巨人」が公開した自作データベースたち

12/5(火) 8:00配信

@IT

 最初に、Amazon Web Services(AWS)の「Amazon Aurora」を振り返ってみましょう。クラウド(AWS)で使うことを前提に、新しい発想で作り上げられたRDB(リレーショナルデータベース)です。RDBの歴史は長く、クラウドのない時代に生まれました。かつて「オンプレミス」という言葉はなく、データベースのサーバをクラウドで稼働させることは想定されていませんでした。そこでクラウドをプラットフォームとするAWSは「想定が変わったのだから、今の環境に最適なものに作り替えよう」とAuroraを開発し、リレーショナルデータベースをサービスとして提供しています。

 Auroraが汎用的なデータベースサービスとして開発されたのに対して、今回取り上げるGoogle Cloud Platform(以下、GCP)の「Cloud Spanner」と、Facebookの「MyRocks」は、元は大規模な自社業務を遂行するために開発されたデータベースです。ちょっと特殊でパワフル。

 これまで、自社業務のためにデータベースを新たに開発するということはあれど、それを一般公開することは珍しかったかもしれません。しかしCloud SpannerもMyRocksも、今は使おうと思えば誰でも使えます(Cloud Spannerは有償のサービスですが)。時代がどんどんオープンに向かっている感じがします。

 とはいえ、どちらもやや特殊で、「どこで誰が使うの?」という素朴な疑問はあります。しかし世界規模で展開される大規模なサービスを支えるために開発され、実際に本番運用されているデータベースなので、性能や効果は確かです。そこに盛り込まれた技術からは学ぶべきことがありそうです。

●Cloud Spannerは、どのように高い整合性を維持しているのか

 まずはCloud Spannerから。2017年5月から正式版となり、現在では東京リージョン(asia-northeast1)でも提供されています。「水平スケーリングが可能で高い整合性を備えた、リレーショナルデータベースサービス」とうたわれています。

 もともと、Googleの広告出稿サービスAdWordsのために開発されました。それ以前はMySQLをベースにしていたところ、シャーディングで課題があり、Cloud Spannerを開発することになったそうです。今ではGoogle AdWordsをはじめ、Google PlayやGCPなど、Googleの基幹業務を支えるデータベースです。社外への提供は2017年からですが、Google内部ではすでに5年以上の運用実績があります。

 2017年6月に開催された「Google Cloud Next Tokyo '17 in Tokyo」では、Cloud Spannerの用途として世界規模でのコンサートチケット販売が例に出されていました。顧客が世界中からアクセスしても重複して販売することがないように、大量のトランザクションを処理できるデータベースサービスです。

 Cloud Spannerは強力な水平スケーリングと高い整合性が特長です。以前は「スケーリングを優先するならNoSQL」とされていましたが、NoSQLは整合性である程度妥協せざるを得ませんでした。そうしたトレードオフがなく、水平スケーリングが可能でありながら、高い整合性を保ち、リレーショナルデータベースとして扱うことができます。ノードを追加すれば自動的にシャードされ、スケーリングが容易、レイテンシが安定しているのが強みです。分散して使うことを前提に強さを発揮できるようになっています。

 ただし、リレーショナルデータベースサービスとはいえ、Auroraのように既存リレーショナルデータベースからの移行には向いていません。Google Cloud データベースプロダクトリードのドミニック・プリュース氏もCloud Spannerについて「既存のリレーショナルデータベースからの置き換えはお勧めしない」と話していました。もし既存のリレーショナルデータベースシステムから移行するならCloud SQLを選ぶべきでしょう。Cloud SQLは、GCPで提供される、MySQLとPostgreSQLに対応したフルマネージドのデータベースサービスです。

 リレーショナルデータベースではあるものの、内部的にはキーバリューストア的な作りでレプリケーションしているようです。また高い整合性を実現するためにGoogleがTrueTimeと呼ぶ技術を用いています。これはGoogleが各データセンターに装備した原子時計から時間の精度を高める技術です。更新処理で高い整合性を実現するにはタイムスタンプが重要になるため、サーバの時間の精度を高めるために原子時計を用いています。

 Googleの強力なインフラを使えることも、強みかと思います。Googleは過去3年間で約3兆円規模の投資をして独自のネットワークを構築しており、このインフラでデータのレプリケーションをするのですから。

 なおCloud Spannerでシステムを設計するときには、プライマリキーに気を付けた方が良さそうです。オフィシャルドキュメントによると、タイムスタンプやシーケンシャルなものにするとホットスポットが発生するのでよくないのだとか。できればユニークになるUUIDを用いた方が良さそうです。

 どんなシステムがCloud Spannerを使いこなせるのか。楽しみです。

●Facebookはストレージエンジンを自作してストレージ使用量を激減

 もう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にしても、データ圧縮効率はとても高いので、「とにかくストレージの使用量を減らしたい」という要望には応えられるかもしれません。オンプレにしても、クラウドにしてもストレージを使えば使うほどお金がかかります。データ量が多過ぎて困っているシステムには有効かもしれません。

最終更新:12/5(火) 8:00
@IT