応用情報技術者 2018年 秋期 午後 問題

共通の文章

インターネットサービス向けサーバのセキュリティ対策に関する次の記述を読んで,

共通の文章

レストラン経営に関する次の記述を読んで,設問1ー4に答えよ。 R店は個人経営の洋食レストランであり,大都市にある乗降客の多い駅の近くの貸 しビルに,数年前に開店した。厨房とホールに,それぞれ人従業員が数名配置され, 夕方から営業を開始している。最近は,売上が横ばい状態の上に,食材価格の高騰の 影響で経費が増加しており,黒字経営とはいえ,利益は減少傾向にある。そこで,経 営者のS氏は売上の伸び悩みや利益の減少の原因を調査・分析し,経営の改善を図 ることにした。 来店客へのアンケートの結果 S氏は,ます来店客に対して,R店に関する印象・意見を求めるアンケートを実施 し,その結果を次のとおりまとめた。 (好評点) ・店が駅から近くて行きやすい。店内がきれいで,雰囲気も良い。 ・ハンバーグステーキがとてもおいしい。 ・料理の品目が頻繁にメニューに追加されるので,店のホームページなどで時々チ ェックしている。追加された料理がおいしそうだと,お店に足を運びたくなる。 ・スマートフォンで稼働するアプリケーションソフトウェア(以下,携帯アプリと いう)を使って予約できるのは,便利である。| ・会計時に,スタンプカードにスタンプを押してもらって,スタンプが一定数たま ると,料理が一品無料になるなどの特典は,お得感があってうれしい。 (不評点) ・注文してから,料理が運ばれてくるまでに,時間が掛かる。 ・来店客で混雑する時間帯は,携帯アプリや電話などで予約しておかないと,入店 までかなり待たされる。 ・料理の品目数が多く,メニューに写真が掲載されていないので,品名だけではど れを選んだらよいか悩んでしまう。店の従業員に料理の説明をしてもらわなけれ ば,注文する料理を決められないので,もっと親切ながメニューにしてほしい。 ・おいしくて安全な料理を食べたいが,料理に使われている食材を,誰がどのよう ー10一 にして作っているか分からない。 ・スタンプカードを忘れた場合に,スタンプがたまらないのは不便である。 ・ディナーの営業だけでなく,ランチの営業もしてほしい。 来店客の待ち時間が長い問題"の要因分析] 次にS氏は,来店客へのアンケートの結果のうち,売上に直結する顧客回転率を 上げるために来店客の待ち時間が長い問題"について改善が急務と考え,店の主要 メンバとブレーンストーミングを行いその要因を分析した。分析は,従業員,店舗, 料理,手順に分けて行った。挙げられた要因は,次のとおりである。 (1)従業員 ・アルバイトには入れ替わりがあるが,新規のアルバイトを雇った場合,十分な教 育をしていないので,仕事に慣れるまで作業の効率が悪い。 ②)店舗 ・貸しビルの店舗の増改築は難しく,客席の数を増やせない。 ・賃貸契約の期間が残っており,多額の解約手数料が掛かるので,店舗の移転は難 しい。 (3)料理 ・料理の品目数を減らさずにメニューに品目の追加を続けているので,料理の品目 数が多くなってしまった。 ・料理の品目数の増加に伴い,使用する食材や調理器具の種類が増加するので,厨 房の作業効率が低下している。 (4)手順 ・仕込みの時間が不足しているので,調理に時間が掛かっている。 ・食材は市場で仕入れており,仕入れに多くの時間が掛かっている。これが,仕込 みの時間の不足の原因となっている。 ・農家と契約して食材を直送してもらうことによって,仕入れに掛かる時間を減ら せる。仕入れに掛かる時間を減らせば,その時間を仕込みなど,他の作業に回せ る。 S氏は,“来店客の待ち時間が長い問題"の要因を,図1の特性要因図にまとめた。 ーロー 従業員 店舗の移転は難しい Cc J仕事に慣れるまで作業のさ_se 光ってい8へアルバイトに入れ替わりがある し5|ごテッ客 効率が悪い店 の十分な教育をしていないの ーーEs 待 厨房の作業効率が 調理に時間が掛かるーーテーテ低下している~オッle 仕入れに時間が掛かるコーラッREO me BRS G7長 coe料理の品目数を減らさずい Rを続けている にメニューに品目の追加 人ea使用する食材や調理器具の の時間が不 注記し)は主要因を示す。主要因とは,抽出された要因の中から絞り込んだ,最も重要と考えられる要因 のことである。 図1“来店客の待ち時間が長い問題"の特性要因図 [“来店客の待ち時間が長い問題"の改善策」 S氏は,図1で抽出された主要因に対して改善策を立てた。 ・主要因“料理の品目数を減らさずにメニューに品目の追加を続けている"について, 2のABC曲線を作成した。これを基に検討した結果,A及びBグループの品目 数が最適な品目数であるという結論になったので,B,Cグループのうちから,将 来の伸びが期待できない品目をメニューから削除し,①料理の品目数を絞ることに Lit. の る %9 20 60 100 にーーーータにーーーー A B(@ 料理の品目数の割合(%) 図2主要因“料理の品目数を減らさずにメニューに品目の追加を続けている"について のABC曲線 ・主要因“市場で仕入れている"について,農家と契約し,食材を直送してもらうこ とによって,仕入れの時間を減らして,仕込みの時間を増やす。 ・主要因“十分な教育をしていない”について,アルバイトを雇用したときに活用す る教育用のマニュアルを作成する。 [その他の問題の改善策〕 S氏は,来店客へのアンケートの結果から,“来店客の待ち時間が長い問題"以外 にも,利益改善に向けて重要だと思える問題を特定し,次の改善策を立てた。また, 仕入先として予定している農家と交渉した結果,食材をたくさん仕入れると,仕入単 価を下げる契約が可能なことが分かったので,この方法も活用したいと考えた。 ・メニューに写真やおすすめする理由を入れて,来店客が料理を選びやすいようにす る。 ・②来店客にも契約農家,生産方法などが分かるようにして,顧客満足度を高める。 ・スタンプカードの不便さを解消するために,既存の情報システムを活用して, [Le| ・③ハンバーグステーキと野菜サラダをセットにしたおすすめ料理を紹介し,セット 料理がより多く売れるようにする。 〔ランチ営業の検討 仕入れに掛かる時間の短縮によって,ランチ営業の時間も取れるので,S氏は,ラ ンチ営業の開始を判断するために,収益見込みを確認した。ランチ営業の開始に伴っ て,R店の固定費が増加することはない。そこで,固定費の総額を,ディナー営業と SY F BRIELLE CHUL,ランチ和営業の1か月の収益見込みを表1のとおり作 成した。 表1ランチ営業の収益見込み 単位千円月 —— em -ランチ営業の収益見込みでは,利益がマイナスとなった。しかし,今後ランチ営業 で見込みどおりの売上高しか得られなかったとしても表1において,|j|こ とから,S氏は,ランチヂ営業を始めることにした。

共通の文章

ウェーブレット木に関する次の記述を読んで,設問14に答えよ。 ウェーブレット木は,文字列内の文字の出現頻度を集計する場合などに用いられる 2分木である。ウェーブレット木は,文字列内に含まれる文字を符号化して,それを 基に構築される。特に計算に必要な作業領域を小さくできるので,文字列が長大な場 合に効果的である。 例えば,DNAはA(アデニン),C(シトシン),G(グアニン),T(チミン)の4 種類の文字の配列で表すことができ,その配列は長大になることが多いので,ウェー ブレット木はDNAの塩基配列(以下,DNA配列という)の構造解析に適している。 ウェーブレット木において,文字の出現回数を数える操作と文字の出現位置を返す 操作を組み合わせることによって,文字列の様々な操作を実現することができる。本 Clk,文字の出現回数を数える操作を扱う。 〔ウェーブレット木の構築〕 文字の種類の個数が4の場合を考える。DNA配列を例に文字列Pを “CTCGAGAGTA”とするとき,ウェーブレット木が構築される様子を図1に示す。 ここで,2分木の頂点のノードを根と呼び,子をもたないノードを葉と呼ぶ。根か らノードまでの経路の長さ(経路に含まれるノードの個数一1)を,そのノードの深 さと呼ぶ。各ノードにはキー値を登録する。 図1では,文字列Pの文字Aを00,文字Cを01,文字Gを10,文字を11の2 ビットのビット烈に符号化して,ウェーブレット木を構築する様子を示している。ま た,図1の文字列の振り分けは,ウェーブレット木によって文字列Pが振り分けら れる様子を示している。 深さウェープブレット木文字列の振り分け 0…文字列P:CTCGAGAGTA 1 ESA METS cc ュープx “aw e™awe™ AAA cc GGG WE 注記1図中の実線はノードの親子関係を示す。注記2図中の矢印は文字列の振り分けを示す。 図1ウェーブレット木の構築 ={= ウェーブレット木は,次の(1)て(3)の手順で構築する。 1)根(深さ0)を生成し,文字列Pを対応付ける。 (2)ノードに対応する文字列の各文字を表す符号に対して,ノードの深さに応じて 決まるビット位置のビットの値を取り出し,文字の並びと同じ順番で並べてビット 列として構成したものをキー値としてノードに登録する。ここで,ノードの深さに 応じて決まるビット位置は,“左から(深さ十1)番目′とする。 ノードが根の場合は,ビット位置は左から(0+1=1)番目となるので,図2に 示すように,文字列P“CTCGAGAGTA”に対応する根のキー値はビット列 0101010110となる。 C T C G A G A G T A fol1[aJ1[hi[ajo[ojo faJo[lo oh[le b+vb bv vv vd 図2根のキー値 (3)キー値のビット列を左から1ビットずつ順番に見ていき,キー値の元になった 文字列から,そのビットに対応する文字を,ビットの値が0の場合とビットの値 が1の場合とで分けて取り出し,それぞれの文字を順番に並べて新たな文字列を 作成する。 MFI Pに対応する根のキー値の場合は,ビットの値が0の場合の文字列とし て“CCAAA"を取り出し,ビットの値が1の場合の文字列として|イ|" を取り出す。 ビットの値が0の場合に取り出した文字列内の文字が2種類以上の場合は,そ の文字列に対応する新たなノードを生成して,左の子ノフードとする。取り出した文 字列内の文字が1種類の場合は,新たなノードは生成しない。 ビットの値が1の場合に取り出した文字列内の文字が2種類以上の場合は,そ の文字列に対応する新たなノードを生成して,右の子ノフードとする。取り出した文 字列内の文字が1種類の場合は,新たなノードは生成しない。 生成した子ノードに対して,(2),(3)の処理を繰り返す。新たなノードが生成さ れなかった場合は,処理を終了する。 ー17一 [文字の出現回数を数える操作 文字列P全体での文字C(王01)の出現回数は,次の(1),(②)の手順で求める。 ①)文字Cの符号の左から1番目のビットの値は0なので,文字Cは根から左の子 ノードに振り分けられる。左の子ノードに振り分けられる文字の個数は,根のキー 値の0の個数に等しく,である。 2)文字Cの符号の左から2番目のビットの値は1である。(①1)で振り分けられた左 の子ノードのキー値の1の個数は2 TC,このノードは葉であるので,これが文字 列P全体での文字Cの出現回数となる。 文字の出現回数を数えるプログラム]〕 与えられた文字列Q内に含まれる文字の種類の個数を0とするとき,あらかじめ 生成したウェーブレット木を用いて,与えられた文字列内で指定した文字の出現回数 を数えるプログラムを考える。ウェーブレット木の各ノードを表す構造体Nodeを表 1に示す。左の子ノード,又は右の子ノードがない場合は,それぞれ,left,rightに はNULLを格納する。 表1各ノードを表す構造体Node 文字列Qに対応して生成したウツウェーブレット木の根へのポインタをrootとする。 文字列Q内に存在する一つの文字(以下,対象文字という)をビット列に符号化し て,整数(0てgo一1)に変換したものをrとする。 このとき,MEW Qの1文字目からm文字目までの部分文字列で,対象文字の出 現回数を数える関数rank(root,m,r)のプログラムを図3に示す。 文字の符号化に必要な最小のビット数は,ABER DEPTHに格納されているもの とする。 function rank(root,m,r) nodep<root d<1//符号中の左からのビット位置の初期化 nem//検索対象の文字列の長さの初期化 while(nodepがNULLでない) count<9 //rに対応するビット列の左からd番目のビット位置のビットの値をbに格納 xで(1を左に|エ|ビットシフトした値) xで(x and)//andはビットごとの論理積 bて(xを右にビットシフトした値)//bは0か1の値 for(iを1 DS nまで1ずつ増やす) if(bがnodep.keyの左から番目のビット位置のビットの値と等しい) count<count+1 endif endfor if(bが|カ|と等しい) nodep<nodep.left else nodep<nodep.right endif ・ー dd+1 end while return n end function 図3関数rankのプログラム [ウェーブレット木の評価] 文字列Qが与えられたとき,MEW Qの長さをN,文字の種類の個数を0とする。 ここで,議論を簡潔にするためにogは2以上の2のべき乗とする。 文字列Qが与えられたときのウェーブレット木の構築時間は,文字ごとに jog(|ク|)か所のノードで操作を行い,各ノードでの操作は定数時間で行うこ とができるので,合計で0(x iog(|クtHe. 構築されたウェーブレット木が保持するキー値のビット列の長さの総和は, [|ュcas.

共通の文章

並列分散処理基盤を用いたビッグデータ活用に関する次の記述を読んで,設問1 4に答えよ。 S社は,スーパーマーケットやドラッグストアなどの小売チェーン(以下,チェー ンという)で販売されている衣料用洗剤や食器用洗剤などを製造する大手消費財メー カである。商品企画部による商品力強化や,営業部による拡販施策検討のために,取 引先である複数のチェーンから匿名化されたPOSデータを週次で購入し,独自に集 計・分析することになった。購入するPOSデータの件数は約10億件プ週と予想され るので,情報システム部のTさんをリーダとして,並列分散処理基盤を利用した POSデータ集計・分析システムを構築することになった。 [並列分散処理基盤のシステム構成〕 Tさんは,S社が保有している並列分散処理基盤のシステム構成を調査した。並列 分散処理基盤のシステム構成を図1に示す。 LAN#1 LAN#2 eauデザRHF TSE |マタナーバトールeg eeeしローカルストレージお0| Ea se—_{Br he 注記マスタサーバ,DITTVbELROIIATY b#2OU-AWVAhV—-VISERTS, 図1並列分散処理基盤のシステム構成 処理対象のデータはブロック単位に分割され,物理的には,各スレーブサーバの内 部バスに接続されたローカルストレージに分散して格納されているが,論理的には, 単一のファイルシステム(以下,分散ファイルシステムという)で管理されている。 分散ファイルシステムのブロックサイズは128Mバイトに設定されている。任意の スレーブサーバ1台に障害が生じた場合でも処理を継続できるように,ブロックは2 台のスレーブサーバのローカルストレージに非同期で複製して格納されている。ファ イル名,ブロック位置,MAB,権限などのメタデータは,マスタサーバが保持して いる。 マスタサーバはクライアントからジョブの実行依頼を受け付け,ジョブを複数の実 行単位(以下。タスクという)に分割し,処理対象のデータを格納しているスレーブ ー20一 サーバに対してタスクの実行を依頼する。データを分割した際にデータサイズのばら つきが小さいほど,タスクが均等に分散される。また,同一ジョブ内のタスク間で処 理するデータが依存しており,タスクが逐次的に処理される場合,それらのタスクは 分散されない。各スレーブサーバで同時に実行可能なタスクの数は,CPUの物理コ ア数一1を上限とする。並列分散処理基盤全体で同時に実行するタスクの数を多重度 どいゆう。 マスタサーバの仕様は,CPU物理コア数2,メモリ容量8Cバイト,ローカルスト レージのディスクLO速度60Mバイトノ秒である。スレーブサーバの仕様は,CPU 物理コア数4,メモリ容量16Gバイト,ローカルストレージのディスクVO速度60 Mバイトノ秒である。 Tさんが調査結果を上司のU課長に報告したところ,①可用性の観点からリスク があるとの指摘を受けた。本リスクを評価した結果,それを受容してシステム構築を 進めることになった。 (POSデータ集計・分析システムのジョプブ構成】 POSデータ集計・分析システムを構成するジョブの一覧を表1に示す。 表1 POSデータ集計・分析システムを構成するジョブの一覧 |パパジョブの和則”|上本和還 処理対象平均ファ|ファイル|ファイルの|データサ|時間(時 記号|ジョブ名処理内容5イルサイ|数(個)|分割単位|イズのば|間) のデータ|、、、 ズ(Mバらつき イト) (A)|データ形式POSデータを統一のデ|購入する300 1,400|チェーン大2.0 統一ータ形式に変換する。|POSデー別・日別 タ (B)|店舗別売上|売上数量を店舗別に集|(A)の処理100 6,300|店舗別中0.5 集計計する。結果 Ole[ara lee||MC]*| (D)|売上予測|重回帰分析の偏回帰係|(C)の処理1商品別小 (C)|商品別売上|売上数量を商品別に集|(A)の処理20 10,000小1.0 数を求め,求めた偏回|結果 帰係数を用いて自社商 品別の売上数量を予測 する。 注記データサイズのばらつきとは,データサイズの偏差(ファイルの分割単位で処理対象のデータを分割した 際の各分割データのサイズとその平均との差)から求めた指標であり,各ジョブにおけるデータサイズの散 らばりの度合いを意味する。 POSデータの購入元は200チェーンあり,POSデータは日別にファイル分割され ている。1週間分のPOSデータのファイル数は1,400個であり,総データサイズは 420 Gバイトとなる。店舗数は全チェーン合わせて6,300店舗であり,取り扱われて いる商品数は10,000点である。そのうち,S社の商品は600点である。 ジョブの実行順序は(A),(B),(C),(D)の順であり,各ジョブは同時には実行され ない。 毎週月曜日23時までには,前週月曜日から日曜日までの全てのPOSデータが分散 ファイルシステムに格納される。商品企画部や営業部からは,毎週火曜日の9時に は最新の分析結果を見られるようにしてほしいとの要望が挙がっているので,月曜日 23時から火曜日9時までの間に一連のジョブを完了させる必要がある。 [性能テスト〕 POSデータ集計・分析システムを開発し,性能テストを実施したところ,②ジョ ブ(B)が目標処理時間内に完了しないことが判明した。ジョブ(B)実行中のマスタサー バ及びスレーブサーバ女1のリソース使用状況を図2に示す。 BB,スレーブサーバ#2及びスレーブサーバ#3のリソース使用状況もスレーブ サーバ#1のリソース使用状況と類似している。 (%)CPU使用素(Gバイト)メモリ使用量 A :! AょょAAにAk a)OO ariisraisig PfWYYYY?77fイ1トワデューー 0 10 20 30 40 50⑳②)"0 10 20 30 40 50 60(分) (Mバイトノ秒)ディスクYO速度凡例 ーーーーーニニニコター 40注記各グラフの横軸はジョブ開始時からの =ューーー a 4ニー 0 10 20 30 40 50 60(分) M2各サーバのリソース使用状況 Tさんは,ボトルネックとなったリソースを特定して適切な対策を講じることによ って,ジョブ(B)を目標処理時間内に完了させることができた。 [スケールアウトの計画] 今後はPOSデータの購入元を増やし,分析精度を高めることを検討している。1 年後には取り扱うPOSデータの件数を現在の10億件週から30億件プ週に増大さ せることが目標である。処理対象のデータ件数が増えると一部のジョブが目標処理時 間内に完了しなくなる懸念があるので,並列分散処理基盤のスレーブサーバの増設 (以下,スケールアウトという)を計画しておくことになった。性能テストにおいて 調査した,POSデータの件数と処理時間の関係,及び多重度と処理時間の関係を図3 に示す。Tさんは,1年後のスケールアウトに向けて予算を確保するために,図3を 基に追加が必要となるスレーブサーバの台数を試算した。 POSデータの件数と処理時間の関係多重度と処理時間の関係 (時間)(多重度が9の場合)(時間)(POSデータの件数が10億件の場合) 6.0 13.5@、、、 へ9.0 2.0 L6 4.0 04 08 a 58.。10 4.0 294-、。2 20 0.0 oy"0.2 0.37 0.4 0.0 ia i 02馬0.4-まーーをーーー4 05 ews a lta 1.0 2 4 6 8 10(億件)1 3 9(多重度) 凡例—e—a7(A)eeジョブ(B)-%-ジョブ(C)…*…ジョブ(①D) B43性能テストにおいて調査した性能特性 1年後にPOSデータの件数が3倍になること,及び図3 POSデータの件数と処 理時間の関係におけるジョブ(A)~て(C)の傾向から,1年後の並列分散処理基盤に要求 されるスループットは現行の並列分散処理基盤の3倍と推定される。処理時間が POSデータの件数に依存しないジョブ(D)はスケールアウトにおいて考慮する必要が ない。図3の多重度と処理時間の関係から,スケールアウトにおいて考慮する必要 があるジョブのうち,多重度を増やしても処理時間が最も短縮されにくいジョブはジ ョブ(A)である。多重度を3倍にした場合,ジョブ(A)におけるスループットは2倍と なる。並列分散処理基盤のスループットを3倍にするために最低限必要な多重度は, 現行の並列分散処理基盤の|b|倍にあたる|c|であぁる。したがって, 1年後までに少なくとも| q|台のスレーブサーバを追加する必要がある。

共通の文章

Webシステムの負荷分散と不具合対応に関する次の記述を読んで,設問1ー3に答 Kao D社は,小売業を営む社員数約300名の中堅企業であり,取り扱う商品の販売数が 順調に増加している。D社では,共通基盤となるWeb業務システム上で販売管理や 在庫管理,財務会計などの複数の業務機能がそれぞれ稼働している。 Web業務システムは,Webサーバ機能とアプリケーションサーバパ機能の両方を兼 ね備えたサーバ(以下,Webサーバという)3台と負荷分散装置(以下,LBという) 1台,データベースサーバ(以下,DBサーバという)1台で構成される。 D社では総務部がWeb業務システムとネットワークの運用管理を所管しており, 情報システム課のEさんが運用管理を担当している。Web業務システムを含むD社 のネットワーク構成を図1に示す。 「172.16.10.5 172.16.10.11 172.16.10.12 172.16.10.13 I サー1 ZB)[783 : !172.16.10.20 DB 1 eB|| 172.16.10.1ーーWeb業務システム サーバサーバ |i 1|L3SW:レイヤ3スイッチ !i i L2SW:レイヤ2スイッチ iL Pc」…LPcli Pc」…LPcliiLEc」…LEc PW:ファイアウォール 総務部営業部企画部 注記図中のIPアドレスのサブネットマスクは,全て255.255.255.0である。 図1 D社のネットワーク構成(抜粋) 各部署のPCは起動時に,DHCPサーバから割り当てられたIPアドレスなどでネ ットワーク設定が行われる。PCから販売管理機能を利用する場合,販売管理機能を 提供するプログラムに割り当てられたURLを指定し,Webブラウザでアクセスする。 | (LBによるWebサーバの負荷分散の動作] LBは,各部署のPCからWebサーバに対するアクセスをラウンドロビン方式で Webサーバ1~3に分散して接続する。LBを利用することによって,Webサーバ1 台で運用した場合と比較して,応答性能と可用性の向上を実現している。 WebブラウザでWeb業務システムのURLを指定してアクセスすると,LBは, Webサーバを一つ選択して,当該サーバ宛てにパケットを送出する。例えば,Web サーバ2が選択された場合,LBはパケットの送信元のPアドレスを| 。a|, 送信先のTPアドレスを| b|に置き換えてパケットを送出する。 またLBは,pingコマンドを用いたヘルスチェック機能を有しており,pingコマン ドに対して応答しなかったWebサーバへのアクセスを停止する。 〔不具合事象の発生〕 ある日,Web業務システムの定期保守作業において,販売管理機能のプログラム をバージョンアップしたところ,応答時間が急に遅くなり,Webブラウザにエラー が表示される,という報告が営業部から情報システム課に多く寄せられた。 〔不具合事象の切分け〕 営業部の多くのPCで同様な事象が発生していたので,EさんはPCが原因ではな いと考え,PCとWebサーバ間の通信に不具合が発生したと考えた。 Eさんは,営業部のPCを利用して,原因の切分けを行った。確認項目と確認結果 を表1に示す。 ー27一 表1確認項目と確認結果 1|PCからLBへのpingテストの結果は良好|pingテストの結果は全て良好だった。 か。また,LB PS Webサーバ1~3への pingテストの結果は良好か。 2|L2SW,。L3SW,LBの各システムログファ|問題となるメッセージはなかった。 イルに問題しなるメッセージがあるか。 3|PCでコマンドを用いた,社内|名前解決テストの結果は良好だった。 DNSサーバの名前解決テストの結果は良好 か。 4|Webサーバ1て3のHTTP通信ログファイ|Webブラウザにエラーが表示されたときの ルに問題となるメッセージがあるか。WebサーバとPC HICSS HTTP通信メ ッセージそのものが存在しなかった。その とき以外のメッセージには,問題となるメ ッセージはなかった。 5|Webサーバ1て3への同時アクセス数が設|同時アクセス数は設定最大値以内であるこ 定最大値を超えていないか。とを通信ログから確認できた。 Webサーバ1~3のシステムログファイル|WebサーバからDBサーバへのアクセスエ に問題となるメッセージがあるか。ラーメッセージ,及びTCPポートが確保 できないという内容のエラーメッセージが あった。 7|DBサーバのシステムログファイルに問題|問題となるメッセージはなかった。 となるメッセージがあるか。 Eさんはここまでの調査結果を整理して,今回の不具合の原因として想定される被 疑筒所について次のような仮説を立てた。 項番1と2の結果から,PCとWebサーバ1~3の間のTP層のネットワーク通信に は間題がない。また,項番3の結果から,Web業務システムのURLに対する名前解 決にも問題はない。項番4と6の結果から,①特定のWeb画面を表示するときだけ, WebプラウザでHTTP通信がタイムアウトとなり,タイムアウトエラーを表示して いると考えた。 Eさんは,ネットワーク通信の不具合についての仮説に対する確認テストを行うた めに,Web業務システムを開発したF社のテスト環境を利用して不具合を再現させ, ネットワークモニタとシステムリソースモニタを利用して状況を詳細に調べたところ, Webサーバ1~3で利用可能なTCPポートが一時的に遷する事象が発生している ことが分かった。 F社から,Webサーバ1ュー3での利用可能なTCPポート数の増加,④Webサーバ1ュ ~3でのTCPコネクションが閉じるまでの獲予状態であるTIME_WAIT状態のタイ ムアウト値の短縮,及び販売管理機能のプログラムの実行環境においてWebサーバ からDBサーバへの通信時のTCPポート再利用について,Eさんは改善項目の回答 をもらつた。 [改善すべき問題点】 Eさんは,不具合の修正が終わった後に,不具合の切分け作業の問題点を考えた。 @Webサーバ1~3やL3SW,LBのそれぞれに記録されたログメッセージの対応関係 の特定を推測に頼らざるを得ず難しかった。また,Webサーバで通信ログを調べる 際に④送信元のPCがすぐに特定できなかった。 Eさんは,ネットワーク運用の観点から改善策の検討を進めた。

共通の文章

継続的1シテグレーションに関する次の記述を読んで,設問1ご4に答えよ。 C社は,会員間で物品の売買ができるサービス(以下,フリマサービスという)を 提供する会社である。出品したい商品の写真をスマートフォンやタブレットで撮影し て簡単に出品できることが人気を呼び,C社のフリマサービスには,約1,000万人の 会員が登録している。 C社には,サービス部と開発部がある。サービス部では,フリマサービスに関する 会員からの問合せ・クレーム・改善要望の対応を行っている。開発部は,フリマサー ビスを利用するためのスマートフォン用アプリケーション(以下,X EWS),タブ- レット用アプリケーション(以下,Yという),及びサーバ側アプリケーション(以 下,Zという)について,開発から運用までを担当している。 競合のW社が新機能を次々にリリースして会員数を増加させていることを受け, C社でも新機能を早くリリースすることを目的に,開発プロセスの改善を行うことに Bok,開発プロセスの改善は,開発部のD君が担当することになった。 〔課題のしアリング〕 D君は,開発部とサービス部に現状の開発プロセスの課題をヒアリングした。 開発部:リリースするたびに,追加・変更した機能とは直接関係しない既存機能 で障害が発生しており,会員からクレームが多数出ている。機能師 加・機能変更に伴い,設計工程では既存機能に対する影響調査を,テ スト工程ではテストの強化を行っている。しかし,①既存機能に対す る影響調査とテストを網羅的に行うことは,限られた工数では難しい。 サービス部:会員からのクレームや改善要望は日々記録しているが,現在の開発サイ クルでは改善要望の対応に最大6か月掛かる。改善要望をまとめて大 規模に機能追加する開発方法から,短いサイクルで段階的に機能追加 する開発方法に変更してほしい。 [継続的インテグレーションの導入] D君は,既存機能に対するテストを含めたテストの効率向上及び段階的な機能追加 を実現するために,フリマサービスの開発プロジェクトに継続的インテグレーション .ー40一 (以下,CIという)を導入することにした。CIとは,開発者がソースコードの変更 を頻繁にりポジトリに登録(以下,、チェックインという)UT,ビルドとテストを定 期的に実行する手法であり,La|に採用されている。CIの主な目的は |b|,[<],及びりリースまでの時間の短縮である。 D君は,開発用サーバにリポジトリとCIツールをインストールし,1に記載の ワークフローとアクティビティを設定した。D君が設定したワークフローでは,リポ ジトリからソースコードを取得し,コーディング規約への準拠チェックとステップ数 のカウントの後に,各アプリケーションのビルドと追加・変更箇所に対する単体テス トを行い,テストサーバへ配備して,全アプリケーションを対象とするリグレッショ ンテストを実行する。 またD Blk,このワークフローを2時間ごとに実行するように設定し,各アクテ ィビティの実行結果は正常・異常にかかわらずX,Y,Zの担当チームメンバ全員に 電子メール(以下。メールという)で送信するように設定した。 BBS,ワークフロー内のアクティビティは,前のアクテイビテイィが全て正常終了し た場合だけ,次のアクティビティが実行できるようにした。 yonレジーre 注記1フォークとは,ここからアクティビティを並行に実行することを指す。 WBI 図1 D君が設定したワークフローとアクティビティ [テストプログラムの作成] D君は,単体テストで利用するテストプログラムを作成した。テスト対象のプログ ラムとテストプログラムの例を図2に示す。テスト対象のプログラムである checkTimeは,時と分を示す二つの整数値を引数hourとminで受け取り,hourが0 以上24未満の値かつminが0以上60未満の値であったらtrueを返し,それ以外の 値であったらfaseを返すプログラムである。一方,テストプログラムである test checkTimeは,境界値テストの考え方に基づき,6種類の境界値に対してそれぞ ー41一 れcheckTimeを呼び出し,全ての呼出しで仕様どおりの値を返したらtrueを,それ 以外ならfalseを返すプログラムである。 また,D君はこれまで手作業で行っていたリグレッションテストについてもCIツ ールで自動実行できるように,テストプログラムを作成した。 なお,新機能のリリース後には,新機能の単体テストで用いたテストプログラムは, リグレッションテストのテストプログラムとして再利用することにした。 //テスト対象のプログラム//テストプログラム function checkTime(hour,min)function test checkTime() if(hourが9よりも小さい又は24以上)if(checkTime(-1,0)がfalseと等しいかつ return false checkTime(24,9のが[|qa|と等しいかつ else if(minが9よりも小さい又は69以上)checkTime(0,-1)がfalseと等しいかつ return false checkTime(9,69)がfalseと等しいかつ end if checkTime(0,9)がtrueと等しいかつ :return true checkTime(23,59)a*trueと等しい) end function return true end if return false end function 2テスト対象のプログラムとテストプログラムの例 (CIの試行〕 次にD Blk,フリマサービスのアプリケーションの全てのソースコードをリポジ トリに移行し,CIの試行を開始した。試行開始から1か月後,D君の設定したCIツ ールは問題なく動作していたが,開発部のメンバから次の3点を指摘された。 指摘1:一つの要求を実現するために必要なソースコードの変更は多岐にわたるので, チェックインは1週間に1回程度行っている。ワークフローは2時間ごと に動作するように設定されているが,1週間に1度で十分である。 指摘2:Yの単体テストでエラーが検出されていたが,CIツールから送信されるメ ールが非常に多く,Yを担当するチームはエラーに気付かず,1日放置され ていた。⑨②開発者がエラーに気付くように,CIツールから送信されるメー ルを限定してほしい。 指摘3:Xのビルドでエラーが検出され,単体テストまでワークフローが流れないこ とが多い。このため,Zを担当するチームでは,開発者の開発PC上でCI ツールと同じテストケースを実行しており,⑨CIの導入効果が出ていない。 D君は,この3点の指摘について必要な対策を実施するとともに,要件定義から設 計までのプロセスの見直しも行い,フリマサービスの開発プロジェクトにCIを適用 した。その結果,段階的な機能追加を実現させ,新機能のリリースサイクルを短縮し だ。

共通の文章

査に関する次の記述を読んで,設問1ー5に答えよ。 Y社は,RF,飲料などを扱う中堅の食品会社である。Y社では,これまで自社開 発した受発注管理,在庫管理,生産管理,財務会計の各システムを利用していたが, 全社的な業務の効率向上のためにERPソフトウェアパッケージを採用した基幹シス テム(以下,新システムという)を導入することになった。 Y社情報システム部には,ERPソフトウェアパッケージの導入経験・開発ノウハ ウがないことから,新システムの導入に際してERPソフトウェアパッケージの販売 代理店であるITベンダのZ社に導入作業を委託した。 Y社監査室は,新システムの本番稼働から3か月が経過し,安定稼働に入った段階 で,新システムの運用・保守管理体制についてシステム監査を実施することにした。 [新システムの予備調査〕 Y社監査室が予備調査で入手した情報は,次のとおりである。 (1)導入概要 新システムは,ERPソフトウェアパッケージの販売管理,購買管理,在庫管理, 生産管理,財務会計のモジュールから成る。企画段階では,費用面を考慮し,ERP ソフトウェアパッケージの機能に業務を合わせてそのまま利用する方針であつった。 しかし,販売管理については,営業部門から,複数の食品卸業者との受注管理,リ ベート情報管理などの業界及びY社固有の取引慣行に対応する必要があるとの要 望を受け,これに対応する追加機能開発を行った。その他,購買管理,在庫管理, 生産管理,財務会計たこついても,各利用部門と調整した結果,規模の大小はあるが 追加機能開発を行った。 Y社情報システム部は,現行業務の分析,要件定義,設計書の内容に関する各利 用部門との調整のほか,テスト計画の作成,Z社が実施したテスト結果のレビュー などを担当した。 2)新システムの保守管理体制 新システム稼働後の保守作業は,引き続きZ社に委託している。新システムの 導入段階では,Z社開発チームがY社に常駐して,管理者権限を付与された開発用 ー58一 IDを使用して追加機能開発,本番環境の設定などを行っていた。本番稼働後は,Y 社情報システム部が本番環境の管理を行うことにしたが,開発用IDは削除せず, 管理者用IDを新たに登録した。Z社の保守担当者はZ社内の保守用端末からリモ ートアクセスし,開発環境及びテスト環境だけにアクセス可能な保守用IDを使用 して保守作業を実施することにした。保守作業の手順は次のとおりである。 ①Y社からの依頼に基づき,Z社の保守担当者が開発環境でプログラムの追加作 成や変更作業を行った後,テスト環境でテストを実施する。 ②Y社が受入テストを実施し,問題がなかいことを確認した後,Z社の保守担当者 が本番環境へ移行するプログラムの準備を行い,Y社に移行申請を行う。 ③Y社情報システム部の担当者が移行処理を実行すると,テスト環境から本番環 境へプログラムが移行され,登録される。 ④Z社が実施した保守作業の内容や日時などが記載された保守作業記録が,Z社 内で承認され,毎月Y社に提出される。 (3)新システムのID管理 保守用IDなどのアクセス権限管理は,Y社情報システム部が“アクセス権限管 理規程"を定めて実施している。“アクセス権限管理規程"の内容は次のとおりで ある。 ①業務メニューだけが利用可能な一般利用者用D 利用部門が“ID登録申請書"を作成し,利用部門責任者の承認と情報システ ム部長の承認を受け,情報システム部担当者が登録・変更・削除を行う。 @ERPソフトウェアパッケージの管理者権限が付与された管理者用D 本番環境の設定,プログラム登録,全てのIDの登録・変更・削除のために, 情報システム部担当者だけが使用する。使用の都度“管理者用ID使用申請書" を事前に作成し,情報システム部長の承認を受ける。パスワードは使用の都度, 情報システム部のID管理者がID使用者に通知し,使用後に変更する。管理者 用IDについては,ERPソフトウェアパッケージの機能を利用したアクセス履歴 及び操作記録(以下、アクセスログという)が取得される。 ③Z社が使用する保守用ID Z社から提出された“保守用ID登録申請書"に基づき,Y社情報システム部 長の承認を受けた後,情報システム部担当者が管理者用IDを使用して登録・変 ー59一