高負荷サービスと技術選択

前回の記事に引き続き、シリコンバレーと日本の違いについてYoutubeを見て思ったことを書いていく。

前回は「シリコンバレーは開発速度重視」って観点で考察したが、別の動画を見るとそうでもなさそう。

ただどちらも「負荷次第」って感じのことは言っている。（まぁ当たり前だよね）

規模の違いからくる前提の違い

日本だとシリコンバレーで使われてる言語とか手法とか無条件で信仰しがちだけど、やっぱりその違いは意識しないといけない。

そこで動画内で言っているキーワードとして「シリコンバレーは世界中の人が使うサービスなので」ってのが大きいように感じる。
ユーザの規模感がまず日本とは大きく違うのだろう。

日本でPLGはなぜ少ないのかの記事でも言語圏の規模の違いを理由の1つとして考察したけど、マイクロサービス化したり言語レベルで最適化しないと耐えられないサーバ負荷ってことから逆算するとあながち間違いでもなさそうだ。

負荷的限界と技術選択

で、負荷的限界が迎えたらそれに合わせて技術選択するってのはすごいわかる。
シリコンバレーでいう成功の桁（ユーザ数的な意味で）が日本と違うから、早めにそうした技術選択をするってのもわかる。

ただやっぱり日本でそこまでの負荷のサービスはほぼないのが実情ではあると思う。

というのも最初ソーシャルゲーム会社でキャリアを開始したので、いかにサーバを落とさず処理を続けるかってのとの戦いだった。

そこで10万DAU超がイベント開始と同時に一気にアクセスするような状況で、ユーザも時間との戦いなのでめちゃくちゃ連打する。つながらなければ尚更連打するので、状況はさらに悪化する。

それこそ「WebサーバのCPU限界きてるけどここでスケールさせても次はDBのWriteが死ぬから一旦Webサーバの台数このままで耐えよう」みたいな戦いだった。

だからこそそれ以降のキャリアで色々なサービス見る中で、「DB１台しか動いてないのか！？」「Index効いてなくてフルスキャンしてるけど全く問題ないのか！？」と驚かされた。

そして、そんな段階で大規模サービスがやるような高負荷を捌くためのアーキテクチャをやることに違和感があった。

そもそも負荷的限界がわからない？

ってのもあったんだけど、改めて考えると高負荷サービスを経験している人が少なくて、そもそも負荷的限界の肌感覚がわからないのかもしれない。

実際にサーバが落ちたときも、アプリケーションエンジニアで見れる人は少なくインフラエンジニアに完全に任せるところが多い。
「速度上げたい＝スケールアップしましょう」ってなったり、話しても「メモリって何？」「CPUって何？」って感じだったりする。

となるとそもそもどんくらいの規模感でサーバ１台だと限界が来るのか。どんくらいから言語的に限界なのか、みたいなところも感覚として持つことはできない。

その気持ちになってみると、技術選択の話で『開発効率は落ちますが負荷分散できます』みたいなトレードオフを適切に判断するのはきついよなぁと思わされる。
コップにどこまで水を入れたらこぼれるかの経験がないのに、「水を足すか足さないか」の意思決定をされるとしたら、そりゃあ安全めに倒したくなる。

おわりに

日本は高負荷サービスなくてあんまり当時の経験活かされることないなぁと思っていたが、実はこうした肌感覚を持てるだけでだいぶ活かされてきたのかもしれない。

というのと、やっぱり本を読んだり手法を学んだりしても結局その前提がわかってないと難しいよなぁとも感じた。

たとえば別の動画で「シリコンバレーは解雇や減給いくらでもできるから部下のモチベーション管理なんてせずやる気ない人は切る」って話してて、まさにこれもそうだ。

これ無視して「シリコンバレーはモチベーション管理しません！」って部分だけ切り取って真似しても成功しないので、ちゃんと背景を理解するのは改めて大切だなと。