3 Minutes Networking Step-by-Step
No.17

ネットワークなぜなに講座

構築第17回サーバへの負荷を軽減しよう(2)

■ 構築問題 第十七問

おねーさん

おね〜さんと、

ほげたん

ほげたんのっ!!

おねーさん

3 Minutes Networking、

ほげたん

Step by Step !!

おねーさん

前回が、負荷分散装置を使ったサーバの負荷の軽減、と。

ほげたん

ろーどばらんさー。

おねーさん

うんうん。負荷分散装置は頻出機器の1つよね。

ほげたん

ろーどばらんさー。

おねーさん

負荷分散装置の配置と、その機能はよく問題にもなるし、重要よ。

ほげたん

ろーどばらんさー。

おねーさん

うるさいっ!!

ほげたん

がはっ!!

Webサーバの負荷を分散しなさい

第十七問

[FigureSS17-01:第十七問]

  • 現在のネットワーク構成は第十四回の問題と同じとする
  • 特にアクセスが多い場合の負荷軽減とセキュリティを目的とする
ほげたん

ろーど…。

おねーさん

それはもういいってば。
前と同じ構成だけど、負荷分散装置を使わない形で考えてみてね。

解答は非表示になっています。自分なりの答えができた方は表示させてください

■ 構築問題 第十七問 解答

ほげたん

負荷分散装置を使わない?

おねーさん

そう、使わないでね。
キーワードは、問題の最後の文、かな。

ほげたん

「アクセスが多い場合の負荷軽減とセキュリティ」?
あと、前回にあったおなじサーバを追加するってのがないよ?

おねーさん

今回は1台のWebサーバだけを運用する場合での負荷軽減よ。
でも、サーバを1台追加してね。

ほげたん

どうすればいいの?

おねーさん

それを考えるのが、ほげたんの役割でしょ?
そうねぇ、ヒント。アクセスが多いとなんで負荷がかかるの?

ほげたん

そりゃ、サーバの処理が多くなるからだよ。
そうすると、サーバの処理能力に負荷が生じて、レスポンスが悪化するんだよ。

おねーさん

そうねそうね。じゃ。それの負荷を減らすためには?
ネットさん並にダイレクトに考えると? 「ネット君、アクセスが多いと負荷が高い。どうする?」

ほげたん

「アクセス数を減らす」。
と、いいそうだよなぁ、パパさんの助手さんだと。

おねーさん

それが正解。

ほげたん

うぇ?

おねーさん

つまり、以前に要求のあったページはサーバにアクセスさせない
はい、これは?

ほげたん

プロキシサーバ!!

おねーさん

そう、リバースプロキシを使うのよ。

おね〜さんの解答

[FigureSS17-02:おね〜さんの解答]

おねーさん

内部ネットワークから、インターネットのWebアクセスの中継を行い、キャッシュを使うことによりインターネットへのアクセスを減少させるプロキシ。

ほげたん

それとは反対に、外部から内部のWebサーバへのアクセスの中継を行い、キャッシュを使うことによりWebサーバへの負荷を軽減させるのが、リバースプロキシ。まさしく「リバース」なんだね。

おねーさん

普通のプロキシは「フォワードプロキシ」なんて呼ぶ場合もあるわね。
このリバースプロキシを配置して、DNSゾーン、NAT、パケットフィルタはこう設定するの。

NameTypeRData
3min.jp.SOA-
3min.jp.NSns.3min.jp.
3min.jp.MXmx.3min.jp.
wwwA200.100.10.11
nsA200.100.10.12
mxA200.100.10.13

[TableSS17-01:ns.3min.jpのゾーンファイル・リバースプロキシ]

分類インタフェースIPアドレスインタフェースIPアドレス
NATWAN200.100.10.11DMZ172.16.10.10
WAN200.100.10.12DMZ172.16.10.12
WAN200.100.10.13DMZ172.16.10.13

[TableSS17-02:NATテーブル・リバースプロキシ]

プロトコル送信元IPアドレス送信元ポート宛元IPアドレス宛元ポート方向動作
TCP**172.16.10.1080WAN→DMZ許可
TCP**172.16.10.1253WAN→DMZ許可
TCP**172.16.10.1325WAN→DMZ許可
IP**172.16.10.0/24*WAN→DMZ禁止

[TableSS17-03:フィルタリングテーブル・リバースプロキシ]

ほげたん

「www.3min.jp」のホストは、200.100.10.11のアドレスを持つけど、それはリバースプロキシである172.16.10.10に変換されるわけだね。NATもそれは通す設定になってる、と。

おねーさん

そう、Webアクセスはこういう経路を通ることになるわね。

リバースプロキシを使った場合の経路

[FigureSS17-03:リバースプロキシを使った場合の経路]

おねーさん

リバースプロキシとWebサーバの配置にはいろいろ考えられるわね。
例えば、こんなのでもいいわけだし。

リバースプロキシを使った配置

[FigureSS17-04:リバースプロキシを使った配置]

ほげたん

は〜、LANカード2枚指して、別ネットワークにわけるわけだね。

おねーさん

そゆこと。リバースプロキシを使うことにより、利点はいくつか考えられるわ。
まず、セキュリティ。Webサーバアプリケーションのセキュリティホールとかを直接狙われなくなるわよね。

ほげたん

そだね。Webサーバには直接パケットが届かないわけだし。
明らかに不正なHTTPメッセージはプロキシで排除できるよね。

おねーさん

webサーバが直接アクセスされないから、DoSや、改ざんなども防げるわけだしね。
キャッシュを改ざんされても、復旧は容易だし。

ほげたん

ふむふむ。

おねーさん

結局、プロキシってファイアウォールそのもの(アプリケーションゲートウェイ・ファイアウォール)なんだからね。
ファイアウォールを二重にかけるんだもの、そりゃセキュリティも向上もするわよ。

ほげたん

さらに、キャッシュを使った負荷軽減でしょ?
いいことずくめだよね。

おねーさん

ただ、実際は、プロキシでの処理の分が入るから、新規ページのアクセスが遅くなったりもするんだけどね。
あとは、そうね。プロキシということで、キャッシュサーバの話もしておきましょうか。

ほげたん

きゃっしゅさーば? プロキシもキャッシュサーバだよね。

おねーさん

そうよ。で、プロキシとよく似てる、というか間違えやすいというか、そういうものに、CDNがあるの。
このCDNで使われる用語がキャッシュサーバ、なのよ。これもやっぱり負荷分散技術なんだけど。

ほげたん

その、こんてんつでりばりーねっとわーく、ってナニモノ?
コンテンツ配信ネットワーク?

おねーさん

うん、そう。コンテンツ配信ネットワーク。
簡単に言うと、コンテンツをコピーしてある複数の「キャッシュサーバ」に、クライアントを分散させてアクセスさせるネットワーク、かな?

[FigureSS17-05:CDN]

ほげたん

もよりのキャッシュサーバにアクセスさせることによる、負荷分散?

おねーさん

そゆこと。アクセス数が大量の場合や、動画などのデータ量の多いコンテンツには特に有効よね。

ほげたん

この、振り分ける配信サーバってどんなの?

おねーさん

特殊な機能を持ったDNSがなる場合もあるわね。サーバへのアドレス問い合わせに対し、送信元アドレスから、もよりのキャッシュサーバを探し出してそのアドレスを応答する、とか。

ほげたん

は〜、ずいぶん賢いDNSだね。

おねーさん

または、Webサーバの場合もあるし。HTTPのGETに対して、もよりのキャッシュサーバへリダイレクトさせる方式ね。

ほげたん

リダイレクト?

おねーさん

HTTPレスポンスメッセージ302、だったかな。まぁ、そこまで詳しくは覚える必要はないけどね。
ともかく、負荷分散される、キャッシュサーバがもよりである、などからレスポンスが改善される、という形なわけよ。

ほげたん

へ〜、上手いこと考えてあるねぇ。

おねーさん

もちろん、いいことずくめじゃないけどね。まず、冗長化サーバ最大の問題点である、データ整合性の問題が発生することになるわよね。

ほげたん

あ〜、データが最新のものかどうかって奴だよね。

おねーさん

簡単に言えばそうね。冗長化サーバの問題点ときたらコレってぐらい、問題になる点よね。
あとは、クライアントキャッシュの問題もあるかな。

ほげたん

クライアント側に残るキャッシュ?

おねーさん

そう、クライアント側ではDNSもキャッシュするし、リダイレクトの結果もキャッシュするから。
もしキャッシュサーバに障害が発生した場合、他のサーバに振り分けるんだけど、クライアントキャッシュのせいで上手くいかないことが多々あるわけよ。

ほげたん

それって対応できるの?

おねーさん

DNSレコードのTTLを減らしたり、コンテンツのTTLを減らしたり、CookieのTTLを減らしたり。
でもあんまり減らすと逆にアクセスが頻繁になって、負荷分散にならなかったりするから結構難しいわよね。

ほげたん

だよね。バランス取りが難しいよね。

おねーさん

ま、今回はこんな感じかな。
リバースプロキシ、CDN、両方ともキャッシュを使っての負荷軽減ってことで覚えておいてね。

ほげたん

うん、了解だよ。

おねーさん

特に、弱点は要チェックよ。じゃ、また次回。 おね〜さんと、

ほげたん

ほげたんのっ!!

おねーさん

3 Minutes Networking、

ほげたん

Step by Step !! でした〜〜〜っ!!
まったね〜〜〜!!

CDN
[Contents Derivery Network]

3 Minutes Networking Step-by-Step No.17

管理人:aji-ssz(at)selene.is.dream.jp