背景
私たちが運用するシステムでは、WebサーバーのCPU使用率が1日に1～2回ほど100%近くに達し、その都度オートスケールが発生する状況が続いていました。この影響で以下の問題が発生していました。
- 画面表示に必要なキャッシュが不完全な状態で取得され、特定の画面へ遷移できない
- 最悪の場合、画面が表示されない
これらを改善すべく、以下の施策を試行しました。
実施した施策
1. キャッシュの保存先をS3からEFSへ切り替え
従来の仕様
- Batchサーバーがキャッシュを作成し、zip化してS3にアップロード
- WebサーバーはS3からキャッシュをダウンロードして解凍
改善後の仕様
- EFSを導入し、BatchサーバーとWebサーバーでキャッシュディレクトリをマウント
- Batchサーバーがキャッシュを直接EFSに出力し、Webサーバーはリアルタイムで参照
成果と課題
- キャッシュ関連の欠陥は解消され、アップロード・解凍プロセスも不要に
- しかし、EFSの速度面でのパフォーマンスが問題となり、導入は見送り。速度重視ではEBSの方が適していることを確認
2. nice/ioniceコマンドの導入
概要
- nice: CPU使用率の優先度を設定
- ionice: I/O操作の優先度を設定
- キャッシュ処理の優先度を下げ、画面アクセスを優先的に処理
成果と課題
- CPUリソース配分の効果を期待したが、他の優先プロセスがない場合に期待通りの効果は得られず
3. TargetResponseTimeForIncreaseの設定調整
概要
- オートスケールのトリガー条件を「応答時間1.5秒以上」から「5秒以上」に緩和
成果と課題
- オートスケール頻度の減少を狙ったが、顕著な改善は確認できず
4. キャッシュ依存の排除
概要
- キャッシュがない場合でも画面遷移可能なように改修
- 必要な情報が欠ける場合も、最低限の動作を保証
成果
- キャッシュ依存が緩和され、ユーザー体験が向上。改修の効果は大きかった
5. EC2インスタンスのスペック増強
概要
- インスタンスタイプを1段階アップグレード
成果
- CPU負荷が大幅に軽減され、システムは安定化
最後に
今回のケースは原因の特定が難しかったため、原因解決ではなく負荷改善施策で安定化を図ろうとしましたが、一筋縄ではいきませんでした。最後にはお金による解決に頼ってしまいましたが、様々な施策を試す中で技術的な引き出しが増えたことを実感しています。
システムの機能改善とサーバーの安定化という両輪をバランスよく回しながら、将来的にはよりコスト効率の良い方法を模索していきたいと思います。