こんにちは！
CTOの島田(@tatsushim)です。 先日mamari tech nightというエンジニア向けのLTイベントを社内で開催しました。 その際にママリのインフラ構成について発表したのですが、当時を振り返り大事だなと思うことがあったので、今回はその学びを共有したいと思います。
完璧なインフラ構成は必要ない
結論からお伝えするとサービスの立ち上げ時に「完璧なインフラ構成は必要ない」というお話です。
ママリの最初のインフラ構成
実はママリの最初のインフラ構成は以下のような構成になっていました。*1
構成は1台のEC2インスタンスのみで、もちろん、DB(MySQL), Apacheなどは全部入りです。 しかしインフラ構成はしばらく変えず、アプリケーションの機能開発にリソースを割きました。
そのインフラ、本当に今必要？
サービスを創る際、1エンジニアとしてはそのサービスを滞りなく運営するために必要なインフラを整えます。 その際、例えば以下のようなケースを考えます。
- サービスがもしヒットしたら膨大なトラフィックが来るはず
- ユーザーランキングの集計ロジックは重いから、キャッシュサーバーたててキャッシュしておかないと
- ユーザー数が100万になったときにも耐えられるようなインフラ設計にしておかなければ
しかし上記はほとんどのケースでサービスのリリースからある程度経ったあとに必要とされる機能です。 実際は多くの場合以下のようになると思われます。
- サービスがもしヒットしたら膨大なトラフィックが来るはず
→ 多くのケースで、期待した程膨大なトラフィックがそもそも来ない - ユーザーランキングの集計ロジックは重いから、キャッシュサーバーたててキャッシュしておかないと
→ ユーザー数が数千人程度の集計ならMySQLで十分なレスポンス速度が出る - ユーザー数が100万になったときにも耐えられるようなインフラ設計にしておかなければ
→ サービスによるが、100万人まで数ヶ月〜数年かかる。
最後のケースはまず1万人いってから考えても遅くないかもしれません。
リリースから1年後のママリのインフラ構成
リリースから1年後はサービスの成長に伴い、大規模なトラフィックをきちんと捌ける構成になっています。
しかし最初からこのような構成にするのは金銭的にも人的にもコストが高いです。
よってサービスの芽が出てから必要に応じて構築すればよく、
リソースの少ないスタートアップにおいてはサービスの本質的な機能の開発にリソースを割くべきです。
「やらないこと」を決めるということ
開発に限ったことではないですが、「やらないこと」を決めることが大事だと日々痛感しています。
1日が本当にあっという間に過ぎていく中で、如何に本質的なことにエンジニアのリソースを投下できるかが勝負の分かれ目だと感じています。
最後に
最後まで読んでいただき、有難うございます。
このブログのフィードバックや、ウチはこうやってるよ！という話を一緒にさせてもらえると嬉しいです。
この記事を読んでくださったあなたが「やらないこと」をどう決めてるか是非教えてください。
*1:この構成からスタートした理由はインフラ代の節約が主な理由です。
