#002 アカウント3,000件！ その男、熊野【SaaSを22本構築したエンジニアの話】

あの日に僕は『医療向けの予約システムを作りたい』

という人間に出会った。それがはじまりだったかも知れない。

スケールの課題、3,000件の重み

2016年、当時僕はあるSaaS提供企業――仮に『X社』――のテックリード的な立場だった。

X社の創業3年目に入社した僕は技術部門を率い、10年ほど受託開発やSaaS製品開発を行っていた。

フルスタックのプレイングマネージャみたいな感じだが、インフラは並の戦闘力だった。

おりしも、取り扱っていた『そのSaaS』は販売開始5年目にしてアカウント数は2,500件を超え、3,000件に届くところだった。

そんな中で『そのSaaS』はキャパシティの課題も抱えていた。

負荷分散がうまくいっておらず、『過負荷で障害が起こる』というのを、僕はうっすらと危惧しはじめていた。

10月になり秋が深まる頃、インフラは大量なアクセスにさらされ、うめき声を上げた。

ロードアベレージ（CPU負荷指標）のピークタイムの尖り（スパイク）は天井を突つきはじめた。

そんな頃に僕らのチームはある男を迎えることになった。

その男『熊野』

彼のいでたちは、今でも憶えている。

180cmを超えそうな引き締まった筋肉質。

グレーのハンティング帽に青いダウンベスト。

「医療向けの予約システムを作りたい。そのために予約システムが日本一の会社にきた」

みたいなことを彼は言った。

彼こそがのちの、GMOリザーブプラス株式会社の副社長、『熊野なおゆき』その人だ。

こんなセリフは聞いたことがなかったし、このときはまだ、彼がどこまで本気なのかはわからなかった。

歓迎のために、メンバーで夕食に出かけた。

店への移動中に、彼のファッションが素敵に思えたから、僕は話しかけた。

「その青いベスト、いいですね」

すると熊野氏は憮然とした表情で、

「私はそういう、おべっかを言う人は信用しない」

――いまだに、何が彼の気を損ねてしまったのかわからない。

けれど当時は、怒りや驚きよりも好奇心を覚えた。

（おいおい、こんなピーキーなヤツ、見たことないぞ…… ※1）

そう思ってその場は、熊野氏から距離をとった。

きっとシャイなんだろう、と思うようにした。

※1：『ピーキー』っていうのは『特定分野でスペシャル。その他は低いテンションで壊れ気味』って意味なんだ。本人にこの記事を見せたら、『せめて繊細なサイヤ人って表現してほしい』と言われた。知らんけどな。

インフラのボトルネック

物事の抜本的解決のためには、優先度を一度破壊し、枠の外に出ねばならない。

――僕はこの事実を学ぶことになった。

当時『そのSaaS』が抱えていた問題は、負荷分散だった。

あるドメインにSaaS参加のアカウントを集約していたのだが、ドメインが単一であるため、必ずどこかにボトルネックが生じる構造だった。

例えばWebサーバの負荷に関してなら、『ロードバランサの強化』『ロードバランサ以下のWeb分散』などで対処できるのだが、そのロードバランサ自体の恒久的なスケールアップが必要となる。

それに、冗長化などまで考えるとコストもかさむ。

やるべきことはわかっていたのだが、当時の僕の経験と知識では、トラフィック量に太刀打ちできなかった。

それに、数ある開発タスクやバグ対応などを優先し、インフラの抜本改善の優先度を上げずにいた。

じわじわと『危機』が近づく中、こんなじり貧状態を甘受していたのだ。

――こんな状況で、熊野氏がメスを入れることになった。

転職してくる前、熊野氏は『世界規模のゲーム構築』をやっていた。

彼からすると、僕の抱えていたスケール問題など、『プロ野球選手が草野球に出る』ようなものだったかもしれない。

正味、代打選手の熊野氏はシンプルで強力な解決策を出してくれた。

続きはこちら：
#003 ホームランを飛ばせ！【SaaSを22本構築したエンジニアの話】

前回の記事はこちら：
#001 はじめに【SaaSを22本構築したエンジニアの話】

本稿は個人の見解であり、会社を代表するものではありません。