ITニュース配信サービスの再構築

H社は，IT関連のニュースを配信するサービスを提供している。このたび，OSや開発フレームワークの保守期間終了を機に，システムを再構築することにした。

〔現状のシステム構成と課題〕

ITニュース配信サービスでは，多くの利用者にサービスを提供するために，複数台のサーバでシステムを構成している。配信される記事には，それぞれ固有の記事番号が割り振られている。現状のシステム構成を図1に，ニュースを表示する画面一覧を表1に示す。

クリックで拡大

図1　現状のITニュース配信サービスのシステム構成

現状のシステム構成では，PC，タブレット，スマートフォン，それぞれに最適化したWebサイトを用意している。APでは，RDBとのデータ入出力とHTMLファイルの生成を行っている。また，関連する記事を見つけるために，夜間にWebサーバのアクセスログをRDBに取り込み，URL中の記事番号を用いたアクセス解析をRDB上のストアドプロシージャによって行っている。

最近，利用者の増加に伴い，通勤時間帯などにアクセスが集中すると，応答速度が遅くなったり，タイムアウトが発生したりしている。

〔新システムの方針〕

この課題を解消するために，次の方針に沿った新システムの構成とする。

APで提供するWeb APIを表2に示す。

次に，Webブラウザ上で実行されるスクリプトの概要を表3に示す。

〔キャッシュサーバの実装方式の検討〕

キャッシュサーバの実装方式として，次に示す二つの方式を検討する。

APのOSのスケジューラーが5分間隔で，ITニュース一覧画面に表示する記事の一覧と，各記事に関連する記事の一覧のデータを更新する処理を起動する。(1)の場合，各AP上のプロセスが内部のキャッシュデータを更新する。(2)の場合，特定のAP上のプロセスがキャッシュデータを更新する。

なお，APのCPU使用率が高い場合，Web APIの応答速度を優先するために，更新処理は行わない。

〔応答速度の試算〕

新システムにおける応答速度を試算するために，キャッシュサーバの二つの方式をそれぞれテスト環境に構築して，本番相当のテストデータを用いて処理時間を測定した。その結果を表4に示す。

注記　ms：ミリ秒

インターネットを介した転送時間やWebブラウザ上の処理時間は掛からないと仮定して応答時間を考える。その場合，ITニュース一覧画面を初めて表示する場合の応答時間は，方式(1)では180ms，方式(2)ではcmsである。ITニュース一覧画面のページを切り替える場合の応答時間は，方式(1)では100ms，方式(2)ではdmsである。次に，記事をリクエストした際の平均応答時間を考える。Web API“ITNewsDetail”の平均応答時間は，方式(1)では156ms，方式(2)ではemsである。したがって，Web API“ITNewsHeadline”の呼び出しも含めたITニュース記事画面を表示するための平均応答時間は，方式(1)ではfms，方式(2)では258msとなる。

以上の試算から，方式(1)を採用することにした。

〔不具合の指摘と改修〕

新システムの方式(1)を採用した構成についてレビューを実施したところ，次の指摘があった。

ITニュース記事画面を生成するスクリプトが実際にインターネットを介して実行された場合，試算した応答速度より大幅に遅くなってしまうことが懸念される。Web API“g”内から，Web API“h”を呼び出すように処理を改修する必要がある。

APに処理が偏ってCPU使用率が高い状態が続いた場合，^②ある画面の表示内容に不具合が出てしまう。

この不具合を回避するためには，各APのCPU使用率を監視して，しきい値を超えた状態が一定時間以上続いた場合，APをスケールアウトして負荷を分散させる仕組みをあらかじめ用意する。

関連する記事を見つける処理について，^③現状の仕組みのままでは関連する記事が見つけられない。Webサーバのアクセスログを解析する処理を，APのアクセスログを解析する処理に改修する必要がある。

以上の指摘を受けて，必要な改修を行った結果，新システムをリリースできた。