私はあんまりコアを意識したことないなあ。
これは、どのくらい CPU がボトルネックになる処理を行うかという、ソフトウェアの中身によるところと、karino2 さんが作っているような、デスクトップやモバイルで前面に出てくるようなソフトウェアと、私が作っているような、いわゆるサーバーサイドかつクラウド上のソフトウェアという環境の違いからきているところがあると思う。
まず、ソフトウェアの中身として、ネットワークのどこかにあるサービスをコールをして、その結果を待つようなものだと、そこまで CPU がボトルネックになるようなことはない。
それに加えて、
- リクエストは並列にやってくるし、リクエストの間で共有しつつ書き換えるデータはそこまでないので、1リクエストでたくさんのコアを使い切らなくても、他のリクエストが使ってくれる (はず)。
- 新しい世代の XL なインスタンス、例えば t3.xlarge や t4g.xlarge でも4コアしかないので、そもそも8コアも存在しない。デスクトップ/モバイルと違って、サーバーのスペックは自分で選ぶものなので、コアを使いきれなかったら安いインスタンスに変えても良い。
- AZ (availability zone) 単位の障害に statically stable に対応するために、サーバーの処理能力はは 1AZ が消失してもなんとかなるように余裕をもって用意する。全部のコアを文字通り 100% 使っていると負荷が高すぎ。
という理由で、頼んでもいないのに8コア来た! 使いきれない! 困った! という気持ちになったことはあまり無い。
もちろん、色々サービスコールをして、その結果を待つようなものでも、結果を待っている間はその処理をコアから下ろして…みたいな処理を、例えば Java だったら CompletableFuture を使って頑張ることもできる。ただこれも、Go みたいなランタイムが代わりに頑張ってくれる言語を使えば、自分が書くコードからは追い出せる。
私の関わっている仕事のうち、containerd とか firecracker-containerd といったオープンソースソフトウェアは、クラウド上の自分達が管理するインスタンスではなくて、世界のどこかにあるメニーコアのマシンで運用されている可能性はある。ただ、これらはコンテナのランタイムという性格上、余っているコアはコンテナが使ってくれればいいので、これもまた自分でコアを使い切る必要はないのだった。オープンソースのリレーショナルデータベースエンジンを開発していたりすると違うのかなあ。でもこれも CPU よりは IO がボトルネックになりそう。