HOME»応用情報技術者試験掲示板»31春、問4の設問3、(3)について
投稿する
31春、問4の設問3、(3)について [1647]
ななしさん(No.1)
先日、API公式の回答が発表され、自身の回答と照らし合わせていたのですが、問4の設問3、(3)の変更の回答に「バッチ処理とその他の処理が実行される機器を分ける。」としてあり、私の回答、「利用者の少ない時間にバッチ処理を行う」というものとかけ離れていました。
私はこの回答を描いた理由として、表1のAPの欄に「利用者数の多い時間帯は、CPU利用率が80%を超える状態が続くことがあり、その時間帯にバッチ処理が実行されると、Webブラウザからのリクエストに対する応答街が極端に長くなってしまうことがある。」というところから取っており、TACでの解答速報にも同じようなことが記載されており、自身があるものでした。
この私の回答は間違っているのでしょうか?また、公式回答のような回答にたどり着くにはどうすればよいのでしょうか。
私はこの回答を描いた理由として、表1のAPの欄に「利用者数の多い時間帯は、CPU利用率が80%を超える状態が続くことがあり、その時間帯にバッチ処理が実行されると、Webブラウザからのリクエストに対する応答街が極端に長くなってしまうことがある。」というところから取っており、TACでの解答速報にも同じようなことが記載されており、自身があるものでした。
この私の回答は間違っているのでしょうか?また、公式回答のような回答にたどり着くにはどうすればよいのでしょうか。
2019.06.20 11:51
初受験さん(No.2)
自分も同じような論点から記述しました。
そもそも現状のシステム構成でCPU使用率が80%を超える状況が発生しているのに、バッチ用の機器とそれ以外に完全に分けることで、利用者からのアクセスに対応する機器の性能は確実に落ちるのではないかと思います。その場合機器を分けたことによって混雑時はアクセスを捌ききれず遅延するのではないかと思いました。機器の増設等スケールアップを行うのであれば話は別ですが、今回の問題にはそのような論点はなかったと思うのですが。。
公式の解答も考え方の1つだとは思いますが、自分としては現状のシステムの性能からして疑問点が残りました。
長くなってしまってすみません
そもそも現状のシステム構成でCPU使用率が80%を超える状況が発生しているのに、バッチ用の機器とそれ以外に完全に分けることで、利用者からのアクセスに対応する機器の性能は確実に落ちるのではないかと思います。その場合機器を分けたことによって混雑時はアクセスを捌ききれず遅延するのではないかと思いました。機器の増設等スケールアップを行うのであれば話は別ですが、今回の問題にはそのような論点はなかったと思うのですが。。
公式の解答も考え方の1つだとは思いますが、自分としては現状のシステムの性能からして疑問点が残りました。
長くなってしまってすみません
2019.06.20 13:49
asdgさん(No.3)
私も「利用者の多い時間帯を避けてバッチ処理を行う。」といった感じで書きました。これが正解でなければ、問題文中の「利用者数の多い時間帯は、CPU利用率が80%を超える状態が続くことがあり、その時間帯にバッチ処理が実行されると、Webブラウザからのリクエストに対する応答街が極端に長くなってしまうことがある。」この部分はいらないですからね。
2019.06.20 15:02
初受験さん(No.4)
自分は「CPU使用率が80%を超えている場合バッチ処理を行わない」と書いたのですが、この場合、利用者少ない云々が〇だとした時に点数貰えますかね...
2019.06.20 15:45
AP7743さん(No.5)
私は逆に公式解答に近く、「バッチ処理機能を新規サーバに分離させる」のような感じで書きました。
問題文の解釈の仕方もあると思いますが、
・確定した構成ではなく、課題に対してどのように構成変更するかの内容であり、
フロントAP、バックAPの台数検討の問題もあったことから
サーバ追加は許容されるのではと考えた
・バッチ処理自体が負荷をかけている前提のため、
定期実行間隔は明記されてないが、バッチ処理自体を分離させたほうが良いと考えた
という感じです。
問題文に各種前提が表記されてないという点では
「バッチ処理が負荷をかけることの根本的な原因調査、プログラム改修の実施」も思いましたが、
それ言ったらきりがなくなるなぁと。。。
どのように前提条件を考えるかで回答はいくらでも出てくるので、
ここはグレーなところですね。
#TACさん等の回答速報や掲示板での書き込みを見たときは
#私の方が違っていたのかと思っていましたが。。。
問題文の解釈の仕方もあると思いますが、
・確定した構成ではなく、課題に対してどのように構成変更するかの内容であり、
フロントAP、バックAPの台数検討の問題もあったことから
サーバ追加は許容されるのではと考えた
・バッチ処理自体が負荷をかけている前提のため、
定期実行間隔は明記されてないが、バッチ処理自体を分離させたほうが良いと考えた
という感じです。
問題文に各種前提が表記されてないという点では
「バッチ処理が負荷をかけることの根本的な原因調査、プログラム改修の実施」も思いましたが、
それ言ったらきりがなくなるなぁと。。。
どのように前提条件を考えるかで回答はいくらでも出てくるので、
ここはグレーなところですね。
2019.06.20 18:58
ななしさん(No.6)
スレ主です。
皆さんご丁寧な回答をありがとうございます。やはり私と同じような回答をした方は多かったんですね・・・でも公式回答にたどり着くプロセスも納得のいくもので、どうにも難しいものですね…
皆さんご丁寧な回答をありがとうございます。やはり私と同じような回答をした方は多かったんですね・・・でも公式回答にたどり着くプロセスも納得のいくもので、どうにも難しいものですね…
2019.06.20 23:36
hogeさん(No.7)
実務上はどう作るかを考えれば、おのずと答えは出てくるかな。
バッチが一日一回なら、そういうのはハナから利用者の少ない時間帯に実行するのが当たり前。
実行間隔がもっと短いなら、時間帯を動かすこと自体が不可能。
負荷の高いときにバッチ処理をスキップするなんてのは論外。ずっと負荷が高い状態が続けば、全くバッチ処理が行われなくなるでしょ。
自分はどう回答したか忘れたけど、サーバをスケールアウトするとかなんとか、そんなことを書いたはず。
バッチが一日一回なら、そういうのはハナから利用者の少ない時間帯に実行するのが当たり前。
実行間隔がもっと短いなら、時間帯を動かすこと自体が不可能。
負荷の高いときにバッチ処理をスキップするなんてのは論外。ずっと負荷が高い状態が続けば、全くバッチ処理が行われなくなるでしょ。
自分はどう回答したか忘れたけど、サーバをスケールアウトするとかなんとか、そんなことを書いたはず。
2019.06.21 14:05
ささにしきさん(No.8)
揚げ足取りのようですが、「利用者の少ない時間にバッチ処理を行う」だと
(バッチ処理を行う前に利用者が少ないかどうかの判別を毎回するのは)処理として現実的ではないと考えます。
スケールアウトを匂わす設問もあったので、そこからイメージを膨らませていくのでしょうね。
(バッチ処理を行う前に利用者が少ないかどうかの判別を毎回するのは)処理として現実的ではないと考えます。
スケールアウトを匂わす設問もあったので、そこからイメージを膨らませていくのでしょうね。
2019.06.24 11:24