データセンターが「落ちる」ことを想定したグーグルのアーキテクチャ

2009年8月31日

サーバを安全に運用する施設として構築されるデータセンターですが、グーグルではそのデータセンターですら"落ちる"ことがあると想定してアーキテクチャを構築しています。

米グーグルが今年の5月に行ったイベント「Google I/O」で、同社のGoogle App Engine datastore leadであるRyan Barett氏が行った講演「Transactions Across Datacenters (and Other Weekend Projects)」のビデオがYouTubeで公開されました。

Barett氏は、担当しているGoogle App Engineのデータベースに関してグーグルが「multihoming」（マルチホーミング）と呼ぶ複数のデータセンターを用いた処理を実現している理由として、データセンターが自然災害や停電に見舞われたり、メンテナンスなどによるデータセンターの停止があり得ること、また、物理的に顧客に近い場所にあるデータセンターでサービスを提供することでよりよい性能を提供できること、などを挙げています。

しかし、複数のデータセンターにまたがった運用では、データセンターにまたがるトランザクションとそれによるレイテンシの発生、回線コストの上昇など、解決することが難しい問題が多発します。

グーグルはそうした問題をどのように解決しているのでしょうか？ Barettの解説を少し読み解いて行くことにしましょう（参考記事：How Google Serves Data from Multiple Datacenters | High Scalability）。

データセンターにまたがる運用の選択肢

複数のデータセンターにまたがったデータベースの運用で、特に難しいのが、以下の2点だとBarett氏は指摘しています。

Consistently? Harder （一貫性を保つには？かなり困難）
with real time writes? Hardest（それをリアルタイムな書き込みでも実現するには？ほとんど無理）

これをどう解決するか？ 1つ目の選択肢は「データセンターにまたがった運用はしない」ということです。しかし、万が一自然災害などが発生した場合の被害が大きいこと、また、地理的にも顧客の近くでの運用がやりにくいといった課題があります。

2つ目の選択肢は、プライマリ用のデータセンターとフェイルオーバー用のデータセンターを用意すること。しかし、一定期間分のデータの消失が考えられ、またデータの一貫性についても保証されていません。

そして3つ目の選択肢が「マルチホーミング」です。複数のデータセンターへ同時に書き込みを行います。難しい方法ですが、災害などに対して一定の対応が可能です。しかし、レイテンシを覚悟しなければなりません。

マルチホーミングのテクニックとトレードオフ

Barett氏は、データベースをマルチホーミングで運用するテクニックとして以下の5つを挙げ、それぞれのメリット、デメリットを紹介しています。

Backups
コピーを別のデータセンターに保存する方法。おおざっぱでデータの一貫性は弱く、一般的にトランザクションも保証されない。以前に採用していた方法。
Master/Slave Replication
一般に非同期で行われ、スループットはよく、多くのRDBMSでも採用されている。しかしEventual Consistencyである。現在採用している方法。
Multi-master Replication
「同時書き込み可」を示す全体的な呼び名である。非同期でEvenutual Consistencyである。シリアライゼーションプロトコルが必要となり、マスター間にまたがるトランザクションは存在しない。
Two Phase Commit（2PC）
一貫性が確保される。しかし処理が重く、同期的なプロトコルであるためレイテンシが大きい
Paxos
完全な分散コンセンサスプロトコル。多数が書き込みに成功すれば、少数が失敗しても処理が継続できる。2PC、3PCに似ているが処理は軽い。それでもレイテンシは大きい