旅行支援の混乱、サーバーダウンについて

質問

https://comemo.nikkei.com/n/neabf8087fa90

＞宿泊施設にとって根幹の予約システム（サイトコントローラーと呼ばれ、TLリンカーン、ねっぱん、らく通、手間いらず等があります。）が、2022年10月11日以降、サーバーダウンしています。これによりほぼすべてのOTA（じゃらん、楽天、一休など）からの予約が止まります。
おそらく皆様が仕事から帰られて、既存の予約を1度キャンセルして、再予約しているからトラフィック集中です。ここから23時までがおそらくピークです。予約キャンセル→再予約は少し時間を分散していただければ幸いです

って事態が起こってるらしいのですがTV報道なのはまだ見ていないと
思います。

　そもそもトラフックが集中するのは判っているのに、根幹の予約システム（サイトコントローラー）がダウンしてしまうとはどういうことなのでしょう？

　クラウド上にこの根幹の予約システム（サイトコントローラー）が
あれば容量を確保してダウンしないと思うのですが、まだクラウド上になってないのでしょうか？

回答No.2

t_ohta

＞　ここは理由がよく判りませんが、参照系はデーターを
＞　見に行くだけなのに対して、更新系はデーターの書換え
＞　を伴うので間違いが起きたらいけないからなんでしょう
＞　か？それとも二番目の問題でどこか単一障害になる箇所
＞　を通るためなのでしょうか？

データベースの参照系はデータのコピーを作って複数のサーバに置いておけばスケールアウトできます。
しかし、更新系を分散してしまうと1個しか在庫が無い商品を複数のサーバで受注してしまい、1個の商品を複数の人に売ってしまうといった問題が発生します。
この問題を防ぐための一番簡単な方法は、データの更新を1台のサーバだけに担当させる事ですが、これだと単一障害点になり処理が集中するとbusyが発生してしまいます。
データの更新系を複数台で分散処理する方法はいくつかありますが、何れにしても複数台で協調して排他制御しないとダブルブッキングしてしまうので処理が複雑になり時間が掛かりますし、参照系のデータベースサーバに対して更新された情報を速やかにダブり無く届けるためにも処理は複雑になってしまいます。
なので、データベースの更新系はスケールアウトではなくスケールアップさせる方が簡単で運用しやすいのですが、スケールアップはサーバの再起動を伴う場合が多いので機動的に行うのは難しいです。

回答No.1

t_ohta

クラウド環境ではなく物理サーバなどで稼働しているケースもあるでしょうし、クラウド環境に構築していても簡単にスケールアウトできる設計になっていなければ単純に容量確保できません。
また、データベースは単一障害点になりやすく、二重に予約を受け付けたりしないよう排他的な管理が必要になるので、リクエストが集中してここの処理が遅くなるとフロントエンドをいくら強化しても処理がタイムアウトして障害となります。
データベースは参照系はスケールアウトで対処出来ますが、更新系は強化するのが難しいですね。

補足

判ったことは、
・クラウド環境で構築し、簡単にスケールアウト出来る
　設計になっていればいいということですね。
・二重に予約を受け付けたりしないよう排他的な管理が必
　要になるので、リクエストが集中してここの処理が遅く
　なると単一障害になりやすい。
　　なるほど、ここですね問題はアイデアを出すなら
　ここがポイントかな、、。
・データベースは参照系はスケールアウトで対処出来ます
　が、更新系は強化するのが難しい。
　　ここは理由がよく判りませんが、参照系はデーターを
　見に行くだけなのに対して、更新系はデーターの書換え
　を伴うので間違いが起きたらいけないからなんでしょう
　か？それとも二番目の問題でどこか単一障害になる箇所
　を通るためなのでしょうか？