理想と現実
やりたいことを理解して整理するというのはとても難しいことです。
(公開停止中)
…サーバーがうまく動いていれば、ここ一ヶ月間の成果が見れると思います。これから別のことで忙しくなりそうなので、とりあえずのまとめとして書いておきます。
基本的にはユーザーがAAで全レスするときに、それを補助するアプリという位置づけです。改善点はかなりあると思います。未実装の機能も多くあります。基本的な機能としては、左のほうの返信タブでいくつかの返信を書き、AAタブでくっつけるAAを選び、右のプレビューで位置を調整してコピペ、という感じです。
細かい使い方とかバグはユーザーが見つけてくれることを期待しています。時間のかけ方としては現時点ではそれが一番かなと。
心機一転！これから何を作ろうか
したらば巡回くんについては及第点まで来たと思います。というわけで、長い間このブログでは、前に作ったプログラムの改善ばかりやっていました。最終的にはぜんぜん違うプログラムになりましたが…。まあ単なるプログラミング上のハウツーだけでなく、したらばのAPIに関する理解と整理がある程度できたので、有用だったと思います。
さて、これからしばらくは、HTML上で動く、AAで遊べる何かを作りたいです。構想はある程度決まっていていますし、加えて過去に作った関数の使いまわしもできそうなので、あとはUIをじっくり考えていきたいところです。消去、追加、編集が直感的にできるリスト。ユーザーの関心事に応じてスムーズに切り替えられるタブ。レスポンシブデザイン。クッキーを利用したカスタマイズ機能。ユーザーの独自のファイルを読み取る機能。スムーズな操作を実現するショートカットキー。あっはてなブログをぱくろう…インスパイア。
とりあえず図１のようなものを作ります。この概略図はまた変更されるかもしれません。あと意図的に適当に書いてます。
今はjavascriptが十分賢いですから、多分簡単に作れると思います。クロスオリジンの制約をうまく回避できれば、やってみたいこともあるのですが、難しそうなので変なことは考えずに頑張りたいです。
過去に作ったソフトウェアのメモ-第一弾-したらば巡回くん(7)
ようやく動かせるようになりました。気づいたことについて書いていきます。カテゴリー別に13個のサーバーインスタンスでデータを収集しています。
・途中でエラーで停止したのが３つある
これはAPIから取得した値が予想外のものだったため。そのうち修正して実行し直します。
・収集するデータに制約を加えれば結構安定してデータが取れる
１つの板で最大5つのスレッドだけ、1つのスレッドには最大で500までのレスまで…というふうに取得するデータ数に制限をかけました。この制限化だとプログラムは安定して動きますね。
・制約のもとでも、結構データ量は大きい
今回とってきたデータの量は7.29GBです。テキストだけで7.29GBってすごいなーって思いました。
・終端の値が間違ってる
カテゴリー別に終端を記録しています。これの数字がちょっと正しくないみたいです。また今度、判定をゆるくして巡回し直します。
・収集したデータはプログラムの改善に使う
AAの判定方法とか…巡回の間隔とか…。今の感覚設定だとだいたい3割のアクセスがエラーになります。アクセス間隔が0.8秒程度になるように組むのがいいのかもしれません。無駄な通信は避けたいですし。
今度の記事では、AA関連板の判定法についてメモしていきたいです。がんばります。
過去に作ったソフトウェアのメモ-第一弾-したらば巡回くん(6)
前回、スレッドプログラミングについて触れていましたが、あれよりも良い方法を実現できたのでこれからはノータッチで行きます。複数のマシンを用意して物理的に並行させます。
書くこと
・これまでの案の図化
・これからの案の図化
・新しい案の触感
これまでの案の図化
今まで文字ばかりの説明だったので、図を盛り込んでみます。
これからの案の図化
サーバーを借りているのだから、処理をまるごとその借りているサーバーたちに委譲しよう！という案でやってみました。すると通信速度はとても改善されました。ほとんど自宅PCからアクセスするのと変わりません。あとは入出力関連をこの運用方法に適した形にして、サーバーに巡回ソフトウェアくんを設置、走らせるだけです。
新しい案の触感
特に不満はありません。まだ初めてなので改善点がポロポロ出てくる段階ですが、いまのところ全部対処可能です。したらばのカテゴリーの数が18個なので18のサーバーインスタンスを起動しています。そしてそのサーバーそれぞれで独立してアクセスと処理を行っています。
これでデータがローカルに集まればAA関連板の評価関数についての実験がしやすくなるのですが…さあどうなるでしょう。
過去に作ったソフトウェアのメモ-第一弾-したらば巡回くん(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で頑張るプログラムを走らせながら寝ます。
過去に作ったソフトウェアのメモ-第一弾-したらば巡回くん(4)
前回に引き続き、改善案とその実装についてです。
今回書くこと
- 連続アクセスエラーを識別するために考えたこと
- プロキシの利用
- 完成したら
連続アクセスエラーを識別するために考えたこと
前回までの調査で、「HTTPのヘッダーを見れば、連続アクセスエラーであるか判定できる」としていました。再調査して、その根拠について表１にまとめました。
※URL…https://jbbs.shitaraba.net/[カテゴリ]/[番地]/
※API1…https://jbbs.shitaraba.net/bbs/api/setting.cgi/[カテゴリ]/[番地]/
※API2…https://jbbs.shitaraba.net/[カテゴリ]/[番地]/subject.txt
説明は繰り返しになるので省略です。
表2はスレッドにアクセスした場合のやつです。
※API3…https://jbbs.shitaraba.net/bbs/rawmode.cgi/[カテゴリ]/[番地]/[スレッド番号]/
連続アクセスエラーが出た場合の対処法は記述できました。これにより動作が格段に安定します。
プロキシの利用
どうやら短時間にたくさんアクセスすると連続アクセスエラーがでるようです。数千単位の板を巡回するためにはどうしても多くのアクセスが必要になります。したがって、連続アクセスエラーを回避するためには、多くの時間がかかります。となると、IPを複数運用する方法が浮かびます。というのも、連続アクセスエラーによる規制はIP単位でかけられているとしか考えられません。なので、IPをたくさん用意して、アクセスを分散させるという方法は有効そうです。しかし、IPを直接的に複数用意するのはコストが掛かります。そこでフリーで使えるプロキシの利用が考えられます。
●方法１
カテゴリーごとにHTTPクライアントのインスタンスを生成。これらのインスタンスにそれぞれ、プロキシを設定する。カテゴリーで並行して巡回する。
●方法2
APIにアクセスするたびに新しいプロキシを設定する。巡回する間隔を減らす。IPを捨て駒にするということです。こちらのほうが実装が楽です。。。
…まあ実装上の話なのでこれだけ見ても意味不明かもしれません。
完成したら
せっかくなのでみんなと共有したいところです。したらばの仕様をいちいち調べるのは面倒ですし。実行形式ファイルとソースコード、両方を公開したいです。あと、巡回した結果を保存して、それについてちょっと調べてみたいです。
