スケーラビリティをとるか、性能をとるか--トレードオフを考える

文:Justin James(TechRepublic) 翻訳校正:石橋啓一郎
2007-12-18 08:00:00
  • このエントリーをはてなブックマークに追加

 少し脱線してしまったが、これで私の言いたいことは分かってもらえただろうか。

 スケーラビリティ、堅牢性、相互運用性、そして将来の拡張性のために作られたn階層のウェブアプリケーションにも同じことが言える。データベースに新しいレコードを挿入する要求を行うクライアントを想像してみよう。

  1. 負荷分散されたHTTPサーバは、要求を受信し構文解析して、その要求をどのアプリケーションサーバクラスターに送るかを判断する。
  2. アプリケーションクラスターはそれを受信し、プレゼンテーションレイヤのレベルで処理を始める。その要求がレコードを挿入するものであることを「理解」し、SOAP要求を作成してそれを処理するビジネスロジックレイヤに送る。
  3. ビジネスロジッククラスターはその要求を受け取ると、他に重複した列を挿入しようとしている要求がないことを確認する必要がある(「送信」ボタンがダブルクリックされていないか?)。このため、自分自身と他のすべてのクラスタのメンバに対して、共有メモリシステムを通じて同じ処理をしていないかを確認する。もしそれが起こっていれば、共有メモリに「今XYZを行っているのは自分であり、それを処理しないように」というメッセージを置く。ビジネスロジックレイヤは行を挿入するためのSOAP要求を作成して、データアクセスレイヤに送る。
  4. データアクセスレイヤはその要求を受け取り、それを開き、どのストアドプロシージャを使うかを判断し、TCP/IPのパイプを通じてそのストアドプロシージャを呼び出す。
  5. データベースはその要求を受け取り、ストアドプロシージャを実行し、呼び出し側に成功したことを報告する。
  6. データアクセスレイヤは状態を受け取り、SOAP要求に対する応答を通じて成功したことを報告する。
  7. ビジネスロジックレイヤは成功したという通知を受け取り、共有メモリに対して処理が終わったことを報告し、場合によってはもう少し処理を行い、プレゼンテーションレイヤに成功したことを伝えるメッセージを返す。
  8. プレゼンテーションレイヤは「OK」のメッセージを選択し、それを返す。

 そして、この例はメッセージの待ち行列処理などを省いた単純なものに過ぎないのだ。

 こうしてみれば、スケーラビリティと堅牢性がいかに性能を悪化させるかがわかるだろう。最終的に、1行挿入するために8つのトランザクションが起こっている。これは、1つのプロセス、1つのサーバの1つのスレッドの中で直接データベースとやりとりする、昔のASPやJSP、PHP、Perlスクリプトなどとは大違いだ。一方は全体として消費するメモリ、スタック空間は少なく、呼び出しスタックも小さく、サーバ間通信やネットワークの遅延の心配もない。もう一方は、バイトやビットの巨大なスパゲッティネットワークを持つ必要がある。

 しかし、これは言っておかなくてはならない。正しく作られれば、n階層アプリケーションは必要なだけの資源を加えることができ、堅牢で、99.999%を達成することができるという点では、スケーラブルなものになる。しかし、それには大幅に増した複雑さと要求ごとに大量の資源を利用するという代償が伴う。唯一の選択肢は、私が知る限り、すべてのものを1つのハードウェアに収めておけるメインフレーム環境しかない。

 毒は注意して選んだ方がいい。

この記事は海外CNET Networks発のニュースをシーネットネットワークスジャパン編集部 が日本向けに編集したものです。海外CNET Networksの記事へ

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]