過去に作ったソフトウェアのメモ-第一弾-したらば巡回くん(5)

　回を重ねるごとにタイトルと中身が一致しなくなってきました。さて、前回までの内容でプロキシの利用について少し触れました。今回はそれの続きで、実際使ってどうだったのかについてわかったことがあるので、それのメモをします。

書くこと

・プロキシ…新しいボトルネック

・独自のプロキシサーバーを建てる

・スレッドプログラミング

プロキシ…新しいボトルネック

　プロキシの利用で、通信の安定性と速度が新しいボトルネックとして現れました。今回、無料のプロキシを13ほど見つけて、それを順番に利用する形でプログラムを組みました。残念ながら、１つのAPIにアクセスするたびに、だいたい3秒以上5秒以下の時間がかかるようになりました。通常、プロキシなしの場合では秒単位のラグは感じません。考えてみれば、プロキシサーバーを1つ挟むことで、インバウンド、アウトバウンドでそれぞれ2倍の転送量がかかるわけです。それに加え、プロキシサーバーの処理速度もトータルの転送時間に影響します。ですから、通常の2倍以上の時間がかかるのは自然と言えます。あと、安定性も怪しいです。なんどかプログラムが止まりました。

独自のプロキシサーバーを建てる

　使っていたプロキシサーバーが無料であったため、あまり性能が良くなかったのかもしれません。独自に自分専用のプロキシサーバーを立ててみましょう。そう、AWSの1年間無料サービスを使わせてもらいます。結果としては、１つのAPIにアクセスに2秒ほどの時間がかかります。細かいことを省いて言えば、プロキシサーバーを挟んだ通信に秒単位の時間がかかるのなら、それを時間的に並列で行う方法しか、高速に巡回する方法はありません。

　この方法では通信の安定性は確保できました。しかし、依然として速度が問題になります。

スレッドプログラミング

　簡単に言えば、処理の流れを複数個保持しよう！ということです。今までノータッチな分野なので、乗り気ではないです。ボトルネックが通信の速度ですので、１つの通信に時間がかかるのは仕方ないとして、それを並列に複数個実行すれば速度が出るだろう、ということです。1回の通信に3秒かかる処理(0.333件/sec)を13個並列に実行すれば、全体として3秒で13個(4.333件/sec)の処理が実行できます。一秒で4件なら大満足ですね。

　AWSの1年無料サービスでは、AmazonEC2では一ヶ月に750時間の利用制限がかけられています。750時間/13=57.7時間です。果たして13個のインスタンスを生成して、それらを57.7時間動かせば、全部巡回できるのでしょうか？この疑問の答えを正確に予測することは不可能です。なぜならそれを正確にすること自体が探索という活動の目的だからです。巡回(探索)なしに結論を出すことはできないです。しかし、無謀を犯す必要はありません。既に出てきた数字で”規模感”としての数字は出せます。それは各カテゴリーの終端や先程の計算などです。

　まず、750時間という制限の中で、平均4秒でのアクセスで何件のAPIへのアクセスが許されるのか。これに対する答えの計算は(750*60*60)/4=675000になります。67万という数字は、13個あるカテゴリーの板の総和、すなわち381,738という数字より大きいです。ひとまず、すべての板を回ることは簡単にできそうです。では残りのアクセスで板のスレッドを全部見ることができるのか？67,5000-381,738=293262,293262/381738=0.768件。前文の計算は、残りのアクセス数を出して、そのアクセス数を板の数で割っている。この数の意味するところは、制限のもとで許される、板が持つ平均のスレッド数です。つまり平均的には1件もスレッドがあってはいけません。…うーん、無料プランをそのまま利用する形では、全部の探索は無理そうですね。

　結論として、代理のIPを複数個用意できるのなら、スレッドプログラミングで巡回を効率的にできそうです。ただし、信頼性のある代理サーバーを無料で探すのは現実的にはほぼ困難です。工夫でAWSの無料で乗り切るか、思い切ってお金を払うか…。はたまた時間がかかるのを覚悟で生のIPで頑張るか…。取り敢えず今日は生IPで頑張るプログラムを走らせながら寝ます。