第3回:IIJ社における分散DB技術「ddd」(1) (1/3)(情報元のブックマーク数)

IIJのdddを使ってクラウド技術を解説

IIJが独自に開発したdddと呼ばれる分散システムを例にとり、その仕組みについて解説します。

dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

クラウドにおけるアーキテクチャの方向性

クラウドコンピューティングでは、ほとんどの場合で後者のスケールアウトの手法がとられています。その理由はスケーラビリティとコストパフォーマンスです。
スケールアウトでは、うまく適合するケースで、ほぼ台数に比例して100倍、1000倍と性能を向上させていくことができます。一方、スケールアップではそこまでの性能の向上は見込めませんし、また2倍の性能を得るのに5倍のコストがかかるようなケースが多く見受けられます。
また、スケールアウトの手法をうまく動作させるためには、多数のマシンを協調動作させる必要があり、従来とは異なる仕組みのソフトウエアを必要とします。この分野は、GoogleAmazonをはじめとした各社が技術開発を続けています。それだけスケールアウトの技術がクラウドコンピューティングの時代において重要な基盤となることを意味しているのでしょう。

dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

キーバリューストア、担当ノードを振り分けてスケールアウト。単機能

キーバリューストアは、RDBMSに比べるとずっと低機能で、基本的にはキーを指定して対応する値を読み書きするということしかできません。そのかわり、キーの値によって担当するノードを振り分けて分散化することに向いており、スケーラビリティを高めることができます。
分散キーバリューストアでは、キーを担当するノードを振り分けるためのアルゴリズムが重要です。dddでは、Amazon Dynamoなどのほかの多くの分散キーバリューストアと同じく、コンシステントハッシュ法(P3参考文献[1][2])と呼ばれるアルゴリズムを採用しています。

dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

ハッシュ関数のみでノードを決めてしまうと偏りが発生するので、対策済み。

コンシステントハッシュ法では、キーの保有数に関係なくハッシュ関数のみにより担当ノードを決めるため、ノードによって担当するキーの数に偏りが生じることがあり得ます。
キーが一様に分布する場合、ノードの担当するキー数は、リング上でのノード間の間隔に依存します。前のノードとの間隔が小さい場合、そのノードに割り振られるキー数は確率的に少なくなります。例えば、図2でノードBがなくなった後のケースを考えると、ノードAの担当範囲がほかのノードに比べてかなり広くなってしまいます。
担当するキー数の偏りを少なくするために、dddではバーチャルノード(virtual node)という概念を利用しています。1台のノードに1つのIDを割り振るのではなく、繰り返しハッシュ関数を適用するなどして 1台のノードに複数のIDを割り振るというものです。

dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

ハードウエアで冗長化するのではなく、アーキテクチャ冗長化。その分ハードウエアが安価に大量に導入できる。

dddではノードのハードウエアコストを低く抑えるために、RAIDなどのディスク冗長化技術は採用していません。そのかわり、より上位のレベルでデータを冗長化して、いつノードが故障して脱退しても全体として問題なく稼働する構成となっています。

dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

screenshot