クラウドでのデータ設計方法
『日経 SYSTEMS』の2010年10月号から、マイクロソフトの萩原正義さんによる『クラウドの設計セオリー』というコラムが連載されています。
クラウドがこれまでのエンタープライズシステムと比較して技術的な不連続性があることなど、クラウドにまつわる技術的な疑問とその答えが整理された、非常に読み応えのある連載です。
先日、2010年12月号の『クラウドのデータ分析設計法』というコラムを拝見させていただいて、自分の中にあったクラウドでのデータ設計方法の疑問点・不明点をきれいに整理することができました。
その整理できた内容を忘れないよう、備忘録として残しておこうと思います。
※全てを網羅した内容にはなっていません。
私自身が理解し易いようにするために、意図的に記述を省いているところがあります。
1.概要:データ層のパラダイムシフト
現在のエンタープライズシステムで主流となっている、いわゆる「3層システム」(UI層−ビジネスロジック層−データ層)では、データ層に RDBMS を使用しています。
RDBMS は、データを表形式で扱えるという理解容易性がありますが、
スケールアウトがしづらく(今は Oracle RAC とかありますが)、
システムのボトルネックになりがちという問題もあります。
一方クラウドでは、データ層がシステムのボトルネックとならないよう、データ層がスケールアウトできるようになっています。
これを実現するために、KVS などの新しいデータストア技術が利用されています。
つまりクラウドでは、これまでの RDBMS とは異なり、データ層をスケールアウトできるようにデータを設計する必要があります。
2.そもそもの疑問
では、データ層をスケールアウトできるようなデータ設計として、具体的に何をどのようにすれば良いのでしょうか?
良く耳にするのが、以下のような事項です。
- データの非正規化を行う(JOIN ができない・しづらいため)
- ロードバランスを考慮する(データが特定箇所に集中するとボトルネックとなるため)
- システムと近いところにデータを配置する(latency を小さくするため)
なのですが…これらを具体的にどう実現すれば良いのかが分からずに困っていました。
その答えが、上記の連載にまとめられていました。
以下、順に整理していきます。
3.分析:基本は同じ
分析のスタートとして、ユースケースとE−R図を作成するという基本は同じです。
但し、これらの活用方法に、これまでと異なるところがあります。
具体的には、データの垂直・水平方向にどう整理するかを判断するために用います。
具体的に見ていきましょう。
3.1.垂直方向のデータ整理
「垂直方向」とは、表形式をイメージしたときの垂直方向、つまり列レベルでのデータのことです。
クラウドでは、各データが同じサーバにあるとは限らないため、JOIN は避けるべきです。
そのため、JOIN しなくても良いように、データを意図的に非正規化します。
具体的には、E−R図に基づいてデータを「マスタ」と「トランザクション」に分け、
「トランザクション」側に「マスタ」の参照するデータを項目として持たせるようにします。
こうすれば、「マスタ」と「トランザクション」との間で JOIN を発生させずに済むようになります。
「マスタ」のデータが「1箇所1事実」ではなくなってしまいますが、「マスタ」は更新されることが少ないため、
必ずしも「1箇所1事実」でなくても良いということが、この考え方の背景にあります。
3.2.水平方向のデータ整理
「水平方向」とは、表形式をイメージしたときの水平方向、つまり行レベルでのデータのことです。
特定の行(レコード)へのアクセスが集中すると、特定のサーバへの負荷が高くなり、
ひいてはシステム全体のパフォーマンスの劣化につながります。
そのため、使用頻度の高い行(レコード)を、各サーバへ分割配置できるようにします。
具体的には、ユースケースで優先度・使用頻度の高いデータを特定し、
これを各サーバへ分割配置するようにします。
データの分割方法としては、以下のものがあります。