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つに集中していたので、マニュアルで直したつもりが自動リバランス機能が元に戻してしまったりする。

fig

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

fig

シャーディングを採用

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

fig

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

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

fig

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

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

fig

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

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

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

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

fig

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

fig

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

fig

新規のユーザーは0から4096までのランダムなシャードに割り当てられる。ボードやピンなどのタイプはユーザーと合わせて付けられる。Local IDはインクリメンタルに付く。

fig

オブジェクトテーブルにはユーザーのボードやピンなどの情報が入っている。

マッピングテーブルには、ユーザーがボードを持ってるとか、ピンがイイネされているとかをマップする。明示的にオブジェクトが何かのオブジェクトとつながるといった単純な構造。すべてのルックアップがシャードに載るとデータの移動がないので、システムはシンプルになる。

検索時に99.9%はキャッシュにヒットする。

fig

それと、われわれが過小評価していたのは古いシステムから新しいシステムへの移行。これに4カ月かかった。5億のピン、16億のフォローデータ移行のためにスクリプティングファームを作った。コード書きに1カ月、データの移行に3カ月かかった。

5年から10年はこのシステムで

将来について。MySQLはいろいろと使われているが、まだクラスタリングの準備は出来ていないと思うので、5年から10年はこのシステムで行くと思う。自動化シャーディングは使えるテクノロジとなっていくだろう。

fig

ここでわれわれが学んだこと「Lesson Learned #3」。チームが200人など大きくなるとコミュニケーションが難しくなり、楽しくなくなってくるので、カルチャーとして楽しい雰囲気にするのは大事だと思う。

fig

当日のスライドへのリンク

QCon Tokyo 2013

あわせて読みたい

MySQL RDB クラウド




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本