大量のアクセスが求められるサーバーについて socket.ioなど

Question

以下、流れです。

Java クライアントアプリケーションよりHttpURLConnectionを利用して、指定のサーバー(例
http://xxxxx.com/test.php)へアクセスして、返されたデータを取得。
この処理は0.5秒毎に実行されます。

phpの処理内容は、指定のデータベースへ接続し15kbのテキストデータを取得し、取得したものをechoにて出力されるものです。

ユーザーをを100人程度で想定しているのですが、
単純計算で1秒間に30kb*100人で3MBの送信量があり、1日/30日スパンで考えるととんでもないリクエスト数と通信量になってしまい、AzureかAWSで考えているのですが高額な料金を請求されるのではないかと思っています。

※ちなみにユーザーがデータベースへデータを送信する事はありません。あくまで受信のみを実行します。

そこで考えたのが、クラウドサーバーを経由しないアプリ同士のソケット通信を考えたのですが、パケット開放の関連で厳しいと感じました。

次に考えたのが、socket.ioなのですが、調べたのですが今一分かりませんでした。
上記の利用を想定した場合、よりコストやパフォーマンスの点など、より良くなりますでしょうか？
（データベースの参照やHttpURLConnectionを必須条件という訳ではないです。ソケット通信が良い例ですが、とにかく最新のデータを効率良く取得(共有)出来ればいいと思っております。)

他に何か最善策があれば、教えて頂けますと幸いです。
よろしくお願い致します。

Comments

[退会済みユーザー]

通信要件が全然分かりません。。。

[Clover]

申し訳ございません。とりあえず訂正しましたが、しっかり説明できているか自信がないです。何か不明点・必要な情報があれば教えて頂けますと助かります。すいません、、、

[退会済みユーザー]

何をやろうとしているのかを開示するのがてっとり早いと思います。

Answer 1

回答ではないですが、そもそも0.5秒に15kbを常時送受信し続ける仕様というのがどこのサーバでやるにしてもまずいと思います。送受信するデータを圧縮する、テキストデータをやめてバイナリデータにして無駄を省く、ポーリングの期間を伸ばす、またはユーザに必要のないタイミングでの送受信を控える、等の仕様を考えるべきかと思います。
あまり通信帯域を常時圧迫するようなことをするとプロバイダに目をつけられてサービスを停止させられる可能性も考えられるので、できるだけ省エネにすることをおすすめします。

あと、socket.ioで通信しても「ユーザ間の直接通信」ではないので、結局サーバへの通信量は変わりません。

もしあなたがサーバの通信量を気にして端末間の直接通信をやるのであれば、UDPホールパンチングという技術を使えばポートの問題は多少解決されます。ただし、これで通信できるのはTCPではなくUDPなので、アルゴリズムを正しく考えないとパケットロスや伝達順序に問題がでます。アプリ側でUDPの通信にIDを割り振ったりタイムスタンプを割り振ったり、受け手側がパケットロスした情報を再要求できる仕組みを考えれば、UDPでもある程度の信頼性を高めることは可能です。

【UDPホールパンチングの解説記事】
http://fanblogs.jp/sert/archive/15/0

【UDPでの信頼性を高める関連記事】
http://itpro.nikkeibp.co.jp/article/COLUMN/20070713/277537/?rt=nocnt

Answer 2

最新の情報が得られれば良いんだよね？
なら設計から見直して差分を受け取れるようにするのが第一段階だね。

• 初回アクセス(全部欲しい): http://example.com/test.php
• 差分データ欲しい: http://example.com/test.php?since="2017-11-10 11:23:34"

クライアントは2度目以降はこの時刻以降のデータが欲しいというリクエストを投げて差分と時刻を受け取る。
こうすれば30秒に一度という高頻度のアクセスでも、
データ更新がなければ時刻1行の超しょぼいデータしかやり取りが行われない。

---

WebSocketでやる場合。

基本は一緒、最初に全データをドカンと落としてきて後は1件ずつサーバ側がクライアントに向かってブロードキャストで送信する。
PHPはSocket.ioのやり取りは苦手なので本気で構築するのはあまりおすすめしない。

RubyやNode.jsでWebSocketのサーバーを構築すると同時接続可能台数は数千台が限界。
しかもサーバーのCPU等の負荷とは別の所（主にネットワーク周り）にボトルネックがあり、そこが事実上の限界となる。

この辺が基本的な情報だね。

Answer 3

数字だけ見ると、通信量は大したことないです。
20-30Mbps なんで、100Mベストエフォート内に収まる。

どっちかって言うと、DB へのアクセスが問題になりそう。

何やりたいのか不明ですが、0.5 秒毎にDB からデータを拾い処理する要件のほうが厳しいはずです。100 件を同じタイミングで返さなくてはならないのであれば、分散させないといけない要件が発生したり。。。

あんまり意味のないところで悩んでいるんで、プロトタイプでも作って試してみることをオススメします。

Answer 4

Socket.IOの特徴として何かが変更されたタイミング（データベースが更新されたなど）で何かの処理をするというのは簡単にできます。

データが更新されたタイミングでクライアントにデータを送るということでいいのであればSocket.IOがいいかと思います。

データの更新関係なく0.5秒ごとにデータベースにアクセスする必要はないかと思いますが0.5秒というタイミングを変更できないのであればSocket.IOを使う利点はあまりないかもしれません。

どうでしょうか？

Answer 5

目的をはっきりさせた上で、もう少し上のレベルでものを考えた方が良いかと思います。

なぜHttpURLConnectionを使いたいのですか？ 慣れているから、だけでは？

HTTPがステートレスなプロトコルであるために、0.5秒毎にリクエストするような発想になってしまうわけで、各クライアントが通信したい相手のIPアドレスを知っているならSocketを使ってステートフルな接続を作って双方向のメッセージングができますよね。

また、より高レベルなミドルウェア（たとえばActiveMQなどのJMSブローカ）を使う手もありますね。
XMPPみたいなプロトコルをサポートしているミドルウェアもあったと思います。

ほとんどの場合、低レベルなオレオレプロトコルを考えるより、目的に合った標準プロトコルや出来合いのミドルウェアを探した方が良いと思います。

Answer 6

さくらのクラウドなら通信量による課金はないので、さくらのクラウドを使えばいいかと思います。