Я создал функцию Lambda, которая извлекает некоторые данные из DynamoDB и выводит некоторые JSON. Я пытаюсь запустить эту функцию в lambda @ edge и создать ответ, который я могу кэшировать с помощью Cloudfront.
Проблема, с которой я сталкиваюсь, заключается в том, что мои данные в DynamoDB реплицируются (в настоящее время) в двух регионах (us-east-2 и eu-west-1) с использованием Global Tables, а lambda @ edge, очевидно, работает во многих регионах.
Это мешает мне использовать AWS_REGION из лямбда-окружения. Например, если запрос выполняется в us-west-1, переменная окружения будет отражать это, и он попытается получить данные из us-west-1, где он должен фактически перейти к us-east-2.
Хотя по общему признанию я не пробовал это (пока), я задавался вопросом, могу ли я установить собственную маршрутизацию на основе задержки в Route53, чтобы указать ddb.mydomain.com на конечных точках для DynamoDB в регионах, которые я использую, предполагая SAN сертификаты настроены это будет работать?
Я подумал, что, возможно, я смогу отобразить регионы в коде, как показано в примере ниже
const process = { env: { AWS_REGION: 'us-east-1' } };
const regions = {
'eu-west-1': ['eu-west-1', 'eu-central-1', '...'],
'us-east-2': ['us-west-1', 'us-east-1', '...'],
};
const activeRegions = Object.keys(regions);
const region = activeRegions.find(
key => regions[key].includes(process.env.AWS_REGION)
) || activeRegions[0];
console.log(region) // us-east-2
Такое ощущение, что это будет больше обслуживания, чем стоит, и я полагаюсь на то, что я выбираю лучший регион. Мне также пришлось бы обновлять мой список регионов.
Я мог бы использовать только первые две буквы региона, чтобы ограничить необходимость его обновления, когда новые центры обработки данных открываются немного, но это все еще не идеально
const process = { env: { AWS_REGION: 'ca-central-1' } };
const regions = {
'eu-west-1': ['eu', 'sa', 'ap', '...'],
'us-east-2': ['us', 'ca', 'sa', '...'],
};
const activeRegions = Object.keys(regions);
const key = activeRegions.find(
key => regions[key].includes(
process.env.AWS_REGION.substring(0, 2) // Just the first 2 letters
)
) || activeRegions[0];
console.log(key); // us-east-2
Я подозреваю, что упускаю что-то очевидное, что может позволить мне разумно выбрать регион, в котором существуют мои данные, по адресу lambda@edge.
Редактировать
С тех пор я нашел этот , мастерскую aws lambda @ edge, которая была удалена, что предполагает аналогичный подход к описанному выше. почему это было удалено, я не знаю.
function updateDynamoDbClientRegion(request) {
let region;
// Check if viewer country header is available
if (request.headers['cloudfront-viewer-country']) {
const countryCode = request.headers['cloudfront-viewer-country'][0].value;
region = countryToRegionMapping[countryCode];
}
// Update DynamoDB client with nearer region
if (region) {
ddb = ddbUS;
}
}
readme для указанного семинара теперь просто обсуждает возможность использования глобальных таблиц для уменьшения задержки, но не дает представления о том, как выбрать ближайшую таблицу с данными.
Редактировать 2
Я взял копию данных о задержке из облачного хранилища и собрал следующую суть, которая работает на данный момент.
https://gist.github.com/benswinburne/06a00fab330dca93ea6df2552f73850a
Недостатком этого является то, что данные устарели. API-интерфейс cloudping, к сожалению, не достаточно быстр для этой цели, и как только я перейду к удаленному ресурсу, чтобы получить обновленные данные, я с таким же успехом мог просто перейти к таблице DynamoDB в любом регионе ¯ \ _ (ツ) _ / ¯