ウェブアプリケーションサーバを複数台構成とか2010年代には流行って欲しくない。

私は結構大規模なサービスに関わっているので、下記のkazuhooku さんの話の前提とはずれてくるんだけども。

つまり、約5,000万PV/月くらいのサイトまでなら、アプリケーションサーバ１台で捌ける、という机上の計算が成り立つ。

API系のアクセスがどんどん増えていかない限り、アプリケーションサーバを複数台で構成する、ってのは、大規模なサービス以外では不要になるんだろうな、と思った。

ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない - kazuhoのメモ置き場

アプリケーションサーバはボトルネックになりにくくなってきているのかもしれない。ただし、ハードウェア資源を有効に使えれば。マルチコアなサーバの資源を有効に使うのは、シングルコアのサーバの資源を使うよりもずっと難易度が高い。

「年々ハードウェアの性能は上がるので、ハードウェア資源の事は気にせずにわかりやすく作れば良い。能力が足りなくなれば増強すれば良い。その方が人件費をかけてややこしいシステムを作るより安い」という発想で作ってしまうと、後から後悔することになる。

上記の発想の前提には、「1000万円のハードウェアで今これだけの処理をさばけているのだから、必要な処理が2倍になれば、後1000万円分ハードウェアを追加すればよい。」というお話が成り立つ必要がある。実際はそんなにうまいこといかない。必要な処理が2倍になったら、2億円のハードウェアが必要になるなんて事も考えられるし、2億積んでもダメってこともある。

1コアあたりの性能が今後も伸び続ける前提が成り立ってればまだ良かったが、ここ数年で1コアあたりの性能は頭打ちになってきている。増強というのはハードの増設によるしかない。つまり、水平分散構成をとることになる。しかし、「わかりやすく」作られたシステムは処理の粒度が荒くなりがちで、そのような粒度で作られたシステムはアプリケーションサーバを増やしても処理速度は上がらないのだ。

また、DB 層がボトルネックとなってしまった場合、分散自体が不可能であったりする。無理やり分散しても分散キーを保持してるDBがボトルネックになったりとか・・・。「わかりやすく」作られているため、任意のボトルネック箇所だけを水平分散させられるような柔軟性を持ち合わせないのだ。

マルチコア化する流れの中で、ハードウェア資源を引き出す、つまり、「スケールアウトする」システムデザインの重要性はますます高くなっている。

難しいのはこれが、アプリケーションサーバやフレームワークと言った仕組み側だけの対応では実現しえないこと。ビジネスロジック側での考慮が必要になってくるのだ。

上で言った粒度の問題だけでなく、スケールアウトするシステムには非同期化が必須となるが、どの部分を非同期化してやるのか、ということはビジネスロジック側でしか決める事ができない。業務要件をそのままビジネスロジックに当てはめるだけではスケールアウトしなくなっちゃう可能性が高い。

ハードウェアの性能はマルチコア化により今も年々上がっているので、ハードウェア資源を有効に使えれば年々複数台構成を過去の物にできる可能性は高まっているが、その難易度も年々上がっている、ということじゃないかなと思っている。