Блог

Ну, некоторое время назад я создал бессерверное приложение с помощью AWS Lambda. Мой текущий поток приложений выглядит следующим образом:

API Gateway (1) → Lambda Function (2) → SQS (3) → Lambda Function (4) → DynamoDB (5)

Теперь есть несколько соображений:

1. Клиент собирается отправить запрос в мой API (1).
2. К событию API подключена лямбда-функция (2), поэтому она будет получать запрос API и обрабатывать его.
3. Теперь, вот где возникает вопрос. После обработки запроса результат этой обработки ДОЛЖЕН быть вставлен в DynamoDB (5). В настоящее время я отправляю его в SQS (3) и возвращаю ответ на HTTP-запрос, отправленный клиентом.
4. Хотя запрос завершен и на него получен ответ, сообщения SQS (3) будут извлечены по событию другой лямбда-функцией (4), которая собирается вставить обработанное сообщение в DynamoDB (5).

Когда я впервые создавал прототип этого потока, у меня было предположение, что отправка сообщения в SQS происходит быстрее, чем вставка его в DynamoDB. Однако я никогда не проводил реальный тест или что-то подобное, поэтому мое предположение было просто произвольным.

Наконец, возникает вопрос: какое из действий выполняется быстрее? Отправка обработанного запроса выполняется через SQS или напрямую в DynamoDB?

Учтите, что в обоих случаях он будет выполняться из лямбда-функции (2), поэтому, теоретически, поскольку он находится в том же контексте, что и сам AWS, у него не будет такого же времени отклика, как при запросе его с другого компьютера.

Если ответ на этот вопрос:

• Вставка непосредственно в DynamoDB выполняется быстрее
• Вставка непосредственно в DynamoDB не быстрее, но разница незначительна

Я могу удалить оба SQS (3) и вторую лямбда-функцию (4), что приведет к более простому и прямому потоку.

Однако, если время отклика увеличивается при отправке сначала в SQS, я могу сохранить этот поток.

Вы спрашиваете, дешевле ли SQS, чем DynamoDB, но в вашем потоке вы используете both…it конечно, будет дешевле просто сделать API Gateway (1) → Lambda Function (2) → DynamoDB (3) .

С точки зрения производительности DynamoDB, как известно, быстр для небольших частых операций записи, поэтому я бы не стал сильно беспокоиться об этом.

Разница между временем отклика SQS и DynamoDB должна быть очень схожей, если только ваша емкость DynamoDB не подготовлена должным образом, и в этом случае у вас могут возникнуть проблемы с регулировками. Если выделенная емкость вас не беспокоит, я предлагаю протестировать как SQS, так и DynamoDB с таймерами внутри вашей лямбда-функции (или с помощью AWS x-ray) и решить, оправдывает ли разница в производительности затраты на добавление SQS и дополнительной лямбда-функции

Если вы сохраняете соединение открытым между вызовами, я видел, что время отклика DynamoDB ниже 10 мс. У меня нет данных о задержке SQS.

Что касается стоимости, вы в основном удваиваете стоимость своего lambda и добавляете все, что вам стоит SQS. SQS стоит примерно на 33% дороже, чем DynamoDB, если вы используете запись по требованию.

1 к ответам Deiv и cementblocks.

Позвольте мне поделиться следующими дополнительными перспективами, которые помогут вам усовершенствовать предлагаемый дизайн.

Если вам необходимо строго соблюдать асинхронную обработку, то есть отделить обработку запроса от ответа, тогда придерживайтесь своего решения на основе SQS.

Если задержка обработки запроса постоянна и приемлема для потребителей конечной точки API, то я бы рекомендовал решение, которое Diev рекомендовал для обработки запроса, сохранения в DynamoDB и возврата ответа клиенту. В качестве бонуса у вас будет более низкий счет AWS (как указано выше).

DynamoDB разработан для обеспечения «постоянной» задержки P99 (т. Е. 99-го процентиля) < 10 мс для чтения одного элемента и < 20 мс для записи одного элемента.

Надеюсь, это поможет!