makotan _at_ gmail dot com

C30K問題とC60K問題

だいぶ前にTomcatのフロントにnginx入れなかったら、入れないの??どうして??って質問されたのを思い出してふと書いてみる
その時は「必要ないから」ってだけ答えて詳しく説明してないけどw

歴史

ずっと昔


Apache - Axx - Tomcat 方式
ApacheをHTTPのネットワークインタフェースとして独自プロトコルTomcatと繋ぐ方法
ネイティブなApacheに静的ファイルを配置してTomcatは動的なファイルだけにすることで遅いTomcatを補完する方法



nginxが良かった頃


nginx - reverse proxy - Tomcat 方式
ApacheTomcatもBlockingIOなので、代わりにnginxをフロントに配置する方法
nignxがNon BlockingIOなのでTomcatが処理本体に集中して接続処理などはnginxが担当する


この辺りでNIOな各種方法がJavaでも出てきた
ちなみに既にApacheもNon BlockingIOなのが入ったのでnignxの優位性はそれほどない


最近
Tomcat単独方式
Apacheもnginxも必要ない
既にTomcatがNIOなのでクライアントから接続が来てもそれだけではスレッドを占有しない
例外はApache/nginx側のモジュールでゴニョゴニョしてからTomcatに引き渡したいとかレスポンスをゴニョゴニョしたいとき
静的ファイルはCDNに置くことを検討する


これから
No Tomcat方式
Javaでの開発ですらTomcat(=ServletAPI)であることのメリットが薄れる時代
最近作られてるJVMベースなWebフレームワークでは仕様化の遅いServletAPIよりnettyベースが多いことからそろそろServletAPIが終焉を迎える
処理としての自然な形での非同期化/小スレッド化を予想
静的ファイルはサーバ内部にそもそも持たずに積極的にCDNを使用して配布する

C30K問題とC60K問題

C30K問題はnginx - Tomcat方式で抱える接続数の上限問題
TCPのポート数が有限のためnginxとTomcatの間で3万程度で上限に来てしまう問題
Tomcatがさらに外部サービスに依存してたりするとこの上限はさらに下がる
nginxを外すことで随分緩和してC60K問題に変化する
あっ、ちなみにC30K/C60Kに達するにはOS側の設定変更が必須です

C60K問題解決案

TCPの接続元ポート数が有限である事を認識した上で・・・
サーバ間の接続を含めて効率的なポートの利用(HTTPからHTTP/2へ)などでポート数の枯渇を防ぐ
UDPの利用を検討する
少ないスレッドで効率的に処理をする(スレッド数分の処理しか行わないので結果的に消費するTCPポートの削減に繋がる)

というかそれ以前に・・・

そこまで必要か?って疑問を先に解決するべきだと思う
同時接続が1台のサーバ上で3万とか6万超えるサービス作ってたっけ?
それよりポチポチやって必要なときにインスタンス台数増やした方が楽じゃね?
みたいな疑問を持った方が開発中も幸せになると思う