- PR -

集中システムを分散化するには

投稿者投稿内容
やぶにらみ
会議室デビュー日: 2006/08/08
投稿数: 5
投稿日時: 2006-08-08 16:13
システムの処理効率アップに関して皆様のお知恵をお貸しください。

現在集中サーバ方式で販売管理システムが稼動しています。
センターと各拠点(6つ)が全国に分散して配置されており
各拠点とセンターはインターネットを通してVPN接続しています。
データとプログラムはセンターサーバにのみ置いて運用中です。
ところが
案の定というか当然ですが
元々LAN内で運用するつもりで構築されたシステムですから
この方式では拠点からの利用では非常にレスポンスが悪く
クライアントから改善の要望があがりました。

そこで
1)ターミナルサービスを導入する
2)拠点サーバを配置してセンターサーバと同期を取る
3)システムの組みなおし
以上の3つの提案をしてみました。

1)に関しては接続端末が今後増加することで
クライアントライセンスの負担を懸念して難色を示しています。

2)に関してはセンターと拠点の同期だけならまだいいのですが
拠点同士が直接繋がっていないにもかかわらず
ある拠点にて別の拠点の情報を入力することがあり
センターサーバ越しにその同期が簡単にできる方法が見つからず困っています。

3)に関しては予算がぜんぜん足りず考慮外になりました。
本音ではこの案が最もいいと思うのですがなにせ予算が...

システム構成としては
センターサーバはWINDOWS2003。
拠点は6拠点で全拠点の接続端末は現状で20台程度
今後増加する可能性が充分にある。
ほとんどの拠点は光回線を導入しており一部ADSLです。
DBMSはFireBrid1.5で総データ件数は30万件程度
1度にやりとりする件数は数万件程度です。
プログラムはDelphiにて作成されています。

要件としては
1)在庫等をリアルタイムに全拠点で把握したい
2)全拠点でデータの入出力が発生する
3)ある拠点で別の拠点の情報を入力することもある
4)この効率アップにそれほどの予算は出せない
です。


個人的にはターミナルサービスを導入するのが安上がりで
現状のシステムの変更も必要ないのでいいかなと思っているのですが
クライアントは2)方式で安上がりになるならそちらがよいと言っています。
拠点サーバを配置するとして
上記のシステム構成や要件で
きちんと同期が取れる方式があるのでしょうか?
それが無理ならそのことをクライアントにきちんと報告して
1)方式を薦めるつもりでいます。
ひろれい
ぬし
会議室デビュー日: 2006/03/02
投稿数: 486
お住まい・勤務地: 万博開催地
投稿日時: 2006-08-08 16:21
DBMS を Oracle化して、レプリケーションで同期を取るとかって出来ないんでしょうか。

昔、レプリケーションで稼働系システムと待機系システムで同期を取っているシステムを見たことがあります。

あまり詳しくないので、突っ込んで聞かないで下さい(^_^;)
あくまで参考にして下さい。
やぶにらみ
会議室デビュー日: 2006/08/08
投稿数: 5
投稿日時: 2006-08-08 16:34
引用:

ひろれいさんの書き込み (2006-08-08 16:21) より:
DBMS を Oracle化して、レプリケーションで同期を取るとかって出来ないんでしょうか。



ありがとうございます。
DBMSのリプレースも検討事項ではありますが
なんせ予算が...
そんな中でOracleなんて...
クライアントはまずOKしてくれないでしょう。
元々低予算で組んだシステムらしく
(らしくってことは
 このシステムの立ち上げには私は参加しておりませんのです。
 問題解決人として使命を帯びて参上したわけでして...)

FireBird1.5のリプリケーションツールIBReplicatorも見てみましたが
FireBird自体がメジャーではないせいか
導入実績が余り見られないので不安がありますね。
その他のリプリケーションツールは
対応DBMSにFireBrid(InterBase)がなかったり(;_;)

引き続き何かお知恵がありましたらお願いします。
おむすび君
常連さん
会議室デビュー日: 2005/03/11
投稿数: 29
投稿日時: 2006-08-08 16:58
[QUIOE]非常にレスポンスが悪く [/QUIOE]

具体的にLAN(で想定していた速さ)と比較してどれくらい遅いのでしょう?

やぶにらみ
会議室デビュー日: 2006/08/08
投稿数: 5
投稿日時: 2006-08-08 17:18
引用:

おむすび君さんの書き込み (2006-08-08 16:58) より:
[QUIOE]非常にレスポンスが悪く [/QUIOE]

具体的にLAN(で想定していた速さ)と比較してどれくらい遅いのでしょう?





3倍程度でしょうか。
先にも述べましたがシステム立ち上げに参加していないので
想定がどの程度か分かりませんが
現状の実測値では
同じスペックの端末で
同じ抽出条件で
とあるデータ問い合わせ画面が戻ってくるまでの秒数が
LAN環境では3秒であったのが
拠点では13秒かかりました。

プログラムによってはもっと差がでることもあります。
6秒と30秒。

実行ボタンを押して30秒も何の反応もなければ
それは問題ありますよね。
おむすび君
常連さん
会議室デビュー日: 2005/03/11
投稿数: 29
投稿日時: 2006-08-08 17:51

その「VPN」の保証速度から換算して
実測した5倍の差は妥当なのだとしたら

4) ネットワークインフラのリプレース

がいいんじゃないですか
(それが無理だから質問してるのかもしれないですが...)

でも物理的に無理なものをDB同期とか、システム組みなおしとか
リスクを追うことは無いかと、、
そうやって考えるとやっぱりターミナルサービスですかねー
(戻ってしまってすみません)
小僧
ぬし
会議室デビュー日: 2002/08/14
投稿数: 526
投稿日時: 2006-08-08 20:45
レスポンスの悪さは、本当に通信回線の速度が問題なんでしょうか?。
・検索結果をクライアント側で何か処理をしている部分が遅い
・DBサーバ自体の検索処理が遅い
などは考えられませんかね。
検索処理の応答がなかなか無い場合は、検索実行を別のスレッドなど
で行わせて、クライアントが使用するプログラム側にメッセージや
アニメーションを表示するだけでも、心理的に無反応な状態よりも
悪い評判は出にくいと思うのですが。
DBの負荷が問題場合は、レスポンスで返す件数を減らす、
インデックスに引っかからないクエリをなるべく作らない、
更新頻度よりも参照頻度の高いテーブル上の検索結果をキャッシュ
するなどの方法で対処できるんですがね。
クライアントのCPUにある程度パワーがあるのなら、検索結果を
圧縮して通信回線に流すと、結構効果あると思います。
クライアントの通信部分とサーバ側の通信部分に圧縮、展開する
仕組み(ミドルウェアとか)を挟み込むようにすれば、手をあまり
加えなくても済むかと。




やぶにらみ
会議室デビュー日: 2006/08/08
投稿数: 5
投稿日時: 2006-08-09 09:17
元々LAN環境で使用するのに充分な程度の作りしかしてないようで
LANなら問題にならないくらいのレスポンスが得られるのですが
WAN経由で使用する段になると
SQLが頻繁に行き来するため
(パケットをキャプチャして確認しました)
極端にレスポンスが悪くなります。
通信回線云々よりも
システム構成とシステム構築の思想が一致していないことが最大の原因かと。


ちょっと質問の仕方を変えます。
1)WINDOWS2003のターミナルサーバを導入された方はいらっしゃいますか?
 クライアントがWAN経由でもそれほど違和感なく使用できますか?
 サーバのスペックにもよるのでしょうが
 どれくらいの同時接続クライアントまで使用に耐えうるレベルを維持できますか?

2)FireBridのレプリケーション機能を使用された方はいらっしゃいますか?
 1:1だけでなく1:Nのレプリケーションはできますか?
 同期の方式はどのような形式で実行されているのでしょうか?

3)IBReplicatorを含めてFireBrid(InterBase)対応の
 レプリケーションミドルウェアを使用された方はいらっしゃいますか?
 もしいらっしゃったらその使用実績を差し支えない範囲でお教えください。


現状の認識としては
インフラ周りどうこうより
現在の運用形態がシステム構成とアンバランスであることが問題であると認識しています。
すなわち
 ・リアルタイムに情報を把握したいので集中式
 ・しかし情報の入出力は遠隔の拠点で行なわれている
 (もちろんセンターでも行なわれている)
 ・センターと拠点はVPNで通信している
 ・元々のプログラムの作りはLANのクラサバを意識している


そのために
1)現状のソフトに変更を加えずに済む方法(ターミナルサーバの導入)
2)多少の変更を加えても構成を運用に合わせて変更する方法
の2点で検討を進めています。

各々に一長一短はあるでしょうから
その材料をできるだけ集めたいと言ったところです。
最終判断はクライアントがしますから
できるだけ色んな情報を提供してあげたいと思っています。

どうかよろしくお願いします

スキルアップ/キャリアアップ(JOB@IT)