lolipopでアクセス制限をかけられた

以前、lolipopで運用しているIPアドレスを調査するサービスサイトでアクセス制限をかけられたことがあるので、本日はそのことについて紹介したいと思います。

 

ある日、突然lolipopから「【ロリポップ！】サーバー負荷に関するアクセス制限のご連絡」という件名のメールが届きました。

 

本文は以下のとおりです。

お客様がご利用のサーバーに大量のアクセスが発生し、サーバー上で著しい負荷をかけておりました。

 

■対象URL
http://XXXXXXXXXXXXXXXX

 

現在もお客様のサイトへのアクセスが継続して行われておりサーバダウンの危険があるため、アクセス数の制限を行っております。

 

ロリポップ！では、サーバーに高負荷障害が発生しサービスの継続が困難となる場合には、緊急にアクセス制限等を行うことがございますのでご了承ください。

 

なお、アクセス数が軽減しサーバーの安定稼働が見込める状態となりましたら、こちらで確認の上、制限を解除させていただきます。

 

また、アクセス数の軽減に関する対策等をお客様ご自身で行われましたら、制限の解除を検討いたしますので、ユーザー専用ページ内の『お問合せ』よりご連絡ください。

 

心当たりはないので、とりあえず、googleアナリティクスを見ると、

 

おぉ！

2/3に13,530PVをたたき出していました。

 

いきなりこんなに増えるわけないので、おそらくPVがすごいサイトにリンクでも張られたのかなと思い、リファラーを見てみたら以下の2サイトからのアクセスが9割以上を占めていました。

• kancolle.doorblog.jp
• kanmusu.blomaga.jp

 

サイトを確認して見ると、２ちゃんねるまとめサイトですね。

記事ページにバッチリリンクも残ってました。

• http://kancolle.doorblog.jp/archives/43202850.html
• http://kanmusu.blomaga.jp/articles/37809.html

 

内容から、不正ログインの調査として紹介してもらえたようです。

 

僕の利用イメージと一致していることがわかり、「ユーザの役に立つサービスを作れてよかったな」と思いました。

 

これからも、便利なサービスを生み出すことで社会貢献していきたいなと強く感じました。

 

めでたしめでたし。

 

 

 

 

 

 

、、、、、

 

 

 

 

 

ってオイ！

 

キレイにまとめてるんじゃねぇよ。

 

作ったサービスがユーザニーズとマッチしていることが明確に分かったのなら、もっとたくさんのユーザに使ってもらえるようにするべきなので、再発防止を検討する必要があるだろうよ。

 

ってことで再発防止案を考えることにしました。

 

原因調査

原因を調べるにあたり、機能を調べて簡単に切り分けることにしました。

 

このサービスはデータベースは利用しておらず、入力された値を外部のAPIへ送り、帰ってきた値を表示するだけのシンプルな機能になってます。

 

そのため、プログラム的には特に問題ないので、考えられそうなのは以下２点。

• サーバ処理能力
• APIの処理

 

ところが、APIの処理についてよくよく考えてみると、APIの処理が遅い分には、サーバ側の処理が楽になり、逆にAPIの処理が早ければサーバの処理がボトルネックとなります。

 

ここを証明する必要があるので、今回問題になった2/3のアクセスを詳しく見てみました。

 

まず、当日のアクセスですが、

 

1日 で 13,530PV = 1時間 で 563.75PV = １分 で 9.395 PV

 

いやー、さすがに弱すぎるでしょう。

 

１分で９PVしか捌けないんじゃ使えなさすぎるぜ。

さすがにもっと前にアラートがあったハズです。

 

んなわけないので、時間別で見てみました。

 

サーバの処理が追いついていない。

 

で確定です。

 

念のためAPIの制約条件も確認しました。

このAPIはIPInfoDBというサービスを利用しており約束事として「1秒に2回以上通信しないこと」のみとありますので、それさえ守っていれば特にアクセス上限などを定めてはいないようです。

 

再発防止案

パッと思いつくのは以下の3つですね。

• アプリのチューニング
• キャッシュ化
• サーバリプレイス

 

チューニングはする余地がないですね。

仮にAPIの処理が早すぎるということであれば、外部APIへデータを送る時に、待ち行列を作るなどの対策は可能。まぁ今回はサーバの処理能力が問題なので、必要ないですね。

 

次にキャッシュ化についてですが、サービスの特性上、同じ値を検索することは少ないと考えていました。

ですが、上記のサイトでの使われ方だと、不特定多数のユーザが同じ値でプログラムに問い合わせに行くケースがあるとわかったので、結構効果はありそうです。

これは実施する価値はありと考えています。

 

最後、サーバリプレイスについては一番手っ取り早いですが、新しいレンタルサーバを選定・契約・移行といった作業が発生するため結構大変です。

 

対応方針は出揃いましたね。

検討した結果、

 

まずキャッシュ化してそれでも効果がないようであればサーバリプレイス

 

で対応することに決めました。

 

対応

今回のサービスにマッチしたキャッシュの仕組みを導入すべきであるということで、調べたところAPCという機能が使えそうだったので早速使ってみました。

（詳しくは、lolipopでサイトの表示が遅いで説明していますのでそちらを参考ください）

 

これでしばらく様子を見ることにします。

 

その後の経過

その後、1ヶ月ほど経過しましたが、lolipopから特に連絡はきていません。

 

Google アナリティクスを見る限り、高アクセス状態になっていないことが要因です（涙）

 

なので、まだ結果はわかっていません。。。

 

またどこかのサイトで取り上げられたりすることを待とうと思います。