自らのインプットのために"サーバ/インフラを支える技術"を読み､ある程度まとめてみました。
今回は第一章の"Webサーバを冗長化する DNSラウンドロビン"をメモしました｡
用語
DNS
IPアドレスとドメイン名の対応を管理する仕組み
DNSラウンドロビン(DNS Round Robin)
DNSを一つのサービスに複数台のサーバを分散させる手法
TTL(Time To Live)
データの寿命
プロキシサーバ
ホームページを見るときに使うソフト（Webブラウザ）の身代わりになってホームページにアクセスしてくれるコンピュータ（サーバ）
DNSラウンドロビン
以下画像では"www.example.jp" へアクセスしたいAさんとBさんを想定しております｡
DNSサーバは,同じ名前に複数のレコードが登録されると､問い合わせのたびに異なる結果を返します｡この動作を利用することで､複数台のサーバ処理を分散させることができます｡比較的簡単に負荷分散できるDNSラウンドロビンですが､以下のような問題点があります｡
- サーバの数だけグローバルアドレスが必要
- たくさんのサーバで負荷分散するためには､IPアドレスをたくさん取得できるサービス(回線)を利用する必要がある｡
-
均等に分散されるとは限らない
- 携帯サイトなどで問題になることがある｡携帯電話からのアクセスは､キャリアゲートウェイと呼ばれるプロキシサーバを経由する｡プロキシサーバでは､名前解決の結果がしばらくの間キャッシュされるので､同じプロキシサーバーを経由するアクセスは常に同じサーバへ届くことになる｡そのため均等にアクセスが分散されず、特定のサーバにのみアクセスが集中する可能性がある｡TTLを短く設定するという方法もあるが､必ずしもTTLに従ってキャッシュを開放するとは限らない｡
-
サーバがダウンしても気づかない
- DNSサーバはWebサーバの負荷や接続数などの状況に応じて問い合わせ結果をコントロールする事ができない｡Webサーバの負荷が高くてレスポンスが遅くなろうが､接続数がいっぱいでアクセスを処理できない状況であろうと全く関知しない｡何かしらの原因でサーバダウンをしていても､それを検出することなく負荷分散を続けてしまう｡そのためダウンしたサーバに分散されてしまったユーザはエラーページと対面する｡
つまり､DNSラウンドロビンはあくまでも負荷分散するための仕組みでしかなく､冗長化の仕組みではないので､他のソフトウェアと組み合わせてフェイルオーバやヘルスチェックを実装する必要があります｡
DNSラウンドロビン冗長構成例
今回は2台のWebサーバの両方にVIPをもたせて冗長化する仕組みを紹介します｡
Web1が停止すると､VIP1がWeb2へ引き継がれ､全てのアクセスをWeb2が処理するようになります｡逆にWeb2が停止すると今度はVIP2がWeb1に引き継がれて､全てのアクセスをWeb1が処理するようになります｡Webサーバ同士が協調しあって､正常なVIPわけができる仕組みです｡
しかし､この構成もスクリプトやソフトウェアを用いてフェールオーバやヘルチェックをできるようになったとしても､サーバの台数が増えるに連れてシステムが複雑に難易度が上がっていきます｡
できればWebサーバ上で特別なソフトウェアを動かさなくても良い構成にしたいです｡
まとめ
今回はDNSラウンドロビンについて少しまとめてみました｡一見便利そうでしたがあくまでも負荷分散を目的としており､冗長化とはまた違うようです｡次回からはApacheで検証しながら､ロードバランサについて触れていこうと思います｡
説明ざっくりとしてもうしわけございません笑
今回は以上です笑