運用中のWEBサービスでサイトにアクセスできない、レスポンスが遅い問題

自社で運用中のWEBアプリ(自社内システム)について。
現在自社で運用しているWEBシステムにおいて最近急にアプリケーションにつながらない(500エラー)やレスポンスが非常に遅い(アクセスに20秒程度かかる)などの問題が発生しております。

サービスの概要
営業成績集計アプリケーション

ユーザー
自社営業100人

使用時間帯
10時〜21時

運用開始次期
2021年7月

サービスにつながりにくい時間帯
10時、20時(営業開始、終了時)

リクエスト数
POSTリクエスト(投稿)1日100件程度

使用技術
使用言語
Ruby6.0.1

WEBアプリケーションフレームワーク
Ruby on Rails6

DB
MySQL5.7

インフラ
AWS

WEBサーバー
NginX

アプリケーションサーバー
Unicorn

現在のレコード数
290425

RDSのCPU使用率
10.33%

RDSクラス
db.t2.micro

EC2インスタンスサイズ
t2.micro

インフラ構成図

知りたいこと
0. 個人的にはインスタンスタイプがt2.microという最小クラスなのでそろそろ負荷に耐えられなくなってきているのではないかと考えておりますが他に原因はありますでしょうか？
0. この場合負荷分散のために行うべきなのはクラスをt2.microから大きくするかec2インスタンスを２つに増やすのか、それとも何か他の対策を講じた方が良いか。
0. インスタンスを2つに増やす場合は構成を変更するのは大変でしょうか？

私自身の経験が浅く情報不足、説明不足等などたくさんあり非常に申し訳ないのですがよろしくお願いいたします。

追記
EC2のCPC使用率
最高で27%でしたが高いのか低いのか判断がつきません。。。

m.ts10806

2021/09/11 22:00

>Ruby6.0.1 Rubyってまだ3では。 Ruby on Railsは6でしょうけど。

行動規範の内容に同意します

回答3件

ベストアンサー

CPU使用率だけでは足りないのでもっと色んな数字とログを見てください。デフォルトでもCPU使用率以外に見られるメトリクスはたくさんあるはずです。
重い原因がリソース不足なのか、アプリケーションのバグなのか、クエリに問題があるのか、これではわかりません。
経験上スケールアウトやスケールアップでとりあえず解決する可能性は高そうに思えますが、闇雲にやるのではなくきちんと調査をしてからやるべきです。

CloudWatch Agentを入れて、メモリ使用率などを確認できるようにする

デフォルトだとメモリ使用率はサーバに入らないとわかりません。
別にCloudWatch Agentを入れないでサーバ上で見てもいいですが、CloudWatch上でグラフで見られるので便利です。別の監視サービスを使うならそれでもいいです。
コマンドで見ることもできますが長くなりそうなので割愛します。
参考
（初心者向け）EC2に CloudWatch エージェントをインストールして SSM で起動する

発生時間帯の各種ログを確認する

ELBのアクセスログ、Nginxのログ、アプリケーションのログ（ここではRailsとUnicornのログ）あたりを確認し、発生時間帯に何が起こっているのかを確認してください。
アクセスがあった時間帯やそれによってアプリケーションの何が呼び出されていてどこに時間がかかっているのかがわかるかと思います。

遅いクエリがないか確認する

RDSではログを出力することができるので、必要に応じてそれを確認して遅いクエリがないかをチェックしてください。こちらを見るよりもアプリケーションのログを見るほうが先だとは思いますが。
参考
MySQL のスロークエリと一般ログにアクセスする

何をするかを考えるのはその後です。原因がわかっていないのにあれこれするのは得策ではありません。
もちろん、切り分けのためにとりあえず何かをするのなら話は別です。

ちなみに

最高で27%でしたが高いのか低いのか判断がつきません。。。

これは全然高くないです。というわけでボトルネックは別のところにありそうですね。多分メモリか重いクエリだと思いますが…。

投稿2021/09/12 15:12

yu_1985

総合スコア7588

個人的にはインスタンスタイプがt2.microという最小クラスなのでそろそろ負荷に耐えられなくなってきているのではないかと考えておりますが他に原因はありますでしょうか？

負荷の掛かるようなSQLが発行されている可能性もあります

この場合負荷分散のために行うべきなのはクラスをt2.microから大きくするかec2インスタンスを２つに増やすのか、それとも何か他の対策を講じた方が良いか。

負荷が一過性のものでないならt2.microよりもパワーのあるもの(t2.small)にするのが普通ですが、動作が重くなる大抵の原因はDB周りなのでまずは動作を重くさせる原因となる酷いSQLが発行されていないかを確認するのが良いでしょう
商用なら負荷を調べるミドルウェア突っ込んで確認するものですが今回は必要無いでしょう

無料枠内で納める事が目的でmicroを使っている場合ですが、もしもDBからのマスター系のReadが多い事が原因の場合に限り同じく無料枠内のElasticCacheを用いる事で対応出来る可能性があります

インスタンスを2つに増やす場合は構成を変更するのは大変でしょうか？

rubyもrubyonrailsも全く知りませんけど、冗長化するだけで手間がいるようなフレームワークは今時あまりないのではないかと思います

自分ならどんな対応をお勧めするかですが、**とりあえずt2.smallにしてみたら？**って言います
t2.smallにする事が負担になるほどの会社の規模には見えませんしね

投稿2021/09/12 03:13

hentaiman

総合スコア6426

個人的にはインスタンスタイプがt2.microという最小クラスなのでそろそろ負荷に耐えられなくなってきているのではないかと考えておりますが他に原因はありますでしょうか？

アクセスログ（アクセスが集中してる時間帯など）、リソースログ（EC2のモニタリングで最小限（メモリはない）のがみれます。）などの実データから原因分析しましょう。
データに基づいてどのインスタンスタイプが適切かを判断しましょう。
ぱっと見メモリ不足感が否めない。あくまでも経験上なので宛になりませんが。