毎度、KORYです。欧州と日本のスタートアップに投資するファンドの共同代表をしています。

ファンドの共同代表とかいうとガッツリ金融系の仕事っぽく聞こえるのですが、実際にやっていることは投資先に日々発生する課題の解決を中に入って一緒にやる、ということをやっています。（ファンドを始める前は自分の会社を作ってゲーム事業をやったり、受託ではシステム開発とかKPI改善コンサルとかをやってました）

昨日ちょうど投資先の開発周りのミーティングをしていてインフラ周りの話が出たのですが、ディレクターの方が若いということもあり、インフラ周りのことはそこまで経験がなさそうな感じだったので、ざっくりとしたインフラの負荷分散についてまとめてみますので読んでみてくださいね！

該当投資先がAmazon Web Services（以下AWS）使ってるので主にAWSの話です。）

※僕のノウハウはベースはmobage/gree全盛期のソシャゲの時に独学で学び、某アプリ会社さんとのお仕事や、投資先のインフラ構築で培ったノウハウになります。本職のインフラエンジニアさんからするとハナクソみたいな知識ですので、もっとこうした方がいいよ、みたいなのはnoteでガンガンみんな公開してくださいw

サーバーがサクサク動くことは経営マター。

非エンジニアの経営陣からすると、自社のアプリやWEBサービスがサクサク動いてくれないとイライラしますよね。でも、ユーザーはもっとイライラしています。

操作開始時間が1秒のサイトと3秒のサイトを比較すると、3秒のサイトは1秒のサイトに比べ、ページビューが22％低下、コンバージョン率は38％低下、直帰率は50％上昇してしまうらしいです。（WEB担より*1）

サクサク動かないとは言っても理由はたくさんあってアプリ側のコードのせいなのか、サーバー側のコード/SQLのせいなのか、インフラが脆弱なせいなのか、はたまた画像が重すぎるのか、などなど。とにかくたくさんあります。

ユーザーが多くないのにサーバーの応答速度遅いなって時はおそらくサーバーインフラではなくてコードの問題だと思いますのでスロークエリとかディベロッパーコンソール見たりしながらコツコツ頑張ってくださいw 今回はユーザー増加に対応する負荷分散をする話です。

まずは切り分けて考える

アプリの場合、アプリとサーバーの２つに切り分ける。１台のサーバーがAPIのプログラムもデータベースも両方を持っていて、アプリはサーバーのAPI経由でデータの書き込みや読み込みを行うシンプルな構成です。（ちなみに会員情報などのデータを一切サーバーで持たない場合はサーバーは必要ないです、スタートアップでは情報登録させないケースはほぼないと思うけど。）

ユーザーがほぼゼロの時/テストのタイミングでは、この構成でOKです。

しかし、この構成では、ユーザーが増えるごとに、どんどんいいスペックのサーバーに乗り換えるか、複数台のサーバーを使うか、という方法になります。

AWSには超ハイスペックなサーバーもありますので、途中まではスペックに任せた１台のサーバーを使う、というのも選択肢としてはありだと思います。が、数十万ユーザー規模とかになってくると流石に１台のサーバーでは厳しくなるので、複数台のサーバーを使うことが必要になってきます。

複数サーバーを立てると、アクセスがどのサーバーに向かうかはどのように制御するの？ということになるんですが、そこはいい感じに振り分けてくれる「ロードバランサー」なるものが存在し、勝手に振り分けてくれます。楽ちんです。

しかし、このままでは実は使えません。なぜなら、読み込みはいいんですけど、データの書き込みにおいては、ロードバランサーにより振り分けられた先のサーバーのみでデータの書き込みをしてしまい、さらに、サーバー間でのデータの同期は勝手にはしてくれないので、サーバーAとサーバーBのデータが異なる、ということになってしまうのです（汗）

そこで、データベースサーバーを切り分けることで解決します。アプリから指示されたデータの書き込みは、APIサーバー/WEBサーバー（EC2）を経由し、データベースサーバー（AWSではRDSとかAuroraと呼ばれるサーバー）に書き込み指示を送ることで、複数のAPIサーバー/WEBサーバーからの読み込み/書き込みに対応することができるようになります。

AWSのDBサーバーもスペックをどんどん上げていくことはできますが、WEBサーバーと同様に、複数台のサーバーを立てていかなければアクセスに耐えられなくなります。

そこで、DBサーバーも複数台の構成にします。書き込みは１台のDBサーバーで行い、読み込みに関しては、読み込み専用複製DBサーバー（リードレプリカ）を通して行います。

ただし、DBサーバーに関してはAPI/WEBサーバーのようなロードバランサがないので、API/WEBサーバー側で各DBサーバーとの接続を個別に設定（APサーバーAはDBサーバーAを読み込む、など）する工夫が必要です。

書き込みは結局１台じゃん！と思った方もいらっしゃると思うのですが、WEBサービスにおいて「書き込みアクセス <<< 読み込みアクセス」なことが圧倒的に多いので、大丈夫です。

もちろん、書き込みアクセスだけにしているのにDBサーバーの最高スペックのサーバーにアップグレードしたのにアクセスが捌けない、という状況になったら別の方法を考える必要があります。

分析のためのDBサーバーはリードレプリカを使って！

社内での分析用にSQLでデータベースを叩くことがあると思いますが、ユーザーが利用するサーバーでそんなことをしてると思わぬSQLを叩いてしまいサーバーが重くなってアクセスしづらい状況になる、ということは多々あります。（経験者は語るw）なので、分析専用のリードレプリカをAWSで立ち上げて、そちらを使うようにしましょう。

余談：レイテンシー（遅延）

AWS使ってると管理画面上で設定できちゃうし、AWSのサービスによってはアメリカのリージョンでしか使えないサービスとかがあるために間違えてアメリカのリージョンでそのまま設定してしまう、なんてこともありえます。インターネットケーブルの物理的な遅延とか馬鹿にできないので、気をつけましょう。（インフラに詳しくないエンジニアさんとかもやっちゃったりしてます。僕はその現場に何度か遭遇してますw）

余談：画像などのアセットサーバー、ランディングページ

これはWEB/APIサーバー側の話ですが、画像や動画に関してはWEBサーバーではなくS3とCloudFrontを組み合わせるなどしてWEBサーバーの負荷を下げるとともに、「〇〇砲がきても大丈夫」な状態を作ることができます。この辺は超シンプルな話なのでググればすぐ出てきます。

まとめ

最近はこの辺のことを楽〜にやってくれるサービスがたくさんありますよね。（GoogleのGCPとかはそもそもロードバランシングしなくても良いとか。）

とはいえコストの最適化含めて考えるとこのあたりをしっかりやっていく必要がありますし、開発のディレクションするにもインフラの話とかまでわかってないと指示できなかったりするので、まあこういうことを考えてやるんですよ、ということをまとめてみました。参考まで。

※実はもっとこんないいやり方があるんだぜ、というノウハウをどんどん共有してほしいし、投資先のインフラとかも相談したいのでそういう人はnoteとかでまとめてTwitter @yuichikory までご連絡くださいw

*1)WEB担の記事：https://webtan.impress.co.jp/e/2014/07/08/17757