インフラのイの字もわからないのにインフラ系のことをせざるを得ない状況になっており、勉強のために某飲食店予約システムのインフラ構成を予想しようと思いました。ピンクくて丸いやつ向けです。
注意
記事の内容は、野球の試合をテレビで見ながらイチャモンをつけるおっさんくらい薄く、知識量に比例して正確性は皆無です。インフラをわかってない人が頑張るとこういう予想にたどり着くんだね、という参考にはなるかもしれません。
参考にしたページ
とりあえず情報を集めます。
トレタのインフラ運用、支えている道具(Packer, Terraform, Serverspec, Ansible, Roadworker, Circle CI)、考え方 – トレタ開発者ブログ
トレタのインフラ運用 – Speaker Deck
トレタのMySQL MySQL casual #8
記事が結構古いからだいぶ変わってそうですね。どっかに答え載ってるんじゃないかと思って開発者ブログを見てみたけど最近の記事はなかった…。SlideShareとかにはあるのかもしれないですね。
うっす～いよそう
実際に使ってみてのエラーの返り方やレスポンスの感じだと以下のような構成でしょうか…？
- サーバ：Amazon EC2
- ロードバランサ：ALB？NLB？
- バックエンド：Ruby on Rails
- DB：Amazon RDS for MySQL
- 静的コンテンツ（json等）：CloudFront
- 静的コンテンツ（画像等）：Amazon S3
default backend – 404（多分Nginx Ingress Controllerのデフォルトバックエンドのレスポンス）が時たま返ってきたことから予想すると、おそらくRoRはKubernetesのPodで動いてるかもしれません。AWSを使ってるなら、GKEを採用しているのかなぁと予想しました。（リバースプロキシもIngressを使用）
実際の挙動からのうっす～いよそう
予約用の内部APIは予約対象の店舗のIDごとに処理する仮想サーバが決まっているわけではないようで、一店舗に予約処理が集中すると他の店舗のリクエストも応答しなくなるという挙動でした。（実際、先月はそれで巻き添え食らったところが落ちていた）
EC2使ってるならスケールアウトするか、予行演習で前もってやばいのはわかってたので、ピンクいやつだけL7ロードバランサでRDSもRoRも専用のインスタンスに処理させるとかいくらでも手は打てたと思うのですが、どうしてこうしなかったのかはよくわかりません。
以下を読んだのですが、ELB自体は5万RPSかけても受けきれるっぽいのと、API叩いたときに502 Bad Gateway返ってきてたので、Ingress Controllerまでは問題なくて、バックがボトルネックになっているのかなぁと思いました。（小学生並みの感想）
[社内勉強会]ELBとALBと数万スパイク負荷テスト
感想
やっぱりよくわからない。