皆さんこんにちは、エンジニアの西尾です。弊社代表およびサービスを取り上げていただきました。システムを落とすことなく、かつパフォーマンスも落とすことなく無事に稼働させることができました。今回はテレビ放送前に、食べチョク開発チームが行ったパフォーマンス対策を紹介いたします。開発チームのミッション放送日が決まった時、代表が一言、Slackにつぶやきました。サーバーを落とさない放送中にサーバーは絶対落とさない。この日から少しずつパフォーマンス対策を始めることにしました。食べチョクはAWS上で運用しており、構成はとてもオーソドックスなものとなっています。EC2,ELB,RDS,ElasticCache(Redis),S3,CloudFrontを主に利用しています。React、DBはMySQLです。データベースのレプリケーションは行っていません。闇雲にパフォーマンス・チューニングをはじめても本当に効果があるのかはわからないものです。Benchをかけて、どこがボトルネックになりそうかを探ります。アプリサーバー、重い!アプリサーバーがとにかく重くて、性能がでない。放送日前までに行ったパフォーマンス対策めちゃくちゃ高性能なインスタンスとDBを立てれば、高負荷にも耐えられる可能性があります。アプリのパフォーマンス改善も行いました。NewrelicとPrometheus(Grafana)を見ながら、1つずつ重い箇所を改善していくことにしました。撲滅N+1クエリ、気をつけているつもりですが、ちょいちょいいました。renderingもいて、パフォーマンスを悪化させていました。簡単なところから改善。重い処理を分割・改善するたとえば、以下は改善前の商品情報ページのコードですが、もうなんというか見ただけで重そうで、実際重かったです。改善前の商品詳細のコード重い処理があるとサーバーが詰まってしまうので、一部を別処理・別APIに切り出したりしました。Controllerも改善できて、よかった。ムダにデータを読み込んでいるところを無くす不要なデータを読み込んで、かつレンダリングまでしている箇所がいくつもありました。HTMLをよくよく見てみると...無駄なデータ読み込みを排除データは全部読んで、CSSで隠してました。Cacheを利用するRailsのビューレンダリングは遅いし、重いです。処理速度を改善していきました。共通ヘッダーを軽くするヘッダーは基本全画面に表示されますが、微妙に処理が遅かったです。ここを少し早くすれば全ページの読み込み速度が改善されるので、キャッシュを部分的に入れるなどして速度改善をしました。jsファイルや一部バナー画像などはWebサーバーから直接配信していました。Webサーバーの負荷は少しでも軽くしたいので、これらをCDN経由で配信するように改修しました。データベースは現状レプリケーションを行ってないため、スケールアウトができない状態です。テレビ放送中にデータベースがパンクしたらシステムダウンを発生させてしまう可能性がありました。データベースアクセスをできるだけ少なくするような改修をしました。このキャッシュ機能は基本的にはオフにしているのと、重要な処理では使わないようにしています。実際には商品が売り切れているのに売出し中と表示されてしまう、みたいな問題が起きないように注意しました。キャッシュクリアの仕組みも作りました。テレビ放送中は、キャッシュをTTL=15分でONにすることでデータベースの負荷を下げることにしました。テレビ放送当日はc5.2xlargeを使いました。CPUがいっぱいいっぱいでレスポンスが悪くなりがちだったので、2xlargeを使うことにしました。2xlargeは高いけど、使っちゃうか2xlargeのインスタンスに合わせて、puma(アプリサーバー)のworker数とthread数を調整しました。poolの値もworker/thread数に合わせて増加させました。ELB(ロードバランサー)は突然の高負荷でアクセス不可になってしまう可能性があります。参考に、AWSにあらかじめELB暖気申請を出しておきました。システムが落ちない保証はありません。最悪の事態に備えて、Sorryページ(エラーページ)も作ることにしました。使う事態にならなくて助かりましたが、一応以下ページを用意していました。Sorryページそして迎えたテレビ放送9月24日のセブンルール(テレビ放送)は、夜の23:20から始まりました。本番開始直後の開発チームのSlackを張っておきます。焦っていて日本語がおかしい。放送が始まった時のSlackシステムが落ちないか心配で、放送時間中にはちゃんとテレビは見られませんでした。放送開始から終了までの30分間、アクセスを無事さばき切ることができました。パフォーマンスはどうだったか番組放送中の食べチョクトップページと商品詳細ページのパフォーマンスは以下のとおりです。アクセスをさばけました。改善7でいれたDBのレコードキャッシュ機能をオフにしたためです。放送中の商品詳細ページのパフォーマンス商品詳細も高速にレスポンスを返しています。サイトにはかつて無いアクセスが押し寄せましたが、無事乗り切ることができました。参加の経験が役に立ったなと感じました。実装を見比べながら、地道に改善を行いました。ISUCON、今年は忙しくて参加できなかったのですが、来年は開発チームのメンバーと出場できたらと目論んでいます。パフォーマンス対策も忘れずに実装いけたらと思います。放送を見逃した方へ以下サイトで10/1(火)22:30まで見逃し配信をしています。tver.jpktv-smart.jp関連リンクよろしければこちらも御覧ください。12:46食べチョク開発チームがセブンルール(テレビ放送)に向けて行った負荷対策Tweet関連記事2019-10-02テレビ放送向けてパフォーマンスを大幅改善しました!2019年9月のカイゼン内容のご紹介こんにちは、食べチョクエンジニアの鹿倉です。皆さんこんにちは、エンジニアの西尾です。今日は食べチョク開...2019-09-03検索機能を大幅カイゼン!2019年8月のカイゼン内容のご紹介こんにちは、食べチョクエンジニアの鹿倉です。8月17日に食べ...2019-08-02祝!肉チョク・魚チョク始動!2019年7月のカイゼン内容のご紹介!こんにちは、食べチョクエンジニアの鹿倉です。7月に、食べチ...2019-07-172019年6月のカイゼン内容のご紹介!こんにちは。食べチョクの鹿倉です。出張マルシェビビッドガーデンスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。