Top▲
マーリンアームズ サポート   翻訳   コンサル   講座   アプリ   コラム

スケーラブルWebサイト    Cal Henderson著    武舎広幸+福地太郎+武舎るみ訳

まえがき

表紙画像 私が初めて作ったウェブアプリケーションは「Terrania(テラニア)」というものでした。参加者が用意されているカスタマイズ機能を使って自分の仮想生物を作り、それが仮想世界で成長していく過程を楽しむゲームサイトです。仮想生物は仮想世界を歩き回り、植物(またはほかの参加者が作った仮想生物)を食べ、闘ったり交尾をしたりします。ゲーム参加者のもとには、自分が作った生物のその日の行動内容を知らせるメールが1日2回届きます。

これをウェブアプリケーションと呼ぶのは少々「拡大解釈」かもしれません。当時は私もそんな風に分類してはいませんでした。このゲームの中核は、1台のマシンで動くC++で書かれたプログラムで、そのプログラムがデータをたったひとつの単純なファイルから読み込み、1回分のゲームに関わるすべてを処理し、最後にすべてをたったひとつのファイルに保存していました。このゲームを作り始めた頃、このゲームのアーキテクチャにおいて、実行ファイルは当然のごとくサーバ側に属していました。当時、ネットワークを介してデータを交換するプログラムを作るというのは大変な作業で、サーバとクライアント間で文字列を交換するだけでもコードを山ほど書かなければならないのが普通でした(あの頃は.NETなどありませんでしたから)。

インターネットの誕生によってアプリケーション開発者は、ネットワークを介してコンテンツを提供するための、共通プラットフォームを獲得したのです。このプラットフォームにおいては、クライアント/サーバアプリケーションの扱いの難しい部分は出来合いのものに任せることができ、コンテンツだけに注力して開発が行えます。肝心な機能を提供するサーバ側に精力を注ぎ、クライアントの方はサーバに比べればごく簡単にHTMLで作ってしまうことができるようになったのです。Terraniaのうち、従来ならクライアント側に属していたはずの要素がサーバ側の要素となり、フラットファイルにアクセスするだけで済むようになりました。クライアント「アプリケーション」の大半のページは、ファイルをメモリにロードし、参加者が大事にしている仮想生物を解析し、静的な情報の必要な部分をHTMLで表示するものでした。新しく生物を作るときには、第2のファイルの最後にデータを追加し、これをサーバが実行のたびに拾って処理し新しい生物をゲームに加えます。成長の様子を知らせるメールも含めて、ゲームの処理はすべてサーバ側のコンポーネントが行いました。サーバ側のクライアント用インタフェースは単純なC++のCGIアプリケーションで、ソースコードにして200行から300行程度、ゲーム用のデータファイルを解析を行うだけのとても単純なものでした。

このシステムはかなり満足のいくものでした。限界を思い知らされるような場面に出くわすことがなかったので、限界を意識しなかったのでしょう。インタフェースに双方向性が欠けていることは大した問題ではありませんでした。ゲームの設計がそもそもそういうものだったからです。参加者は最初に生物を作るときにデータを書き込む必要があるだけで、あとは読み込みしかないゲームでした。もう一点、表面化しなかったのが並列処理の問題です。Terraniaはほとんど読み込み専用のプログラムだったので、参加者が何人同時にページを作っても大丈夫でした。書き込みはどれもファイルへの追加にすぎず、処理時間もかからなかったため、負荷が重すぎて処理できない状態に陥ることもなかったのです。また、偶然2人の参加者が同時に書き込みと読み込みをしてしまう事態が起こるほど参加者の数も多くはありませんでした。

それから2、3年後、私はTerraniaよりもウェブアプリケーションと呼ぶにふさわしいものに関わりました。英国のメディア企業で働いていたとき、Groupee社のUltimate Bulletin Board(UBB)で作ったメッセージボードのHTMLの出力を修正してくれと頼まれたのです。UBBはPerlで書かれており、CGIとして機能しました。利用者のアカウントや、ディスカッションを構成するメッセージなど、アプリケーションのデータは、専用のフォーマットを使って単純なフラットファイルに保存していました。ページによっては、このフラットファイルから読み込まれるデータからその場で動的に生成されました。また、ディスカッション部分のように、アプリケーションがHTMLコードを生成して必要に応じてファイルに書き込んでいたページもありました。表示に必要なものをディスクに保存してしまうというこの技術は、ブログのような、書き込みに比べて読み込みの頻度が圧倒的に多い状況では現在でも使われています。このような状況では、表示用のページをその場で生成するコストが、(1回あたりで比較すると、それよりはるかに処理速度の遅い)ファイルをディスクに書き込む作業のコストを上回ってしまうのです。

UBBでよかったのは、それがスクリプト言語のPerlで書かれていた点でした。ソースコードをコンパイルする必要がないので開発のサイクルが大幅に短縮でき、待ち時間なしで、あれこれ試すことがはるかに簡単にできるようになりました。ソースコードは3つのメインファイルに整理されていました。利用者が実際にリクエストする「エンドポイント」用のスクリプトと、ユーティリティ関数の入った2個のライブラリファイルです(ubb_library.plとubb_library2.plの2つです。冗談ではなく)

コマーシャル関連のクライアント2、3社を相手に、UBB絡みの仕事を少し経験したあと、メッセージボードの「ハッキング」をしているグループに足を突っ込みました。既存のメッセージボードソフトに新機能を追加するために自分の時間を費やしている一風変わった人々のグループです。結局私は、ある男 ― その後、Infopopのプログラマーとなって、UBBの次のバージョンを作ることになる男 ― とともに「UBB Hackers」というサイトを立ち上げました。

初期の頃のUBBは並列処理が大の苦手でした。プラットフォーム間で互換性がなく(ターゲットプラットフォームのひとつである)Windowsでは動かないファイルロックのコードに依存していたのです。たまたま2人の利用者が同じスレッドに同時に答えたりすると、データの一部が失われてしまうことがあったのです。システム当たりの利用者数が増えるにつれて、データの破損と混乱が起こる可能性が増大していきました。アクセスの多いシステムでは、HTMLファイルをディスクにレンダリングすると、たちまちファイルの入出力が遅くなります。ここで講じるべき次なる対策は、今考えれば「明白」と思えるのですが、当時はそうではありませんでした。

ウェブアプリケーションの世界を大きく変えたのがMySQL 3です。これが登場する以前は、今のようにウェブアプリケーションのデータの保存にデータベースが簡単に使える状況ではありませんでした。既存のデータベース技術は、(Oracleのように)値段が法外に高いか、(FileMakerのように)速度が遅くて扱いが難しいか、さもなければ(PostgreSQLのように)設定と保守が途方もなく複雑だったのです。しかしMySQL 3が登場してからは、そんな事態も変わり始めました。PHP 4が普及し始め、phpMyAdminプロジェクトもすでに始まっていました。phpMyAdminプロジェクトによって、ウェブアプリケーションの開発者は、FileMakerの珍妙なビジュアルデザインを用意しなくても、コマンド行で操作するための難解なSQLの構文を知らなくても、データベースを活用できるようになったのです。私は、テーブルを作ったり、新ユーザーにアクセス許可を与えるのに使ったりするSQL文を今でも正確に覚えていないのですが、もう覚える必要もないのです。

MySQLの登場でアプリケーション開発者にもたらされたのが並列処理機能です。読み込みと書き込みを同時に行ってもデータの破損が起こらなくなったのです。MySQLが改良されるにつれて、並列処理機能はさらに向上し、フラットファイルを使ってディスクにレンダリングする方法よりもはるかに作業効率が高まりました。インデックスを使うことで、データを任意の組み合わせや順序で選択できるようになりました。データを全部メモリに読み込み、データ構造の操作をする必要がなくなったのです。これによって果てしない可能性が生まれました。

その状況は現在も変わっていません。

スケーリング、機能性、相互運用性といった側面について、ウェブアプリケーションの可能性は今なお拡大をつづけています。APIが爆発的な勢いで続々と公開されるようになったことにより、複数のアプリケーションを「マッシュアップ」して新たなサービスを作り出す可能性が生まれ、サービス指向の考え方が普及してきました。こうしたAPIサービスのモデルが私たちに示しているのは、柔軟性に富み拡張性の高いアプリケーションを低コストで設計する明確な方法です。

Flickr、Friendster、MySpace、Wikipediaなど、現時点で規模も人気も最高レベルのウェブアプリケーションは、1日に何十億件というクエリーに応答し、膨大なデータセットを持ち、廉価なハードウェアから構成される巨大なハードウェアプラットフォームで動いています。Googleは巨大なアプリケーション群の「イメージキャラクター」的存在ですが、その一方で、ほかの、より規模の小さな(しかしそれでも巨大な)アプリケーションは、「Web 2.0」と呼ばれるようになった次世代アプリケーションの「お手本」となりつつあります。対話性が、ネットワーク容量が、APIの公開の規模や速度が増すにつれ、次世代のウェブアプリケーションの開発がさらに面白いものになっていくことでしょう。