SOA-1.2モニタリングと可用性のメトリクスに基づいて問題を修復する。

ヒントボタン

Evictions メトリクスが増えるのはメモリ不足によるキー追い出しですから、Amazon ElastiCache for Memcached ではノードを追加して水平スケールするとキャッシュ容量だけを伸ばせますし、CloudWatch アラームと Amazon SNS でしきい値越えを検知して AWS Lambda から ModifyCacheCluster API を呼び出す方式なら数分でクラスターにノードを組み込みつつアプリケーション側の DNS を変えずに遅延を抑えたまま処理できます。
インスタンスサイズを r6g.large などにリサイズするスケールアップは一時的なピークのために常時高い料金を払い続けるリスクがあり、さらに変更時は全ノードの再起動が伴うためキャッシュのウォームアップ期間が発生しますが、水平スケールアウトならピーク後に逆方向の CloudWatch アラームでノード削減も自動化できるので、手作業が不要で費用効率も高く保てます。
運用自動化、キャッシュ命中率維持、そして最低限コストという三つの要件を同時に満たす解は、ElastiCache のオンラインスケールアウト機能を EventBridge や SNS・Lambda などイベント駆動で制御し、必要なときだけ容量を増減させる構成が総合的に最も合理的だと判断できます。

ヒントボタン

CloudWatch の StatusCheckFailed_System メトリクスに 1 分間隔のアラームを設定しアクションで EC2 Auto Recovery を選ぶと、ハイパーバイザ障害を検知した直後に同一 AZ 内の健全ホストへインスタンスを移行できます。EBS ルートボリュームや Elastic IP、ライセンスに紐づくインスタンス ID は保持され、systemd による自動起動でアプリも即時復帰するため RTO 2 分・RPO 0・稼働率 99.9% を追加コストなく達成できます。

Auto Scaling グループに最小最大 1 台で組み込む方法は、ヘルスチェック失敗時に既存 EC2 を Terminate して新規 m5.large を Launch するためインスタンス ID が変わります。Elastic IP の再関連付けには Lambda や EventBridge の運用が伴い、復旧が数分を超えるとライセンス制約や RTO 2 分要件を満たしにくくなります。コストと手間を抑えながら ID 固定を維持する観点でこの挙動を整理しておきましょう。

Systems Manager Automation や CPUUtilization を使った stop/start スクリプトはハードウェア障害を即時検知しづらく誤動作の恐れもあり、RTO 約 2 分の保証や Lambda・EventBridge の保守コストが課題になります。単一 AZ、インスタンス ID 固定、追加コスト最小という複数要件を満たすには、CloudWatch アラームと EC2 自動復旧で EBS と Elastic IP を維持し 99.9% 稼働と RPO 0 を同時に実現する構成が総合的に最適と判断できます。

ヒントボタン

日次で 18 時に視聴者が急増するなら、Auto Scaling のスケジュールされたスケーリングを使い、cron 式で 17:55 に Min と Desired を 10 台へ設定して事前に t3.medium をウォームアップさせると CloudWatch の CPU アラームを待たずにピークを迎えられます。cron は UTC 指定なので JST との差を考慮し 08:55 を入力し、ステップスケーリングとの干渉を避けて安定的に余裕キャパシティを確保しましょう。

運用負荷を増やさないという条件を満たすには EventBridge や Lambda を新規導入せず、Auto Scaling グループ自身のスケジュールアクションで DesiredCapacity を変更するのが最小構成です。CLI やコンソールで一度 cron を登録するだけで IAM ロールや関数エラー監視の手間が消え、さらに MaxSize を 15 台程度に広げておけば想定外スパイク時にステップスケーリングが連動し、コストと可用性のバランスを取れます。

Predictive Scaling は EC2 や Application Auto Scaling の履歴を機械学習で予測しますが、数日分のデータ学習が必要で 15 分間だけ跳ね上がる負荷を正確に当てるとは限りません。今回は 18:00 と 23:10 という明確なビジネスルールがあるため cron ベースで Min/Desired/Max を宣言する方がシンプルかつ確実です。需要パターンが読める場面では、複雑なアルゴリズムより組み込みの時間指定機能で台数を固定化するという総合判断が最適と言えます。