【条件により500pt以上】

大規模システム構築(プログラムではなく仕様の構築)経験者にお聞きします。
クライアントサーバ型のシステムを構築中ですが、複雑な画面(CADを想像してください)になっているため、クライアント側に多くの処理を持たせています。
このことについて、客先システム担当より「クライアントサーバにしたのだからもっとサーバ側に処理をさせるべきなのではないか」という指摘を受けています。
この指摘に対して言い訳を思いつくままに考えてください。多ければ多いほどいいので、たくさん挙げてください。
言い訳1つにつき、以下のポイントをつけさせていただきます。
 一本 :500pt(まず出ないと思いますが)
 技あり:300pt
 有効 :100pt
 効果 : 10pt
レスポンス低下やサーバへの負荷集中時の話については、当たり前の話ですので除外したいところですが、思わず「そうだよね〜」と納得してしまうようなうまい言い回しをしていただければ高ポイントとします。
作る側からの観点、使う側に立っての観点、どちらからでも結構です(両方が望ましいです)。

回答の条件
  • URL必須
  • 1人2回まで
  • 登録:2005/09/06 16:51:33
  • 終了:--

回答(6件)

id:ootatmt No.1

ootatmt回答回数1307ベストアンサー獲得回数652005/09/06 17:07:31

ポイント50pt

サーバーの処理を多くすると、非常に高いスペックが要求されるので、結果として高いシステムになる。

それよりもクライアント側の処理を増やして、付加を分散したほうが得策である。

id:t-ueno

高スペック、高価。

納得です。

2005/09/06 17:38:25
id:nitscape No.2

nitscape回答回数526ベストアンサー獲得回数02005/09/06 17:17:29

ポイント130pt

どのようなシステムか分からないので検討違いかもしれませんが...


■サーバー側に処理を持たせても大丈夫だが、複雑な画面構成で”処理”前後のデータ数を比べると処理後には●倍になる。そのためサーバーに処理を任せる場合とクライアント側に処理を任せる方法では送受信するデータ量が大きく変わりネットワーク負荷にも影響する。


■「サーバー」と言っても実際のCPU性能は普通に使われているパソコンと同等レベルであり、そのCPUパワーをクライアントで分けることを考えると処理速度がクライアントに任せた場合よりも遅くなる。


■クライアント側のパソコンはPCの入れ替え頻度が高く、常に最新に近い性能のPCを利用可能だが、サーバー側はハードウエア更新は少なくなりがちなので、数年後を見通した場合にクライアント処理の方が使い勝手がよくなる。


■クライアント処理にするとサーバー側では●●の処理にCPUパワーを多く割り当てることが可能で、より細かな●●●のような作業も実装することが可能になる。サーバー処理にすると処理が思い●●●の作業は実装をあきらめざるを得ない。


■サーバー処理にするとメイン処理を含む部分のソフトウエア更新が楽。だがクライアント側のソフトウエアに自動アップデート機能を含ませることでクライアント処理でもメイン処理部分などの更新が楽に可能。

id:t-ueno

どんなシステムかを説明するとまずいことになると思うので、すいませんが割愛しました。なので、見当違いになってしまうのは覚悟の上ですので気になさらなくて結構です。

メールで客先に回答しようとしています。そのいい例文集みたいな感じにしていただきありがとうございます。

2005/09/06 17:41:15
id:zondag No.3

zondag回答回数52ベストアンサー獲得回数02005/09/06 17:22:14

ポイント50pt

どんなシステムを使っているか分かりませんが、サーバー型だとクライアント側の人がスタンドアローンの時より面倒な事が沢山あります。

例えば、ファイル一つを保存する場合でもサーバのファイル管理を知らないと何処に保存して良いのやらわかりません。

あと何処までサーバーに任せているのか分かりませんが、もしサーバーが故障した場合にすぐにローカルに切り替えられる用にクライアント側に任せてあると言えばいいのではないでしょうか

他にはセキュリティ面ですね、データの分散化により大量の個人情報の漏洩が防げるや、ウイルスなどに対応するにはまず入り口であるクライアント側のセキュリティを上げる方が先などと言ってはどうでしょうか

でもやっぱりレスポンスなどの方が普通に分かり易いと思います。

比喩的な表現で、「どんなに部屋が大きくても入り口が小さければ出入りできる人数は同じだ」みたいに言ってみてはどうでしょうか

id:t-ueno

データ漏洩についてはちょっと納得しかねる部分がありますが、その他については新たな視点を与えていただきました。

2005/09/06 17:43:53
id:redcherry No.4

redcherry回答回数135ベストアンサー獲得回数02005/09/06 17:27:20

ポイント100pt

・(顔を真っ赤にして)そんな仕様はプライドが許しません!

 ※知人が本当に言っちゃった発言です!!


・ユーザー毎のリソースや負荷が相当にサーバー側にまわっちゃうので、見積もりが2桁くらい違ってきちゃうんですけど

 ※困ったらとりあえず見積もりをちらつかせて逃げる、という常套手段


・動作がもっさりしてる、なんてクレームはこちらへまわさないと約束していただけますか?

 ※レスポンス低下の件に近いわけですが・・・責任の所在を言えば相手も逃げるだろう、ということで

id:t-ueno

お、「事件は現場で起きているんだ!」的ですね。

1番目のは、思わず笑ってしまいました。

2005/09/06 17:47:28
id:dev_zer0 No.5

dev_zer0回答回数332ベストアンサー獲得回数252005/09/06 18:02:31

ポイント310pt

アーキテクチャからの観点:

複雑な画面というとまずはXウィンドウがあります。

これは描画の指示などはサーバが受け付けますが、画面の大きさの変更や移動などはウィンドウマネージャが行い、サーバは検知しません。

JavaApplet、flashなどはサーバ側はクライアントに送信するだけでほとんどど何もしません。

これらのアーキテクチャから考えると、サーバ側はシンプルな仕事を数多くこなすべきであり、複雑な仕事はクライアントがこなすべきでしょう。


経費の観点:

数年経てばPCの性能がサーバの性能を上回ることも十分に考えられます。

長期的に見るとサーバを常に最高性能に保つよりもPCを適時入れ替えた方が経費がかかりません。

(そちらの構成がわからないので断言できないですけど...)

id:t-ueno

アーキテクチャ話は例え話に使えますね。

使わせていただきます。

2005/09/06 18:11:03
id:name_mm No.6

name_mm回答回数94ベストアンサー獲得回数02005/09/06 18:21:48

ポイント20pt

URLはダミーです。


現在のソフトウェア構成は、ネットワークに接続されているサーバー/クライアント負荷がなるべく均等になるように設計されています。

サーバー側に処理の一部を移行すると、クライアント側に余力ができてしまい処理効率が低下し、サーバー側に負荷をかけると、ハード故障が発生しやすくなりシステム稼働率が低下します。

また、クライアント製品は安価なため数年後クライアントのみハード交換するだけで、処理能力が大幅に向上します。


ではどうでしょうか?

id:t-ueno

負荷分散と将来的ハードコスト。

どちらも既出でしたが、了解です。

−−−−−

どうもありがとうございました。

締め切りまして、仕事に戻ります。

配点は夜遅くになるかと思います。

2005/09/06 18:25:10
  • id:t-ueno
    ポイント配分

    ビミョーになってしまってすいません。
    「効果」の10ptにするには忍びないけど「有効」まではいかないものについて、50ptにしました。で、それが結構多かったのでビミョーになてしまいました。

    ootatmtさん:
    負荷分散、そうしないと高価、という件について初出ですが・・・50ポイント

    nitscapeさん:
    10ポイント
    10ポイント
    50ポイント(クライアント更新初出)
    50ポイント(もっともらしい言い訳、応用可能)
    10ポイント

    zondagさん:
    サーバー管理者的な視点のご意見で、システム開発の視点と違う観点を見させていただいたので、総合評
    価で50ポイント

    redcherryさん:
    前線で頑張っているっぽい感じのご意見、熱意がよかったのと、笑わせていた
    だいたので100ポイント

    dev_zer0さん:
    アーキテクチャ話は報告での例え話に使わせていただきました。技ありです。300ポイント
    クライアント更新については既出につき10ポイント

    name_mmさん:
    負荷分散についてはちょっと一般的過ぎるので10ポイント
    クライアント更新については既出につき10ポイント

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません