Управление версиями данных AWS Kinesis и Lambda

Я создал конечную точку AWS Firehose (может измениться на простой Kinesis), которая получает журналы от производителей и сохраняет их в корзину S3, и лямбда-функцию, которая потребляет данные, обрабатывает их и сохраняет выходные данные в db.

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

Я не уверен, что было бы наилучшим подходом к созданию версионной системы с использованием кинезиса и лямбда. Должен ли я копировать всю структуру для новых версий (включая разработку и постановку) и заставлять производителей писать в конкретный версионный поток?

или я должен создать среднюю лямбда-функцию, которая проверяет пакеты (которые содержат информацию об их версиях) и выводит события на конкретный s3, который имеет папки с версиями? Таким образом, лямбда-функции будут использовать только те данные, о которых они знают. Это позволит мне использовать поддержку версий для лямбда-функций.

Вот структурное изображение для первой идеи

«Отдельные

Вот вторая структура

«Единый

Интересно, какое решение будет лучше или есть более эффективные способы добиться этого?


person bahadir    schedule 28.03.2017    source источник


Ответы (1)


Во-первых, лямбда-выражения можно активировать напрямую с помощью Kinesis - нет необходимости в Kinesis Firehose или S3.

Во-вторых, ваш вопрос действительно сводится к следующему: нужен ли вам отдельный конвейер Kinesis + Lambda для каждой версии или нет. Я бы выбрал следующее решение:

  • Один поток Kinesis для всех версий данных.
  • Одна лямбда-функция в этом потоке. Он внутренне обрабатывает разные версии отдельно. Грубо говоря, подумайте о различных проверках if-else для номера версии.

Преимущества вышеуказанного подхода по сравнению с одним конвейером Kinesis + Lambda для каждой версии:

  • Первый вариант проще в эксплуатации. В последнем случае вам нужно будет настраивать новый конвейер каждый раз при выпуске новой версии.
  • В любой момент у вас будет небольшое количество активных версий. Итак, несколько проверок if-else в коде должны работать нормально.

Разумеется, конвейеры Dev и Prod должны быть разделены, чтобы в первом случае минимизировать радиус взрыва плохого кода.

person ketan vijayvargiya    schedule 28.03.2017
comment
Наша команда решила использовать firehose + s3 для хранения необработанных данных. в противном случае вы правы - возможно, мы перейдем на решение kinesis only - person bahadir; 29.03.2017