2010年9月5日日曜日

librahackに思うこと(動的コンテンツ生成方式について)

Librahackの一件を聞いて、サイトの開発・運用に携わる人の多くは「自分のサイトは大丈夫かな?」と心配になるだろう。実は私が現在運営しているサイトでも、同じような問題を抱えている。当該サイトの詳細はセキュリティ対策上、詳しく説明できないが、その概要を次のとおりまとめてみた。なお、本稿は技術的な内容なので、分からない・興味がない人は無視してください。逆に間違った個所があれば指摘いただけると幸いです。

さて、サーバーサイトで動的に内容を生成して出力する方式は「CGI方式」「Webサーバのモジュール方式」「Webアプリケーション方式」の3方式に大別できる。

まずは1番目のCGI方式から。Web技術の黎明期ではメインの方式だった。ユーザーからのリクエストに対して動的に結果を出力する場合、Webサーバは別のプロセスを起動して処理を行い、その結果をユーザーに返すのがCGI方式である。手軽に動的コンテンツを構築できる半面、ユーザーから要求を受け付けるたびにプロセスを起動するため、、大量のアクセスが発生したときに負荷が大きくなる欠点があった。この方式では、開発の手軽さからPerlが好まれて使われていたので、CGI=Perlと誤解する人は多かった(私もそうだった)。

そして、CGI方式でのプロセスの起動のオーバーヘッド(無駄)をなくして効率化を図ったのが2番目のWebサーバのモジュール方式である。Webサーバにプログラムの実行環境をモジュールとして組み込んでおけばプロセスを起動する必要がなくなるので、処理の高速化・大量アクセス時の安定性が増した。Web開発で現在よく利用されているPHP・Ruby・Perl・Pythonでは、この方式が採用されている。また、プログラム(スクリプト)をコンパイル(バイトコード化)してメモリに保持することで、さらなる高速化を目論む場合もある。

さらに効率化を実現するのが、3番目のWebアプリケーションサーバ方式である。Webサーバは動的な処理を行わず、別に起動している処理専門のサーバ(アプリケーションサーバ)にユーザーからの要求を受け渡す。アプリケーションサーバは、ユーザーの初回訪問時にインスタンスを立ち上げ、ユーザー固有の情報をメモリ上に保持しておく。同一ユーザーの2回目以降のアクセスにはインスタンスに保持しているデータを再利用するため、わざわざデータを外部ソースから読みだす無駄がなくなり、処理の高速化が実現できるという具合だ。Javaを使った開発ではWebアプリケーションサーバが利用される。

以上3種類の方式が存在するが、いまどきCGI方式を使うことは少なく、主にWebサーバのモジュール方式かWebアプリケーション方式が使われる。

さて、この2方式の最大の違いは、ユーザー固有のデータをメモリ上に保持しておくか否かにある。Webサーバのモジュール方式では、ユーザーに結果を送信してしまえばデータは破棄されてしまうので、非効率な半面、開発がシンプルになる。逆にWebアプリケーション形式では「インスタンスが誤って他のユーザーのデータを取得する」「メモリに残ったインスタンスが暴走する」といった不具合が発生しないよう、慎重に開発する必要がある。

いろんなWebサイトを見る限り、今回のLibrahackの舞台となった図書館サイトでは「Webアプリケーション方式」が採用されていたが、その作りに不備があったらしい。このサイトでは、ユーザーから要求が発生するたびにインスタンスを立ち上げてデータベースに接続していたが、ユーザーに結果を返した後もデータベースの接続を解放しなかったようだ。そのため、大量のアクセスが発生すると大量のインスタンスが生成されてしまい、それぞれがデータベースの接続を行うため、データベースは行列ができたラーメン屋のようにあわてふためいて処理ができなくなってしまったのが原因と考えられている。このあたりの動きをFlashアニメにしたサイトがあるので、興味のある人はご覧あれ。

私が管理しているサイトはPHPを使ったWebサーバのモジュール方式なので、少なくともLibrahackのように「サーバの中がデータベースに接続したままのインスタンスであふれかえっている」という現象は発生しない。ただ、一部のページではPHPからUnixコマンドを呼び出しているため、複雑な処理条件でアクセスが多発すると大量のプロセスが起動し、サーバの負荷が高まってサイト応答に遅延が生じる。現在、この問題を解決すべく奮闘しているのだ。

Librahackの件で、図書館サイトの開発元を非難する声があちこちから上がっているが、膨大なコスト・専門知識・経験をもってしても大量アクセスでダウンしないサイトを構築するのは至難の業だ。実際、MixiでもMemcachedの不具合によりサービス停止に追い込まれたことがある。Web開発・運用に携わる人は、Librahackを対岸の火事として傍観せず、いま一度自分のサイトに不備や脆弱性がないかを確認すべきだと思う。

2 件のコメント:

  1. 岡崎・図書館・ブログでの検索でたどり着きました。

    MDIS を非難している声のほとんどは、「少量アクセスでダウンしたサイトを構築した」ことよりも、不具合を隠蔽し無実の人の逮捕・20日もの身柄拘束につなげたことを非難しているように私は読めます。

    返信削除
  2. コメントありがとうございます。本件に関して様々な意見がでているかと思いますが、「大量アクセスでダウンしたサイトを構築した」こと自体に対する非難もあちこちで確認しています。あと、はてぶやヤフーニュースのコメントでもMDISの技術力を非難するコメントを多数見ています。
    http://neta.ywcafe.net/001121.html

    本投稿で私がいいたいのは、Web開発に携わっていれば同様の不具合を出す可能性は皆無ではないため、「MDISはダメだけど自分のサイトは大丈夫」と過信してはいけない、ということです。無実の人云々、という話は本投稿の主旨とは関係ないことをご理解願います。

    返信削除