読者です 読者をやめる 読者になる 読者になる

Yuichi Murata's Engineering Blog

Go / App Engine / GCP とか書いていきます

Google Spanner のアーキテクチャを知る

最近 Cloud Spanner のベータ公開によって話題の Spanner。 気になっていたので論文を読んだり勉強会などで情報収集していました。日本語のリソースもそこまで多くないので、調べてわかったことを纏めておきます。

簡単にまとめると特徴は以下のとおりです。

以下で、細かい説明を続けていきます。

Spanner の全体構成

Spanner の全体像についてまとめます。

f:id:yuichi1004:20170226100525p:plain

図1. 全体構成図 (ref. 1 より引用)

Universe と Zone

プラネットスケールを謳うだけあって、名前付けもおしゃれです。Universe は Spanner システムのデプロイメントの単位です。Google 社内では開発用 Spanner、本番用 Spanner といったいわゆる環境の分割に使っているようです。

Universe は、Universe Master、Placement Driver そして複数の Zone から成ります。ここでいう Zone は Spanner システムの管理用途の区分であって、データセンターやアベイラビリティゾーンといった物理的な区分ではないことに注意です。同一のデータセンターやアベイラビリティゾーンに複数の Zone を配置することも可能です。そして、Zone はシステムを稼働させたまま追加したり削除したりすることができます。

ここで Universe Master と Placement Driver が単一障害点の様に見えるのが気になるところです。ただし、両者共に即座のサービス影響がでるものではないようです。Universe Master は各ゾーンの情報を見るための管理コンソールや、デバッグ用のシステムです。Placement Driver は各 Zone に配置されたデータの再配置を行うものです。つまり、これらが障害を起こしたとしても即座にデータアクセスができなくなるというものではない、ということです。

Zone と Spanserver

各 Zone に配置されたコンポーネントの内、最も重要なのが Spanserver と呼ばれるものです。Spanserver が実際にデータを格納するためのソフトウェアスタックとなっています。いわば、Spanner の心臓部分です。一つの Zone におよそ数百から数千の Spanserver が配置されます。

Zone には Zonemaster が配置されており、この Zonemaster がデータをどの Sapnserver に配置するか決定します。クライアントがアクセスしてきたときにどの Spanserver を参照するかは Location Proxy が返します。つまりクライアントは直接 Zonemaster と直接通信しません。

Spanserver の構成

Spanserver の構造について説明していきます。

f:id:yuichi1004:20170226110714p:plain

図2. Spanserver スタック (ref. 1 の図を参考に作ったものです)

Spanserver と Replica

Spanserver 内部では Replica と呼ばれるデータ構造を多数管理します。1 台の Spanserver は 100 から 1,000 の Replica を管理します。ここで重要なのが、Replica は複数のデータセンターに分散されているということです。つまり Spanserver というのは物理的なサーバーを指しているのではなくて、一連のソフトウェアスタックを指しているということです。

Replica と Participant Group

幾つかの Replica が集まって Paxsos Group というグループを構成します。この Paxsos Group 内で同一のデータを複製します。

各 Replica はクライアントから送信されたデータと、その操作ログを分散ファイルシステムである Colossus (GFS の後継) に記録していきます。そして Paxos Group 内で Paxos という仕組みを通じて、レプリカ間の整合性を取っていきます。Paxos の詳しい説明は避けますが、端的にまとめると複数人で同じ仕事をして不整合が発生したときには多数決で状態を決定するというものです。マスターが存在しないため、単一障害点が存在しないのが特徴です。

Replica のグループには各グループを代表する Leader Replica が存在します。このリーダーは 10 秒程で役割を交代します。ここでこのリーダーの選出にも多数決が用いられます。

Participant Leader

Leader Replica は Participant Leader としても振るいます。Participant Leader は、Transaction Manager としての役割を果たし、Lock Table を持ちます。

ここで大事なことは Transaction Manager は、複数の Paxos Group にまたがるトランザクション時にのみ作動する分散トランザクション用の機能であるということです。つまり、大部分のユースケースである単一の Paxos Group 内でトランザクションが解決する場合、Transaction Manager は何もしないで済むということです。Paxos Group 内でトランザクションが完結する場合、Lock Table と Paxos のやり取りのみでトランザクションを完結することができます。このあたりはタイムスタンプを使ったトランザクション処理を細かく見ていくと詳細がわかるのですが、いったんここでは割愛します。

そして、上述したように Lock Table は Paxos Group 内でトランザクション処理が必要な場合などに利用されます。

Spanner は Datastore に似ている

ここまで読み込んでみてわかったことは、Spanner のアーキテクチャは Datastore にとても似ているということです。特に、以下の点が共通点です。

  • Tablet (Bigtable で使われているデータ構造) に各列を分散保存することでスケーラビリティを確保する
  • ↑に対して Transaction Manager の処理を追加実装することによってスケーラビリティと整合性を両立している

更に言うと、Spanner は Datastore と同じく、ツリー型のデータ構造をとり、データを局所化してアクセス効率を上げている点でも共通しています。この点に関しては別記事で書いてみたいと思います。

まとめ

本記事では、Spanner のアーキテクチャについて自分の理解できた範囲で解説してみました。 Spanner は Tablet に分散してデータを保存する点や、その機構の上にトランザクション処理の機能を追加実装することによって、整合性とスケーラビリティを両立する、Datastore のアーキテクチャにとても近いことを述べました。

引き続き、Spanner の論文や記事を読んで理解できた話について書いていきたいと思います。

参考文献 

ref 1. Google Research Publication: Spanner