| ■ 【ぷろじぇくと ぞうさん】 〜E-Bananaサーバ 構築日記〜
|
第９日目：〜外伝V〜 ロードバランサーを作れ！ (その１)〜
|
どうも、ご無沙汰しております。('A`)です。
前回の日記からもう１ヶ月以上過ぎてしまいました。。。
この日記を忘れていた訳では無いのですが、花代の後の作業がすさまじくて、
なかなか時間が取れなかったです。スミマセン。
(bgってなんですか？eacceleratorって何者ですか？64bitがうまく動かないんです・・・)
まあ何とか乗り切りましたし、月も変わりましたので、日記に取り掛かれます。
前回お伝えしましたロードバランサーについて、「外伝V」としてこれからお話します。
(今わたしの方で現在進行形で進めている作戦です。)
みなさんの中には自分でサーバ運用されている方もいるかと思いますが、
サーバの負荷が上がった時にはどういう対応をされていますか？
たいていは
・ハードウェアの強化
(CPUやHDDを高性能なものにする、メモリを増やす、等)
・ソフトウェアのチューニング
(例えばApacheの設定を変更する、アクセラレータ等のソフトを導入する、等)
をされるかと思います。
それでも場合によっては１台ではどうにも処理しきれない場合もあります。
(アクセス数が１日数百万以上もあったりすると複数台でのサーバ運用を考えないと
実際捌けないでしょう。)
この様な大量のアクセス・処理要求をこなす為に「負荷分散」をおこなう事になります。
有名なところでは「DNSラウンドロビン」という方法があります。
もう１つ有名なところでは「ロードバランサー」を使う方法があります。
さて、例の如く(^_^;)さんが現われました。
(^_^;)：「えーとさ、ロードバランサーは知ってるよね？」
('A`)：「ええ、名前は聞いていますけど、、、」
(^_^;)：「作って欲しいんだけど。」
('A`)：「え、、、、初めての事なので、すぐに出来るかは判りませんが・・・」
(^_^;)：「とにかく作ってみて。DNSのラウンドロビンだと、新しい情報の浸透中に
ネガティブキャッシュを食っちゃう事があるから、サーバにアクセス
できなくなる時間が発生しちゃうんだね。」
('A`)：「まあDNSの仕組み上、切り替わるのに時間がかかりますからねえ、、、」
(^_^;)：「そこでロードバランサーですよ！ロードバランサーでコンテンツが
置いてあるサーバに自動的に振り分けできれば、万一どれかサーバが
ダウンしても、他のサーバに振り分けされてアクセスできなくなる
時間も短縮できるでしょ。」
('A`)：「原理はそうでしょうけど、、、」
(^_^;)：「じゃあ、頼んだよ。これから出かけなきゃならないから♪」
('A`)：「え、あ、ちょっと！どこ行くのーーーー」
|
後に残されたのは、この特化型サーバの過去ログだけ。
いつもの事だけど、どんなものか判らないうちに振られるんだよなあ。。。
この日記を書きながら、実はまだ読んでいます。。。複雑すぎて判らないとこだらけです(泣
('A`)がちょっと調べた感じでは、必要な機能としては以下の３つがあるかな、と思いました。
・サーバや稼働中のサービスの監視機能
(振り分けに際して、各サーバが稼働しているかダウンしているかを把握する)
・各サーバ間の振り分け機能
(外部から来たアクセス要求を他のサーバに振る際にどのサーバにどの程度
割り当てるかを決め、振り分ける。)
・各サーバとの通信制御機能
(振り分けしたサーバに対して、最終的な応答先の情報を与える。)
３番目は判りづらいかもしれませんが、要は「誰が何処に対して返事をするか」という事です。
通常は外部からのアクセス要求に対して、
@「ロードバランサー」が受取り、他のサーバに振り分ける
A振り分けされたサーバが「処理」を行ない、返事(応答)を「ロードバランサー」に返す
B返事を受け取った「ロードバランサー」は応答先(アクセス元)に返事を返す
という動きをします。
しかし、2ちゃんねるの「雪だるま」システムでは「ロードバランサー」ではなく、
「振り分けされたサーバ」が応答先(アクセス元)に直接返事を返しています。
これは特殊な仕組み(matdというものが使用されています)を使って実現しています。
まずは会社にお願いして、３台のサーバを借りてきました。
そのうちの２台に「heartbeat」というソフトウェアを入れてみます。
(ロードバランサーの「監視機能」を実現する為に入れます。)
でも、これっていくらソースコードがあるとはいえ、Linuxなんだよなあ・・・・
使っているサーバはFreeBSDだから、Portsにあるパッケージからpkg_addコマンドで
入れられるか、試してみます。
あ、そうだ。今後の日記についてなんですが、テーマとは別に「小ネタ」を書こうかと
思っています。
自分なりに消化して理解した事を書こうと思っていますが、間違いがあったら
突っ込んで下さい。
(突っ込まれてばっかりだったりして・・・・)
今日は「DNSラウンドロビンについて」最後に書きますので、そちらもご覧下さい。
それでは、また。
|
|
[DNSラウンドロビンについて]
DNSラウンドロビンはサーバの負荷分散の手法の１つです。
具体的にはある１つのドメインに複数のサーバ(IPアドレスと言った方が良いかもしれません)を
割り当てます。そしてホスト名とIPアドレスの対応関係を利用して負荷分散を行ないます。
これはDNSサーバのしくみが判る人だとイメージが掴みやすいと思います。
例えば3台のサーバ(A:206.223.999.997, B:206.223.999.998, C:206.223.999.999)に
hoge.maido3.comというドメインをTTL=300で割り当てているとします。
この hoge.maido3.com をDNSコンテンツサーバを指定して、digコマンドで調べると
以下の様になります。
hoge.maido3.com 300 IN A 206.223.999.997
hoge.maido3.com 300 IN A 206.223.999.998
hoge.maido3.com 300 IN A 206.223.999.999
|
この結果 hoge.maido3.com にアクセスすると、1番目にAサーバが、2番目にBサーバが、
3番目にCサーバが割り当てられています。
この状態ですと1番目のAサーバが呼び出される事になります。
では、続けてdigコマンドを打つとどうなるでしょう？
実はこうなります。
hoge.maido3.com 300 IN A 206.223.999.998
hoge.maido3.com 300 IN A 206.223.999.999
hoge.maido3.com 300 IN A 206.223.999.997
|
1番目に呼び出されるサーバがAからBに変わりました。
これがDNSラウンドロビンの特徴です。
１つのドメインに複数のIPアドレスが登録されていた場合、DNSサーバは登録されている
内容を問い合わせがあるたびに順番に答えます。
ちょうどdigコマンドで問い合わせをした時に、１回目はAサーバ(IPの末尾が997)を答え、
2回目にはBサーバ(IPの末尾が998)を答える事になります。
このDNSの応答によって結果的にサーバへのアクセスが分散される事になります。
もっと負荷を分散したいと思った場合は、コンテンツ内容も含めて「同じ」サーバを
用意して、そのサーバをDNSのラウンドロビンのレコードに追加します。
逆に故障等によってアクセスできなくなったサーバが発生した場合は、ラウンドロビンの
レコードから削除すれば故障したサーバ以外のサーバにアクセスが振り分けられます。
便利な様に見えますが、ラウンドロビンにも欠点があります。
それは、アクセスが切り替わるまでに一定時間かかる事です。
前述の例で仮にCサーバが故障したので、A・Bサーバだけでラウンドロビンする様に
変更したとします。その場合、新しい情報がDNSキャッシュサーバに完全に浸透するのに
約1時間かかります。
(これはTTL=300のドメインについて実地で観察した結果です。)
TTL=300だから5分で切り替わるのではないか、と思われるかもしれませんが、
しかし、全世界のキャッシュサーバが同タイミングで一斉に切り替わる訳では
ありません。キャッシュサーバ内のデータの寿命(これはTTLで指定されています)は
各サーバとも違っています
(なぜなら一番最初にキャッシュされたタイミングが各サーバともまちまちだから、です。)
また(どういう仕組みで動いているのかよく判りませんが)キャッシュサーバの一部には
TTLの値を無視してサーバ側で設定されている時間だけキャッシュデータを保持する
ものも存在します。
なので、実際に該当のサーバへのアクセスが完全に無くなるのはTTL以上の時間が
かかります。
DNSラウンドロビンを実施する際には上記の様なDNSの浸透を早くする為にTTLを
短めに設定する事が一般的です。
(しかしながらTTLを限りなく短く設定する事は、一方でDNSサーバの負荷を
上げてしまう弊害が発生します。300(5分)以下に設定するのはお勧めしません。)
最後にBIG-serverのサイトでも紹介ページがありますので、こちらもご覧下さい。
|
|
|
|
|
8日目に戻る。 10日目に続く。
解析
|