長谷川 裕行 （はせがわ ひろゆき）
有限会社 手國堂 代表取締役
http://www.hirop.com/
テクニカルライターとして活躍。プログラミングに関する著書多数、DB Magazineなどにも多くの記事を提供している。 |
前回に引き続き、ネットワーク環境でのアプリケーション開発について考えていきましょう。今回は、アプリケーションの設計と動作テスト時の注意点を取り上げます。
多数のコンピュータが1つの資源に同時アクセスするネットワーク環境では、スタンドアロン環境では発生しない問題も生じてきます。アプリケーションの基本的な設計は大きく変わらなくても、その使われ方が異なるためです。当然、動作テストにも配慮が必要です。
ネットワーク環境がどのようなものかは、いまさら説明するまでもないでしょう。今や当り前の環境です。
ネットワークには様々な形態が存在しますが、パソコンLANではクライアント・サーバー方式が一般的です。クライアント・サーバー方式では、サーバーとなるコンピュータのハードウェア資源を、クライアント・コンピュータが利用します。
スタンドアロン環境では、基本的に1人のユーザーが1つのデータファイルを、1つのアプリケーションからアクセスします。この場合、特に注意すべきことはありません。データベースの扱いも、ADOなどのオブジェクトに任せれば済みます。
しかしネットワーク環境では、1台のサーバーに保存されたファイルを多数のクライアントがアクセスすることになるため、ファイルのアクセスに注意を払わなければなりません。
ネットワーク環境で実行する業務アプリケーションでは、アプリケーションとデータの配置にいくつかの形態があります。
- データもアプリケーションも -
- サーバーに配置 -
アプリケーションとデータベースをサーバーに保存し、クライアントはサーバーに保存されたアプリケーションを実行します。
| ・ |
メリット
アプリケーションとデータの管理が一元化できます。アプリケーションの更改もサーバーだけを扱えば済むため、管理は楽です。
|
| ・ |
デメリット
多数のクライアントからアクセスが集中するとサーバーの負荷が増えるため、処理能力が低下します。
|
データの分析や管理、データベースの保守など、少数のユーザーが利用する場合に向いています。受発注や在庫管理のように多数のユーザーが頻繁に利用する処理では、デメリットが目立ってしまいます。
図１：データとアプリケーションの両方をサーバー側に保存する
- データをサーバーに、アプリケーションを -
- クライアントに配置 -
アプリケーションをクライアントごとにインストールし、共通のデータベースをアクセスします。おそらく、最も一般的な形態でしょう。
| ・ |
メリット
アプリケーションがクライアント内だけで完結するため、ネットワークへの負荷はデータベースのアクセスだけとなります。
|
| ・ |
デメリット
アプリケーションの更改など管理作業を、クライアントごとに行う必要が生じます。特に、全体のバージョン管理に手間がかかります。
|
多数のユーザーが利用する処理に向いています。但しクライアント数が多い場合、データベースへのアクセス頻度が高いと負荷が増大します。在庫管理や顧客管理のように、多くのユーザーが利用するけれど、さほど頻繁にデータが更新されないような処理に向いています。
図２：データはサーバー、アプリケーションは個々のクライアントに保存する
- クライアントにデータのコピーを配置する -
データベースのレプリケーション機能を用い、サーバーのデータをクライアントにコピーして同期を採ります。アプリケーションはクライアントごとに配置します。
| ・ |
メリット
データベースのアクセス自体もその大半がクライアント側で処理され、変更があったときだけサーバーのデータベースが更新されるため、ネットワークへの負荷を最少にできます。
|
| ・ |
デメリット
レプリケーションの設定と調整に手間がかかります。クライアント数、アクセス頻度などから適切な設定を行わないと、必要以上にネットワークに負荷をかけたり、逆に更新結果が即座に反映されないような状態となる場合があります。
また、クライアントごとにアプリケーションとデータベースのコピーをインストールしなければならないので、管理の手間も増えます。 |
多数のクライアントが頻繁にデータベースをアクセスするような処理に向いています。販売管理、予約受付など顧客との頻繁なやり取りを入力するような処理には最適ですが、顧客や商品のデータ管理をするだけのような場合には、無駄が生じる場合もあります。
図３：サーバーに保存したデータのコピーをクライアントに保存する
- 複合型（折衷型） -
データベースはサーバー、アプリケーションはその処理目的に応じてサーバーに配置したりクライアントに配置したりします。
多くのユーザーから頻繁にアクセスされる業務はクライアントにアプリケーションを配置し、データ分析や保守など少数のユーザーが時々利用する処理はサーバーにアプリケーションを配置します。
こうすることで、ネットワークにかかる負荷を適切に分散できます。大規模なデータベースの場合は、さらにデータベースのレプリケーションを利用すれば、効率的な運用が可能です。
- Webアプリケーション -
本稿のテーマから逸脱するので詳しく触れませんが、現在ネットワーク環境ではイントラネットでWebを介してアプリケーションを実行する方式が広まっています。
Webを介することでアプリケーションはブラウザ上で実行されることになり、クライアントのOSに依存しなくなります。しかし現状では、すべてをWebに頼り切ることには無理があります。VBを使ったWindowsネットワークとイントラネット上のWebアプリケーションとを共存させていく必要があるでしょう。
次のコラムを参照してください。
図４：Webアプリケーションはブラウザで実行される
|
イントラネットとWebアプリケーション
インターネットと同じTCP/IPプロトコルを使った局所ネットワーク、いわゆるイントラネットでは、Webサーバーからクライアントにアプリケーションを配信し、ブラウザで実行する形態のアプリケーションが利用できます。言語としては、
VB ScriptやJavaを用いることになるでしょう。
WindowsではIIS(Internet Information Server)上でASP(Active Server Pages)を利用すれば、データベースを利用した業務アプリケーションを、簡単に手早く作ることができます。
Microsoft社の次世代ネットワーク管理環境である.NETでは、ASP+によってさらに記述性の高いコードを書くことも可能です。
みなさんもご存じのように、今後はイントラネットでWebアプリケーションを利用するというスタイルが一般化し、広まっていくでしょう。すると、VBによるアプリケーション開発は不要になるのでしょうか？
Webアプリケーションの利点は、クライアントのOSに関係なくブラウザからアプリケーションを実行できる点にあります。OSの壁を越えられるのは利点ですが、半面オーバーヘッドによる処理速度の低下などの問題も出てきます。
利用するユーザー数も利用頻度も少ない分析業務などは、わざわざWeb化してパフォーマンスを落とすより、Windowsネットワーク上で稼働させた方が効率的な場合もあります。VBの出番がなくなるわけではありません。
今後は、業務の内容や利用形態を考え、適切な環境で実行できるよう設計することも、設計・開発者の重要な仕事となっていくでしょう。
|
ネットワーク環境では、特にデータベースの同時アクセスに配慮しておく必要があります。設計時の注意点を掲げておきましょう。
- 共有と排他制御 -
ネットワーク環境のメリットは、1つの情報を多くのユーザーで共同利用できることにあります。しかしこれを裏返すと、「アクセスの競合」という問題が浮上してきます。複数のユーザーが同時に1つのデータを書き換えようとした場合、データに矛盾が生じる可能性があるのです。
この問題はデータベースだけではなく、ネットワークで共有するあらゆるデータファイルに存在します。一般に、アプリケーションあるいはデータファイルを管理するその他のプログラムは、1人が書き換えられる状態でデータをアクセスしていれば、他のユーザーはそのファイルをアクセスできない――という排他制御を行うようになっています。
|
|
しかし、これでは誰かの処理が終わるまで他のユーザーはデータの書き換えを待たなければならないことになり、作業効率が下がってしまいます。そこでデータベースの場合は、通常レコード単位で排他制御を行います。
- 排他制御とレコードのロック -
データベースやその中のテーブル自体は、複数のユーザーがいつ同時にオープンしても問題は発生しないようになっています。しかし、あるユーザーがその中の1件のレコードを書き換えるためにアクセスしている間は、他のユーザーが同じレコードを書き換えることはできなくなります。
この仕組みに頼っていればまず問題はありませんが、大規模な処理では意図的に複数のレコードやテーブル全体をロック(アクセス禁止状態)にすることも可能です。例えば棚卸しなどで、一時テーブルを利用して商品データの一括変更をバッチ処理的に行うような場合です。実際のアクセスはレコード１件ごとに行われますが、全体の作業が終わるまで外のユーザーがレコードを書き換えないようにしなければなりません。
このような処理を行う場合、ロックと解除のタイミングをうまく設計する必要があります。長時間ロックし続けると他の処理が滞りますし、処理を終えたレコードから順にロックを解除するようにすると、処理が冗長になります。
- レプリケーションを利用する -
SQL ServerなどのRDBMSでは、この排他制御の問題を無理なく解決するために、レプリケーションという機能が搭載されています。レプリケーションは、AccessのJetDBエンジンでも利用できます。
各クライアントにデータベースのレプリカ（複製）を保存しておき、サーバーと情報交換しながら同期を採って整合性を保つ――という仕組みです。この場合、サーバーに保管されるデータベースはマスター・データベースとなり、勝手に更新できません。データベースに対する変更は常にレプリカに対して行い、RDBMSによって同期を採ることでその結果がマスターに反映されます。
大規模なデータベース・アプリケーションでは、レプリケーションの採用を検討するべきです。但し、マスターのデザイン変更など、管理上の手間が増えることも考慮しておきましょう。
- ネットワークの混雑 -
多くのクライアントが頻繁にデータファイルをアクセスすると、特定のサーバーに大きな負荷がかかります。また、信号が忙しく行き来することになるため、回線も混雑します。このようなネットワークの混雑具合をトラフィック(traffic:元の意味は“自動車などの交通”のこと)と呼びます。
日常頻繁にアクセスされる大規模なデータベースが1台のサーバーに集中していると、トラフィックは急激に増大することになります。しかしアプリケーションの開発中に、実際にネットワークに負荷をかけてテストする訳にはいきません。大規模なアプリケーションでは、テスト用のネットワーク環境を準備し、実際にネットワークに負荷をかけてトラフィックを検討し、データの分散保存などを考える必要も生じます。
- セキュリティの問題 -
特にイントラネットとインターネットをシームレスに接続するような場合、外部からの不正な侵入には十分な注意を払うべきです。
通常の閉じたネットワーク(外部に解放されないネットワーク)の場合、外部からの不正侵入はあり得ないでしょう。が、敵は外にいるとは限りません。事実、外部からの侵入やデータ漏洩事件などの原因を探っていくと、多くの場合部内の人間が故意に、あるいは過失でパスワードを漏洩してしまった――といった事実が判明する場合が多いものです。
社外秘、社員や顧客のプライバシー情報などはもちろんのこと、部署内や特定プロジェクトだけ、あるいは特定の役職以上だけが知りうる情報などは、他のメンバーが簡単にアクセスできないよう、十分な配慮をしておきましょう。
但しこれは、アプリケーション開発者の関知する問題から離れ、ネットワーク管理者の担当する仕事となります。開発者としては、そういった重要なファイルにアクセスを許される場合が少なくないため、機密保持に配意することを肝に銘じておきましょう。
- DBサーバーの検討 -
一般には、業務処理で用いるデータベースはファイルサーバーに保存することになります。しかし大規模な業務処理で多数のデータベースが頻繁にアクセスされるような場合には、別途データベース専用のサーバーを用意することも検討するべきです。
データベースとその管理機構であるRDBMSを保存し、データベースの処理を専門に受け持つサーバーをデータベース・サーバーと呼びます。データベースサーバーはネットワーク内に1つだけとは限らず、人事データ、顧客データ…など種類や業務によってさらに分散させることも可能です。
但し、分散させ過ぎると管理が大変です。基本的には１台のサーバーでデータベースを一元管理するのがよいでしょう。こうすれば、蓄積されたデータを分析などに利用するのも簡単です。
この場合、ヘタをすると「１台こけたらみなこけた」になるので、サーバーの安定稼働に配慮し、バックアップをしっかり行うなどの配慮が不可欠です。
ネットワーク・アプリケーションを開発する場合、テスト環境が重要になります。いくつかの注意点を挙げておきます。
- ネットワーク独自のテスト項目 -
スタンドアロンの場合は単一のコンピュータで実行してテストできますが、ネットワーク・アプリケーションでは実際にネットワーク環境の上でテストする必要があります。
実際には、スタンドアロンの場合でも、アプリケーションが実行されるコンピュータの設定を考え、どのような設定、どのような環境でも正しく動作するかどうかを調べなければなりません。例えば、画面解像度の違いやフォルダ構造の違いなどがあります。
ネットワーク環境では、そういったスタンドアロン環境での問題に加えて、先述した同時アクセスなどの問題についてもテストしなければなりません。
- ２通りのテスト環境 -
ネットワーク用のテスト環境は、ネットワークそのものでなくてはなりません。しかし、実際に稼働している業務用のネットワークをそのまま使うわけにはいかないでしょう。
もちろん、簡単な処理なら本番と同じ環境でテストすることも不可能ではありません。しかし、大規模なデータベースをアクセスする処理のテストでは、必要以上のトラフィックが発生したり、ときにはバグによってサーバーが停止するなど、いろいろな問題が発生する可能性があります。
まず、テストのために小規模なネットワークを構築しましょう。基本的に、実際にそのアプリケーションが動作する環境に近い設定とします。とは言っても、大規模なネットワークのコピーをそのまま作る訳にはいきません。テスト用ネットワーク構築の考え方には２通りあります。
| ・ |
全体重視型
ワークグループの配置、サーバー同士の連携の状態など全体の構造をできるだけ本番に近く設定します。
組織内全体で利用されるアプリケーションのテストに向いています。
|
| ・ |
ディティール重視型
サーバー名、クライアント名など、限定的な範囲での設定をできる限り忠実にコピーします。特定部署で利用されるアプリケーションのテストに向いています。
|
どちらの場合も、コンピュータの数は数台程度で構いません。場合によっては、サーバーとクライアント各１台ずつで対応することもあります。しかし、特にトラフィックへの影響をしっかり調べるには、クライアント数をできるだけ多くし、実際の作業に近い環境を再現した方がよいでしょう。
この点に関しては、予算との絡みもあるため「これがベスト」と言える方策はありません。ただ、ネットワーク・アプリケーションの開発には動作テストのためのコストもかかるのだということを、上司や経理担当者に理解させる努力は必要です。
- テスト用環境でのテスト -
開発初期の動作テストでは、例えばデータベースの接続やレコードの更新がうまく行われるかどうかなど、基本的な処理をチェックすることになります。そのための環境は、サーバー１台、クライアント１台でも構いません。
しかし開発の最終段階に近付くと、レプリケーションが正常に動作するか、２台以上のクライアントが同時に同じレコードを更新した場合、どのような問題が起きるか…など、現実的な使い方を意識したテストが必要になります。
そのためには、各クライアントにWindows Scripting Host(WSH)を使った自動運転プログラム（いわゆるバッチ処理）を設定し、同じタイミングでアプリケーションを動かしたり、意図的にトラフィックを増大させるなど、様々な工夫が必要になります。
わざと処理能力の低いコンピュータをサーバーにして、擬似的に負荷のかかった状態を作るという手もありますが、サーバー個体の処理能力が低いのと、トラフィックによってネットワーク全体の処理能力が低下するのとは、本質的に異なります。
同時アクセス時の処理結果を試す場合、クライアント２台でアプリケーションを同時に動かし、「せーの！」でマウスをクリックするといった原始的な方法も考えられます。実は、これをやっているところは案外多いようです。
- 本番環境でのテスト -
最終的には、完成したアプリケーションを実際のネットワークで稼働させ、現場での使用状況を見ながら細かな調整を行うことになるでしょう。しかし、その前段階として、アプリケーションが「テスト用の環境で正常に動作する」ことをしっかり確かめておかなくてはなりません。
本番に移行してよく問題となるのが、アクセス権の設定です。テスト環境ではアクセス権の設定できないWindows 98やMeをサーバーにした状態で試し、本番ではユーザーごとのアクセス権をがっちり設定できるWindows 2000で稼働する――といった場合、思わぬトラブルが発生する場合があります。
データベースそのもののアクセス権はもちろん、設定用のファイル、その他の予備的なファイルの保存場所など、テストの段階で本番の環境をできる限り再現しておくことが重要です。 |
