いきあたりばったりのアーキテクチャと教訓

2011年5月18日

データベースの間違った使い方10項目」という記事が少し前に話題になっていました。そこで紹介されていたスライド「Architecture by Accident」(いきあたりばったりのアーキテクチャ」の中で、アーキテクチャが少しずつ複雑になっていく様子を示した図がありました。

これがいかにも実際にありそうな内容だったので、紹介したいと思います。

いきあたりばったりのアーキテクチャの例

最初はシンプルなWebアプリケーションとしてのアーキテクチャから始まります。

fig

負荷が増えてくるので、アプリケーションサーバを増設。

fig

データベースの負荷も増えてきたのでレプリケーション。

fig

さらに負荷を減らすためキャッシュを採用。

fig

インデキシング専用のサーバも追加。

fig

APIの提供も始めたのでAPIサーバも用意して。

fig

ロードバランサー/リバースプロキシを前段に入れて。

fig

スレーブを増やしたり、認証サーバを追加したり。

fig

スライドの作者であるGleicon Moraesは、これらの図を示した上で、リレーショナルデータベースはガムテープのようにつぎはぎで使えるような万能薬ではない。シャーディングや非正規化などは検討すべきよい選択肢であり、またリレーショナル以外のデータベースも選択肢としていれるとよいだろうと説いています。

そして次のような「リレーショナルデータベースの間違った使い方10項目」を示しているのです(訳は前述の記事「データベースの間違った使い方10項目」から)。

スケールが2桁かわるときにはデザインを考え直す

大規模なシステムをつねに開発し続けてきたグーグルは、過去の経験から「スケールが2桁変わるときには、オリジナルデザインをもういちど考え直した方がよい」と考えているそうです(参考:グーグルが構築した大規模システムの現実、そしてデザインパターン(4)~デザインパターン編)。

一方で、トラフィックの急速な増大に対応しようとMySQLからCassandraへと大胆な切り替えを計画していたTwitterは、昨年の夏にCassandraの本採用を断念し、MySQLのシャーディングによるシステムの継続を選択しています

Facebookは、大規模処理のためにNoSQLデータベースのCassandraを開発したにも関わらず、新サービスの基盤に選んだのはHBaseでした

日本に目を向けてみれば、Mobage(モバゲー)で知られるDeNAが大規模なMySQLの運用を実現するために、memcachedより高速なHandlerSocketを開発したり、自動フェイルオーバーのための仕組みを開発するなどしてきました。

成長するシステムにとってなにが最適なアーキテクチャなのか、デザインの見直しはつねに求められていますが、現実にはそれを実現し、うまく動かして行くのは容易なことではなありません。そこを突破できたサービスだけが人気サービスとして利用者に快適に使ってもらえるようになるわけです。

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : NoSQL , リレーショナルデータベース



≫次の記事
EPUB 3、ファイナルは6月以降にずれ込む模様。ドラフト第3版公開
≪前の記事
グーグル、NoSQL軽量ライブラリ「LevelDB」を公開。ChromeブラウザのIndexedDBとして採用

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


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



Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus