解説

• 〔aについて〕
  スマートフォンやタブレット端末の登場より、Webページは様々なディスプレイサイズで閲覧されるようになりました。スマートフォン黎明期には、PCサイトとスマートフォンサイトを別個に作成するのが定番でしたが、最近では1つのHTMLファイルを用意し、CSSのメディアクエリによって画面サイズごとの表示を制御する手法が一般的になっています。画面サイズ（実際にはブラウザの描画領域のサイズ）に応じて、適切なデザイン／レイアウトに切り替えて表示する手法を「レスポンシブWebデザイン」（単に、レスポンシブデザインとも）といいます。
  
  問題文中の「一つのWebサイトで全ての種類の端末に最適な画面を表示できるようにする」より、レスポンシブWebデザインを採用することがわかるので、空欄aには「CSS」が当てはまります。
  
  CSSのメディアクエリとは、媒体の種類、表示領域の幅や高さ、表示領域の幅と高さの割合、デバイスの解像度などのメディア特性に応じて、適用するスタイルを変える機能です。例えば、デスクトップPC向けの表示ではサイドメニューを常時表示する一方、画面幅が狭いスマートフォンでは開閉式にするなどの制御が可能です。以下は、メディアクエリを記述する@media構文を利用して、表示幅ごとに異なるスタイルを定義する例です。
  
  @media screen and (max-width:480px) {
  　/* 表示領域幅480px以下の場合は、ここに記述されたスタイルを適用 */
  }
  @media screen and (min-width:768px) and (max-width:1024px) {
  　/* 表示領域幅768px以上1024px以下の場合は、ここに記述されたスタイルを適用 */
  }
  @media screen and (min-width:1024px) {
  　/* 表示領域幅1024px以上の場合は、ここに記述されたスタイルを適用 */
  }
  
  • 正しい。レスポンシブWebデザインでは、CSSのメディアクエリを利用することでデバイスごとに最適な表示を実現します。
  • DOM(Document Object Model)は、HTMLやXMLで記述された各要素をプログラムから取り扱うためのAPIです。HTMLは単なるテキストデータなので、そのままではHTMLタグで記述された各要素を個別にプログラムで操作することができません。HTMLで書かれたページをメモリ内でオブジェクトとして表現することで、プログラムから要素やその属性、値などを操作できるようにするインタフェースがDOMです。
  • HREF(Hypertext Reference)は、アンカーリンクを定義するaタグなどと組み合わせて使われるHTML属性の一つで、リンク先や目的とする資源の場所を指し示すものです。
    
    //aタグのリンク先を指定
    <a href="https://www.ap-siken.com/">サイトトップページへ</a>
    //HTML文書にリンクするCSSファイルを指定
    <link rel="stylesheets" href="newslayout.css">
  • Pythonは、簡潔な文法と使いやすさを特徴とする汎用の高水準プログラミング言語です。対応するプラットフォームの多さ、機械学習・データ分析・画像処理・数値演算など幅広い分野の優れたライブラリの存在により、Webアプリケーション、データ分析、機械学習を用いた人工知能開発など様々な分野で使用されています。
  ∴a＝ア：CSS
  
  
• 構造化データを記述するための汎用的なデータ形式としては、XML、JSON、CSV、YAMLなどがありますが、WebブラウザとWebサーバ間の通信において、標準的に使われているのはJSONです。
  
  JSON(JavaScript Object Notation：ジェイソン)は、以下の例のように": (コロン)"で連結した名前と値の組を", (コンマ)"で区切って指定するデータ形式です。元々JavaScriptにおけるオブジェクト定義用の構文という位置付けでしたが、その軽量性と汎用性からRFC8259として標準化され、多くのプログラミング言語で利用されるようになりました。
  
  {
  　名前1: 値1,
  　名前2: 値2,
  　名前3: [値5, 値6],
  　名前4: {名前7: 値7, 名前8: 値8}
  }
  通常、Webブラウザ上で動作するスクリプトはJavaScriptで実装されます。JSONはJavaScriptの基本データ形式のひとつであることから、JavaScriptにはJSONデータを解析し、アクセスし、操作する機能が標準的に備わっています。また、他のデータ形式として軽量であり、Webブラウザとサーバ間の通信量を抑えられる利点があります。このような理由から、Webサービスのデータ交換の形式としては、JSONが使われることが一般的です。
  
  ∴b＝JSON
  
  
• LFU方式とは、Least Frequently Usedの略で、最も使用頻度の低いデータを置換え対象とするアルゴリズムです。言い換えると、使用回数が少ないデータから置き換えていくということです。LFU方式では、使用回数が多いデータは長くキャッシュに残り、使用回数が少ないデータは早々に置換え対象となります。この特徴を踏まえると、記事をLFU方式で管理する場合、利用者から高い頻度で閲覧される記事ほどキャッシュサーバに残ることになります。したがって、解答としては「参照回数が多い記事」「アクセス数が多い記事」「閲覧頻度が高い記事」などが適切となります。
  
  ∴参照回数の多い記事

解説

1. Webブラウザからのリクエストを受けたWebサーバが、HTMLやスクリプトなどのファイルをWebブラウザへ転送する
2. Webブラウザが、受信したファイルを解析する
3. Webブラウザ上のスクリプトが、"ITNewsList"を呼び出す
4. APが、応答データをWebブラウザへ転送する
5. Webブラウザが、受信した応答データの内容を整形し、画面を描画する

• 方式(1) … 100＋80＝180ms
• 方式(2) … 200＋80＝280ms

• 方式(1) … 60ms×0.6＋300ms×0.4＝156ms
• 方式(2) … 120ms×0.9＋300ms×0.1＝138ms

• 方式(1) … 156ms＋15ms×6＝246ms
• 方式(2) … 138ms＋20ms×6＝258ms

解説

• 〔ghについて〕
  表3より、ITニュース記事画面を生成する際には、表示させたい記事のデータを取得する"ITNewsDetail"と、それに関連する記事を取得する"ITNewsHeadline"のどちらもがWebブラウザ上でスクリプトを実行して呼び出されることがわかります。特に"ITNewsHeadline"は、関連する記事を一つずつ呼び出すために6回分の通信（1回ごとにリクエスト＋レスポンスの1往復）が発生することになるので、一つのニュース記事画面と関連する記事を表示するためには「1＋6＝7回」の通信が発生することになります。全部のデータを取得し終えるまでコンテンツの描画が行われない仕様なので、インターネットの転送時間が上乗せされることにより応答時間の悪化が懸念されます。
  
  ITニュース記事画面の仕様上、記事データが表示するときには必ず関連する記事のデータも表示することになっています。応答時間の改善を図るために通信回数を減らすことを考えると、Webブラウザから"ITNewsHeadline"を都度呼び出すのではなく、"ITNewsDetail"の呼び出しを受けたAPが内部的に"ITNewsHeadline"を呼び出して、6つの関連記事データを取得することが効果的な改修策として考えられます。これにより1度の通信で必要なデータをWebブラウザに渡すことができるので、応答速度の改善が見込まれます。
  
  ∴g＝ITNewsDetail
  　h＝ITNewsHeadline
  
  
• 〔キャッシュサーバの実装方式の検討〕に「APのCPU使用率が高い場合，Web APIの応答速度を優先するために，（キャッシュデータの）更新処理は行わない」との記述があります。つまり、APのCPU使用率が高くなった場合、本来5分間隔で行われるべきITニュース一覧画面に表示する記事一覧と、関連する記事一覧のデータの更新が行われないことになります。その結果として、いつまでも古いデータが表示されてしまう不具合が生じます。したがってここで起きる問題とは、「ITニュース一覧と各記事に関連する記事の一覧が更新されない」となります。
  
  ∴ITニュース一覧と各記事に関連する記事の一覧が更新されない
  
  
• 現状、記事同士の関連性に関するデータは、Webサーバのアクセスログを基に、URL中の記事番号を用いたアクセス解析を行うことで取得されています。具体的には、利用者ごとにアクセスしたURLの履歴を調べることで、ページ遷移の分析などを行います。
  
  SPAではWebサーバにアクセスするのは初回アクセス時のみで、その後はWebブラウザとAPとのデータ交換により必要な部分のみが変更されていくので、Webサーバのアクセスログには初回アクセス時のURLは記録されるものの、その後どの記事にアクセスしたのかのログが残らないという問題があります。

  マルチページアプリケーション（MPA）

  WebサーバはWebブラウザからリクエストを受ける度にURLに基づいて新たなHTMLを生成し、Webブラウザに返す。そのためアクセスする度にWebサーバにはURLの履歴が残る

  

  シングルページアプリケーション（SPA）

  WebサーバはWebブラウザからリクエストを受けると、必要となるHTMLやCSS、JavaScriptを返す。その後はWebブラウザとAPとの通信により必要な部分のみが更新されていくため、Webサーバ上にはURLの履歴が残らない

  

  このため、Webサーバのアクセスログだけでは、利用者がどのように記事を閲覧し、どんな記事からどんな記事へ遷移していったかの流れをたどることができなくなります。このため、システム変更後はAPのアクセスログに記録されることになる参照された記事番号のデータなどを併用して、記事の関連性を分析する必要があります。
  
  したがって、関連する記事が見つけられない理由としては、Webサーバのアクセスログだけではページ遷移がわからないという点を主軸に解答することになります。
  
  ∴記事間の遷移がWebサーバのアクセスログのURLでは解析できないから