NAP-Web における優先アクセスの設計と評価

10T236 曽川直也 (最所研究室)
NAP-Web の優先アクセス機構の実装を目指し優先アクセス機構の設計と評価について述べる。
1. はじめに処理
我々の研究室では過負荷時にサービスできないユーザに次回アクセス可能時刻を記載した整理券を配
Run_Ready
布し、そのときのアクセスを保障する Web システムである NAP(NextAccessPromised)-Web を開発してWaitいる。さらに Web サーバとキャッシュサーバ群からなる分散 Web システムの開発も行っている。
Re_Access
本研究では NAP-Web を分散 Web システムのキャッシュサーバのキャッシュの更新や、会話的なサービNext_Wait
スをスムーズに行うことを実現するため、優先アクセス機構の実現を目指している。
NAP-Web に通常のアクセスとは別に、特定のクラスケジューラ
イアントからのリクエストを優先的に処理する優先図 1.優先度調整による優先アクセス機構の概要
アクセスを取り入れた際の性能評価を行う。
山田[1]によって提案された優先アクセス機構を図2. NAP-Web におけるアクセススケジューリング
1 に示す。図 1 では従来のスケジューリンググループ
NAP-Web では次回アクセスを保証するため、ユーに加えて、優先的に処理すべきアクセスを受け入れキザからのアクセスをサーバの状態に応じて以下の 4ューイングするための赤丸で囲んだ優先アクセスグつのグループに振り分け、アプリケーションレベルでループを追加する。優先用のアクセスグループは、通スケジューリングを行なっている。
常のアクセスグループとは区別され、優先して処理す
Run_Ready： OSによって通常通りスケジューリンることができる。処理に割り振るアクセスの配分は、グされ、処理が行なわれるアクセスグループである。
Run_ready を共有し、それぞれのグループのリクエ
Wait：Run Ready からあふれたアクセスが入り、到ストの割合を増やすことで優先度を上げる。
着順にキューイングされる。Run_Ready に空きがで本研究では、追加した優先アクセスグループにきしだい、先頭からRun_Ready に移動する。
Run_ready を個別にもたせそれぞれの同時処理数のNext_Wait：Wait からもあふれたアクセスが入る。
調整により優先度の決定を行う機構を提案している。
一旦処理を拒絶され、再アクセスが可能になる時間が
図 1 の構想は Run_Ready は一つでよいが、それぞ記載された整理券を配布される。
れのグループに入るリクエストの処理時間に偏りがRe_Access：整理券を持ったアクセスが指定された時ある場合使用される計算機 のリソースの割合が、刻に行われた場合に振り分けられ到着順にキューイ
Run_Ready 入るリクエストの割合と異なってしまう
ングされ、Wait に空きができしだい、先頭から Wait問題がある。これは処理時間が長いリクエストが多いに移動する。
グループのリクエストが Run_Ready で滞在する時間が長くなるためである。
3. NAP-Web における優先アクセス機構
本研究で提案した構想は、それぞれの処理に割り当
3.1 優先アクセス機構の概要
てられる計算機のリソースの割合は Run_Ready の大優先アクセス機構は、特定のクライアントからのリきさに比例する。しかし、複数の Run_Ready を用意クエストをグループ化し、優先的に処理を行う機構でする必要がある。この二つの優先アクセス機構の構想ある[1]。サーバが過負荷状態になり、従来通りのアの得失に関しては今後の課題である。
クセススケジューリング機構によって次回アクセスに回されれば、致命的になってしまうようなリクエス
4 .優先アクセスの評価実験
トが存在する。このようなリクエストに対して専用の優先アクセスが入ることによる通常アクセス処理グループを設けて、サーバの負荷状態に関わらず確実への影響の調査を目的とし実験を行った。
なレスポンスを返すようにする。
4.1 実験の概要
設計した優先アクセス機構を実装するに至らなか
3.2 優先アクセス機構の設計ったので、図 2 に示すように特定のクライアントから優先アクセス機構を実装する際の検討事項としてのアクセスを直接処理することで優先アクセスを実既存のアクセスと優先アクセスに対して割り当てる現する。同時優先アクセス数変えることにより、優先計算機資源の量を調整する必要がある。
アクセスに使用するサーバのリソースの割合を変えた負荷実験を行う。ここでは特定の IP アドレスからのアクセスを優先アクセスと判断している。
処理
Run_Ready
Wait
Re_Access優先
アクセス

Next_Wait

スケジューラ

図 2.簡易的な優先アクセスの実装

本実験は優先アクセスを行うクライアントと通常アクセスを行うクライアントを用意し、優先クライアントからの同時アクセス数(同時優先アクセス数)を 0、1、5、10、通常クライアントからの同時アクセス数(同時通常アクセス数)を 1500、3000 と変え、この組み合わせにより実験を行った。
4.2 スループット評価
同時通常アクセス数が 1,500 と 3,000 の時でほとん
ど結果が変わらなかったため、1500 の時の実験結果
のみ図 3 に示す。
図 3 から優先アクセスが始まると、おおよそ優先アクセスのスループット分だけ通常アクセスのスループットが減少していることが分かる。またスループットの減少分の変動が少なく安定したリソースの割り当てが行われていることが分かる。優先アクセスが 5の時と 10 の時でスループットに関してはほとんど変化がないがこの原因調査については今後の課題とする。

図 3.スループット移動平均

紙面の都合上以降の評価では結果の図は省略する。
4.3 応答時間評価
優先アクセスの応答時間は、同時通常アクセス数にほとんど影響されず、非情に短い時間で処理が行われており、優先アクセスが正しく機能していることを確認できた。
優先アクセスが行われていない時の通常アクセスの応答時間は同時通常アクセス数に関わらず 4,000ミリ秒付近で安定していた。優先アクセスが行われることにより同時通常アクセス数が 1,500 の方の応答時間が 5000～9000 ミリ秒になっていたが、3,000 の方は 10,000～16,000 ミリ秒となっており、優先アクセスによる影響が大きく現れた。これは同時アクセス数が倍になった分、優先アクセス時の次回アクセスの数が増えたためである。
4.4 初回アクセス率評価
初回アクセス率は全体のアクセスに対する再アクセスではないアクセスの処理数の割合とする。
同時通常アクセス数が 1,500 の時と 3000 の時はどちらも、優先アクセスが入ってない時はそれぞれ一定値で安定していた。3000 の時の方が初回アクセス率は小さくなっていた。優先アクセスが入るといずれの場合も初回アクセス率が低下していた。特に 3000 の時の方の低下率が大きかった。これは優先アクセスが入った時の応答時間の伸びを反映しており初回アクセスが入る隙間が小さくなったためである。
同時アクセス数 3000 の時優先アクセス終了時点で初回アクセス率が急に上昇した。優先アクセスが入った時のスループット分の次回アクセスが行われるようにしている状態で、優先アクセスがなくなったことにより、その分のリソースが初回アクセスに用いられたためであると考えられる。
4.5 チケット発行時間評価
NAP-Web の整理券には次回アクセスの可能時間が記載されるが、記載される時間はサーバの負荷状況に応じて松浦[2]によって提案された平均スループットを用いた時間予測手法を用いて算出している。
優先アクセスがない時の発行時間は、同時通常アクセス数が 1,500 と 3,000 の時でそれぞれ約 6 秒と約14 秒となっていたのに対し、優先アクセス中はそれぞれ約 15 秒と約 30 秒となった。通常アクセスのスループットに応じて発行時間を延ばすことができていることが確認できた。
5.おわりにNAP-Web の通常アクセス処理は優先アクセスが急に入ると応答時間が伸び、初回アクセス率が急激に低下したり、チケット発行時間が伸びたりといったスケジューリング効率の低下を及ぼすことが分かった。
これの対策として優先アクセスを急に増加させるのではなく、少しずつ増加させることでスケジューリングの効率低下を防ぐことができると考えている。
今後の課題は優先アクセスを少しずつ増加させていった際の通常アクセスに対する影響の調査と、設計した優先アクセス機構の実装である
参考文献[1] 山田茂和. "NAP-Web の時間予測に関する評価と優先アクセス機構の設計",
香川大学工学部, 修士論文, 2013[2] 松浦正尚. "次回アクセスを保証する Web シス
テムにおけるアクセススケジューリング機構の改良",
香川大学工学部, 学士論文, 2012