| 直接サーバアクセスによる連続処理 前章でマクロプログラムによる連続処理では実質的ではないことを説明したが、それ以外のやり方としては直接サーバアクセスによる連続処理が考えられる。いわゆる直鯖と呼ばれる隠語で表されるものである。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
これは755の端末アプリが行う処理を解析し、その一部だけを取り出してサーバに対して直接アクセスしてデータ更新を行うやり方である。 本来端末アプリとサーバアプリは相互に確認作業をしながら処理を完了させる。しかし、その場合は要求した新しい画面を開くなどの一連の処理が終わってから初めて次の処理がまた実行できるようになるので、1台で速度をコントロールしながら大量の処理を短時間で実行するのはほとんど不可能であろう。 しかし、端末アプリの中のW数を上げるのに必要な一部の処理だけを取り出して、連続してその部分の要求をサーバに対して投げかければ、W数は飛躍的に増やすことはできる。 そしてその処理を繰り返すプログラムの中で、変数として加速度を与える仕様にすれば、加速しながらデータを送り込むことも可能になる。 ただこれには専門的な知識が必要な上、自身でプログラムを作成できる技術がなければ不可能である。 |
 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
果たして本当にそんなことが行われたのだろうか？ |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 上記は755アプリのようなWeb環境でのアプリケーション構築事例を元に想定した755アプリのシステム概念図である。各端末の755アプリからの要求は、通信機器を経由したのちWWWサーバを経由してから755のサーバアプリケーションとの間でやりとりをしていると考えられる。アプリケーションサーバは通常のトークルーム表示が行われたら、その情報をきっかけにしてDBサーバに格納されているW数データをカウントアップするという仕様だと予想される。 また。755のシステムで特徴的なのは、コメントの書き込みやW数の増加に関係するのは、あくまでもスマホやタブレットなどで755アプリを利用した場合に限られるのだが、やりとりしているトークルームの内容を見ているだけなら、一般的なパソコンのブラウザソフトでも確認できる。 たぶんこれらのソフトから確認できる仕組みはWWWサーバの中で構築されており、WWWサーバが直接DBサーバの内容を参照するか、一部のデータをアプリケーションサーバを経由して確認するなど状況に応じた方法でデータ参照のみ行い、その結果を用いたWebページを作っているものと考えられる。 このとき755の端末アプリからの要求を受け付けるWWWサーバや755アプリケーション用サーバは、1台のみということは考えられず数十から数百台の規模で存在しているものと考えられる。そうでないと現在250万ダウンロードを超えているという755アプリを導入した端末からの処理要求をさばききれない。このときに重要な働きを持つのが端末からの要求を適切に分散させる負荷分散装置（ロードバランサー）である。 実は今回のバトルの最中にこの負荷分散装置が一時的にうまく働かなかったのではないかと思われる現象が見られた。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 上記は5/3の24時付近のデータ変動である。古畑のところは23:55あたりからW数の増分が下がっている。それに対して上西の分は23:55にピーク（5分間で780,875＝156,175/分ということから考えると、100/分の処理が出来るマクロ自動化端末約1,561台以上の端末が必要となるW数の増加）に達し、その後に数字が下がっている。最後の数字の落ち込みは人手での作業量低下とも考えられるが、23:55での古畑の落ち込みにどういう問題が影響しているのかが非常に不可思議である。 というのは、このタイミングで古畑サイドでの755利用者に通信不能となった報告が数多くあった。メンバーの一人はそのことをGoogle+に投稿していたりしていた。私個人もこの時間帯は全く755アプリが利用できなかった一人である。また、もう一つ貴重な情報があった。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 上記データは同時期に競争していた他の雑誌社のイベントに参加していたメンバーのウォッチ数推移データである。 今回データ収集には下記サイトの情報を利用させて頂いた。 http://paruru.csie.org/755_FLASH.html http://paruru.csie.org/755_BOMB.html http://paruru.csie.org/755_UTB.html 上のデータをよく見て頂きたいのだが、どちらも23：55のデータが欠落しているのがわかるだろうか？この表に疑問をお持ちなら、上記サイトでご確認頂けたらと思う（2015/5/14 8:30時点では確認できている）。 上記サイトでは各雑誌毎にデータの収集が行われていたのだが、この日に最終日を迎えるUTBのイベント参加各メンバーの情報はきちんと更新できていたのに、なぜか他の雑誌のメンバーの情報収集に関しては23:55のデータだけ取得できていない。 一般的にこうしたサイトの作成方法としては、情報を取得できるWebサイトのページを指定した時間毎に読み込みを行い、その中に含まれている必要情報（今回の場合はウォッチ数）を自動的に取り込むプログラムとなっているはずである。たぶん今回23:55時点の情報を再読み込みしようとしたが反応が返ってこず、次の24:00になってしまったのではないかと思われる。そのため23:55のデータだけ未受信になっていたのではなかろうか？詳細は上記サイトの作成者に確認するしかない。 755のシステムではPC用Webサイトにて情報提供もしているが、それは一般的なWebページであるため単に保存されているデータを検索するだけで、端末アプリからのデータ更新と連動している755のサーバアプリケーションと密接に関係しているとは思えない。従ってこういったPC側のWebシステムにまで影響を及ぼしているとしたら、多くの更新処理要求が発生してアプリケーションサーバでの反応が悪くなったからとか、WWWサーバでの端末認証エラーとかということより、一部の固定された経路から上西のトークルーム宛てに、本来755端末アプリでは短時間に通常発生し得ない大量データ送信を受けたため、負荷分散装置がそちらを優先的に処理した事により、他のメンバー向けの更新データや一般サーバ宛ての問い合わせデータの帯域が十分確保できなかったというのが、通信トラブルの原因としての可能性が高いと考えられる。 これに関しては具体的な情報がないので、755運営側が明確な情報を公開しない限りその原因は明らかにできないだろう。 ただいずれにしてもこの時間、外部から755アプリケーションサーバ向けに大容量のデータが送信されたことは間違いなさそうだ。負荷分散がうまくいっていない状況を見ると、そのデータが755の端末アプリを経由して発生したものとは考えにくい。 次は最終日における3名の終了時までのデータ変動について詳細に検証してみる。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 前へ |  トップへ戻る |
最終日(5/3)詳細編へ |
