調べてみたところ、この503エラーは「1時間につき2,000リクエストまでの当初利用限度」という利用制限にひっかかったのが原因みたいです。
この制限は2010年10月15日から施行されていたようですが、「1時間2000リクエストなんて自分のサイトではあり得ない」と思って完全スルーを決め込んでいました。
1時間に2000リクエストということは、1分に33.333リクエスト。だいたい2秒に1リクエストくらいです。
自分の管理サイトがこんなにアクセスが多いはずはないんですが、放置するわけにもいかないですし、とりあえず調査します。
ひとまず様子をみてみましたが、だいたい毎時30分くらいになると503エラーが出るようになり、毎時55分~00分くらいになると商品情報取得が再開され、また30分くらいで503になる、、、というのが繰りかえされていました。
30分足らずで2000リクエストの制限を使い切ってしまっているようです。
人間によるアクセスがこんなに多いというのはありえないので、おそらくbotによるアクセスが原因でしょう。
とりあえず、以下の対策をとってみました。
■自作ウィジェットを削除
まずはこのブログのサイドバーに置いていた自作のウィジェットを削除しました。今はAmazon公式のウィジェットにしてます。
ちなみに削除したウィジェットはキャッシュを使ってなかったので1アクセスごとにリクエストを送っていました。
このブログはだいたい1日あたり1,200PVくらい(Google Analyticsの解析結果)なんですが、analogの解析結果だと5,000PVくらいありました。
まずはこれで1時間あたり200くらいはリクエストを削減できたと思います。(後になって焼け石に水だったわかりましたが)
■不明なボットを弾く
別の管理サイトのログを見てみたら、ここ数日同一ホストから1日8,000ほどアクセスがあるのがわかりました。User-agentも名乗らず、リファラもなし。ホストが「www????.sakura.ne.jp」になってるので、たぶん誰かがレンタルサーバーに設置してるbotだと思います。
.htaccessで
deny from www????.sakura.ne.jp
して弾くようにしました。
■GoogleBot-Imageを弾く
GoogleBot-Imageが大挙襲来していたのが分かりました。
画像をインデックスしてもらっても特にメリットはないので、robots.txtでブロックすることにしました。
あとmsnやyahooのボットもちょくちょく来てるようなので、ついでにCrawl-delayも追加。
User-agent: Googlebot-Image
Disallow: /
Crawl-delay: 10
■キャッシュを使う
キャッシュを使うようにしました。
キャッシュは当然使うべきなんですが、実は過去に
bot襲来→キャッシュファイル増大→数GBに膨らむ→サーバ落ちる→サーバ再起動時のディスクチェックに12時間以上かかる
という苦い経験があったので、キャッシュを使うのは避けていました。
とりあえずキャッシュの設定を復活させ、有効期限を半日にしてしばらく様子を見みます。
で、一晩明けてみてみたら、まあ予想はしてましたが、キャッシュファイル数が1万を軽く超えてました。
とりあえず一旦キャッシュファイル全削除。
ちなみに調べてみましたが、Linuxでひとつのディレクトリ内に格納できるファイル数はせいぜい1万程度ということらしいです。それ以上だとパフォーマンスが大幅に落ちたりするらしいです。とりあえず全削除で凌ぐとして、この問題はなんとかしないといけません。
というわけで、キャッシュの使用によって新たな問題をひとつ抱えることになってしまいました。。
■asianetcom.netを弾く
ログをみていたら、MSIEのUserAgentを名乗っているものの、アクセス数も動きも人間のものではないIPアドレスがいくつかありました。
逆引きしてみたら、「asianetcom.net」といういかにもあやしいホスト名。調べてみたら、どうもBaidu関係の、お行儀の悪いBotのようです。
http://wiki.livedoor.jp/aissle/d/%A5%ED%A5%DC%A5%C3%A5%C8%A1%CA%B9%F1%C6%E2%A1%CB#content_2_4
↑こちらのページを参考に、というかそのまんまの設定でBotを弾くことにしました。
deny from 61.14.160.0/19
deny from 122.152.128.0/18
deny from 125.252.64.0/18
deny from 202.147.0.0/18
deny from 203.192.160.0/19
deny from 210.232.15.16/29
これがかなり効果があり、ほぼ1時間2000リクエスト以内におさまるようになりました。
■Amazonへのリンク先をDetailPageURLにする
1時間2000リクエストの制限は、売上に応じて変動します。
Product Advertising APIへのアクセスのために使用される各アカウントは、1時間につき2,000リクエストまでの当初利用限度が認められます。その後は、各アカウントは、 30日間に発生する出荷された商品の1時間あたりの収益100円ごとに、1時間につき500リクエスト(1時間につき最大25,000リクエストまで)が受けられます。
要は売上に応じて段階的にリクエストの上限が増えるということです。
さらに
利用限度は収益実績に基づき毎日再計算されます。また、各アカウントに利用限度の追加が認められるかどうかを確認するため、アマゾンへのリンクバック時にはProduct Advertising APIのレスポンスにより返されるURLを改変なしに使用しなければならず、使用されるアソシエイトタグは、Product Advertising APIアカウント所有者のEメールアドレスと同一のEメールアドレスのもとに設定されたものでなければなりません。登録アドレスが一致しない場合、上記利用コントロールが正しく適用されない恐れがありますので、ご注意ください。
ともあります。
これまで自分の場合、amazonへのリンクはhttp://www.amazon.co.jp/exec/obidos/ASIN/B003T9VDIC/myhp-22/みたいなシンプルなものを使っていたんですが、これだと収益実績としてカウントしてくれないわけです。
というわけで、PAAPIのレスポンスにあるDetailPageURLを使うように変更しました。
以上でひとまず対応完了。
悪質なbotはいなくなったものの、まだgoogleやyahooのbotが頻繁に来てるので、やや危ない水準ですけど、2000リクエスト制限問題はほぼ解決しました。
しかしお行儀の悪いbotって本当に迷惑ですね。特にレンタルサーバだと思ったようにアクセスログが取れないこともあるので、対応に苦労しました。
このまま落ち着いてくれるといいんですけど、まだ対応を終えて数日しかたっていないので、しばらくは監視を続けようと思います。
[...] い。。。Googlebotが来たら1~2時間程度で消化してしまうレベルです。 少し前にAmazon PAAPIでもアクセス数制限が導入されましたが、ポータルが提供するAPIは、膨大な負荷になってしまうん [...]
返信削除DetailPageURLじゃないとカウントされないんですか・・・まじですか・・ありがとうございます。
返信削除