助っ人を呼ぶには、備えが必要(その1)

以前「バズったらどうする?」の記事に、自動スケーリングは過去のしがらみでできないことが多いことを書きましたが、ではどうやって解決するのかについて、代表的な方法を記したいと思います。

問題になるバターンは概ね決まっている

アクセスが増えたのでサーバを増やそうとして失敗するケースは、ほぼ下に挙げるパターンによって問題が発生します。

・どこか一カ所に頼った作りになっていた

・「厳密な処理」を適用しすぎた

これらが複合している状況もあります。

「結局○○さんに頼るしかない状況なので、受注を増やせない」

「とにかく正確さを求めすぎて、一向に仕事が進まない」

と置き換えると、現実世界でもありそうな話ではないでしょうか?

インターネット上のシステムでは、アクセス集中でパンクしているところもあれば、それを平然と乗り切っているところもあります。

では、「乗り切っている」側はどうやって解決しているのか、代表的な考え方をご紹介します。

ライブ会場の例

例えば、大きなライブ会場があり、入場券が大量に発行されたとします。

もちろん高額な席もあれば、安い席もあります。

席のランク(S席・A席など)ごとに入り口があり、チケットの確認係の人も多く働いています。

しかし会場は広いので都度本部に問い合わせることはできません。

入場者が多すぎて、携帯電話での通信に頼ることも困難です。

この時、チケットに

・お名前　○○様

・S席　1列目

という情報だけ書いていて、それを確認するだけだと、

「一番安いC席を買って、Cのところを書き換えてSにしてやろう」

と考える悪い人に対して対抗ができなくなります。

「確認番号」を使う方法

そうなると困るので、以下のように情報を追加します。

・チケット番号　123番

・お名前　○○様

・S席　1列目

・確認番号　A2B4521JL

情報を追加した上で更に、確認係の人たちだけに

「チケットに書いてある情報だけで、この確認番号が本当に正しいかを、自分だけで確かめられる方法」

を教えます。

こうすれば、本部に問い合わせることなく、通信回線を使うこともなく、確認係の人たちは自分たちだけで「この人を通してもいいのか?」を判断することができます。

実際のシステムでは、この確認番号にあたる部分は「電子署名」と呼ばれるものを使っており、解析されないよう相当長い暗号になっている上、更に有効期限を付ける方法で不正利用されない仕組みになっています。

一つだけ、「確認番号が本当に正しいかを確かめる方法」が部外者に知られてはいけないという制約があり、それは別の方法で管理する必要があるのですが、この考え方に基づいてシステムを作れば、アクセス集中時にサーバを大量に増設しても、それぞれが自律して同じように操作を受け付けられるようになります。

「厳密な処理」を適用しすぎた

の例については、次回記したいと思います。