アークシステムの業務事例

オープン基盤ソリューションの事例

ネットワークの再構築・改善・最適化の事例

高い装置にさようなら ! キャッシュ・プロキシサーバーの負荷分散を安価に

大規模企業様でのネットワーク更改の設計・構築を実施した際、インターネット閲覧のためキャッシュプロキシサーバーを複数台導入しました。その際、高価な負荷分散装置を使用することなく、安価なDNSラウンドロビン方式をフル活用し、負荷分散のみに留まらず高可用性を同時に実現しました。

負荷分散と可用性確保のために高価な負荷分散装置の導入を選択していませんか?

DNSラウンドロビンという古くからの周辺技術の進化を見過ごしていたばかりに、多大なコストを無駄にしているかもしれません。

お客様の業種

情報

お客様の目的

ネットワーク構築・維持コストの適正化

アークシステムの支援の特徴

世の中の主流や従来の常識にとらわれず、顧客の立場からコスト削減するにはどうすればよいかを徹底的に検討する姿勢と、技術力に裏付けられた創意工夫

プロダクト

(キャッシュプロキシサーバー、負荷分散装置、DNSサーバー)

 ポイント

  • 高価な負荷分散装置を導入しなくても負荷分散と高可用性を実現できる
  • DNSラウンドロビン方式の弱点を、Webブラウザの進化が補完する

概要

負荷分散装置には多くのメリットがありますので、一概にその採用を否定するものではありません。ただし、可用性向上のためだけに導入しているのであれば、以下のような代替手段も検討に値すると考えます。
キャッシュ・プロキシサーバーの負荷分散を安価にする事例の概要図

よくある誤解と事実

 DNSラウンドロビン方式によくある誤解と真実の説明図

よくある誤解   事実
  1. DNSラウンドロビン方式では、障害の発生したサーバー(b)にも必ずアクセスが行われてしまう(DNSラウンドロビンの制約)
  2. その結果、障害の発生したサーバーへのアクセス時は通信が失敗する?
  1. DNSラウンドロビン方式では、障害の発生したサーバー(b)にも必ずアクセスが行われてしまう(DNSラウンドロビンの制約)
  2. 次に障害の発生していないサーバーにブラウザは自動的にアクセスを試みる
  3. その結果、通信は成功する(エラーにならない)
通信を失敗させないように(高可用性を実現)するためには、高価な負荷分散装置が必要? DNSラウンドロビン方式でも、サーバー障害時に通信が失敗しないように(高可用性を実現)することができる

DNSラウンドロビンにて、サーバーのホスト名に対し複数のIPアドレスを返された際に、仮に1台目の接続が無応答でも、すべてのIPアドレスへの接続をWebブラウザが試行します。つまり、ダウンしたサーバーへのリクエストに応答がなくても、別のサーバーから応答があれば接続が成功します。

多くのWebブラウザが、複数のサーバーにリトライを試行するよう進化しています。故に、DNSラウンドロビン方式でも、高可用性の実現が可能です。

DNSラウンドロビン方式の課題と対策

既存のDNSサーバーのゾーンファイル設定変更のみで実装が可能なDNSラウンドロビンは、負荷分散の方策として、導入が容易で安価に構築できるメリットがあります。しかしながら、以下のような問題も内在しています。これらの課題解決のためにアークシステムが実施した対策を紹介します。

1. 負荷のコントロール

説明 負荷が100%均等には分散されない
負荷分散装置との差異 負荷分散装置の場合は、負荷制御のしくみがある
解決方法 完全に分散されなくとも極端な偏りは発生しないため、許容範囲内と割り切ることも必要(5:5が6:4となる程度は許容範囲)

2. 障害サーバーのコントロール

説明 サーバー障害時も、そのサーバーにリクエストを送ってしまう
負荷分散装置との差異 負荷分散装置には、障害サーバーを検知し切り離すしくみがある
解決方法
  • 多くのWebブラウザは、サーバーのホスト名に対し複数のIPアドレスを返された際に、仮に1台目が無応答でも、すべてのIPアドレスに接続を試行するため、ダウンしたサーバーへのリクエストに応答がなくても、別のサーバーから応答があれば接続が成功する(再試行まで多少時間は必要だが、ブラウザのタイムアウトで通信断するまではいたらない)
  • サーバー障害は監視で検知できるため、障害が長期間におよぶ時は、手動でDNSゾーン設定を書き換えて対応する

3. 分散先サーバーの通信継続性

説明 接続ごとに接続先が違うと、接続の継続性が求められるサーバーの場合に問題が起きる可能性がある(暗号化通信など) 
負荷分散装置との差異 負荷分散装置では、接続継続性を制御できる
解決方法
  • クライアントPC単位では同じサーバーにて通信を継続(DNSキャッシュ使用)するため、基本的には問題ない
  • ただし、DNSキャッシュのTTL更新のタイミングでそれまでと異なるサーバーと通信する可能性があり、このタイミングでは継続性が必要な通信は切れる(ユーザーは接続の再試行が必要)
  • この状況を回避するためには、TTL値の見直しを行う(ブラウザのTTLと同じにするなど)

 

お問い合わせ・資料請求

このページの先頭へ