Level 2：高可用化・安定運用

Level 1：AWSへの初期移行で、Nortia CRMのCRM・SFAは無事AWSへ移行しました。しかし、EC2・RDSともに単一構成のままという限界が残っています。

今回の企業・業務状況

CRM利用者80人という前提は変わりませんが、事業拡大に伴い利用が徐々に増加しています。開発・運用担当は引き続き3〜5人です。

現在のアーキテクチャ

Route 53 → ALB → EC2（1台） → RDS（Single-AZ）という、Level 1の構成のままです。

発生した課題

• CRM停止が営業業務へ直接影響するようになった（利用が業務に定着したため）
• 利用者増加により、単一EC2のCPU使用率が上昇する場面が増えた
• 単一EC2・単一AZ構成への不安（障害発生時に気づくのが遅れる）
• 障害の予兆をリアルタイムで検知する仕組みがない

新しい要件

• インスタンス障害・AZ障害が発生しても、CRMを止めない
• 利用者増加に応じて自動的にスケールする
• 異常が発生したら、担当者へ即座に通知が届く
• 開発・運用担当3〜5人のままで運用を継続できる

設計候補

候補	概要	採否
Auto Scaling（複数AZ）＋RDS Multi-AZ	既存構成を冗長化する	採用
ECSへの全面移行	この段階でコンテナ化まで行う	見送り（Level 3以降で検討）
マネージドロードバランサーなしでDNSラウンドロビン	複数EC2への振り分けをDNSで行う	見送り

採用したAWS構成

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

Auto Scaling GroupでEC2を複数AZへ分散配置し、RDSはMulti-AZ構成に変更します。CloudWatch AlarmとSNSで異常を検知・通知し、WAFで基本的な攻撃を防御します。

なぜそのサービスを選んだか

• Auto Scaling：単にEC2を2台に固定するのではなく、負荷に応じて台数を自動調整できる。
• RDS Multi-AZ：AZ障害時に自動フェイルオーバーし、運用担当が手動で復旧作業を行う必要がない。
• CloudWatch Alarm＋SNS：3〜5人という少人数体制でも、異常を早期に検知できる。
• Systems Manager：EC2台数が増えても、SSH鍵管理をせずに安全にインスタンスへアクセスできる。

採用しなかった選択肢

この段階でECS Fargateへ全面移行することも検討しましたが、まずは「単一障害点をなくす」という最小限の変更で課題を解決することを優先しました。コンテナ化は、複数企業向けSaaS化（Level 3）以降、デプロイ頻度が増えるタイミングで再検討します。

リクエスト・データの流れ

Level 1と同様に、Route 53 → ALB → EC2 → RDSですが、ALBが複数AZのEC2へリクエストを振り分け、EC2はセッション情報を外部化（RDSまたはElastiCache相当）することで、どのEC2にリクエストが振られても同じ状態で処理できるようにします。

障害時の動作

EC2の1台に障害が発生しても、Auto Scaling Groupが自動的に異常インスタンスを切り離し、正常なインスタンスへ新しいインスタンスを追加します。RDSのAZ障害時は、Multi-AZのスタンバイへ自動的にフェイルオーバーします。

実際に単一EC2構成でCPU使用率が95%まで上昇した事例は、障害記事：CRMのEC2が高負荷になり、営業画面が遅くなったらで詳しく扱っています。

セキュリティ

WAFをALBに関連付け、一般的なWeb攻撃パターンをブロックします。Security Group・Secrets Managerの方針はLevel 1から変更ありません。

監視・運用

CloudWatch Alarmで、CPU使用率・RDS接続数・レスポンスタイムのしきい値超過をSNS経由で運用担当へ通知します。定期的にバックアップからの復旧試験を実施し、実際に障害が起きた際に手順が機能することを確認します。

コストの主な要因

EC2台数の増減（Auto Scaling）、RDS Multi-AZによる追加コスト、WAFのリクエスト処理料金が主な増加要因です。利用者数に対してオーバースペックにならないよう、Auto Scalingの最小・最大台数を業務時間帯の実績に基づいて設定します。

移行・リリース手順

1. RDSをSingle-AZからMulti-AZへ変更する（無停止で実施可能）
2. Auto Scaling GroupとALBのターゲットグループを設定し、既存EC2を組み込む
3. セッション情報の外部化をアプリケーション側で実装・検証する
4. CloudWatch AlarmとSNSトピックを設定し、通知先を確認する
5. WAFルールを段階的に有効化し、誤検知がないことを確認してから本番適用する

この構成の限界

単一企業（自社）での利用を前提とした構成のままであり、複数の企業へCRMを提供する場合のテナント分離やアクセス権限管理の仕組みがありません。

次のLevelで改善する点

Level 3：複数企業向けSaaS化（Coming Soon）では、自社専用CRMを、グループ会社や外部企業へ提供するSaaSへと発展させます。