SKYSEA Client Viewはたくさんの端末と通信を行います。SKYSEA Client Viewで10000台以上の端末を管理しているお客様もいらっしゃいます。SKYSEA Client Viewは一日あたり1MB程度のログを生成します。10000台ともなれば、10GBもの情報がネットワークを流れることになります。
ログデータについては、サーバーにアップロードできなかった分はSKYSEA Client Viewは端末に蓄えておくという動作になっています。というのは、端末のログはサーバーに接続されない間も必要とされます。ですから、サーバーにアップロードできなかったログは端末に蓄えられたままになります。そして、サーバーに接続すると、ログのアップロードを行います。
さて、サーバー障害やネットワーク障害が発生した場合も、端末の中にはログが蓄えられていきます。その後、サーバーやネットワークが復帰するとどうなるでしょうか。先の例であれば、10GBものデータが短時間にネットワークとサーバーに流れ込むことになります。
このような場合に何の考慮もないと、これがトリガーになってネットワーク障害が発生し、ログがほぼアップロードされないうちに、ネットワークに障害が発生することになります。結果、通信が回復せず、ログがアップロードされない状況が続く、ということもあり得るのです。
では、SKYSEA Client Viewはどのような対策を取っているのでしょうか。簡単に言えば、転送レートを非常に抑える、という対応を取っています。SKYSEA Client Viewがログを収集するデータサーバーがあるセグメントには、端末の数だけ通信が発生することになります。何の配慮もないと仮に10000台の端末があれば、当然、10000台がデータをアップロードすることになります。しかし、SKYSEA Client Viewはこの台数を絞っています。各データサーバーは上限を超える端末が接続しようとすると、端末にリクエスト拒否を通知します。この仕組みにより、たくさんの端末がデータを送信することを防いでいます。
さらに、ログは細かいブロックに分割され、アップロードされていきます。SKYSEA Client Viewは1ブロックをサーバーに送信すると、一定のインターバルを取るようになっています。もちろん、技術的にはもっと高速にログをアップロードすることは可能です。しかしながら、すべての端末が高速にアップロードすると、問題が発生する可能性があります。ログについては、最終的にすべてがアップロードされればよいのです。ですから、あえて、ゆっくりとアップロードするようにしています。そうすることで、最悪の事態を避けることになります。
SKYSEA Client Viewには帯域制限機能がありますが、ログのアップロード速度抑制のためには実はあまり利用されていません。 というのは、以上の仕組みから問題にならない程度のトラフィックしか発生させないので、多くの場合問題にならないのです。
さて、別のアプローチを考えてみます。ネットワークを流れる流量をそもそも減らすアプローチとしては、流れるデータを送信する前に圧縮するという方法があります。SKYSEA Client Viewは、端末とサーバー同士でやり取りするデータについては、圧縮してから送信します。近年のコンピューターの性能向上により、送信側のデータの圧縮、および、受信側のデータの伸長を行ってもパフォーマンスが下がらなくなりました。それよりも、データの送受信を待つ時間が短くなることで、応答速度の向上が望めます。そして、データ圧縮によって、一斉にデータを送信しても障害の発生確率が下がるのはもちろんです。
SKYSEA Client Viewのようなたくさんの端末と接続するシステムの場合、データの総量への配慮がないと、正しくデータを送信するという動作が障害を生むこともあります。そうならないための配慮は、発売当初から行われてきました。今後もこのような配慮は続けられていくことでしょう。
