一斉アクセスで鯖落ち

一斉にアクセスが増えると鯖落ちするのはかなりありがちの事象です

サーバーから見たら完全にDDoS攻撃

実際に勘違いされた例はあるのか

岡崎市立中央図書館事件

自動アクセスだから違うのでは

ユーザーから見たら完全に設計ミス

俗にいうログインオンラインみたいに、強制的に時間を空けさせてやるといいんでしょうけど、非難は避けられないでしょうねぇ

一斉のアクセスに耐えられるように対策を取ると極端にコストパフォーマンスが悪くなったりしがち(学校のサーバーを組んだりしてないけれど、そういうところってオンプレミスでやっているイメージがある...)

ただし、クラウドを使っているなら別。学期の始まりとか明らかにアクセスが殺到するタイミングだけ、サーバーの数を増やしたりできる

アクセスの増減で自動でサーバーの台数をオートスケールすることもできるらしいけれど、極端なスパイクには対処しきれなかったり、無限にコストが増えるという問題もある、と聞いたことがある

(そういう今風な開発してみたいな！)

よくある対処方法

フロントエンド

CDNの導入(イメージはこれ)

キャッシュサーバーの導入

バックエンド

処理するサーバーを増やす

LBを挟んで振り分けたりなんたりしないとダメ

処理するサーバーのスペックを上げる

クラウドなら簡単。オンプレミスだと大変かも(環境構築が大変だったり、コストが大きかったり)

DBをいいかんじにチューニングする

インデックスを適切にする

なんとか句を入れて、強制的にインデックスを使わせたりする

こういう付け焼き刃的な対応は逆効果になりやすい

データベースを適切に設計して、インデックスを適切にする

DBの台数を増やす

やり方によっては手間が増えたりする可能性大。コストも大

RedisやmemcachedなどのキャッシュDBを使う

スマートな対処方法

サーバーじゃなくてクライアントの処理させるって記事を/shokai/shokai.iconさんのところで見かけた気がするが見つけられなかった

サーバーは数少ないけど、クライアントは沢山あるからね

この考えを発展させたらP2Pになるのかな？who.icon

アクセス集中に役立つ技術

コンテナ技術(Docker等)

仮想マシン

クラウド

/shokai/サーバーサイドレンダリング

CDNと相性が良い

CDN

code:mermaid

graph TD

マスターサーバー <--> キャッシュA

マスターサーバー <--> キャッシュB

マスターサーバー <--> キャッシュC

マスターサーバー <--> キャッシュD

キャッシュA <--> ユーザーA-A

キャッシュA <--> ユーザーA-B

キャッシュA <--> ユーザーA-C

キャッシュA <--> ユーザーA-D

キャッシュB <--> ユーザーB-A

キャッシュB <--> ユーザーB-B

キャッシュB <--> ユーザーB-C

キャッシュB <--> ユーザーB-D

キャッシュC <--> ユーザーC-A

キャッシュC <--> ユーザーC-B

キャッシュC <--> ユーザーC-C

キャッシュC <--> ユーザーC-D

キャッシュD <--> ユーザーD-A

キャッシュD <--> ユーザーD-B

キャッシュD <--> ユーザーD-C

キャッシュD <--> ユーザーD-D

このような構成の場合、階層型組織問題が発生しないかが懸念されている

P2P

windows updateにも使われている基素.icon

ソフトウェア面

軽量なフレームワークを使う

会社でもあるある

社員番号～～の人は～～曜日にアクセスしてください、誕生日～～月の人は～～曜日にアクセスしてください

こういうアナログな対処になる

技術も金もないし、デリケートな機密情報はクラウドに置きたくない！もあるので中々対処されない

大企業だとウン千人ウン万人がアクセス（それも仕事でバリバリ使うレベルの密度）するので、本質的に難しい問題もある