導入
今回の記事では 同時接続数 についての解説を書いていこうと思います！
自分からすれば「見たこと・聞いたことはあるけど、ちゃんとは同時接続数のことを知らない」という状態だったのですが、
最近他社のエンジニアの方とお話した時にたまたまその話題が出て、「いよいよちゃんと調べた方がいいな..」と感じ、今回の記事を通して自分も勉強できればと思いました。
疑問点
同時接続数について調べ始める前に、自分が持っていた疑問は下記の3点でした。
-
そもそもなぜ同時接続数を設定する必要があるのか？
- 制限をかけなければ皆アクセスできるようになってハッピー、と考えたが、メモリ不足で落ちるのを避けるためとかなのか？
-
同時接続数に設定する値は何を基準に決めるのか？
-
同時接続数をオーバーしたら何が起きるのか？
- すでにサイトにアクセスしているユーザーはそのまま使えるけど、新しくサイトにアクセスしたユーザーは使えない、みたいになるのか？
今回の記事では、最終的にこの3点への自問自答を行うことで同時接続数への理解を深めたいと思います。
調査結果
同時接続数の理解のためには、そもそもこの「同時接続数」がどのように算出されるかを理解する必要があります。
同時接続数は、アクセスしているユーザーの数 × アクセスされているファイル数 によって導き出されます。
例えば、下記の8つのファイルが使用されているWebページに10人が同時にアクセスした時には、同時接続数は 80 となります。
- HTML ×1
- CSS ×1
- Javascript ×2
- jpgファイル ×4
ただ、いまどきページごとのファイル数が8つでおさまるようなWebページは「阿部寛のホームページ」以外にはあまり見かけないのが実情です。
今回の同時接続数の勉強にあたって、「レンタルサーバーで気にしておきたい同時アクセス数とは？」というページを参考にさせていただきましたが、
こちらのページ内で使われているファイル数をdevtoolsで確認したところ、119個のファイルを使っているようでした。
ここまででで疑問に感じたのが、「このWebページで10人が同時アクセスすることを考慮するなら、1190まで同時接続数を上げなくてはいけないのか？」という点ですが、
答えは No です。
同時に接続するユーザーの上限を10とするのであれば、同時接続数の上限は60で問題ないです。
実は、普段私たちが使うようなChromeやSafariなどのブラウザ自体にも同時接続数の上限が存在しており、この記事の執筆時点では 6 で設定されています。
そのため、10人が同時アクセスすることを考慮するのであれば、同時接続数の上限は60であれば問題ない、という結論になるのです。
さらに言えば、現実世界のケースで考えると、こういったファイルのダウンロードは1秒以下で終わることもあるくらいなので「10人がms単位で同じタイミングでアクセスする」ということがどれだけ現実的なのか、という話にもなってきたりします。
一方で、動画や音声ファイルを扱うWebサイトの場合は同時接続数に関してはよりシビアになる必要があります。
HTMLやCSSなどのファイルとは違い、動画や音声ファイルなどの容量が比較的大きいファイルに関しては、
ダウンロードをしている間「接続数 ×1」が残ってしまいます。
そのため、動画や音声ファイルを使用する場合は、最大でどれだけのユーザーが見ていても大丈夫な作りにしたいか、というのも考える必要がありそうです。
疑問点へのセルフ回答
というわけで、今回は自分なりに同時接続数についての情報を調べてみました。
上記の調査結果においては同時接続数についての基本情報を書きましたが、
元々自分が抱えていた疑問に対しての回答は以下の通りです。
1. そもそもなぜ同時接続数を設定する必要があるのか？
「なぜ同時接続数の上限を設定するのか」という疑問に対しては、当初の予想の通り、
「サーバーのメモリ不足などの支障をきたす原因となるため」でした。
ただ、同時接続数は世の中の全てのサーバーに設定されているわけではなく、ビジネスの場面では、レンタルサーバーや外部連携用APIサーバーに対して設定されていることが多いようでした。
（他にもいろんなケースがあるかもしれませんが、とりあえずは自分の目に留まった2つを紹介します。）
レンタルサーバーの場合
レンタルサーバーにおいて、もしもそれぞれのサーバーに同時接続数が設定されておらず、1つのサーバーにとんでもない数の同時接続があった場合、
他のサーバーにまで影響を与えてしまい、メモリ容量を圧迫してしまう可能性があります。
そのため、レンタルサーバーを提供している企業からすれば、「大きなトラフィックを扱うサイトを持ちたかったら、同時接続数を大きくできる高額なプランを契約してね。」という形になるわけですね。
APIサーバーの場合
APIサーバーにおいても、メモリ不足等の原因でサーバーが落ちて、進行中のタスクが中断されるような事態を避けるために同時接続数の上限を設定していることが多いようです。
確かに銀行間のやりとりなどミッションクリティカルなサービスにおいては、十分に考慮しなくてはならないんだな、と激しく納得しました。
2. 同時接続数に設定する値は何を基準に決めるのか？
「アプリケーション・リソースと同時接続数の試算例」という記事にてこの疑問へのヒントになるような情報が載っていましたが、
ざっっっくり言えば「メモリ容量次第」といったところになるようです。
こちらの記事では同時接続数の適切な値をどうやって試算するか、というエキサイティングな挑戦をされています。
数字が並ぶ記事ですが、是非とも読んでみていただくと良いかと思います。
3. 同時接続数をオーバーしたら何が起きるのか？
最初に自分が考えていたような「すでにサイトにアクセスしているユーザーはそのまま使えるけど、新しくサイトにアクセスしたユーザーは使えない」というのは間違いでした。
そもそもリクエスト単位なので、すでにサイトを回遊していたユーザーであろうがなかろうが、次にリクエストを送ったときに同時接続数をオーバーしていれば表示されない、というのが正しいかったですね。
まとめ・その他雑談
そんなわけで同時接続数について、簡単にではありますが、記事を書かせていただきました。
ちなみに、「AWSのEC2は同時接続数の制限とかあるのだろうか」と思い、もう少し調べましたが、EC2はクラウド上のサーバーをそのまま使っており、「影響を与える他のサーバー」が存在しないため、同時接続数の上限は存在しないようでした。
そもそもLinuxは同時接続数を含めた処理をファイルとして扱っていて、ファイルを開く上限の数が決まっているとか、
EC2/AWSに関して同時接続数を考えるのであれば、サービスのアーキテクチャをどのようにするのがいいのかという話になってきたりと、
同時接続について調べ始めてみるといろんな話がもっともっとできそうです。（笑）
またの機会にでも記事として公開させていただければと思います！