どこまでも拡張できる超大規模システムを目指して

"THE MAGIC ROUNDABOUT"というものがあるそうで、ラウンドアバウトがいくつも連結しています。


大きな地図で見る

運転するとなれば、これはちょっとびびりますね...

携帯コンテンツ変換のラウンドアバウトでは、大規模システムをターゲットした製品です。大規模システムに要求されるシビアな品質と拡張性こそ、ラウンドアバウトが実現している比類なき特性です。


大規模システムにおいては、まず拡張性です。システムが拡張できないことには大規模にそもそもなりません。大規模システムは、トラフィックが多く、アプリケーションが複雑です。サーバーの台数も種類もネットワーク機器も多く、回線も複雑です。このようなシステムにミドルウェアを導入しようとすれば、機能以外のシステム要件は次のようになるでしょう。

・ネットワークに影響しないこと、アプリケーションに影響しないこと、他のミドルウェアに影響しないこと、パフォーマンスに影響しないこと、システムキャパシティに影響しないこと

さらに言えば、

・導入が簡単であること、運用業務が増えないこと、スキル習得が必要がないこと、エラーを起こさないこと、止まらないこと

などです。「しないこと」は「影響が軽微または無視できる範囲であること」ですが、システム全体や運用に影響を与えすぎないことが、コストとサービスレベル両面から求められます。特に携帯コンテンツ変換では、導入動機がアプリケーション要件よりもコスト要件なので、メリットを相殺してしまわないことが重要です。

ラウンドアバウトは設計にあたり、もっとも注意したのが当にこの点です。絶対に実現しなくてはならないと考えたのが、

・一段のロードバランサの下でサーバを並列に並べることができる

という点です。ここには従来の製品には２つの問題点があります。１つはサーバ型なのでロードバランサが二段（変換サーバの前と後ろ）になること、もう１つがセッションを使ってしまうので現実的には１台しかアクティブにならない問題です。これでは大規模システムには利用できません。

ラウンドアバウトはApacheモジュールとして実装したことで、ロードバランサ一段だけで済みます。またセッションを使わないポリシーを追求することで複数サーバが同時にアクティブになります。

最大の関門だったのは、マルチ画像変換をセッションレスで実装したアーキテクチャーです。我々はラウンドアバウトの目玉機能として、「自動容量調整」を当初から考えていました。携帯サイト開発において常にトラブルのものである画像制作のレギュレーションをなんとしても排除したかったのです。そして、１ページ中に配置された画像を全て自動でキャッシュに押し込める技術は世の中に存在していませんでした。１つ１つの画像は別々のリクエストで来るので、これをロードバランサの下で別サーバにリクエストされれば、１ページ内としての計算をやり遂げることができません。つまり、同じサーバに振り分けてセッション管理すれば実現ができそうです。

しかし、我々のポリシーである「セッションは使わない」という中で設計を工夫し遂に、セッションを使わずに画像が別々のサーバにリクエストしても動作することを実現しました。これにより、ラウンドアバウトでしか出来ない生産性と運用性の向上を実現しながら、大規模システムに使えるシステムとなりました。ラウンドアバウトは何個でも並列な並べることができ、PCサイト同様にサーバを増やすだけでシステムキャパシティを増やすことの出来る唯一の製品となることができたのです。

ラウンドアバウトが目指している大規模システムをターゲットとして取り組んだ特性は、これまでのエントリーも含めてまとめると、

・ロバストで止まらない、エラーが起きない
・構造的に高パフォーマンスであり、限界速度
・メモリ消費が少なく、ApacheWebサーバと同じレベルの安定動作
・ロードバランサの下で何台でもサーバを並べられる拡張性

となります。ラウンドアバウトは大規模システムのシビアな要求に応えることのできる製品なのです。そして付け加えておけば、当然これらの特性は小規模システムにも大きなメリットをもたらすことができます。