Высоконагруженный веб-сайт работает на EC2 и использует Kinesis Data Streams для сбора веб-логов. Приложение-потребитель Kinesis, также работающее на EC2, отстает при пиковых нагрузках, и записи теряются. Какое решение улучшит обработку потока с наименьшими операционными издержками?

Правильный ответ предусматривает масштабирование потребителя Kinesis горизонтально и увеличение периода хранения. Метрика GetRecords.IteratorAgeMilliseconds в CloudWatch напрямую указывает на отставание потребителя: высокое значение означает, что потребитель не успевает обрабатывать записи. Горизонтальное масштабирование потребителя (добавление инстансов EC2) позволяет распределить нагрузку и обрабатывать записи параллельно. Увеличение периода хранения Kinesis Data Streams предотвращает потерю данных, если потребитель временно отстает, давая ему больше времени для обработки. Остальные варианты менее оптимальны: Перенос логов в S3 и использование EMR для обработки не решает проблему отставания потребителя Kinesis и потери данных в реальном времени. Перенос потребителя в AWS Lambda может быть решением, но для высоконагруженных сценариев с большим объемом данных может быть дороже и сложнее в управлении, чем масштабирование EC2. Добавление шардов в Kinesis Data Streams увеличивает пропускную способность потока, но если потребитель не масштабируется соответствующим образом, он все равно будет отставать. Это может быть частью решения, но само по себе не решит проблему отставания потребителя.