« September 2004 | Main | November 2004 »

October 28, 2004

HTTPヘッダー研究その3: キャッシュコントロール

ロゴや.cssのように滅多に更新されないデータがあったとします。サイトにアクセスする度にWEBブラウザーがこういったデータを毎回読み込むようになっているとネットワーク帯域の無駄遣いですし、レスポンスも遅くなります。そこで今回はHTTPレスポンスヘッダーを書き換えてそれらのデータをWEBブラウザーのキャッシュに残るようにする方法を記してみたいと思います。

【基礎知識編】
キャッシュコントロールを考える際、知っておくべきHTTPレスポンスヘッダーは4つ。Cache-Control、Pragma、Expires、及びETagである。細かい話しは省略するので次のサイトを見ておいてください。(ずるい?)

事例に学ぶWebシステム開発のワンポイント(12)

今回はETagは無条件削除、Cache-ControlだけコントロールするとしてPragmaとExpiresは対象外とします。


【Apacheでの設定編】
apacheの場合いろいろなやり方があるようですが、ここではmod_expiresを追加する方法をご紹介します。

まずmod_expiresを追加してコンパイルします。
./configure --enable-module=expires
make; make install

そして以下のような要領でhttpd.confを書き換えます。


<Directory />
Options None
AllowOverride None
ExpiresActive On
ExpiresByType text/html "access plus 1 hours"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType text/css "access plus 1 days"
ExpiresByType application/x-javascript "access plus 1 days"
</Directory>


【Tux Web Serverでの設定編】
①/proc/sys/net/Tux Web Server/generate_cache_controlが"1"になっていなければ"1"にします。ただしデフォルトが"1"なので特に書き換える必要はないかも。
②/etc/Tux Web Server.mime.typesを次の要領で書き換えます。


text/html html|3600 htm|3600
image/gif gif|86400
image/jpeg jpeg jpg|86400 jpe


③/etc/init.d/Tux Web Server restart


【IISでの設定編】
IISの場合は拡張子別でのHTTPヘッダーコントロールができず、フォルダ単位になります。IISの場合はGUIベースなので簡単です。
HTTP_compress_IIS.gif


【やってみた結果】
HTTPレスポンスヘッダーを見て次のようになっていたら成功です。
Date: Thu, 28 Oct 2004 09:31:06 GMT
Content-Type: text/html
Cache-Control: max-age=3600

さて効果はどうか。実際のデータを多少改変したのが以下の図です。日曜日と月曜日の間に設定変更をしましたが、リクエスト、レスポンス共激減したようですね。
cache_hit.gif

| | Comments (1) | TrackBack (0)

October 27, 2004

LANケーブル、カテゴリー5eと6のどっちにする

1000BASE-Tのネットワークを作ることになったとします。LANケーブルとしての選択肢はカテゴリー5eとカテゴリー6の2種類です。あなたならどちらを選びますか?(昔これで少し悩みました)。ちなみに値段はカテゴリー6ケーブルの方が高いです。

予算があり余っているのであればカテゴリー6を選ぶいうのがベターな気がしますが、私は現状では過剰投資だと思っています。1000Mbpsに対応していると堂々と謳われているカテゴリー5eで十分だと思います。

【ご参考】
http://www.okadadenko.com/topic/4_multimedia_012.htm

| | Comments (5) | TrackBack (0)

October 26, 2004

徹底的にリンク切れを取り除こう

HTMLファイルを注意深くのぞいてみると、リンク切れしている部分が意外と多く発見できるものです。特にデザイン変更を繰り返しているページはそれが顕著に見られます。これをWEBデザイナーに指摘すると「開発効率を上げるためにはそんな些細な部分まで追求できないよ」という答えが返ってきそうです。しかしシステム管理者の立場から見るとリンク切れは徹底的に取り除くべきだといえそうです。

【リンク切れが引き起こす影響】
度々参照されるファイル、例えばロゴや.cssファイルは通常HTTPレスポンスヘッダーを操作してWEBブラウザーのキャッシュに残してもらうような記述をします。このファイルがうまく読み込まれれば以後はそのファイルに対してほとんどアクセスがなくなるのですが、もしこれがリンク切れだとすると、該当ページへのアクセスの度にそのファイルを読み込みにいきます。これはレスポンスの低下とネットワーク帯域の無駄遣いにつながります。

【404エラーページは極力簡略化すべき】
とはいいつつもWEBデザイナーや開発者が常にリンク切れに気を配ってくれることを期待すべきではないし、システム管理者が常にリンク切れをチェックすることも現実的ではないです。そう考えるとリンク切れ、すなわちFile Not Foundが発生したときに読み込まれる404エラーページは極力簡略化しておいたほうがよいといえます。もし404エラーページが凝っていると、リンク切れがあるページにアクセスがあるたびに凝った404エラーページも読み込まれることになります。

【リンク切れをどのように探す?】
apacheのログをひたすらチェックするという方法もありですが、私は秀まるおさんが作られた横取り丸というソフトを使っています。これはIEのプロクシーサーバとして機能して、アクセスのあったURLをその名の通り横取りして、HTTPリクエストとHTTPレスポンスをリアルタイムに表示してくれます。このソフトを動かしながらサイトにアクセスすると、慣れればすぐにリンク切れ発生個所がわかるようになります。

| | Comments (0) | TrackBack (0)

October 25, 2004

ホスト級UNIXマシンにLinuxを入れよう

以前IBMさんとお話ししたとき、IBMで販売しているサーバ機ならどれでもLinuxが動くように準備をしているということを聞きました。これは安価なIAサーバからホスト級UNXサーバp690までどれでもということです(SunのFire25kではLinuxは動かないようですがHPのSuperdomeではLinuxが動くようですね)。当初の私は素人考えで「Linuxなんか動かす人なんているのか~?」なんて思っていましたが、最近は「それもアリかも」と思うようになりました。

会社規模が大きくなってくると、サーバダウンが即機会損失につながります。会社創業当時だったら機会損失といっても1時間サーバを止めても数百円程度にしかならなかったのでへっちゃらでしたが、最近だと、○○○○円(企業秘密)もの損失になるため、コストがかかってもサーバを止めないための出費なら許されるようになりました。

というように状況が変わると、Linuxでしか動かないアプリケーションは、ホスト級UNIXマシンに載せて動かすのは可用性向上には大変効果的なのではないかと考えるようになりました。読者の皆さんはホスト級UNIXマシンの経験があるかどうかはわかりませんが、そのクラスのマシンになると、まずハードウェア的な障害でシステムがダウンすることはまずありません。またそのクラスのマシンはどのメーカーも論理的分割(Sunだとドメイン、IBMだとLPAR、HPはよく知らないけどパーティショニング?)ができるので、マシンパワーの数パーセントをパーティション分けして使うというようなことができるようになります。すなわちホスト級UNIXマシンをまずメインDB用途に導入しておき、余ったマシンパワーでLinuxを動かすという使い方ですね。

| | Comments (0) | TrackBack (0)

October 24, 2004

メールサーバのDNS逆引き設定を忘れずに

メールサーバ(SMTPサーバorMTAサーバと呼ぶのが正しい?)を稼動させるためにはDNSサーバの設定も必要になりますが、MXレコードの記述は必ずなされますが、逆引きの設定までは徹底されていないように感じます。そんなわけで、今回はメールサーバの逆引き設定をしてみましょう。

【なんで逆引き設定が必要なの?】

世界中を見渡すと、メールサーバの仕組みを全然理解しないでとりあえずどこかから設定例を入手して動かしてみて、とりあえず動いたからOK,という安直な方法で本稼動させてしまっているシステム管理者が非常に多い気がします。でもまあそれは次の理由からなんとなく分かるような気がします。

 ①メールサーバを設定する機会は非常に少ない。
 ②接続する相手が千差万別なのでテストが難しい。
 ③メールの仕組み自体複雑で理解がしんどいのに、ただでさえ理解しにくいDNSの仕組みまで理解を要求されるのでますますしんどい。

要するに仕組みの理解が面倒くさい割には人生のうちでメールサーバを設定する機会なんてそう滅多にないので真剣に理解することよりもとりあえず動かしてしまって早くメールサーバ立ち上げの仕事から逃れたいという心理が働くのでしょう。

さて、なんで逆引き設定が必要なのかという本題に戻りますが、そもそもメールシステムの本質はSMTPサーバとSMTPサーバがTCPコネクションを張ってメールデータの受け渡しをするだけです。ここまでは簡単ですね。しかし時代と共にウィルスメールやSPAMメールが社会問題化してくると、問題のあるメールは受け取らないようにフィルタリングしてしまいたいというニーズが高まってきました。そこでいろいろなフィルタリングがメールサーバに施されてきましたが、その流れの中で「送信 IP アドレスからホスト名の逆引きができない場合に受信拒否する」実装を施したメールサーバが現れました。このメールサーバにメールを送っても逆引き設定をしていないと受信拒否されることが予想されます。

・・・とはいいつつも正直私はそのような実装が施されているメールサーバの名前を具体的に知らないんですよね。どなたがご存知でしたらコメントいただけると幸いです。それがわかれば、正引きと逆引きをぴったり一致させなければならないのか、それともとりあえず逆引き設定さえしておけばよいのか調べることができます。私はそのあたり不安なので今は正引きと逆引きをぴったり一致させています。


PS: メールサーバって自分の中では「SMTP/MTA」サーバのことを指しているのですが、一般的な概念としては「POP」も含まれるのでしょうか。POPが含まれるのであればIMAPやAPOPも含まれるのだろうか???メールシステムって本当に難しい!

| | Comments (2) | TrackBack (0)

October 22, 2004

HTTPヘッダー研究その2: 不要なHTTPレスポンスヘッダーは消しましょう

HTTPレスポンスヘッダーって無駄が多いですよね。何を持って無駄かというのも議論が分かれるところですが、大規模サイトになると1行の無駄でも数万~数百万アクセスという量になってかなり大きな無駄が発生してしまいます。これは当然ネットワーク費用にも跳ね返ってくるのでもったいない話しです。そこで今日はapacheのHTTPレスポンスヘッダーの削除方法を記して見ます。

【設定方法】
apacheの場合、いくつかのHTTPレスポンスヘッダーはhttpd.confの編集で操作できますが(例: ETagの場合は「FileETag none」とか)、それ以外のものになると基本的にはC言語で書かれているソースの該当個所を削除することになります。え、危険ではないかって?それがオープンソース(すなわち自己責任)というものなのでリスクは積極的に受け入れましょう。

ではまずは何を消すかを考えてみましょう。
---------------------------------------------------
% telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK

Date: Mon, 18 Oct 2004 11:23:39 GMT
Server: Apache/1.3.31 (Unix)
Last-Modified: Fri, 10 Oct 2003 11:39:51 GMT
ETag: "b7d74-64-3f869a87"
Accept-Ranges: bytes
Content-Length: 100
Connection: close
Content-Type: text/html
---------------------------------------------------
賛否両論あるかと思いますが、一旦上記赤字の部分としてみたいと思います。ということで以下の要領で該当部分をコメントアウトしてコンパイルしてみましょう。

src/main/http_core.c

/*
ap_set_last_modified(r);
ap_set_etag(r);
ap_table_setn(r->headers_out, "Accept-Ranges", "bytes");
*/

そしてapacheを再度起動してHTTPレスポンスヘッダーを出して見ると・・・
---------------------------------------------------
HTTP/1.1 200 OK
Date: Mon, 18 Oct 2004 11:23:39 GMT
Server: Apache/1.3.31 (Unix)
Content-Length: 100
Connection: close
Content-Type: text/html
---------------------------------------------------

大成功です。

| | Comments (4) | TrackBack (0)

October 21, 2004

404エラー用ページを用意しよう(apache編)

apacheをなにも考えずにインストールすると、404エラーがこんな感じになります。


Not Found

The requested URL /a was not found on this server.


Apache/1.3.31 Server at hogehoge.nifty.com Port 80


これはむちゃくちゃかっこ悪いですしapacheのバージョンもバレバレなので、多少でも加工してみることにしましょう。


【設定方法】
httpd.confファイルに下記の行を追加するだけです。①だとメッセージがそのまま送信されます。②だと指定のURLにリダイレクトします。

①ErrorDocument 404 "<h1>404 error. File Not Found</h1>"
②ErrorDocument 404 http://www.hogehoge.com/404error.html

今回をきっかけに、他社サイトを参考にしながら是非かっこいい404エラーページ(?!)を作ってみてください。


【他社の例】
Yahoo!
楽天
ビッダーズ
朝日新聞
@NIFTY
biglobe
ラクーン
NAVER
ハンゲーム

| | Comments (0) | TrackBack (0)

October 20, 2004

ロードバランサーの選び方

ロードバランサーにはいろいろな機種があり、どれを選んだらよいか迷いますよね。そんなわけで主観的なロードバランサーの選び方を今回は記してみましょう。

【PCサーバベースかスイッチベースか】
まず最も重要なこととして、ハードウェアがPCサーバにソフトウェアを載せたタイプのものか、スイッチの専用チップ上に専用OSを載せたものかを選択します。PCサーバベースは高機能、多機能でかつWEB上で操作ができる等扱いやすいものが多いですが、所詮はPCサーバベースなのでフルワイヤーの転送速度が出ない(FastEtherのインタフェースを持つものだと30-50Mbps程度しか出ない)場合が多いです。スイッチベースは基本的な設定をコマンドライン上で行うことが多く扱いにくいですが、フルワイヤーが出る(FastEtherのインタフェースを持つものだと100Mbps近く出る)場合が多いです。大規模サイトであれば無条件にスイッチベースを選ぶことになります。

PCサーバベースで代表的なメーカーはF5networks(BigIPシリーズ等)とRadwareあたりでしょうか。
スイッチベースで代表的なメーカーはFoundry(ServerIronシリーズ)とNortel(ALTEONシリーズ等)あたりでしょうか。

【SSLのセッション維持ができるか】
SSLのセッション維持をしているサービス管理の経験がないので何ともいえないのですが、このあたり、ロードバランサーを選ぶ際には重要なポイントになると思います。


以下、スイッチべースを前提に記します。スイッチベースのロードバランサーは通称L4スイッチと呼んでいるのでここでもそう呼ばせてもらいます。

【コマンドラインの操作性】
L4スイッチはメーカーによって操作性が全然違うので、実際に使ってみて自分に相性のよい機種にするとよいと思います。例えばFoundryはなんとなくCISCOっぽいです。NortelはなんとなくUNIXっぽいです。(使ってみればわかります)

【ポート数】
ポート数は当然たくさんあればあるだけよいのですが、当然ポート数が多くなればなるほど高くなります。ただし意外と知られてないようなのですが、L4スイッチ配下にL2スイッチをぶら下げてその下にサーバをつけてもロードバランス可能です。すなわちポート数は上位と下位で最低2ポートあればよいことになります。またいつか記す予定のDSR構成を選べば1ポートあればよくなります。・・・というわけでポート数は最低ポート数+L2スイッチという組み合わせが一番コストパフォーマンスがよいです。

【その他】
基本性能や安定性等も当然考慮点の一つに入るとは思うのですが、これまでの経験ではそれらはどの製品もそれなりに条件をクリアしているのでそんなに気にしてはいませんでした。(エンタープライズ用途でキャパシティぎりぎりまで使うということはないですし、通常二重化するので安定性についてもそこまでシビアに考えることもないかという考えからです)

むしろL4スイッチにおいて重要なのは専用OSの品質とバージョンアップ頻度です。たとえばFoundryだとバージョンアップ頻度は高くないですが最新バージョンはバグが多く、枯れたバージョンを選んで使うのが重要です。Nortelだと毎週のようにパッチがリリースされるのでどれをいれてよいのかさっぱりわかりません。等々そんな感じです。L4スイッチの挙動は意外と複雑なのでL2やL3スイッチと比較してバグがあって当然というつもりで考えたほうがよいです。

| | Comments (3) | TrackBack (1)

bind 製品情報隠蔽

ポートスキャンをかけると、bindについてもバージョン情報がバレバレです。こんな情報はクラッカーにとっては有用ですが、通常のユーザには全く不要なのでさっさと出ないようにしてしまいましょう。(ただbind自体セキュリティホールが多いので個人的には他のDNSサーバを使ったほうがよいとは思いますけど)

【やり方】

named.confというファイルに

「version "";」

を追加するだけです。


例:

options {
directory "/etc/namedb";
versioin "";
 ・
 ・
 ・

| | Comments (0) | TrackBack (0)

October 18, 2004

HTTPヘッダー研究その1: apache製品情報隠蔽しよう

HTTPヘッダーって見たことありますか? 見てみると製品情報がバレバレです。

---------------------------------------------------
% telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 18 Oct 2004 11:23:39 GMT
Server: Apache/1.3.31 (Unix)
Last-Modified: Fri, 10 Oct 2003 11:39:51 GMT
ETag: "b7d74-64-3f869a87"
Accept-Ranges: bytes
Content-Length: 100
Connection: close
Content-Type: text/html
---------------------------------------------------

こんな製品情報を出しておく合理的な理由は特にないです。悪意を持ったユーザが
こんな情報をこんな簡単な方法で入手できるのも問題です。そこで今回は
apacheでの製品情報隠蔽方法をご紹介します。


【apacheでの製品情報隠蔽方法】

以下の要領でファイルを書き換え、通常の方法でコンパイルすればOKです。
既にインストールされているapacheの場合でも再コンパイルが必要となります。


※apache1.3系の場合
include/httpd.h
 #define SERVER_BASEPRODUCT "Apache"
 #define SERVER_BASEREVISION "1.3.31"

 #define SERVER_BASEPRODUCT "HogeHoge"
 #define SERVER_BASEREVISION ""

※apache2.0系 の場合
include/ap_release.h
#define AP_SERVER_BASEPRODUCT "Apache"
#define AP_SERVER_BASEREVISION AP_SERVER_MINORREVISION "." AP_SERVER_PATCHLEVEL
 ↓
#define AP_SERVER_BASEPRODUCT "HogeHoge"
#define AP_SERVER_BASEREVISION ""


すると以下のようになります。

---------------------------------------------------
HTTP/1.1 200 OK
Date: Mon, 18 Oct 2004 11:23:39 GMT
Server: HogeHoge/ (Unix)
Last-Modified: Fri, 10 Oct 2003 11:39:51 GMT
ETag: "b7d74-64-3f869a87"
Accept-Ranges: bytes
Content-Length: 100
Connection: close
Content-Type: text/html
---------------------------------------------------

※ただしapacheの世界シェアは7割以上ということもあり、こんな隠蔽をしてもapacheであることはバレバレだと思ったほうがよいです。今回の対応は、まあやらないよりはやっておいたほうがよいくらいに思ったほうがよいでしょう。

| | Comments (0) | TrackBack (0)

October 01, 2004

パッチパネルを使って配線しよう

サーバやラックが増えてくると配線が悲惨なまでにごちゃごちゃになります。特にポート数がたくさんあるコアスイッチに全てのスイッチからのケーブルを集約しようとすると見るも無残な配線になります。そんなときはパッチパネルを使うことをお勧めします。

【パッチパネルとは?】

通常はLANケーブルや光ケーブルでダイレクトにスイッチとスイッチ、サーバとスイッチ等を接続します。しかしラックが増えてくると配線がごちゃごちゃになり、何がどこにつながっているのかわからなくなってきます。これを少しでも解消するためにはいったん配線を中継できると便利です。それを実現するのがパッチパネルです。

パッチパネルの仕組みはシンプルで、ケーブルのInputとOutputを中継するためのポートがたくさん並んでいるだけです。パッチパネル自体には電気を使いませんのでスイッチと違い信号を増幅する機能はありません。単に2本のケーブルを物理的に接続する仕組みしかありません。

パッチパネルのよいところは、仕組みが単純なので非常に安価なことです。ケーブル集約だけならL2スイッチでも同じことができますが、その方法だとラック数が数十とか数百といった単位になってくるとコストがかなりかさんできます。またうまく設計すると配線変更をパッチパネルにて行えるようになるのでメンテナンスの容易性が増します。


| | Comments (0) | TrackBack (0)

« September 2004 | Main | November 2004 »