Минимизация / устранение начальной задержки запуска FN для авторизации OCI API GW

Мы используем функцию FN для авторизации шлюза OCI API (https://docs.cloud.oracle.com/en-us/iaas/Content/APIGateway/Tasks/apigatewayusingauthorizerfunction.htm). Мы обнаружили небольшую задержку в процессе аутентификации, когда он не запускался в течение некоторого времени, когда экземпляр контейнера Function раскручивается, чего и следовало ожидать. Как указано в документации Oracle:

Когда функция завершает выполнение и после определенного периода бездействия, контейнер Docker удаляется. Если Oracle Functions получает другой вызов той же функции перед удалением контейнера, второй запрос направляется в тот же запущенный контейнер. Если Oracle Functions получает вызов функции, которая в данный момент выполняется внутри работающего контейнера, Oracle Functions масштабируется по горизонтали для обслуживания как входящих запросов, и запускается второй контейнер Docker. (https://docs).cloud.oracle.com/en-us/iaas/Content/Functions/Concepts/functionshowitworks.htm)

Мы хотели бы минимизировать или, в идеале, устранить эту начальную задержку, например, постоянно выполняя один экземпляр функции. Какой будет лучший подход?


api-gateway oracle-cloud-infrastructure fn
person Alex D.    schedule 27.10.2020    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Я сомневаюсь, что вы могли бы поддерживать FN Container в горячем состоянии, не вызывая его повторно. Один из глупых вариантов - продолжать вызывать его после каждого интервала сна; но это должно быть заменено соответствующей стоимостью вызова FN в месяц.

Другие варианты могут зависеть от того, как долго длится фактическая операция. Например, это можно разделить на две операции, представленные двумя FN. FN может вызывать другой FN; поэтому вы должны иметь возможность последовательно вызывать их один за другим, если это возможно для вашей предполагаемой задачи.

person bmuthuv    schedule 27.10.2020

arrow_upward
2
arrow_downward

В бессерверном режиме это называется холодным запуском, и это то, над чем работают, чтобы сократить время первоначального запуска. До этого времени можно использовать проверку работоспособности для периодического опроса функции.

По сути, создайте случай в функции, где URL-адрес заканчивается чем-то вроде / status или / healthcheck. В этом случае верните response.Response (ctx, response_data = json.dumps ({status: OK}), headers = {Content-Type: application / json})

В API Gateway создайте маршрут, убедившись, что включен анонимный для / status (или / healthcheck), который вызывает функцию.

Затем настройте проверку работоспособности для периодического вызова API с конечной точкой / status или / healthcheck. Это позволяет поддерживать функцию в активном состоянии и следить за состоянием здоровья. Ваше дело может выполнить любую необходимую проверку, а не просто вернуть ответ OK.

Также следует иметь в виду, что API Gateway будет кэшировать ответы, поэтому в зависимости от выбранного вами TTL вы можете соответствующим образом настроить время проверки работоспособности.

person Robert W    schedule 28.10.2020
comment
Спасибо за предложение, мне это очень нравится, поскольку вы говорите, что одновременно с этим вы можете проверить состояние здоровья. Я попробую реализовать это. Ваше здоровье. - person Alex D.; 28.10.2020