Тесно място при хоризонтално мащабиране
Мащабирахме хоризонтално до 50 инстанции. Тесното място просто се премести.
Фаза 1: Тесно място в приложението
- 5 app сървъра, 100% CPU
- Решение: Мащабиране до 20 сървъра
- Резултат: App CPU 30%
Фаза 2: Тесно място в базата данни
- База данни: 100% CPU, 5000 връзки
- Решение: Connection pooling, реплики за четене
- Резултат: Database CPU 60%
Фаза 3: Тесно място в балансьора на натоварване
- Единичен ALB достигнал лимит на пакети
- Решение: Множество ALB с DNS round-robin
- Резултат: Трафикът разпределен
Фаза 4: Тесно място в опашката за съобщения
- RabbitMQ единичен възел наситен
- Решение: Клъстерирана опашка, разделени топици
- Резултат: Съобщенията текат
Урокът:
Законът на Amdahl: Ускорението е ограничено от последователните части
Пропускателна способност на системата = min(
app_capacity,
db_capacity,
network_capacity,
queue_capacity,
external_api_capacity
)Какво научихме:
- Идентифицирайте тесното място ПРЕДИ да мащабирате
- Load test на целия път
- Мониторинг на всички компоненти, не само на apps
- Понякога вертикалното мащабиране е по-евтино
Урок: Мащабирането на един компонент премества тесното място към следващия. Планирайте за капацитет от край до край.