[37signals] Moore氏はシャーディングを蹴飛ばす

(原文: Mr. Moore gets to punt on sharding)

シャーディングは大規模データベースをより小さなものに分割するデータベース構築手法だ。でかい鉄のかたまりのような１台のマシンに１００万人ぶん格納する代わりに、より小さな個別の１０台のマシンに１０万人ぶんづつ格納する。

この手法については一般に、必要に迫られるまで手を出すな、と言われている。Martin Fowler（訳注: リファクタリングでおなじみ）が分散オブジェクト設計の第一法則として「オブジェクトを分散させるな」と言っているのと似たようなものだ。シャーディングはいまだに他の手法と比べて難しいし、支援ツールは貧弱だし、あきらかにセットアップ作業が複雑化する。

まぁ、選択の余地がなくなる日が来るのは避けられないのだということは常に意識してはいる。上方向への拡大（訳注: マシンのパフォーマンス向上などのことか）について打つ手がもうないからという理由で、素直にシャーディングしなければならなくなるかもしれない。でも、その日がくるのは遠い未来のことに思える。

キャッシュをでかくすれば読み込み性能も上がる

今やみんなが256GBのRAMが載ったマシンを入手出来るようになったという現状のおかげで、ある面、読み込み性能の問題は片付いた。私たちはちょっと前にBasecampデータベースサーバのRAMを32GBから128GBに拡張したが、これ以上拡張するつもりはない。

マシンはメモリスロット上限までRAMを積んでいたし、当時128GB以上のRAMはアホほど高くついた。だが今や256GBのRAMはお手頃価格だし、そのうち512GBのマシンも手に入りやすくなると考えている。

そういうわけで、ムーアの法則に従ってこんな風にマシン性能を飛躍的に向上させることが出来るうちは作業内容を全てメモリに置いておく事が出来るし、この先もうまくいくだろう。たとえ頭打ちになったとしても、シャーディングに手を出す前に能動的な読み込み専用スレーブマシン（訳注: レプリケーションなどに代表される負荷分散手法）を使うという手がある。

書き込みの方がより難問だ

もともと、読み込み性能が原因でシャーディングせざるを得なくなるということはない。書き込み性能が原因なのだ。私たちのアプリケーションでは未だに読み書きの競合が深刻な問題で、他の問題はそれほどでもないのだ。

だが、Fusion-IO社の120k IOPS（訳注: Input Output Per Secondのこと。スループットではなく実際の読み/書き回数を示す）を実現するioDriveのようなSSDが出てきた事により、シャーディングせざるを得なくなる状況に追い込まれるまでは、技術の進歩のおかげで今回もまた救われそうだ。

シャーディングを蹴飛ばせ

そういうわけで、シャーディングする理由なんてどこにあるんだ？ 私たちに関して言うならば、ここ数年というもの状況は変わっていない。複雑税（訳注: 複雑性の増大に伴うツケ）とは無縁なのだ。シャーディングには万策尽きた時は素直に採用するしか無いという程度の利便性しか無い、というのは言い過ぎだが、その見返りはまだ充分とは言えない。

現実面で私たちが本当に困っているのは、MySQLで構築した巨大なテーブルからデータベーススキーマを掘り起こす（訳注: いわゆるマイグレーション。データベース移行・変換に伴う作業）のにとてつもなく時間がかかってしまうという点だ。巨大なテーブルに対する項目の追加・リネーム・削除を行うのを避けるするために手の施しようがないほど肥大化した、大企業にありがちなデータベーススキーマを避けて自社スキーマに移行しようとすると、直近の問題としてこれが出てくる。えんえんと「メンテナンス中」の表示を出しっ放しにするというのも避けたい。

私としてはMySQLに詳しいヤツがこの問題に関してうまい解決策を考えてくれることを心底望んでるんだけどね。こういった点に関してはPostgreSQLの方が遥かにいいよと聞いているので、出来れば比べてみたい。

明日出来る事は今するな

近い将来の技術的進歩が解決してくれるようなことを今すぐ片付けようとするのは無意味だ、というのが私の考えた結論だ。マシンはどんな時代であれ、より速くそしてより安くなるだろうが、プログラミングに関する人員や時間といった資源には相変わらず制限がつきまとうからだ。

将来を見越して早まった最適化を行うためにでなく、ユーザの懸念事項に取り組むための人員を追加することに資源を割く事が出来れば、その近い将来というものが遂にやってきた暁には、ビジネスにおいてチャンス到来ということになるわけだ。

---

訳者コメント:
UOプレイヤーには、アバタールがぶっ壊したモンディンの「不死の宝珠」のかけら、ということで馴染み深いシャードの概念ですが、分散データベース手法としてのシャード分割というのは、レプリケーションやマルチマスタによる負荷分散とは毛色が違って「アプリケーションレイヤでなんとかする」という発想が感じられて面白い。

ざっとみたところ手法は２つ。

1. ユーザAのデータはマシンAに、ユーザBのデータはマシンBに、といったユーザレベルでのシャード分割。UO的と言える。例はこちら。
2. テーブルAはマシンAに、テーブルBはマシンBに、といったテーブルレベルでのシャード分割。リレーション（というかJOIN）と何が違うんだ？という気もする。例はこちら。

まぁDHHの指摘通り、面白いというのと実際に現場で採用するというのは別ものであり、時期尚早じゃない？というのが正直なところでしょう。アプリケーションレイヤで頑張ってパフォーマンス改善するというのはプログラマとしてはうずうずして来るところではありますが、そこをこらえるのも技量のうちということですかね。もっと他にやることあるだろうと。

ちなみに、もしシャードが今年のバズワードになったら、2chのUO板のようにショエードとかシャドーとかシャドルーとか言うヤツが出てくるんじゃないかとか、マ板かUO板か区別つかなくなるな、とか思ってニヤニヤしたですよ。