CRMのEC2が高負荷になり、営業画面が遅くなったら

Level 1：AWSへの初期移行を終えたNortia CRMのCRMは、単一EC2＋RDS（Single-AZ）で稼働していました。ある日、営業担当から「CRMの画面が重い」という報告が相次ぎます。

今回の企業・業務状況

CRM利用者80人（営業・管理者）が、平日8時〜20時に集中してアクセスします。月初の商談登録が集中するタイミングで、この問題が発生しました。

Route 53 → ALB → EC2（1台） → RDS（Single-AZ）。Level 1で構築した最小構成のままです。

まず、次のメトリクスをCloudWatchで確認します。

この結果から、ボトルネックはRDSではなくEC2のCPUであると判断できます。

まず、EC2のインスタンスタイプを一段階大きくし、CPU使用率を下げてサービスを安定させます。ただし、これは根本解決ではなく、次に同じ規模の負荷が来れば再発します。

Level 2：高可用化・安定運用で導入したAuto Scaling Groupにより、CPU使用率に応じてEC2台数を自動的に増減させます。ALBが複数EC2へリクエストを振り分けるため、1台あたりの負荷が下がります。

スケールアップだけでは、次に利用が増えたときに再び同じ問題が発生します。一方でスケールアウトは、負荷の増減に自動で追従できるため、月初・月末のような周期的な負荷変動に強い構成です。

RDSのスケールアップも検討しましたが、CloudWatchの確認結果からRDSはボトルネックではないと判断したため見送りました。原因を切り分けずに全体をスケールアップすると、コストだけが増えて根本解決にならない典型的な失敗パターンです。

Auto Scalingで複数EC2構成にする際、EC2内にセッション情報を保持していると、リクエストが別のEC2に振られたときにログイン状態が失われます。セッション情報をEC2の外（RDSまたはキャッシュ）へ外部化することで、この問題を回避します。

今回はRDSがボトルネックではありませんでしたが、接続数がじわじわ増えていた点は将来的な懸念点です。EC2台数が増えるとRDSへの同時接続数も増えるため、コネクションプーリングの設定や、必要に応じたRDSのスケールアップも合わせて監視します。

Route 53
   ↓
ALB
   ↓
Auto Scaling Group
├─ EC2 / AZ-a
└─ EC2 / AZ-c
   ↓
RDS Multi-AZ

Level 2で導入したAuto Scaling＋RDS Multi-AZ構成そのものが、この障害への恒久対応にもなっています。