ぢろーらもブログに4秒に1度のアクセス？なんぢゃこりゃ・・・

ええと、つい最近、ぢろーらものサイトにけっこうすごい量のアクセスがありました。ただ、これは「人気サイトで躍り出た」というわけでもなんでもなく、別の理由のようでした。

ぢろーらもは毎日自分のブログに対して、どのくらいアクセスがあったか、というのを確認しています。平日であればだいたいユニークユーザー数が200人～300人くらいで、その中で目的のページから他のページを見てくれる人は少ないので、アクセス数はこの数値よりも数十多いくらいが普通です。

土日祝日等通常の会社が休みになるときは、アクセス数はこれの半分くらいになります。これは、休みの日は以前に書いたIT系のブログへのアクセスがけっこう減るからと思われます。

で、昨日のアクセス数なのですが・・・・ん？

1日のアクセス数・・・13681回？？？

どういうこと？？普通のブログだぞ・・・そんなにアクセスあるわけないじゃん・・・。きっとこれには理由があるはずだ・・・。

ぢろーらもは先に「どのサイトにアクセスがあったか・・・」というのを確認するので、すぐに「特定のページに繰り返しアクセスされている」ということはわかりました。このパターンだと、アクセス元は同じはずだな・・・。で、ユニークアクセス数を確認します。やっぱり200人程度ですわね・・・。

で、時間毎のアクセス数を確認すると・・・うん、朝の9時台から夜中の12時台にかけて、毎時間900アクセス程度きてますね・・・。で、1時台に終了している、と・・・。

つまり、「4秒に一回特定のページにアクセスされている」ということか・・・。かなり規則的ですね・・・。

どう考えても、人の手でやっているわけではなく、なんらかの自動化ツールですね・・・ぢろーらものサイトの生死確認でもしてるのかいな・・・ってか、アクセス履歴見るのに困るから、そんなことしないでほしいんだけどなぁ・・・。

で、同じことになっている人がいるかなぁ・・・と思ったら、いらっしゃいましたね・・・。

http://kchon.blog111.fc2.com/blog-entry-281.html

何らかの運用監視ツールだったり、JMeterのようなWeb用パフォーマンス測定ツールだったり、はたまたロードバランサのヘルスチェックであったりと、特にプログラムの知識がなくとも数秒に1回のアクセス、という状況は簡単に作り出せます。上記サイトの方が参考としてあげているのはGoogle Chrome用の拡張ツールで、指定間隔でページをリロードできるようなものでした（http://www.forest.impress.co.jp/docs/review/20100616_374691.html）。もちろん、これでも同じことはできそうですね。

まあ、現状としては

・当然のことながら、4秒に1回程度のアクセスではWebサーバにとっては大した負荷ではないので、ブログが表示されにくくなるなどの不具合が発生することは考えにくい

・ぢろーらもがアクセス履歴を見る際も、今の時点で主にみているのはアクセス数ではなくユニークユーザ数なので、今のところその部分には影響がない

・定期アクセスされているページは1つのみなので、そのページを除外すれば、よくアクセスされている他のサイトを把握することはできる

といった感じです。そんなには困ってません。

とりあえずほっとこうかな・・・。ずっと続くようだったらNTTコミュニケーションズさんになんとかしてもらうかもしれませんが、今はいいことにします。

・・・。

で、直接は関係ないのですが、この件についてちょっと調べていたら、こういうのも見つかりました。2010年に起こった「岡崎市立中央図書館事件」です。http://ja.wikipedia.org/wiki/%E5%B2%A1%E5%B4%8E%E5%B8%82%E7%AB%8B%E4%B8%AD%E5%A4%AE%E5%9B%B3%E6%9B%B8%E9%A4%A8%E4%BA%8B%E4%BB%B6　

自動化ツールで図書館のシステムにアクセスしていた男性が、システムに高頻度のアクセスを故意に与えていたということで、偽計業務妨害容疑で逮捕されました（その後、起訴猶予処分として釈放）。やはり1秒に1回程度のアクセスなので、常識的に考えるとこの程度でダウンするシステムのほうが問題です。当然、セキュリティの専門家の方も「攻撃とは明らかに違うもので、警察の捜査には問題がある」と指摘しています。まあ、わたくしも普通にそう思います。警察だけだとどうしても限界ありますよね・・・。

まあ、かなり運が悪く（我々から見ると）かなり理不尽なケースではありますが、このように場合によっては警察に捕まってしまうこともあるので、この程度の頻度であってもよそさまのサイトに定期アクセスをしかけるのは控えたほうがよろしいかと思いますよ・・・。

・・・。

ちなみに、こちらをモチーフにした＠ITの連載コラムをリーベルGさんという方が書いていて、けっこう人気のサイトになっています（鼠と竜のゲーム→http://el.jibun.atmarkit.co.jp/pressenter/2012/09/1-0f4e.html）。

毎週月曜日に更新のこちらの記事、面白く読ませていただいておりますm(_ _)m

---

この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

---

データベースの負荷分散

こちらも会社出ていた話題ですが、今日は「大規模なシステムでデータベース（DBサーバ）を負荷分散するにはどうしたいいのか？」という話がでていました。「負荷分散環境でのWebアプリケーション開発」でも触れましたが、Webサーバの負荷分散のほうは負荷分散装置での負荷分散（スケールアウト）が一般的ですが、DBサーバの場合には必ずしもそうではないですしね。特に更新が多い場合には気をつけないといけませんし（参考サイト：http://japan.zdnet.com/sp/feature/06sp0130/story/0,2000066437,20234267-2,00.htm　）。

データベースの場合、関連するのはDBそのももの作りやクラスタ用のソフト、ストレージ等であり、主にネットワーク機器を扱っているぢろーらものところにはこれまで話はほとんどありませんでした。まあ、せいぜいあってもL2レベルの話か・・・。

では、こちらも少し調べてみることにするかな・・・。

http://thinkit.co.jp/cert/article/0610/1/6/2.htm　などにもあるように、複数のDBサーバでデータの同期がとれるのであれば、参照系に関しては負荷分散装置（ロードバランサ）を使う方法がよいようですね。もちろん、参照系と更新系とで担当するサーバをわける、というのでも負荷分散になるかと思います。

DBサーバそのものを増やさずに、Memcachedというソフトで「DB用のキャッシュサーバ」のようなものを構築する方法もあります。たとえばhttp://www.atmarkit.co.jp/fcoding/articles/rorcgm/04/rorcgm04a.html　などに説明ありです。なるほど、これであれば読み出しは速くなりそうですね。http://gihyo.jp/dev/serial/01/various-nosql/0002　にもあるように「揮発性」なので、データが消えても問題ない場面に使用されます。

確かTwitterのような大規模なシステムでも、WebサーバとDBサーバの間にMemcachedをインストールしたサーバを数台置き、DBサーバ自体はSunのおばけサーバー1台（おそらく数千万円）で運用している、という話を聞きます。　

あと、こちらはサーバ内の話ですが、http://thinkit.co.jp/cert/article/0610/1/6/2.htm　にはtmpfs（メモリ上のファイルシステム）を使用する方法なども掲載されています。実際にmemcachedとtmpfsとのパフォーマンス比較をされた方もいらっしゃるようです（http://blog.asial.co.jp/220　）。

更新系の場合には負荷分散装置を使って、というのは難しいということは上記のとおりです。やっぱりそうすると、クラスタ用のソフトなどが必要になるのかな・・・。よく聞くのがOracleのRACですね。複数サーバがある場合に更新処理の一貫性を保つための処理を、独自の方法でメモリ上で行なっています。http://www.atmarkit.co.jp/fdb/rensai/basics_rdb/07/basicrdb07_01.html

あとはデータベースのテーブルを分割して、マスターになるサーバをわけるなどの方法があります。http://itpro.nikkeibp.co.jp/article/NEWS/20060330/233820/　ではmixiの例、http://enterprisezine.jp/article/detail/25　ではモバオク/モバゲーの例が取り上げられています。

そのほか、もっとシンプルな方法としては、http://thinkit.co.jp/free/tech/10/4/1.html　はハードディスクをわけることによるI/O負荷分散です。管理情報などのテーブルスペース（DBやインデックスなどを置く場所）と、サービスとして使うDBのテーブルスペースを別のディスクに置く、というものです。

なるほど、けっこう工夫されているわけですね。Webサーバの負荷分散よりもいろいろと複雑です。

そういえば、mixiを利用されている方ならご存知かと思いますが、システム障害で2日間ほどつながりにくい状態にありました。http://slashdot.jp/it/10/08/12/0540221.shtml　http://www.publickey1.jp/blog/10/miximemcached.htmlなどにもあるとおり、memcachedの問題なのですね。そっか、だから「保存されている日記などのデータには影響がない」というのもそのとおりなのですね。詳細はわかりませんが、ここまでわかっているのであればある程度信憑性はありますね。

---

この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

---

負荷分散環境でのWebアプリケーション開発

以前、お客さんから「今までWebサーバを負荷分散するような環境でアプリケーションを作った案件があまりないけど、開発の際の注意点とかある？」と質問されました。

ぢろーらもはアプリ屋さんではないので詳細についてはわからないのですが、たとえば負荷分散装置（ロードバランサ：アプリケーションスイッチ）などで問題になりやすいのはセッションをどう維持するか、という問題（負荷分散装置で接続維持機能を使って同じクライアントからの通信は同じサーバに振り分ける、もしくは負荷分散装置は振り分けのみ行ないセッションの管理はアプリケーションに任せる）だったり、負荷分散装置のSSLアクセラレータの機能を使う場合に、「もともとの通信がHTTPSかHTTPかをWebサーバがどのように区別するか？そしてそれにしたがってどのようにWebアプリケーションの動作を制御するか」などがあります。

前者に関しては、JSPなど動的ページを生成する場合には割とよく出てくる話です。まあ、負荷分散装置（ロードバランサ）であれば当然のことながら接続維持には対応しているでしょうし、比較的安価な装置でも”クライアントIPベースでの接続維持、Cookieベースでの接続維持などには対応しているはずです。

一番動作が単純なのはクライアントIPベースです。しかし、サービスの対象となるクライアントが不特定多数ではなく、特定プロキシやNATなどによって多くのクライアントが同じ送信元IPで負荷分散装置に到達するような場合、クライアントIPベースでは負荷が特定のサーバに偏ってしまうこともありえます。その場合、Cookieベースなどほかの方式を使う必要があります。　

後者ですが、たとえば「アプリケーション（パッケージソフト）がページを生成する際、ページに含むURLリンク絶対パスで生成してしまうので、Webサーバが”もとの通信はHTTPS”ということを知らないと、リンクをhttpで生成してしまうので正しく通信できない」ということはあります。（参考サイト：http://yaekan.sakura.ne.jp/blog/articles/program/160.html　など）

リンクは相対パスで生成するようにすれば問題ないですし、それ以外の方法としては「WebサーバプロセスをTCP:80（TCP：8081など）のもの以外も用意し、HTTPSの場合には、TCP:80以外のポートにフォワーディングする」「クライアントのHTTPSリクエストを複合したあと、バランサ側で、”もとはHTTPSだった”ことを示す任意のHTTPヘッダを挿入してサーバに教えてあげる」なんて方法もあります。もちろんバランサがそれに対応してないといけませんが。

あとは、最終手段（？）としては「バランサ（あるいはほかの機器）で、ページ内のリンクに含まれているHTTPのリンクをHTTPSにかえてしまう」という方法もあるかと思います。アプリケーションに一切手を加えられない場合にはこんな方法での対応するしかないかもしれませんが、HTTPのデータ部まで自在に書き換えられる負荷分散装置（アプリケーションスイッチ）、となると機種は限られますかね。

ええと、他にはどんなこと注意する必要があるのかな・・・と思ってちょっと調べてみました。たとえば、http://www.atmarkit.co.jp/fjava/rensai2/webopt01/webopt01.html　のサイトが参考になりますね。これはWeblogicの例か・・・。

複数サーバ（クラスタ化/負荷分散構成）の場合のみ関連ありそうなのは1回、3回、12回あたりで、気をつけるべきは「複製のオーバーヘッドによる性能低下」「複数サーバ構成でコンテンツキャッシュが正常に働かないことによるパフォーマンス低下」のあたりでしょうか。

こちらも続編があれば書きたいと思います。

---

この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

---

セッションのタイムアウト

よくWebサイトを見ていると、「セッションがタイムアウトしました」というようなメッセージが表示され、ページの再読み込みが必要になる場合があります。たとえばこちらは、同じページを長時間見ていて、次のページに移ろうとしたときなどに表示される場合が多いです。

Webサーバは通常、クライアントからの操作が一定時間ない場合にはそのセッションを切断します。Webサーバにとってもセッションを多く維持しなくてはいけないというのは負荷の増大につながりますし、セキュリティ上も長期間の放置は望ましくありません。なので、こういう動きをします。まあ、Webサーバを構築したことがある人にとっては割と当たり前のことかもしれませんが。

Webのセッションタイムアウトについてはhttp://www.ipa.go.jp/security/awareness/vendor/programmingv1/pdf/a05_03.pdf　が参考になります。
　
たしかMicrosoftのIISであればタイムアウトのデフォルトは20分かと思います。もちろん、最適値というのはそのシステムによってかわります。単に情報を提供するだけの公開サーバであればhttp://ash.jp/java/webapp_session.htm　にもあるように5分などの短めの時間が望ましいですが、社内システムでログインして使うものの場合、長くする必要があります。

もっとも、社内システムだと「一日つなぎっぱなしで使っていてもセッション切断されないようにしたい」というのもあると思います。いずれにせよ、状況によってけっこうチューニングの必要はあるはずです。

同様に、ネットワーク機器でも同じような考え方でセッションタイムアウトがあります。たとえば、セッション情報をもとに処理を行うステートフルインスペクション対応のファイアウォールであれば、その通信がどの状態（TCP通信（3Wayハンドシェーク）が確立前かそのあとか、SMTPでどの段階まで処理したか、など）かを覚えておく必要がありますし、ファイアウォールのほかルータ等NAT処理を行うものであれば変換前後の情報を覚えておく必要があります。このセッションも、無通信の状態なのにそのまま残しておいては、機器のメモリを消費してしまうのである一定時間セッションが無通信の場合にはそのセッション情報（エントリ情報）を削除します。

たとえばYAMAHAルータの場合、http://www.rtpro.yamaha.co.jp/RT/docs/firewall/index.html
の「4.4. 動的フィルタのタイムアウトの設定」のとおりパラメータを設定可能です。

ただ、ネットワーク機器の場合、このあたりはあまり調整されないことが多いでしょう。だいたいの場合、デフォルトの値の設定であれば問題は少ないと思います。たとえば、tcp-syn-timeoutであれば3ウェイハンドシェークが確立する前なので、通常1分もこの状態であることはないはずです。たとえばTCPSynを受けてTCPAck返してるのにそのあとの通信を続けてくれない、というケースだとSynフラッディング攻撃かもしれません。その場合にはこの値を短くすればルータの負担は軽減できますが、短くしすぎると正常なセッションに問題を起こしてしまうこともあるでしょう。また、tcp-idle-timeのように3ウェイハンドシェークが完了して一旦セッションが確立してしまえばその状態はある程度長く続きますが、まったく無通信の時間が60分を超えるというのもケースとしてはなくはないですがあまり多くはないでしょう。

セッションタイムアウトがらみでぢろーらもが一度経験したトラブルとしては、お客さんのところで導入していた機器（YAMAHAではありません）が、UDPセッションがタイムアウトを起こして通信が正常にできなかった、ということがありました。そのときにももちろん、UDPのセッションタイムアウト時間を長くすることにより対応できました。
　
実はそのお客さんところではUDPセッションを使う独自のアプリケーションを導入していたのですが、確かクライアントがUDP投げてから、応答が来るまで30秒～40秒、場合によってもっとかかるようなシステムでした。UDP自体、リアルタイム処理を目的とするものなので、応答にそんなに時間がかかることは通常想定していないはずです。なので、通常どのネットワーク機器もUDPのタイムアウトについてはけっこう短めに設定されています。

そのときも確か、パケットとか見て、「この機器でセッションが切れている」ということで気がついたように記憶しています。前回の話にもつながりますが、こういう局面だとやはりパケットキャプチャも重要になりますね。

P.S　「今週の検索ワード：業務系（ITなど）：2010年8月15日～8月21日」のほうで、メール（SMTP)のセッションタイムアウトについても少し触れています。

---

この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

---

藤色の風：Twitterチャット大会・・・

ラジオNIKKEIで好評放送中の、浅羽由紀さんの新ラジオ番組「藤色の風♪」ですが、由紀さんのブログの記事「朗報◆ラジオＮＩＫＫＥＩ「藤色の風♪」が全国どこでもネットからリアルタイムで聴けるようになりました！」にも紹介されているとおり、http://www.kikeru.com/　のサイトからラジオを聴けるだけでなく、Twitterと連動してつぶやくことができてしまいます。

上記由紀さんのブログでは、「放送を聴きながらTwitterでチャットしましょう！」という呼びかけもあったので、「それならばぜひ・・・（＾＾）」ということで、さっそくTwitterのアカウントとりました。
Twitterの登録や使い方についてはhttp://www.greenspace.info/twitter/　など親切に解説しているサイトもありますが、基本的にはTwitterのトップページにある「今すぐ登録」から言われるがまま登録していけば割とすんなり登録はできました。

ログインしてつぶやくこともできますし、「浅羽由紀」で検索したらあっさり由紀さんも見つかりました

妻なおのアカウントも作ったのですが、どういうわけかぢろーらもから妻も探せませんし、妻からぢろーらもも探せません。

まあ、とりあえずいいや・・・とりあえずkikeruのサイトでTwitterと連携しているっぽいことは確認できました。じゃあ、番組はじまったら遊びに行こう・・・・。

そして番組開始5分前、由紀さんはすでにいらっしゃるようでした。あれ？ぢろーらものこと見えてないのかな？というか、kikeruのタイムラインにぢろーらもの発言が反映されないぞ・・・　一応はいるけど、リロードしたらなくなってしまうし、案の定妻が使っているPCからぢろーらも発言は見えません・・・。何が起こったんだ？というか、なんかこっちの処理に不備があった？Twitterのサイトにはすべて入力した内容は反映されてるけどなぁ・・・。

でも、もう番組ははじまってます・・・ちょっとgoogleとかも調べましたが有益な情報はありませんでした。というか、焦ってて探しきれてないだけかも・・・。

どうも、由紀さん本人にメッセージを送ることはできるようです。ひとまずこちらがログインしていることは認識してもらいました。

結局番組終了しても問題は解決しませんでした・・・あーあ、まともにラジオ聴けなかった・・・後日オンデマンドで聴くかな・・・。

せっかく見ているときのリアルタイムの感想だったり、また由紀さんが何かもらって食べてたりしたら「あ、また食べとる・・・「（＾＾；」とか、つっこみをいれよう（笑）かと思ったのに・・・・。

なんか、こっちの調査不足、設定不備で焦りまくり、由紀さんには大変見苦しい姿を見せてしまったかもしれません・・・失礼いたしました・・・m(_ _)m。

で、妻から報告があり、ぢろーらもがつぶやいたいくつかの発言のうち、1つだけがkikeruのタイムラインで見えている、とのこと。は？どういうこと？？そうすると、このパソコンの設定ミスとか、そういう問題ではなさそうだな・・・。じゃあ、Twitter側の問題？？

そう思って、Twitterのヘルプ（http://jptwitterhelp.blogspot.com/）みたら、しっかり書かれていました。

ツイートがタイムラインから消えてしまった・・・要するに調査中ということか・・・、まあ無料のサービスだから仕方ないのかもしれませんが、それじゃあ困るんだけどなぁ・・・しばらくしたら安定して使えるようになればいいけど・・・。

ちなみに、同じヘルプの別項目投稿の検索結果や「友だちを検索」に自分のアカウントが反映しないで、アカウントの検索ができない件についてもわかりました。登録したばっかりだと検索ひっかからず、しばらく時間かかるんですね・・・。

だとすると、こっちでできることはなさそうです。次回にチャレンジ、です「（＾＾；）

P.S　今、妻なおに教えてもらいましたが、「藤色の風♪」放送時のぢろーらものつぶやきが、kikeruのタイムラインにちゃんと反映されていました。遅いってば・・・（－－）。やっぱりTwitterのアカウントがまともに使えるまで時間がかかっただけのようです・・・。

---

この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

---