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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Dynamic table creation（動的なテーブルの作成）
• Table as cache（テーブルをキャッシュとして使う）
• Table as queue（テーブルをキューとして使う）
• Table as log file（テーブルをログとして使う）
• Distributed Global Locking（分散したグローバルなロック）
• Stored Procedures（ストアドプロシージャ）
• Row Alignment（使われない項目）
• Extreme JOINs（JOIN地獄）
• Your ORM issue full queries for Dataset iteration（ORMによって繰り返されるクエリ）
• Throttle Control（負荷のコントロール）

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

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

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

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

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

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