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

昨日の続きで、
「厳密な処理」を適用しすぎた

について記します。

とにかく真面目なRDB

おそらく世の中の殆どのシステムで、RDB(リレーショナルデータベース)と呼ばれる記憶手段を使っています。

RDBには幾つかの特徴があるのですが、それらの一つに「とにかく持っているデータ全体で矛盾が生じないように頑張る」性質があります。

確かに素晴らしいことなのですが、その性質を保つために、必ず1台のコンピュータのみで情報を操作する仕組みになっています。

とりあえず1台のコンピュータで賄えているうちはいいのですが、システム設計者やプログラマーが手を抜いて(というか何も考えず)何でもこの場所に放り込む作り方をしてしまうと、やがて追加や更新の依頼が捌ききれなくなり、あるとき急に音を上げます。

音を上げた時に慌てても、もともと手を抜いていたところに「全体で矛盾してはいけないもの」と「別にそうでもないもの」の区別はできようもなく、今度はシステム担当者が音を上げてしまう、といった惨事が、世の中のどこかで、しばしば発生しています。

「真面目さ」の範囲を限定する

この問題に対する解決策ですが、システムの導入以前に「考え方の整理」が必要です。

例えば、オンラインショップのシステムを考えた時、

1.「買い物かご」の中身　→　各お客様に対して矛盾が無ければ、問題ないはず。

2.「実際の商品在庫」　→　倉庫の内部で整合性が取れていれば問題ないはず。

3.「購入するボタンを押した瞬間」

　　→商品在庫から買い物かごの中身をお客様に対して割り振る、というタイミングだけは、やはり厳密な整合性が必要そう。

と3段階に分けて考えれば、少なくとも1.は助っ人に分業できそうです。

実際のところ、オンラインショップで3.が発生するタイミングは、買い物かごに追加したりショップ内を見て回ったりといった操作に比べて発生頻度は非常に少ないので、この一工夫だけでも「音を上げる限界点」は相当変わるはずです。

ちょっと嫌味な話題になってしまいますが、「予約販売の受付」というケースであれば、3.自体を予約受付終了後に処理すればいいので、そもそもあまり考えなくても「御用聞き特化型の助っ人」を沢山呼べば解決するはずです。

つい最近も、そこそこ大手の企業で「予約販売システムダウン」が起きたみたいですが、何も考えていなかったのでしょうか･･･

クラウドサービスで解決する荒技も

さてここで、

「あの世界的超巨大通販サイトだと、これでも対応できないのでは?」

と思われた方は鋭いです。

多分、その昔、対応できなくて困ったのだと思います。

でも彼らは、どこかのタイミングで、それですら克服してしまったのだと思います。

そして今の時代･･･

彼らはその解決策ですら、クラウドサービスとして販売しています。

少なくともその仕組みを上手く組み込めれば、あの通販サイトが音を上げるレベルくらいまでは耐えることができます。

つまり、大方の人にとっては、ほぼ気にしなくてもよい状況になります。

新しくするなら、是非検討してください!

昔作ってしまったシステムは、半ばどうしようもありません。

担当者が入れ替わってしまって、手が付けられないケースもあります。

ただ、これから作るシステムについては、もう失敗の知見も世に出回っているので、今の時代に合わせた作り方ができます。

新しいシステムを導入する際には、
「バズったらどうする?」

を是非頭の片隅に置いた上で見渡してみてください。