グーグルのBigtableが耐障害性を強化、Megastoreレプリケーションで
グーグルがGoogle App EngineやGoogle Appsのデータベースなどのデータベースとして利用しているのが、「Bigtable」と呼ばれるキーバリュー型ストアです。
グーグルは以前からこのBigtableを複数のデータセンターにまたがって運用し、万が一障害が発生したとしてもデータを失うことがないように、データセンター間のバックアップなどを行ってきました。
しかし、先月の記事「データセンターが「落ちる」ことを想定したグーグルのアーキテクチャ」で紹介したように、グーグルといえどもこうしたデータセンターにまたがるデータベースを安全に運用する方法については試行錯誤しており、7月には6時間にわたり大規模なデータベースの障害を引き起こしていたことは、「Google App Engineにデータストアの障害発生。復帰まで約6時間、原因は現在も不明」で紹介しました（この件については後日、原因などをグーグルが報告しています）。
そのBigtableを強化し、Megastoreという機能でレプリケーションを改善、耐障害性を強化したと、9月14日付けのGoogle App Engine Blog「Migration to a Better Datastore」で説明されていました。
いままでのレプリケーションには問題があった
Google App Engine Blog: Migration to a Better Datastore記事「データセンターが「落ちる」ことを想定したグーグルのアーキテクチャ」の中のプレゼンテーションでグーグルのRyan Barett氏が説明しているように、グーグルはいままでデータセンター間のバックアップを、「Master/Slave Replication」という方法で行っていました。これは一般に非同期で行われ、スループットはよく、多くのRDBMSでも採用されていますが、Eventual Consistencyだという特徴を持っています。
しかし、このレプリケーション方式では障害発生時に問題が生じる可能性がありました。ブログから引用します。
if the Bigtable cell in A is unhealthy, we're in trouble. Bigtable replication is fast, but it runs in the background, so it's usually at least a little behind, which is why we wait for that final flush before switching to B. If A is unhealthy, some of its data may be unavailable for extended periods of time. We can't get to it, so we can't flush it, we can't switch to B, and we're stuck in A until its Bigtable cell recovers enough to let us finish the flush.
もしもBigtableの（データセンター）セルAに問題が発生すると面倒なことになる。Bigtableレプリケーションは高速だが、バックグラウンドで処理されるため多少の遅れはありがちだ。そのため、（アプリケーションからデータベースへのアクセスをセルAから）セルBに切り替える前にはデータのフラッシュを待たなければならない。しかしAに障害が起こった場合、そのデータにはしばらくのあいだアクセスできなくなり、フラッシュもできなくなり、Bへのスイッチもできなくなってしまう。Aがフラッシュできるほど復旧するまでは待たなければならないのだ。
Aの障害にBが巻き込まれて運用を止めざるを得ないときがある、ということのようです。そして、前述の長時間による障害も、これが原因であったようです。
Megastoreという解決策
これを解決するのが、Megastoreという技術だと解説されています。
Thankfully, there's a solution to our consistency problem: Megastore replication. Megastore is an internal library on top of Bigtable that supports declarative schemas, multi-row transactions, secondary indices, and recently, consistent replication across datacenters. The App Engine datastore uses Megastore liberally. We don't need all of its features - declarative schemas, for example - but we've been following the consistent replication feature closely during its development.
ありがたいことに、このコンシステンシの問題にはソリューションがある。Megastoreレプリケーションだ。Megastoreは、Bigtable上の内部ライブラリであり、宣言的スキーマ、複数行トランザクション、2次インデックス、そして最近、データセンタにまたがる一貫性のあるレプリケーションが実現された。 App EngineのデータストアはこのMegastoreを（一部）利用している、ただしMegastoreのすべての機能、例えば宣言的なスキーマは必要としていない。しかし、一貫性のあるレプリケーションについては開発段階から注目していた。
Megastoreレプリケーションとはどのようなものなのでしょう？ 詳細は明かされていませんが、次のように説明されています。
Megastore replication was originally intended to replicate across multiple datacenters synchronously and atomically, using Paxos. Unfortunately, as I described in my Google I/O talk, the latency of Paxos across datacenters is simply too high for a low-level, developer facing storage system like the App Engine datastore.
Megastoreレプリケーションは元々、Paxosを用いて複数のデータセンター間の同期を自動的に計ろうとしていた。しかし、Google I/Oで話したように、Paxosのデータセンター間でのレイテンシは非常に大きい。
Due to that, we've been working with the Megastore team on an alternative: asynchronous, background replication similar to Bigtable's.
そこで、我々はMegastoreチームと協力して別の方法法を採用した。Bigtableレプリケーションに似た、非同期でバックグラウンドで動作するレプリケーションだ。
実は、Megastoreへのマイグレーションはすでに完了しています。9月22日午前5時（米国時間）に作業が予定されており、無事に終了したようです。今後、Google App EngineやGoogle Appsはより安全に利用できることになるのでしょう。
グーグルはGoogle File Systemの次世代版も計画しています「グーグルが「Google File System」次期バージョンを開発中」。クラウドは稼働し続けるのが当然とはいえ、それを維持しながら内部では改善を行っていく様子は非常に興味深いものがあります。
今回紹介したGoogle App Engineのエントリ「Google App Engine Blog」の内容は、「Migration to a Better Datastore - hidemonの日記」で翻訳されています。この記事を書くのにも参考にさせていただきました。
関連記事 on Publickey
あわせて読みたい
