« October 2004 | Main | December 2004 »

November 26, 2004

なぜシステム管理者と開発者は対立するのか

システム管理者と開発者は何故対立することが多いのか。今回はそれについて考察し、よりよい解決方法を模索してみたいと思います。

【システム管理者の立場で考えると】
システム管理者の立場からWEBサイトを見ると無駄にネットワークやDBリソースを食い潰すものをたくさん見つけることができます。普段DBやサーバチューニングを一生懸命やっているシステム管理者から見るとそういうものもチューニング対象と考え、いくつかの提案をまとめて開発側に修正依頼を出します。しかしそういった依頼はなかなか開発側で対応してもらえずイライラがつのります。

【開発者の立場で考えると】
開発者のミッションは決まったスケジュールの中でシステムを完成させるということです。ミッションを達成するために取る合理的な行動としてはシステムを一番楽な方法で完成させるということになるかと思います。そんな開発者にシステム最適化という仕事が振ってきても、それの達成が自身の評価の対象にならないのだとしたら、あまり引き受けたくない仕事になります。

【対立を避けるには】
お互い話しをすればお互いの言い分はもっともであると言えます。しかし当事者同士でこれらを話し合っても決裂するかもしくは開発側で忙しい時間を割いて仕方なく対応してくれるかのどちらかになるかと思います。ではどうしたら対立を避けることができるか。それは開発側のプロジェクトマネージャにお願いして、開発スケジュール作成の時にシステム修正のためのリソースも組み込んでもらうことだと思います。開発側のミッションにシステム修正も加わればそれをやらざるを得なければなります。ただしそのためにはシステム管理者はそのシステム修正によってどのくらいのインパクトがあるのかということを開発側のプロジェクトマネージャに説明できないといけません。スケジュールは各プロジェクトの優先順位によって決められていくため、その修正がどの程度優先順位が高いか把握できないとスケジュールに組み込みようがないというわけです。

※とはいいつつ、本音は企画や設計段階がしっかりしていればシステム修正なんて必要ないのになぁと強く思うんですけど、スピードの速いITベンチャーの中でそれを期待するのは難しいというものですね。(×_×;)

| | Comments (0) | TrackBack (2)

November 22, 2004

コンテンツプロバイダーのネットワーク費用はかなり安くできる

超裏話です。

通信の世界には上りと下りがあるのは言うまでもないですよね。この上りと下り、一般的にコンテンツプロバイダー側では上り(ユーザへのレスポンスパケット)が圧倒的に多く、下り(ユーザからのリクエストパケット)が少ない。それに対してユーザ側では上り(サーバへのリクエスト)が少なく、下り(サーバからのレスポンス)が圧倒的に多い。

これを通信業者の目から見たマクロの世界で考えてみましょう。コンテンツプロバイダー側に近いところの線を提供している通信業者は一般的に(コンテンツプロバイダーから見て)下りがスカスカです。逆にユーザ側に近いところの線を提供している通信業者は一般的に(ユーザから見て)上りがスカスカです。これは何を意味するか。ユーザ側に近いところの線を提供している業者は、(ユーザから見て)上りがスカスカなので、この部分を埋めてくれるコンテンツプロバイダーと契約すれば追加費用なしに売り上げを増やせると考えるわけです。

世の中コンテンツプロバイダーの数と比較したら圧倒的に一般ユーザのほうが多いです。そう考えるとほとんど全ての通信業者の(ユーザから見て)上りがスカスカな状況です。となるとコンテンツプロバイダーとしたら完全に買い手市場なわけで、この原理をしっかり理解して価格交渉に臨めばネットワーク費用をかなり安く押さえることができそうです。交渉のネタにお使いください。

| | Comments (0) | TrackBack (0)

November 18, 2004

サブネット分割でBroadcast packet削減

クラスC(256個)分のIPを取得したらそのまま使ってしまう人も多いと思います。しかしうまくサブネットを分けると内部ネットワークのBroadcast packetが削減でき、ネットワーク機器にやさしいネットワークができあがります。

【どういうときにサブネットを分ける?】
例えばLAN上に次のサーバが並列で並んでいたとします。

 ①動的コンテンツ配信WEBサーバ
 ②DBサーバ
 ③静的コンテンツ配信WEBサーバ(画像やhtmlファイル等)
 ④DNSサーバ

別にそれでも問題ないのですが、考えてみれば毎回これら全てのサーバにBroadcast packetが投げられるというのは無駄な気もします。ではどうすればよい?

ポイントは「サーバ同士で通信する必要のあるサーバとそうでないサーバに分ける」ということになります。上記の例だと①と②はDB連携のために同じサブネット上にあったほうがよいです。それに対して③と④はどのサーバとも連携していないので同じサブネット上に置く必要がないです。

| | Comments (0) | TrackBack (0)

November 17, 2004

社内ネットワークに認証スイッチや検疫LANを導入しよう

会社が小さかった頃は社内セキュリティをしっかりしようとして、個人ノートPCの持ち込みをいちいちチェックし、その都度IPを発行していました。しかし会社規模が急に大きくなるとその作業だけでかなりの負担になってきたのでDHCP公開することにしてしまいました。そうなると予想通り社外の人間(来訪者)がノートPCをつないだり、アンチウィルスソフトの入っていないノートPCを持ち込む人を制限できなかったりするようなことが起こるようになります。かつそういったことが全くログに残らないという大きな問題が生じました。

【認証スイッチと検疫LANとは何か?】
そんなときに雑誌で見て「いいなぁ」と思ったのに認証スイッチと検疫LANというものがあります。認証スイッチとはLANにつなげる際、認証スイッチにて認証を済ませないとLANに接続できないというもの。検疫LANとはセキュリティポリシーに適合するクライアントPCだけを社内LANに接続可能にするソリューションです。これらは情報システム部員の負担をかなり軽減してくれそうな魅力的なソリューションであります。

■参考
http://www.hitachi-cable.co.jp/infosystem/extreme/case/interview8.stm
http://www2.hitachi-cable.co.jp/apps/hnews.nsf/0/c4718c71dfdd991b49256e930016fd57?OpenDocument
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20041028/151841/

| | Comments (2) | TrackBack (2)

November 16, 2004

セキュアなWEBサイトの構築方法(ネットワーク構成編) part2

セキュアなWEBサイトの構築方法(ネットワーク構成編)を公開したところ、改善案を送ってくださった方(というか友達)がいました。なんと図まで作成してくれました。本人に聞いてみたところ、著作権放棄で(笑)公開を許可してくれましたので載せてみたいと思います。匿名希望とのことで名前は出しません~。

【案1】
sercurenet2_1.jpg

■ポイント
・Private IP segment (A)でglobalから内部NWを隠蔽
・DBへの接続はcore SW経由より、別NWをひいて、InternetとDBのtrafficを分離(保守とか負荷とかを考慮して)
・DBセグメントを設けて、Private IP (A)と(B)を分離する。FWのpolicyで不正なtrafficが流れないようにする。Routingはしない。Static NATでforwardするのみ。
 →DBに個人情報などがある場合は、特に注意。private IP (B)をクリーンルームにする(一般の社員がアクセスできないようにする)。FWでアクセスログを取るなど。
・private IP (A)と(B)のクラスを別にすると、管理が比較的容易。
・メンテナンス用端末は、Distribution SWとFWの間のSWにぶら下げればヨロし。


【案2】
sercurenet2_2.jpg

■ポイント
一歩進めて、あらかじめSVRとdistribution SWに二重に配線をして、それぞれprivate IP (A)と(B)のセグメントを付与する案。完全にトラヒックを分離する。ただし、distribution SWの負荷はチェック要。ただし、前の案と比べてdistribution SWのポートとSVRのNICが単純に倍必要になるので、コストは高め。たぶん配線は、そこそこ楽になると思う。

※sanonosaより一言: 「トラヒック」となっているところが業界人っぽくてよいですね。あと、わざわざ画像まで作ってくれたということは、暇なのではなくむしろ逆でよほど彼が今仕事でテンパってる(=現実逃避モード)ということでしょう。でもとりあえずまだ余力がありそうで一安心です。お仕事引き続きガンバってください。(なんじゃそりゃ(笑))

| | Comments (2) | TrackBack (0)

セキュアなWEBサイトの構築方法(ネットワーク構成編)

姉妹サイトにてリクエストがありましたので、今回はセキュアなWEBサイトを構築するためのネットワーク構成について記してみたいと思います。

【一般的なセキュアネットワーク】
ネットワークセキュリティを語る際、求めるセキュリティレベルと予算によって作り方が結構変わってくるのですが、例えばDBのデータを守ることを第一に考えたとしたら以下のようなネットワーク構成になります。
sercurenet1.jpg

このネットワーク構成のポイントは

①DB用にプライベートIPネットワークを構成している。
②DBの前にファイアウォールを設置している。

というものです。不正アクセスに結構強そうですね。でもこの構成、各サーバからLANケーブルが2本ずつ出るようになるので配線が結構しんどいです。

【配線が楽なセキュアネットワーク】
シンプルな配線のままネットワークセキュリティレベルを向上させる方法ってないの?という叫びに近い声(?!)にお答えすべき、配線が楽なセキュアネットワークの構成例をご紹介します。この構成は一般的な例よりもセキュリティレベルが落ちますが実施は比較的楽なのでおすすめです。(この構成はウチで考えたもので、普通のSI企業からこのような提案を受けることは多分ないと思います。ただ、おすすめとか言っておきながらまだこの構成を実際に試したことはないんですけどね:-p)
sercurenet2.jpg

このネットワーク構成のポイントは

①コアスイッチでプライベートIPネットワークへのルーティングをしている。

というものです。なお言うまでもないですが、コアスイッチと各サーバにスタティックルーティングを追加する必要があります。(もしこの説明で不足でしたら個別に聞いてください)

【もっとセキュアにする方法はないの?】
画像データを作るのが面倒くさいので文章で説明します。^^;) この次は各WEBサーバをプライベートIP化することでしょう。グローバルIPを持つのはL4スイッチのVIPだけでよい、という方針です。ただそこまでやると今度はサーバメンテ等の作業が面倒になるんですよね~。開発者からは非難が殺到することでしょう。

| | Comments (0) | TrackBack (0)

November 12, 2004

HTTP圧縮を実現するアプライアンスサーバ

サーバ設定変更でHTTP圧縮を実現するのは結構大変です。Apacheであればmod_gzipインストール、IISであればIISの圧縮機能設定やISAPI追加等の必要があります。これらの設定は概してとても面倒で、HTTP圧縮の威力はよくわかるものの、システム管理者としては極力楽にそれを実現したいと思うわけです。そこで今回はHTTP圧縮を実現するアプライアンスサーバをいくつかご紹介しましょう。

【HTTP圧縮アプライアンスサーバの仕組み】
通常のネットワーク構成ではロードバランサーの下にWEBサーバをぶら下げる構成を取ります。HTTP圧縮アプライアンスサーバを導入する場合は、WEBサーバからの戻りパケットがアプライアンスサーバを通るように構成します。すなわち戻りパケットをWEBサーバから受け取り、アプライアンスサーバがデータを圧縮してクライアントに返すわけです。とってもお手軽です。

【販売しているHTTP圧縮アプライアンスサーバ】
現在販売されているものを簡単に調べてみました。ハードウェアタイプのものとソフトウェアタイプのものがあります。

http://www.macnica.net/redline/
http://www.takachiho-kk.co.jp/products/networking/prod/netscaler/
http://www.ashisuto.co.jp/prod/detail.php?A=83
http://www.ashisuto.co.jp/prod/quix/web/gaiyo01.php
http://www.zend.co.jp/products/zps/

■参考
http://nosa.cocolog-nifty.com/sanonosa/2004/09/http.html

| | Comments (0) | TrackBack (0)

November 10, 2004

L4スイッチはDSR構成にすべし

ネットワーク今昔物語

大規模サイトではL4スイッチをDSR(Direct Server Return)構成で組むことはもはや常識です。しかし国内には大規模サイトが少ないためかDSR構成についての情報が不足しているのが現状です。L4スイッチを扱っているベンダーさんもDSR構成でネットワークを構築したという例をほとんど聞かないとのことです。そこで今回はDSR構成の紹介とメリット&デメリットをご紹介します。

【一般的な構成とDSR構成の違い】
一般的な構成ではスイッチとサーバの間にL4スイッチを挟み込む構成を取ります。それに対してDSR構成ではスイッチに直接L4スイッチを接続します。
DSR1.gif

これを踏まえてパケットの流れを見てみましょう。一般的な構成では行きのパケットがL4スイッチを流れサーバに到達し、帰りのパケットもL4スイッチを流れていきます。それに対してDSR構成では行きのパケットはL4スイッチを通りますが、帰りのパケットはサーバから直接スイッチを通っていきます。
DSR2.gif

DSRの詳しい設定方法はL4スイッチのベンダーさんに譲るとして、1つ注意としてはサーバのNICにVIPをIPアドレスとしたloopbackを必ず設定してください。以下設定例です。(netmask、network、broadcastの設定値も注意です)


DEVICE=lo:0
IPADDR=172.16.0.120
NETMASK=255.255.255.255
NETWORK=172.16.0.120
BROADCAST=172.16.0.120
ONBOOT=yes
NAME=loopback:0

【DSR構成のメリット】
DSR構成のメリットは3点あります。

①L4スイッチがネットワークトポロジーから独立することによりネットワーク構成が比較的自由になる
一般的な構成ではスイッチとサーバの間にL4スイッチを挟まなければならないという制約がありました。これはサーバ構成を変更するときやL4スイッチが故障した時にいちいちネットワーク構成まで変更しなければなりませんでした。その制約がDSR構成ではなくなります。図のように基本的にどのスイッチにL4スイッチを接続してもロードバランシングが可能です。
DSR3.gif


②リクエスト量に対するL4スイッチのキャパシティが増える
通常WEBサーバではin-boundとout-boundのトラフィックに圧倒的な差があります。通常WEBサーバは数バイトのリクエストに対して数10~数100kバイトのレスポンスを返すからです。一般的な構成の場合L4スイッチが上りも下りもトラフィックを処理します。例えばin-boundが20Mbpsでout-boundが120Mbpsだとしましょう。L4スイッチが100MのFastEtherポートを持っていた場合、in-bound側はまだ80Mbpsも余裕があるのに、out-bound側の20Mbpsの不足のためポートをギガビット化しなければなりません。図を見てください。上図は一般的構成の場合、下図はDSR構成の場合です。DSR構成ではin-bound量とout-bound量がほぼイコールになります。out-bound量が大幅に節約できたことによりリクエスト量に対するL4スイッチのキャパシティが大幅に増えることになります。
DSR4.gif

DSR5.gif


③ポート数が1ポートで良い
一般的な構成ではL4スイッチにたくさんのスイッチかもしくはたくさんのサーバを接続するためポート数がたくさん必要になります。しかしポート数が多いL4スイッチは非常に高価なので通常はL4スイッチの下にL2スイッチをぶらさげそこにサーバを取り付ける構成を取ります。それに対してDSR構成では上位スイッチに1ポートだけ取り付ければよいので非常に経済的です。(無論ニ重化やトランキングをする場合はもっと必要ですけど)


【DSR構成のデメリット】
一件良いことずくめのDSR構成ですがこれまで様々な実験や実稼動を経験してきてDSR構成にはいろいろなクセがあることがわかっています。そのクセを自分のものにしない限りは安心して本番系に投入できないかもしれないですね。デメリットは3つあります。

①DSR構成時の内部の動きが理解しにくい
サーバのloopback設定が鍵になるのはなんとなく理解していただいたと思いますが、L4スイッチ内でどのように動いているのか等100%完全に理解できないところが気持ち悪いところです。

②上位L3スイッチにサーバのMACアドレスが残ってしまうことがある
DSR構成にしてしばらくはきちんとロードバランスされていても時間が経つと特定サーバにロードが偏ってきてしまう場合はおそらくこれです。我々の調査ではどうやらLinux Kernel2.4の場合この現象が起こるようです。Linux Kernel2.6にすれば大丈夫っぽいですが、応急処置として上位L3スイッチのMACテーブルをstaticに書くという方法もあります。

③全WEBサーバにloopback設定をする必要がある
サーバ台数が少ないサイトはよいですが、うちのように600台以上サーバがあるだけでなく、OSだけでも5~6種類、バージョンも千差万別なサイトではかなり大変です。テストしながら少しずつ適用していったのでたぶん1年近くかかったのではないかな・・・。

■他の関連記事
Windows serverでDSRを行う方法

■参考文献
http://www.cisco.com/japanese/warp/public/3/jp/solution/slbguide/slb_03.shtml


PS: CISCOのアイコンライブラリーをクリップ素材として使わせてもらいました。

| | Comments (9) | TrackBack (1)

November 08, 2004

コネクションプールが可能な開発言語を使うべし

開発がし易く生産性が高いという理由でサイト構築にPHP言語やASP言語を選択するサイトが多いと思います。しかしこれらの言語にはコネクションプール機能がないため大規模サイトには不適切と言われています。そこで今回はコネクションプールの考え方と、大規模サイトに相応しい開発言語について考えてみましょう。

【コネクションプールとは?】
DBにアクセスするためには基本的に①DBとコネクションを張り②SQL文を送り③レスポンスを受け取り④DBコネクションを切る、という流れが必要になります。この中で①と④のDBコネクション周りは実はとても負荷が高く、アプリケーションを作成する際はSQL文のチューニングと同じくらいDBコネクション処理コストの削減が重要になります。そこでコネクションを一度張ったらずっとコネクションを切らずに使いまわす(コネクションをプールする)という考え方が生まれました。

【コネクションプールが可能な開発言語とは?】
私の知っている限り、JAVA言語とASP.NETでコネクションプールが実現できます。JAVA言語の場合はどのコンテナを使うかによってコネクションプールの実現方法が変わってきます。TOMCATを使う場合は自分でコネクションプール機能を実装しなければなりません(簡単ですし一般的です。検索すれば該当ソースがたくさん出回っています)。BEA社のWEBLOGIC等のアプリケーションサーバを使う場合はそれ自身にコネクションプール機能が実装されているので邯鄲にコネクションプールが実現できる、らしいです(使ったことないので・・・)。ASP.NETの場合は予めコネクションプール機能がついている、らしいです(これも実はまだ使ったことないです・・・)。

逆にコネクションプールが不可能と言われている開発言語で有名どころではPHP、Perl、ASPあたりでしょうか。Ruby、Python等は知りません。(誰か教えてください)

※ただしテクノロジーは常に進化しているので今日不可能だったことは明日には可能になっているかもしれません。

質問!

どなたかWindowsのODBCでコネクションプール機能を持つものって存在するかご存知ないですか?開発言語レベルでなくODBCレベルでコネクションプールを実現しているものがきっとあるに違いないと思って探したんですがみつからなかったんですよね~。

| | Comments (2) | TrackBack (0)

November 05, 2004

HTTPヘッダー研究その4: IISのHTTPヘッダーを書き換えよう

IISのHTTPヘッダーを書き換える方法は、apacheのそれと比べて情報源がかなり限定されていて調べるのに大変苦労しました。それだけにここでその方法を書いてしまうのはちょっと惜しい気持ちもあるのですが、まあ隠しても仕方ないので書いてしまいます。(この書き込みが役に立たれたら是非コメント欄に書き込んでください・・・)

基本的にIISでHTTPレスポンスヘッダーを書き換えるためにはISAPIフィルタリングアプリケーションをIISに登録する必要があります。

【HTTPヘッダーを自由自在に書き換える方法】
HTTPヘッダーを自由自在に書き換えられる無料のISAPIアプリは残念ながらみつかりませんでした。しかし有料ではservermaskという強力なものがあります。

servermaskは不要なHTTPヘッダーを消したり書き換えたりする機能の他に、HTTPヘッダー的に他のWEBサーバに化けるという機能もあります。HTTPヘッダーいじりが本当に自由自在にできるので便利です。価格は1サーバライセンス99.95ドル。サーバ台数が少ないサイトでは有効ではないでしょうか。(うちはサーバ台数が多すぎて無理です・・・)


【HTTPヘッダーの製品情報を隠蔽する】
製品情報の隠蔽、すなわちServerName部分だけ隠蔽するだけだったら無料のISAPIが2つ存在します。

1つめはマイクロソフト社が提供するURLSCANツールを入れる方法です。

まずはインストールしましょう。次に設定ファイルを変更します。設定ファイル

c:\WINNT\system32\inetsrv\urlscan\urlscan.ini

の中で「RemoveServerHeader=1」として、urlscan.exeを実行し、IISを再起動することで適用されます。ただしURLSCANツールはHTTPヘッダーの書き換えのためにあるというよりは不正アクセスの防御のために作られたツールです。適用の前にはURLSCANの仕組みをよく理解しておくことが必要です。特に[AllowExtensions]に.aspを追加し、[DenyExtensions]で.aspを削除しておかないとASP言語の実行がされなくなります。使い方を間違えるととても危険なツールです。


もう1つはMoIISProtectをISAPIに追加する方法です。

MOIISProtectをISAPIフィルタに登録するだけでIIS製品情報が非表示になります。これは簡単で便利です。
MOIISProtect.gif


【HTTPヘッダーのETag情報を隠蔽する】
最後にETag情報だけを隠蔽するためのETagFixというISAPIアプリを紹介します。これは試してないですが、多分予想通りの働きをしてくれるものと思われます。無料だそうです。

| | Comments (0) | TrackBack (2)

November 04, 2004

DNSサーバ設定上級編:オリジン・キャッシュの区別とforwarder設定の使い分け

DNSサーバは、メールサーバに並ぶくらい仕組みをよく理解されない状態で設定されて公開されてしまう場合が多いです。「とりあえず動いているからいいか」という妥協が良くないのは言うまでもありません。ということで今回はDNSサーバの正しい設定と構成について話しをしたいと思います。

【オリジンとキャッシュの違い】
DNSサーバにプライマリとセカンダリがあることはよく知られています。しかしオリジンとキャッシュという考え方を初めて聞く人も多いと思います。オリジンは管理しているサイトの情報を提供するサーバです。キャッシュはいわゆるキャッシュのサーバになります。

オリジンとキャッシュを分けるメリットは2点あります。一つ目は例えばDNSサーバにDoSアタックがあったとしてもオリジンサーバにまでそのアタックが及びません。二つ目はオリジンサーバに不正侵入されて情報が盗まれるというリスクが減ります。(ただしオリジンサーバは必ずプライベートIPにしておきましょう)

【forwarder設定の有無がなぜ重要か】
外部公開用DNSサーバとDNSオリジンサーバ共、管理しているサイトの情報だけ正引き・逆引きの情報を提供できれば十分です。forwarderというのは、問い合わせに対してサーバが情報を持っていない場合他のDNSサーバに代理で問い合わせをするという仕組みです。公開用DNSサーバにはforwarder設定は不要です。もしDNSサーバにforwarder設定をしてしまうと一般ユーザのPCのDNSサーバ設定に公開しているDNSサーバのIPアドレスを設定されてしまうかもしれません。そうなると余計なサーバ負荷やネットワーク帯域利用率が増えてしまいます。

【理想的なサーバ構成とforwarder設定】
お金に余裕があるサイトは次のようにサーバを構成するのがよいでしょう。(6台必要になります)
-----------------------------------------------------------------------------
・外部公開用DNSサーバ(forwarder設定なし)
【DNSプライマリ(キャッシュ)】 【DNSセカンダリ(キャッシュ)】
==================================================
・DNSオリジンサーバ(forwarder設定なし)
【DNSプライマリ(オリジン)】 【DNSセカンダリ(オリジン)】
==================================================
・社内利用用DNSサーバ(forwarder設定あり)
【DNSプライマリ(キャッシュ)】 【DNSセカンダリ(キャッシュ)】
-----------------------------------------------------------------------------

【forwarder実験】
実験してみましょう。まずはDNSサーバにforwarder設定をしていない適切な例を示します。


% nslookup -query=NS hogehoge.co.jp
bidders.co.jp nameserver = ns.hogehoge.co.jp

% nslookup www.yahoo.co.jp ns.hogehoge.co.jp
*** UnKnown can't find www.yahoo.co.jp: Query refused



次はforwarder設定がされている不適切な例を示します。

% nslookup -query=NS araara.co.jp
bidders.co.jp nameserver = ns.araara.co.jp

% nslookup www.yahoo.co.jp ns.araara.co.jp
Name: www.yahoo.co.jp
Addresses: 210.81.150.5, 211.14.15.5, 202.229.198.216, 202.229.199.136
203.141.35.113, 210.81.3.241



1個目の場合はns.hogehoge.co.jpにwww.yahoo.co.jpの正引きの情報を問い合わせたらQuery refusedになりました。2個目の場合は正引きのレスポンスが帰ってきてしまいました。この違いは何でしょうか。それは管理しているサイト以外の問い合わせに答えるか答えないかの違いになります。基本的にDNSサーバは管理しているサイトの問い合わせ情報だけ答えればいいので余計な情報まで返す必要はないため、1個目が正解になります。


【とはいいつつも】
とはいいつつも、DNSサーバのために6台もサーバを割けるサイトというのは少ないでしょう。一般的なのはオリジン、キャッシュ、社内利用を兼ねたDNSサーバを2台用意するというパターンです。これはこれでよいと思いますが、その構成だとサイトに大量アクセスがくるようになると危険が一杯だということだけ覚えて置いてください。

| | Comments (0) | TrackBack (0)

« October 2004 | Main | December 2004 »