快適な交差点→安定して高速な変換システムを目指して①

パリの凱旋門はもしかしたら一番有名なラウンドアバウトかもしれません。


大きな地図で見る

そこでも、交通量が増えてくると、ノロノロの渋滞も起きるようです。



携帯コンテンツ変換のラウンドアバウトでは、このようなことが無いように設計・実装されています。


ラウンドアバウトでは、システムのパフォーマンスと安定性は表裏一体、という考えに基づいた設計・実装をしています。優秀な実装のソフトウェアであれば、トラフィックが少ない時にパフォーマンスが良く、扱うケースが少なければ高い安定性を維持できることでしょう。しかし、ラウンドアバウトに要求されていることは、TV連動や携帯メール一斉配信のような極端なピークが発生し、豊富な画像が配置された言語不定の入力を全携帯端末に配信するような非常に複雑な処理を、高いパフォーマンスと安定性で実現することです。

■Apacheモジュールとして実装した理由。それしかないから。

ラウンドアバウトはミドルウェアとして、究極的にはシステム中にその存在感があってはならないと位置づけられます。なぜならミドルウェアが少しでもユニークな顔を出すことは、即ちシステムの制限となるからです。（実現できるかどうかは別として）変換システムが機能する場所は、アプリケーションの中・既存のミドルウェアの中、ネットワーク中、ブラウザの中の４つです。ブラウザは変更できず、アプリケーションは適用範囲を狭くします。残る、ミドルウェアとネットワークの違いは、システムへの影響度とパフォーマンスです。となれば、システムに影響することなく、圧倒的にパフォーマンスで有利なミドルウェアでの実装を選択しない理由はありません。

こうして、ミドルウェアとしてWebサーバーのデファクトであるApache（しかもオープンソース）での実装に決定することで、パフォーマンス確保の条件が１つ整いました。

■言語変換でツリーを構成せず、画像変換を機種やURLに依存せずに極小化する

１つ１つの重要な機能についてもパフォーマンスが最大限考慮されています。製品HPにありますが、言語変換で構造解析を行っていないのは、どんな入力も受入可能な柔軟性とともに、パフォーマンスを確保するためです。また画像変換において機種や端末に依存させなかったのも、実質的にキャッシュ数を減らしてHIT率を高めてパフォーマンスを出すことと、バッチ併用による「運用によってもリスクを回避できて」パフォーマンスを確保するためです。こうした、１つ１つのアーキテクチャーを既成概念に囚われず、根本から設計することでパフォーマンスが出る理由を積み重ねています。

（次回に続く）