5. クライアント・サーバシステムを考える

ちょっと、脇道にそれます。

というより、「世界の鳥類検索辞典」は、適当なデータベースを作るための素材であって、それをネタに DB アプリケーションとその運用について、いくつか気になることを検証し、書いてみたい、というのがこの文書の主旨でもあります。

5.1. データベースとアプリケーション

5.1.1. クライアントとサーバ

今回の実装では、WEB サーバ(Apache)、アプリケーションプログラム(Perl の CGI)、DB サーバ(FireBird DBMS)は同一ホスト上で動かしました。

しかし、データベースシステムにおいて、アプリケーションと DBMS は TCP/IP 通信を行っているわけで、同一ホスト上であろうとなかろうと意味も動作も全く変わりません。

これが、「クライアント・サーバ・システム」の本来の意味です。

前章 4.4.4. のプログラムが、実験にちょうど手頃だったので、これを使います。

5.1.2. LAN 上で測定

まず、LAN 上で DB クライアントと DB サーバを分離してみました。

Gigabit-Ether の LAN で繋がれた別のマシンから、DB サーバにアクセスしてみます。

localhost で動かしたものと殆ど変わりません。

この環境での LAN の速度は、ハードディスクの速度を上回りますから、LAN 経由だからと言ってそんなに遅くはなりません。
むしろ、サーバプロセスとクライアントプロセスを別 CPU に分散できる有利さもあります。

では、次に、遠隔地の WAN ではどうでしょう。

5.2. 速さは何で決まる

5.2.1. WAN 経由で

離れた地点にある 2台のマシンを使ってみました。
クライアントもサーバもPentium3/933MHz/memory256MBという古いマシンで、B-フレッツで繋がっています。

同一収容局、同一プロバイダなので、下記の実測値。一般的なフレッツ網としては非常によい環境です。
NTT ビル内のプロバイダのルータで直接折り返しのようです。

  帯域幅:  25 Mbps
  経路:     8 hops
  遅延:     6 ms

実際に、この上で Oracle DBMS を使った一般的なクライアントサーバ型の会計パッケージを動かしていましたが、遅さは感じるものの、不便なく使えます。

テストは次のグラフのようになりました。

LAN より遅くなります。当然ですが。

LAN は 1000Mbps、WAN は 25Mbps。40 倍も速度が違うんですから。
でも、しかし。
この数字で納得しないでください。『システムのウソ』の罠にはまったことになります。

25 Mbps ってじつは凄く速いのです。一昔前の LAN は 公称 10(実測5〜7)Mbps だったのを思い出してください。
抽出件数が 1〜10行程度の時のサーバ〜クライアント間のデータ量は 2〜3KB 程しかありません。
単純計算なら 1ms 程です。なのに、何故 2桁も多く時間が掛かるの？

1000 Mbps と 25 Mbps の差は、この場合の原因ではないのです。
原因を読み違えて、効果のない対策に時間と費用を費やさないようにしましょう。

簡単なことです。
3KB のデータを 25Mbps で転送すると何秒かかるか、軽く暗算してみる手間を惜しまないことです。

5.2.2. 帯域幅を絞ってみる

実験を続けます。

QoS (帯域制御ソフトウェア) を入れて、わざと帯域幅を絞ってみました。
帯域幅を 1/8 の 3Mbps にします。

帯域幅を 1/8 にしても、ほとんど変化はありません。

さらに帯域幅を 1Mbpsにします。

少し変化が見えてきました。
抽出行数100行付近から処理時間が右上がりに伸びはじめました。

これがデータ量によって変わる領域、すなわち帯域幅で律速された部分です。

それ以下の一定速の部分はデータ量の影響を受けていません。これは往復するパケットの個数に依存する領域、すなわちパケット遅延による律速で、パケット遅延が大きいため帯域幅の影響が現れない状態です。

この条件における LAN と WAN の速度差は、帯域幅ではなくて、パケット遅延であることが分かります。

どこのキャリアも、ブロードバンドの売り文句は何 Mbps ! って帯域幅で、パケット遅延にはあまり触れません。想定している用途・ユーザーが違うんです。

さらに帯域幅を 1/64 の 384Kbps まで絞ったのが以下の図です。

回線は無駄に太い？

さて、ここで一般的なデータベースアプリケーションを考えてみましょう。

例えば、経理事務の仕訳入力や伝票参照。
複合仕訳であっても、貸方借方合せて数行の処理が大部分です。

スーパーマーケットやコンビニエンスストアの商品受発注。
ターンアラウンドチェーンストア統一伝票は 1型で最大 6行、2型フォーマットで最大 9行です。

その様な 10行未満のトランザクション処理、問い合わせでは、ブロードバンドの帯域幅は速度向上に全く寄与していないことが分かります。

パケット遅延(往復) 6ms というのは非常に恵まれた環境ですら、それでも帯域幅は 384Kbps もあれば充分だったのです。

このように DB アプリケーションは、帯域幅よりパケット遅延の影響を大きく受けます。
LAN なら、昔の遅い 10Base-T でもこれより1桁低い遅延でしたから、速度低下は感じなかったのです。

5.2.3. もう少し一般的な WAN で

上記の WAN は条件が良すぎるので、もう少し普通の環境で。

遠隔地の ADSL ブロードバンド環境にクライアントを置いて、同じテストをしてみます。
帯域幅は ADSL としては良好な部類です。が、遅延が大きいです。

  帯域幅:   6 Mbps
  経路:    18 hops
  遅延:    41 ms

このネットワーク環境では、クライアント・サーバ型アプリケーションは動作の遅さが目立ち、アプリケーションの作り方によってはイライラがつのる状態になります。

実際にこの環境で、ある業務アプリケーションを動かしたときは、ストアード・プロシジャ化を進めるなどチューニングが必要になりました。

テスト結果は以下のようになりました。

ご覧のように、抽出 1行と抽出 1000行の処理時間差が 2.5倍程しかありません。

こんどは、帯域幅を 1/100 の 64Kbps、つまり ISDN 同等まで絞ってみました。

ISDN と変わらないんじゃ？

傾向はさらにはっきりします。
パケット遅延が大きいので、ここまで帯域幅を狭めても10行以下の範囲では何も変わりません。

このように、小サイズのパケットをやり取りする DB アプリケーションでは、ブロードバンドに変えても、ISDN 64Kbps の時代からあまり進歩していない実感がありました。
それが裏付けられてしまいました。

むしろ、場所によってはパケット遅延の少ない分、ISDN の方が有利でしょう。

ブロードバンドで何が変わったのだろう

インターネットが普及する以前なら、9600bps のモデムで P-to-P 接続だったかもしれません。
光ファイバーの 1万分の1 の速度で。実際、それでもあまり変わらず実用になっていたのです。

5.3. ブロードバンドの光と影

5.3.1. ネットワークは進歩した

夢のような高速化の時代が来た

ブロードバンド環境は目覚ましい進歩を続けています。
帯域幅は広がり、音声・動画など数年前には考えられなかった量のデータがネットワークを流れています。

それはそれで、素晴らしい。

それでも変わらないもの

でも、少量トランザクション処理に関してはどうでしょうか？

金融口座取引、会計仕訳、商品受発注など、ブロードバンドはどれだけ寄与しているのでしょう。

これらこそが、経済活動の基盤であるべきなのに。

ミッションクリティカルなトランザクション処理に関していうなら、20年前のメインフレーム端末の使い勝手からいかほども進歩しているようには思えないのです。

いや、むしろ。
ブロードバンド・バブルのおかげて、プログラミング・ツールもプログラマのスキルも、そしてユーザーの要求も、大量のネットワークリソースを消費する方向に流れています。
条件は悪くなっているかもしれないのです。

5.3.2. もう一つの地方格差

高速道路と…

かつて、地方経済と文化の振興を謳って、高速道路網が地方に延びました。
中央との時間距離の隔たりが解決されて、地方は豊かに……なりませんでした。

その結果は、より一層の中央への集中と地方の過疎化、地域産業の空洞化をもたらしました。

地方の時代、という言葉だけが虚しく響きます。

…そして、ブロードバンド

ネットワークの時代は、地方の時代を予感させました。
ブロードバンドネットワークの普及により、中央と地方の情報格差はなくなると。

しかし、これもより一層の中央集中を招いたように見えます。
ネット通販は、地方都市の老舗の商店街に壊滅的な打撃を与えました。

たしかに、東北地方の片田舎でも 100Mbps の光ファイバー回線が手に入る時代になりました。
しかし、帯域幅は得られても、NTT フレッツ網の中継基地経由によるパケット遅延は、ほぼ距離に比例して増大します。
動画視聴などエンターテイメント分野では同等かもしれない。しかし、ミッションクリティカルな処理に関してはより一層格差は目立つのです。

帯域幅偏重のブロードバンド政策が続く限り、これは変わりません。