システムとセッションとパビリオン
というわけで、Webシステムである。あまりに愛地球博のWebシステムがお粗末だったので（しかも実害を蒙ったので）今回はこれがネタ。
今回のことで言いたいのは、世の中の中小企業診断士のように、せめて税金を使って作ったものくらい「Webシステムを診断する人」を作れ。ということ。
一種のオンブズマンだろうか。
それにしても愛・地球博のWebシステムは酷い。こんな通販サイトがあったらあっという間に倒産しているだろう。インターネットに公開されたシステム、特にこういった「人気のものへの予約」では必ず問題となる「大量リクエストに対する設計」ということがされていない。（注：リクエスト→ユーザーによるWebシステムの利用の１単位と数えても可）
この予約システムは、少なくとも
- ログイン
- 週毎の空き状況確認
- 指定日・指定パビリオンの時間帯ごとの空き状況
- 約束事への確認
- 予約実行
と５画面以上の画面を順路として通っていかなければならない。
しかし、混みあっているため、途中でまず間違いなく
https://reserve.expo2005.or.jp/aichiexpo/ReservUpActionLogin.do?meetingStartTime=1210&meetingEndTime=1230&calHoldDate=20050712&pavNo=09101&hostid=h1申し訳ございません
只今、観覧予約システムに大変接続しづらくなって
おります。誠に恐れ入りますがしばらくたってから
もう一度アクセスをお願いします。
We're sorry, but the reservation system is
difficult to access now. Please try again later.
愛・地球博
EXPO 2005 AICHI JAPAN
というような画面になる。当然、しばらく待つと予約埋まってしまうのでリロードしまくるわけで、ますます混雑する。
もちろん「んなもん、しばらく経ってからだったら予約埋まってるから意味無いだろ！！（怒）」という感情的というか、「意味無いことを言っている」という無礼さもシステムの設計としてある種非常に問題（特にそれが税金で作られていることが）なのであるが、今回問題にしたいのは、もっと技術的な問題である。
もちろん、Webシステムはハード面で無限ではないから、「無限の大量のリクエスト」に対してのきちんとした技術的な解は無い。しかし、システムの設計如何で「限られたハードでできるだけ多いリクエストを捌く」ということが決まる。
(ITの)システムを作るというのは、家や建物を建てるのに似ている。ちょっと手元で自分が使う程度のシステムなら、犬小屋を作るのと一緒で素人の日曜大工でも問題ない。
もう少し、何人かで使うシステムなら、普通の一軒家を建てるようなもので、「世の中で使われている普通の方法」を一度経験した人なら、まあみようみまねで作れる。
しかし、インターネットに公開するような何千人、何万人が使うようなものだと、東京ドームやディズニーランド同様に、「そのケースにあったしっかりした設計」を建築家がしておかないと、あまたの利用者に迷惑がかかる。
そして、その昔、「SE：システムエンジニア」という言葉ができた当初は、そういった「システム全体」を、そのシステムの必要条件に応じて最適（に近い）ものにするだけ高度な技術を持った人に与えられた称号だが、最近では新卒でも名乗るほどに軽い称号になった。しかし、システムをきっちり作るというのは、建築家や医者のような技能の領域が必要なのである。
さて話はそれたが、Webシステムについてである。
大量リクエストのような過負荷がかかった場合に、システムが想定以上にパフォーマンスが悪化している場合、「無理しているところ」を疑うのが第一である。この辺は医者に似てると思う（建築家にも？）
さて、Webシステムが「無理しているところ」といえばどこだろうか？
その１つが「セッション」である。と書いても専門用語なので、たとえると「電話が繋がっている状態」である。電話で予約するとき、当然ながら予約センターと電話が繋がっていないと予約はできない。
Webから予約するときも同様である、予約センター側と“繋がってないと”予約の残りを照会したり、予約を入れたりとかができない。
しかし、しかしである、実はWebでは自分たちのパソコンと予約センターは“電話のようには繋がっていない”のである。自分たちがWebブラウザを相手に構いなしに閉じれるのもそのためである。実際にはずっと繋がっている電話というよりは、短い間隔でのメールの送りあいに近い*1。
となると、「電話のようにずっと繋がっている状態」かのようにするために“仕掛け”が必要である。その仕掛けが“セッション情報”であり、Webシステム側では「何分か前までにブラウザで見に来た人」を保持しておく。そして時間切れ(タイムアウトという)になる前にもう一度来た場合には「まるでいままで繋がっていたかのように」次の段階に進むのである。
となると、愛地球博のような仕組みでここが混みあい、色々な人がリロードしつづけたり、ブラウザをたくさん立ち上げるとどうなるか？
ただでさえ多くなる「セッション情報」が、必要の無いものも含めて無駄なものもどんどん溜まってしまうのだ。何しろWebシステム側は、パソコンの前の相手がうまくいっているけど悩んでいるのか、あきらめたのか、それともうまく回線が繋がらないのか、まったく分からないので「ただ待つ」ことしかできないので。
ではどうすれば良かったか？
それは、せっかくログインの仕組みは作ってあるのだから、「ログイン」するところで制限をしっかりかけ、きちんと処理できる人数だけを別サーバーにしてその後の一連の動作へと通して予約処理する。
もちろんこの仕組みでもユーザーはログインの場面で何度も「ただいま混みあっておりますが」になるけれども、ログインするとスムーズに進む。セッション情報はこの間だけしっかりしておけばいい。予約が終了したら、セッション情報も破棄できる。
この方が「無駄セッション情報」が発生しないので、結果的には同じマシンでより多くの処理ができる。
さて、この仕組み、実は考え方としては難しいことでもなんでもない、Webシステム上のことでなければ、実はそれこそ万博が一番当たり前のようにやっていることなのである。そう、「パビリオン」である。
パビリオンではパビリオンに収容できる人数だけを入り口から入れて、後の人は列で外に待たせている。なぜなら、無差別に収容して混乱するよりは、結局のところそちらの方がスムーズだからである。
とまあ、仮にも一日８万人以上の来場者を見込んで（累計1200万人か）のWebシステムなら最初からきちんとシステムアーキテクチャを設計して作ってもらいたい。ですね。
そして、税金の投入が絡むような事業に関わるシステムなら、「そのシステムが投入された金額に見合うだけの成果を挙げているか？」をきちんと診断する組織が必要だと思うのですがいかがでしょう？ 世の中のハコ物は、メディアが「無駄遣い！建物」と取り上げてますが、こういう観点も必要だと思います。そうとう垂れ流されてる気が。
ちなみに僕の前の職場での仕事が「テクノロジーアーキテクト」。こういった「システムのアーキテクチャを技術的な観点で調査・設計する」のが仕事でした。
