■ 構築問題 第十七問
おね〜さんと、
ほげたんのっ!!
3 Minutes Networking、
Step by Step !!
前回が、負荷分散装置を使ったサーバの負荷の軽減、と。
ろーどばらんさー。
うんうん。負荷分散装置は頻出機器の1つよね。
ろーどばらんさー。
負荷分散装置の配置と、その機能はよく問題にもなるし、重要よ。
ろーどばらんさー。
うるさいっ!!
がはっ!!
Webサーバの負荷を分散しなさい
[FigureSS17-01:第十七問]
- 現在のネットワーク構成は第十四回の問題と同じとする
- 特にアクセスが多い場合の負荷軽減とセキュリティを目的とする
ろーど…。
それはもういいってば。
前と同じ構成だけど、負荷分散装置を使わない形で考えてみてね。
■ 構築問題 第十七問 解答
負荷分散装置を使わない?
そう、使わないでね。
キーワードは、問題の最後の文、かな。
「アクセスが多い場合の負荷軽減とセキュリティ」?
あと、前回にあったおなじサーバを追加するってのがないよ?
今回は1台のWebサーバだけを運用する場合での負荷軽減よ。
でも、サーバを1台追加してね。
どうすればいいの?
それを考えるのが、ほげたんの役割でしょ?
そうねぇ、ヒント。アクセスが多いとなんで負荷がかかるの?
そりゃ、サーバの処理が多くなるからだよ。
そうすると、サーバの処理能力に負荷が生じて、レスポンスが悪化するんだよ。
そうねそうね。じゃ。それの負荷を減らすためには?
ネットさん並にダイレクトに考えると? 「ネット君、アクセスが多いと負荷が高い。どうする?」
「アクセス数を減らす」。
と、いいそうだよなぁ、パパさんの助手さんだと。
それが正解。
うぇ?
つまり、以前に要求のあったページはサーバにアクセスさせない。
はい、これは?
プロキシサーバ!!
そう、リバースプロキシを使うのよ。
[FigureSS17-02:おね〜さんの解答]
内部ネットワークから、インターネットのWebアクセスの中継を行い、キャッシュを使うことによりインターネットへのアクセスを減少させるプロキシ。
それとは反対に、外部から内部のWebサーバへのアクセスの中継を行い、キャッシュを使うことによりWebサーバへの負荷を軽減させるのが、リバースプロキシ。まさしく「リバース」なんだね。
普通のプロキシは「フォワードプロキシ」なんて呼ぶ場合もあるわね。
このリバースプロキシを配置して、DNSゾーン、NAT、パケットフィルタはこう設定するの。
Name | Type | RData |
---|---|---|
3min.jp. | SOA | - |
3min.jp. | NS | ns.3min.jp. |
3min.jp. | MX | mx.3min.jp. |
www | A | 200.100.10.11 |
ns | A | 200.100.10.12 |
mx | A | 200.100.10.13 |
[TableSS17-01:ns.3min.jpのゾーンファイル・リバースプロキシ]
分類 | インタフェース | IPアドレス | インタフェース | IPアドレス |
---|---|---|---|---|
NAT | WAN | 200.100.10.11 | DMZ | 172.16.10.10 |
WAN | 200.100.10.12 | DMZ | 172.16.10.12 | |
WAN | 200.100.10.13 | DMZ | 172.16.10.13 |
[TableSS17-02:NATテーブル・リバースプロキシ]
プロトコル | 送信元IPアドレス | 送信元ポート | 宛元IPアドレス | 宛元ポート | 方向 | 動作 |
---|---|---|---|---|---|---|
TCP | * | * | 172.16.10.10 | 80 | WAN→DMZ | 許可 |
TCP | * | * | 172.16.10.12 | 53 | WAN→DMZ | 許可 |
TCP | * | * | 172.16.10.13 | 25 | WAN→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]