アクセス過多により、予約サイトにアクセスできなかったり、購買サイトにアクセスできなかったりして、欲しいものが手に入らなかった、必要な予約ができなかった、ということが時々ニュースになることがあります。
「あれ、さっきまでアクセスできたのに」と、真っ白になったWebブラウザを見た、という経験をしたこともある人もいるのではないでしょうか？
許容限度を超えたアクセスがあると、システムは応答ができません。
この、応答ができない、という現象には二種類の事象があります。一つは、「ただ時間がかかっているだけ」という状態です。あるWebサイトに、たくさんの人がアクセスしている状態で、私が 「購入ボタン」をクリックしたとしましょう。
無事にその要求をサーバーが受け取ったとしても、サーバーは先にたどり着いた要求を順番に処理をしていきます。私がボタンを押す前に行われた、他の誰かが行ったクリックに対応した処理がすべて行われるまでには 時間がかかります。
ブラウザはサーバーから応答があったことをもって、正常に処理が行われたことを知るわけですが、要求する側は、ある程度時間がたつと、異常とみなして、継続処理をあきらめることが多いです。
これを図にしたのが下図です。
処理待ちの要求が少なければ、端末は自分の要求が処理されるのを待っていますが、下の場合は、想定以上に時間がかかっているので、端末の方で待ちきれずエラーにします。
電子マネーのチャージ中に通信エラーが発生したときに、チャージがされていたり、されていなかったりするのはこのためです。サーバーにはまだ処理が残っていて、時間がたてばチャージの処理がされていたりします。このケースであれば、時間がたち、要求する人が少なくなれば自然に復旧します。
もう一つは、アクセス過多になりすぎて、システムがそもそもダウンしたケースです。
この場合は、いつまでも復帰しませんので、ITエンジニアが必死に復旧を試みています。検索エンジンなど、いつでも応答を受け付けて検索結果を返してくれますが、この可用性はすごいな、といつも思います。
さて、IT資産管理システムは、端末にエージェントをインストールし、端末からデータをアップロードさせることで、必要な情報を収集し、管理コンソールに表示させます。
ということは、いつ購入ボタンを押すともしれない、多数の顧客を抱えているようなものです。
１万台の管理端末を管理しようと思ったら、最悪の場合は、１万台の端末が、一気にアクセスに来る、ということでもあります。そうなると、サーバーはアップロードデータを処理しきれず、一向にデータがアップロードされない、ということも考えられるわけです。
では、どのようなアプローチが考えられるでしょうか？
一つは、サーバーを分割することです。
１万台の同時アクセスの担保が難しければ、1000台の同時アクセスをなんとか実現し、サーバーを10台にしてリクエストを分割することで、サーバーあたりの処理を軽くする、ということが考えられます。
10000台の端末が一斉にアクセスするワーストケースを想定するよりは、1000台の端末が一斉にアクセスするときのワーストケースを想定する方が、難易度が低いのは間違いありません。
この方式のデメリットはなんでしょうか？
ソフトウェアの構造が複雑になることです。また、監視対象が増えますので、運用の手間も増えます。
あらかじめ端末を複数に分けておき、アクセスする時刻を分けておく、という方法も有効です。
短い時間の間にたくさんアクセスがあるからさばききれないわけですが、一日は長いのです。皆がバラバラに来てくれれば、普通に処理ができるわけです。
そこで、端末にアクセスしてよい時間帯をあらかじめ渡しておいて、許可された時間帯だけアクセスさせる、という方法も考えられます。
同じようなアプローチとして、サーバーから端末に要求していく、という方法があります。ある端末の情報を受け取り、終わったら次に行く、という方法です。
この方法であれば、サーバーの忙しさに合わせて処理ができますので、忙しくて応答不能になる、ということがそもそもありません。
そうはいっても、たくさんの端末が一気にアクセスする、という状況を完全に不可避にすることはできません。そこで、
- 端末側はどういう依頼を行うのか、という最低限の情報が載ったリクエストを送ることから始める
- 極力軽い処理にしておき、とりあえず返信する
という実装にしておいて、これだけは設計上の最大数を処理できるように努力します。
そのうえで、忙しい時は処理時間のかかる処理は受け付けないようにして、再リトライを促し、処理が分散されるように実装する、ということが考えられます。
以上はあくまでも一般論です。
日頃利用するシステムにおいて、どういうアプローチがなされているのか、想像するだけでわくわくしませんか？
SKYSEA Client Viewにおいても、処理の集中に対してはいろいろなアプローチをしていますが、一例を示しましょう。
SKYSEA Client Viewの管理コンソールは設定を変更すると、端末に設定変更を行った旨を通知します。
それを受けて、端末は設定を取得するために、サーバーに情報を取りに行くのですが、対象の端末が一気にアクセスすると、処理が集中してしまいます。
これを避けるために、端末に通知を行うときに、何分後に取りに行くように、という情報も合わせて通知しています。
こうすることで、端末に設定を配布する際、サーバーに要求が集中しないようになっているのです。
