分散 Web システムにおける DNS を用いた負荷分散機構の実装と評価
12T270 森垣 航太 (最所研究室)
負荷量に応じてキャッシュサーバの台数を動的に変更することでリソースとコストの最適化を行なう
分散 Web システムにおいて，DNS を用いた負荷分散機構の実装とその評価について述べる．

1

はじめにインターネット利用者の増加により，Web サーバにかかる負荷が増加している．負荷が増加し続けることでレスポンスタイムの悪化や，サーバがダウンしてしまう可能性があるため，高負荷時でもサービスを維持し続けられるシステムが必要になる．近年ではクラウ
ド上にキャッシュサーバを容易に構築し，手軽に負荷を分散させることが可能になった．しかし，負荷量に応じて適切にキャッシュサーバの台数を管理しなければ，応答性が十分に向上しなかったり，余剰なリソースによる不要なコストが発生したりしてしまう．
そこで本研究室では，クラウド環境において，負荷量に応じて動的にキャッシュサーバの台数を増減することでリソースとコストの最適化を行なう分散 Webシステムを開発しており，ロードバランサを用いて負荷分散を行う機構が研究されている [1]．この方法では，負荷が増加した際にロードバランサそのものがボトルネックになる可能性がある．このため本研究では，ロードバランサのようなボトルネックが生じにく
い DNS を用いた負荷分散機構の実装を目指す．

2

システムの概要

提案しているシステムの概要を図 1 に示す．負荷監視機構はオリジンサーバやキャッシュサーバの負荷を監視し，負荷量に応じてキャッシュサーバの起動・停止と，DNS 管理機構へ追加・削除要求の通知をする．
DNS 管理機構は通知を受け取り，その通知内容を元に DNS の振分け先更新を行なう．リクエストの振分
けは DNS のラウンドロビン機能を用いる．

3

設計及び実装3.1

負荷監視機構負荷量として，堀内 [1] が開発した Apache の最大同時処理数に対する現在の処理数の割合 (稼働率) を用いる．閾値を 2 つ設定し，上限の閾値を超えた場合はキャッシュサーバを追加，下限の閾値を下回った場
合にはキャッシュサーバを削除する．追加・削除時には DNS 管理機構へ振分け先更新の通知を行なう．

‫☎✄✂ ✁؞‬⋇य़কॵ३গ१‫ش‬ংକ৿⋈ஷীऐ੔୯ਸਏ੷
⋉'16の振分け先更新ॡছॖ॔থॺ੡৐ੰৠ
'16१‫ش‬ংड़জ४থ१‫ش‬ংஷীऐ੔更新୯ਸచ௾ਏ੷

'16管理機構‫✝✆✂ ✁؞‬॔ॡ७५ীങ଀෰૰ଳਃଡ଀෰૰ଳକ৿‫؞‬೿ૃ⋇ஷীऐ੔చ௾ਏ੷
⋈'16の振分け先更新⋉य़কॵ३গ१‫ش‬ং೿ૃॡছक़ॻ঱भय़কॵ३গ१‫ش‬ং

図 1: DNS を用いた負荷監視機構

3.2

DNS 管理機構

負荷監視機構から受け取った通知を元に，BIND のnsupdate コマンドを用いて振分け先を更新する．また，BIND のロギング機能により振分け先更新の結果のみをログに出力し，監視する．

44.1

評価
DNS の設定反映時間の評価

DNS を用いた方式では，DNS キャッシュにより設定変更の反映に遅れが生じる．そこで，ドメイン名の情報を管理する DNS サーバ 1 台，DNS キャッシュ
サーバ 3 台，クライアント 18 台を用いて，2 パターンの経路における振分け先の更新反映時間への DNSキャッシュの影響を調べた．一定時間ごとに管理 DNSで問い合わせの対象となっている IP アドレスの追加・削除を交互に行い，クライアントの問い合わせ結果に反映されるまでの時間を計測する．キャッシュの有効期限である TTL は 15 秒とする．問い合わせ経路には DNS キャッシュサーバを 1 台経由するパターン Aと，2 台経由するパターン B を設けてあり，どちらもfowarders 機能により，キャッシュを持っていない場合に次の DNS へ名前解決を回送する．クライアントは，それぞれのパターンで 3 台ずつ問い合わせる間隔を変え，指定したドメイン名の問い合わせを行う．

パターン A の場合は最短で 4 秒，最長で 15 秒で設定が反映された．パターン B の場合は最短で 4 秒，最長で 14 秒で設定が反映された．どちらも TTL の値である 15 秒以内に反映されており，経由する DNS サーバの台数による設定反映時間への影響はないといえる．
この結果から，DNS キャッシュによる設定反映の遅延は TTL の値以内であり，キャッシュサーバ追加・削除時にはその程度考慮すればいいとわかった．

✁ ✂✄☎ ✆✝
'16
管理サーバय़কॵ३গ१‫ش‬ং

'16ᇍ๚৓ऩঝ‫ॺش‬१‫ش‬ং

'16
'16य़কॵ३গ१‫ش‬ং

負荷分散機構及び DNS の管理機構の評価ॡছॖ॔থॺ

図 2 に示す環境で，負荷監視機構と DNS 管理機構により，負荷量に応じたキャッシュサーバの管理と負荷分散が行えるか評価を行った．すべてのサーバは 2 台のハイパーバイザ上に仮想マシンとして構築している．
以下の手順で実験を行なった．

1. 同時リクエスト数を 60 秒毎に 100 ずつ増加．

✁ ✂✄☎ ✆✞

まとめ分散 Web システムにおける DNS を用いた負荷分散機の概要と各機構の実装について述べた．さらに DNSय़কॵ३গ१‫ش‬ংକ৿‫؞‬೿ૃ

य़কॵ३গ१‫ش‬ং଀෰૰ଳ଀෰૰ଳਃଡ

ਈপ৊ৎ॔ॡ७५ य़কॵ३গ१‫ش‬ং✌✁ ✂✄☎✆✝✞✠✟✡☛☞✎✍

3. 120 秒経過後，60 秒毎に同時リクエスト数を 0 になるまで 100 ずつ減少．

5,3॔ॻঞ५ৢੴ

図 2: 各機構の評価実験における構成図

2. 同時リクエスト数が 500 に達した後，120 秒間その状態を維持．

それぞれのサーバの同時処理数は 150 に設定する．キャッシュサーバ追加の判断には直前の平均稼働率を，停止には直前 5 回分の平均稼働率の移動平均を用いる．
キャッシュサーバを起動させる閾値が 0.6 の場合の結果を図 3，0.8 の場合の結果を図 4 に示す．どちらも停止させる閾値は 0.1 とする．直前の平均稼働率を high，5 回分の平均稼働率の移動平均を low としている．
同時リクエスト数が 200 になると，どちらも平均稼1 ．その働率が急激に増加し，1 まで上がっている (⃝)
後，平均稼働率が閾値を超えたことでキャッシュサーバが起動し負荷分散が行われ，平均稼働率が減少してい2 ．その後，最大リクエスト数が減ることがわかる (⃝)
3 ．
少すると平均稼働率も減少していることがわかる (⃝)
キャッシュサーバ停止後は振分け先が減るため，平均稼働率が増加している．また，各閾値でのキャッシュサーバ台数最大時の稼働率の合計は閾値が 0.6 の場合は0.6×(4+1) = 3.0，0.8 の場合は 0.8×(2+1) = 2.4 とな
る．0.8 の場合，もう 1 台起動すると 0.8×(3+1) = 3.2となり，閾値が 0.6 の時のキャッシュサーバ台数が 4 台のときより大きくなる．このことから，閾値を変更した場合でもある程度同じ処理能力分のキャッシュサーバの起動ができていることがわかる．
以上の結果より，負荷量の計測とそれに伴うキャッシュサーバの追加・削除とリクエストの振分けが出来ていることが確認できた．

'16管理機構य़কॵ३গ१‫ش‬ং

ਖः়ॎच

4.2

振り分け先更新ड़জ४থ१‫ش‬ং

図 3: 実験結果 (閾値:0.6)✂☎✆✝✞✟✠✡
☛☞✌✍✎

✁
✄

図 4: 実験結果 (閾値:0.8)
キャッシュの DNS の設定反映時間への影響を調べ，実装したシステムの評価を行った．
今後は，振分け先サーバの性能差や負荷状態による振分けの重み付けや，急激な負荷の上昇に対するキャッシュサーバの複数台追加について検討する．

参考文献[1] 堀内晨彦，最所圭三，“クラウドに適した Web シス
テムにおけるキャッシュサーバの負荷監視および負荷分散”，電子情報通信学会技術研究報告，IN201429，pp.79-84，2014