Output Archive

通信の際の取り決め。
渡すデータの形式・その解釈方法など。

アプリケーション層
いわゆるメーラーとかの送信時に、
本文の部分を示す情報や宛て先などの情報がヘッダとして付与される。

プレゼンテーション層
機器固有のデータ表現をネットワーク共通のデータ表現に変換。
データの符号化方式を判別するための情報のヘッダが付与される。

セッション層
通信の際の論理的な道筋やデータの送信方法などを決定。
データをどのような手順で伝えるかなどの情報が書かれたヘッダが付与される。

トランスポート層
通信の信頼性を保障する。
パケット番号などの情報を含むヘッダが付与される。

ネットワーク層
パケットの配送処理を行う。
始点・終点IPアドレスなどの情報がヘッダとして付与される。

データリンク層
直接接続された機器間での通信のやりとりを補助する。
データを2進数で表現し、データを意味のある単位(フレーム)に纏める。

物理層
2進数で表現された情報を光の点滅や電圧の高低で表し、
通信媒体を通してデータを流し込む。


受け取る時はこの逆の処理を行う。
(ヘッダを付与するのではなく、ヘッダを取り除いていく)

コンピュータ・ネットワークの歴史
1950年代
バッチシステム　　　　　　　　　テープに処理を順次記述・読み込み・順次処理
　　　　　　　　　　　　　　　　　 　FORTRAN・COBOLはバッチ処理向けの言語

1960年代
タイムシェアリングシステム　　一つのコンピュータを複数の端末でシェア
　　　　　　　　　　　　　　　　　　　細かい時間でCPU割り当てを切り替える
　　　　　　　　　　　　　　　　　　　BASICの登場・対話型のプログラムが主流に

1970年代
ネットワークの登場　　　　　　 複数のコンピュータを繋いでネットワークを構築
　　　　　　　　　　　　　　　　　　 ファイル移動などにかかる手間が軽減される
　　　　　　　　　　　　　　　　　　 ウィンドウシステムの登場により、複数のプログラムの同時実行が
　　　　　　　　　　　　　　　　　　 可能となる

1980年代
ネットワークの拡大　　　　　　　取引関係にある企業や複数の学術機関のネットワークが結合される

1990年代
インターネットの登場　　　　　　情報処理に力をいれた機関では一人一台のコンピュータ
　　　　　　　　　　　　　　　　　　　World Wide Webによる情報公開

2000年代
通信の統合へ　　　　　　　　　　各々仕様が異なる通信網をIPを用いたものに統合

TCPのようなコネクション型通信における原則として、
ある通信パケットが送信された時、送り返されるパケットは
最初に定義した始点・終点IPアドレスのみを用い、
それ以外のIPアドレスからのパケットは破棄するというものがある。
ゆえに、負荷分散装置は始点・終点IPアドレスを適切に書き換える必要がある。
上のことを踏まえた上でサーバ負荷分散のパケットの流れを見る。

サーバ負荷分散におけるパケットの流れは、
1. ユーザーから負荷分散装置のVIP宛てにパケットが送信される
2. 負荷分散装置がパケットを受け取り、終点IPアドレスを実サーバのものに書き換えられる
3. 実サーバがパケットを受け、処理する
4. 応答パケットを負荷分散装置に返す
5. 負荷分散装置が始点IPアドレスを負荷分散装置のVIPに書き換え
　 ユーザーにパケットを送る
といったものである。

このパケットの流れの負荷分散は負荷分散装置の負荷が大きい。
何故なら、実サーバが処理した後のパケットも
負荷分散装置を通らないといけないためである。
そこで、負荷分散装置の負荷をより軽減できる方法として、
DSR(Dynamic Source Routing)がある。
これは上の処理手順における4〜5の処理を省くというものである。
これにより返答パケットを負荷分散装置を経由することなく
直接ユーザーに返すことが可能となる。

DSRではMAT(MAC Address Translation)を行い、
レイヤ2でのパケット操作を行う。
始点IPアドレスを書き換える必要をなくすために、
VIPを実サーバのネットワークインターフェースにも持たせる必要がある。
しかし、ネットワーク上において二つのMACアドレスに対して
同じIPアドレスを割りあてることはできない。
そのため、VIPはループバックインターフェースに割りあてる。
ループバックインターフェースはサーバ内部の通信に用いられ、
そのIPアドレスは127.0.0.1である。
しかし、ネットワークインターフェースに複数のIPアドレスを付与できるのと同様に
(IPエイリアス)、ループバックインターフェースにもIPエイリアスを付与できる。
これにより、複数のMACアドレスに対して同じIPを割りあてることができないという
問題に対処する。

DSRでの負荷分散は次のような手順でパケットが操作される。
1. ユーザーから負荷分散装置のVIP宛てにパケットが送信される
2. 負荷分散装置がパケットを受け取り、MATを用いて終点MACアドレスを
　 実サーバのネットワークインターフェースのものに書き換える
3. パケットが実サーバのループバックインターフェース宛てに届く
4. 実サーバがユーザーに返答パケットを返す

Webトラフィックは約1:8の割合という特徴を持つ。
パケット1を受け取り、その返答パケットを8返す。
(これは処理すべきトラフィックの量であって、パケット数自体はほぼ同一である)
そのため、DSRを用いることにより負荷分散装置の負荷を大幅に削減できることになる。

ただし、DSRは設定の複雑化や、
レイヤ5-7のURL解析やハッシングが動作しない他、
通常はクッキーを使う維持機能が動作しないなどの欠点がある。


他のサーバ負荷分散方式としては、
始点・終点IPアドレスどちらかのみを書き換えるハーフNATや
両方を書き換えるフルNATなどがある。
フルNATはプロキシやキャッシュのサービスにおいて有効な場合がある。


負荷分散装置は通常サーバベース負荷分散装置と
スイッチングベース負荷分散装置の二つに分けられる。
以下それぞれのメリット・デメリットである。
ただし、これらのメリットなどは常にあてはまるものではなく、
ベンダや機種により大きく異なる場合がある。

サーバベース負荷分散装置
ネットワークスタック上のソフトウェアコードによりパケット書き換えを行う。
メリット
・使用するOSの開発者が雇いやすいため、開発が容易
　→コード変更や新機能の追加を迅速に行える
デメリット
・コードのサイクルが短いため、バグが出やすい

スイッチングベース負荷分散
ASIC(Application Specific Integrated Circuit)チップを使いパケット書き換えを行う。
メリット
・ASICチップは専門化されたプロセッサで汎用プロセッサより高速である
・安定している
デメリット
・ASICチップの柔軟性に欠け、
　新たな機能の追加の際にはASICを設計しなおす必要がある
　(IP自体は変化しないためそれらの機能をASICに埋め込み、
　再設計を避けられる場合もある)
・コード開発が難しくリリースが遅い(だがそのため安定性が高い)

ラウンドロビンDNSの問題点を解決した、
さらなる柔軟性・可用性・拡張性を持ったソリューションが求められた。
そこでサーバ負荷分散の登場である。
Webサービスは今や企業戦略上で重要なポジションを占め、
サイトがダウンすることは利益の損失に直結する。
負荷分散装置はサイトが受けるトラフィックを受け、
そのパケットを操作して負荷を分散する。
逆にユーザーにパケットを送り出す時にもパケットを操作する。

サーバ負荷分散の三つの強み
・柔軟性
サーバ負荷分散はいつでもサーバの追加・撤去ができ、
その効果を即座に現すことが可能である。

・可用性
サーバ負荷分散は利用できるサーバをチェックし、利用できないサーバには
処理を割り振らない。利用できる状態に復帰したサーバは、
自動的に処理が割り振られるようになる。

・拡張性
サーバ負荷分散はサーバの数を増やして処理能力を増強する。
一般的にハイエンドサーバの導入よりも多数の汎用サーバの導入の方が
安価かつ費用対効果が高い。

サーバ負荷分散の他に、負荷分散技術としては
・ファイアウォール負荷分散
・グローバルサーバ負荷分散
・クラスタリング
などがある。

このうちクラスタリングはサーバ負荷分散に似ているが、
サーバ負荷分散は負荷分散装置がトラフィックを振り分け、
実際に処理を行うノードは負荷分散していることを意識しない。
一方クラスタリングは全てのサーバ上でソフトウェアエージェントが動作し、
どのサーバがどの処理を行うか、などのサーバ間での緻密な連携が必要である。
また、クラスタリングは特殊なソフトウェアが必要なことが多く、
これらのソフトウェアの多くは限られたプラットフォーム上でのみ動作するものであるが、
サーバ負荷分散は負荷分散装置上で処理が完結しており、
サーバのプラットフォームに依存しない。

この本ではサーバ負荷分散を、負荷分散装置を用いて、
ネットワークトラフィックを複数のサーバに振り分けるものと定義する。

以前、インターネットは主に学術機関の中で使用されるものであった。
1995年頃から個人にも普及されはじめ、ネットワークが広がっていったが、
Webショッピングなどのインターネットを利用したサービスは少量で、
当時はまだ単独のサーバで対応することが十分に可能なアクセス数であった。
しかし、時が進むにつれて、徐々に企業がインターネットの有用性に気付き、
それに伴いトラフィックが増加し、何らかの形でそれらを処理できるようにすることが
必要となった。

処理可能件数を増加させたい時、まず初めに考えられるのは、
メモリの拡張やCPUのグレードアップでサーバの能力を増強することである。
しかし、この方法は、ハードウェアプラットフォームや使用するOSの制限で、
その拡張性は頭打ちになるときがくるし、
そうしたサーバのスペックアップを行う期間はサービスをダウンさせなければならない。

そこで柔軟性・拡張性が優れた方法としてサーバ負荷分散がある。
これは、サーバの数を増やせば増やすほどトラフィックの処理可能件数が向上し、
また、その際は新たなサーバを既存のサーバ群に加えるだけで良いため、
スペックアップのようにサービスを停止する必要がない。

サーバ負荷分散が普及するまでの方式としては、
ラウンドロビンDNSによる負荷分散が行われることが多かった。
ラウンドロビンDNSを用いるとホスト名に複数のIPアドレスを関連付けることが可能となる。
(revelation.a.ne.jpに192.168.1.2、192.168.1.3、192.168.1.4を関連付けるといった具合)
こうすると、名前解決の際にホスト名がそれぞれのIPアドレスのどれかに関連付けされ、
トラフィックが分散される。

しかしラウンドロビンDNSには、予測不可能なトラフィック分散やキャッシュ問題、
そして耐障害性に欠けるという欠点がある。

通常DNSの名前解決は、
1. ローカルDNSに問い合わせ
2. ローカルDNSにそのホスト名の関連付けがないならルートDNSに問い合わせ
3. ルートDNSよりそのホスト名を知る権限のあるDNSが紹介される
4. 権限のあるDNSよりそのホスト名のIPアドレスを知る
上記のようなプロセスで行われる。

毎回名前解決の際に、新たに権限のあるDNSに名前解決を行えば良いのだが、
一度名前解決を行った際に、DNSの負荷を減らすため、
その内容はキャッシュとしてローカルDNSに保存され、
次からはそのキャッシュ情報の有効期限が切れるまでは
1のローカルDNSに問い合わせをするのみで名前解決が終わる。

通常、ホスト名とIPアドレスの関連付けはそう頻繁に変わることはないため、
これによる影響は少ないのだが、ラウンドロビンDNSにおいては問題がある。

キャッシュ情報がある限り、
次回からは同じクライアントは同じサーバに関連付けされるため、
処理するサーバの偏りが発生する恐れがある。
また、サーバを追加し、トラフィックをさらに分散しようという時にも、
以前のキャッシュ情報が消えるまでは既存のサーバにしか処理がいかず、
新たに追加したサーバは導入後すぐにはトラフィック分散への貢献度が低くなってしまう。
これによりラウンドロビンDNSは速急なトラフィック処理可能数の増加には向いていない。