Подсчет лямбда-вызовов AWS и сегментирование данных по ключу API

Question

Клиенты (около 1000) регистрируются в моем сервисе и получают уникальный ключ API клиента.Затем они используют ключ при вызове лямбда-функции AWS через шлюз API AWS для доступа к данным в DynamoDb.

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

1. При каждом увеличении числа попаданий в API счетчик в DynamoDB.
2. При каждом попадании в API ставить в очередь aсообщение в SQS, получите его в лямбду-счетчике обращений и увеличьте счетчик в DynamoDB.
3. Разверните отдельную лямбду для каждого клиента.Используйте встроенный счетчик вызовов AWS.

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

1. Сохраните требуемый ключ API вместе с данными, к которым у клиента есть право доступа.
2. Разверните отдельную лямбду для каждогопокупатель.Используйте API-шлюз, чтобы защитить его с помощью ключа.
3. Создайте отдельную конечную точку в API-шлюзе для каждого клиента, защитите его с помощью ключа API.

Ни один из перечисленных выше вариантов не выглядит какхороший способ разработать решение.Есть ли канонический способ сделать это?Если нет, какой из перечисленных выше вариантов является лучшим?Я пропустил очевидное решение из-за того, что не знаком с AWS?

Answer 1

Я постараюсь разобрать ваши проблемы с помощью моего опыта, но, возможно, Майкл - Sqlbot или Джон Ротенштейн могут дать более подходящие ответы.

Требование 1

1) Это звучит как хороший подход.Я не вижу здесь ничего критического.

2) Это, ИМХО, лучший из трех вариантов. Он отделит доступ к данным от биллинговой службы, что является отличной вещью в мире микросервисов.

3) Это не масштабируется.Представьте, что ваша система развивается, и вы получаете 10К лямбда-функций.Вам нужно будет не только создать очень надежный механизм для автоматизации этого процесса, но также вам необходимо отслеживать 10 тысяч различных вещей (представьте журналы CloudWatch, API-шлюз и т. Д.), Не говоря уже о том, что у вас будет 10 тысяч функций сточно такой же код (отдельные параметры клиента).Я бы даже не подумал об этом.

Требование 2

1) Это может работать и хорошо вписывается в модель действий DynamoDB: хранить как можно большеданные, как вы можете в уникальной таблице, так что вы можете получить все за один раз.Из того, что я вижу, вы могли бы даже использовать этот ApiKey в качестве ключа раздела и, ради простоты этого ответа, хранить данные клиента в виде JSON в столбце с именем data.Так как ваш запрос должен запрашиваться только с помощью ApiKey, сохранение JSON в DynamoDB не повредит (однако имейте в виду, что если вам нужно выполнить запрос по любому из его атрибутов JSON, чем у вас плохо, так как DynamoDBвозможности запросов очень ограничены)

2) Нет, из-за Требование 1.3

3) Нет, из-за вышеизложенного.

Если вы все ещевам нужно хранить ApiKey в другой таблице, чтобы вы могли выполнять другой анализ и сохранять более точный контроль над вызовами, доступом, выставлением счетов и т. д. клиента, это тоже не проблема, просто убедитесь, что вы дублируете свой ApiKey на ClientData таблица вместо создания FK (DynamoDB не поддерживает FK, поэтому вам придется самостоятельно управлять этими ограничениями).Дублирование просто отлично в мире NoSQL.

Ваш вариант использования явно мультитенантный, поэтому я также рекомендую вам прочитать Мультитенантное хранилище с Amazon DynamoDB , которое будетдать вам больше понимания и немного расширить свои возможности.Многопользовательская аренда не является легкой задачей и может причинить вам много головной боли, если она не реализована правильно.Я думаю, именно поэтому AWS также подготовил для нас это приятное чтение:)

Рад продолжить это в разделе комментариев, если у вас есть дополнительная информация для обмена

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