Pinterestはいかにスケーラビリティと格闘してきたのか（後編）。QCon Tokyo 2013

2013年5月14日

4月23日に都内で開催されたエンジニア向けのイベント「QCon Tokyo 2013」。急速に人気サイトへと成長したPinterestが、その裏でいかにスケーラビリティと格闘してきたのかをPinterestのエンジニア自身が紹介するセッション「Scaling Pinterest」が行われました。

この記事は「Pinterestはいかにスケーラビリティと格闘してきたのか（前編）。QCon Tokyo 2013」の続きです。

クラスタリングは怖い

スケーラブルなシステムで問題なのは、データベースがひとつのサーバに収まらなくなったときにどうするのか、ということだ。

例えば、Cassandraは自動的にスケーリングしてくれて設定も簡単。可用性も高く単一障害点はない。しかし障害はそれでも起こるもので、クラスタリングの技術はまだ枯れておらず基本的に複雑なものだ。コミュニティもまだ十分ではない。

私たちはCassandraで4回ほど、カタストロフィ（破滅的）な現象に遭遇したことがある。データのリバランシングに失敗したことや、すべてのノードでデータが壊れてしまったこともある。10のノードがあるのになぜか負荷が1つに集中していたので、マニュアルで直したつもりが自動リバランス機能が元に戻してしまったりする。

そんなわけで、私たちが学んだこと「Lesson Learnd #2」は、クラスタリングは怖い、ということ。技術として枯れていないので、変な壊れ方をする。

シャーディングを採用

そこでシャーディング。シャーディングの方法はいろいろあるが、アルゴリズムは非常にシンプル。

どの時点でシャーディングを開始するべきか。シャーディングを始めるには、新しいサービス開発を止めて数カ月はシャーディングに取りかからなければならないし、遅くなるほどシャーディングは難しくなる。

まずできるだけ複雑なジョインを取り除き、キャッシュなど追加する。それでもまだ足りなければシャーディングに取り組む。

私たちはまず、1台のDBに外部キーとジョインを用い、次に非正規化とキャッシュ。さらにリードのスレーブを追加。この段階でシャーディングを考え始めた。

そのあといくつかの機能をシャードしたデータベースとリードスレーブなどを使い始めた。私たちがシャーディングを始めるのは遅すぎたといまは反省している。

そのあとでアーキテクチャを再考し、IDによるシャーディングを行った。シャーディングを行うとジョインなどがなくなるため、スキーマを計画的に変更しなければならない。

64ビットのIDでシャードを指定

われわれがどうシャードしたか、具体的な方法だが、これはFacebookやFriendfeedなどのやり方を研究し、そこからわれわれに合ったものを採用した。

まず8つのサーバそれぞれに512個のデータベースがあり、それぞれにユニークな名前（db00001、db00002、db00003～db04096）がついている。名前からどのデータベースがどの物理サーバにあるかが分かる。また物理サーバにはそれぞれスレーブサーバが用意されており、レプリケーションされている。

仮にキャパシティがもっと必要になればデータベースを分けて新しいサーバにレプリカを作り、再コンフィグレーションする。例えば512のデータベースを256までと512までに分けて、それに合わせてコードを直す。こういう分割は容易にできる。

データのIDは64ビットで、Shard IDがどのシャードにデータがあるのかを示しており、Typeはどのタイプのデータなのか、そしてLocal IDでそのテーブル内の位置を示している。アプリケーションはどのシャードがどのサーバに入っているか知っているため、これらによって中間のサーバなどに頼ることなく直接そのデータに到達できる。