Хранение больших данных, совместно используемых микросервисами, работающими в контейнерах на AWS

Хранение больших данных, совместно используемых микросервисами, работающими в контейнерах на AWS
Хранение больших данных, совместно используемых микросервисами, работающими в контейнерах на AWS - growtika @ Unsplash

Я имею дело с приложением, которое делает следующее:

  1. у нас есть микросервис, работающий на EKS, вызываемый заданиями, которые извлекают XML-данные из внешней системы. Объем данных может быть довольно большим (иногда 700 МБ-1 ГБ). Мы не можем контролировать объем данных, нет разбиения на страницы или способа подтянуть дельту.
  2. данные записываются в S3 порциями, по одному файлу на запись; сообщение отправляется в очередь SQS, запускает лямбда-функцию, которая вызывает другую службу
  3. следующий сервис выполняет преобразование данных

Проблема, с которой мы сталкиваемся, заключается в том, что, поскольку мы можем получить более 1500 файлов в S3, их запись и чтение не особенно быстры. Кроме того, мы имеем дело с ситуацией, когда одновременно могут выполняться десятки заданий, хотя не все из них будут использовать 1 ГБ, но у вас может быть несколько таких заданий. Мы подумали о нескольких способах исправить ситуацию:

  1. используйте ElastiCache/Redis; меня беспокоит то, что нам понадобится слишком много памяти, и это будет непомерно дорого. Если мы держим память на низком уровне, это означает, что мы должны иметь возможность быстро ее освобождать, но выполнение преобразований для 1500 файлов не обязательно будет таким быстрым, поэтому мы можем в конечном итоге удерживать память в течение минуты или двух. , что в данном случае довольно долго.
  2. использовать DynamoDB; беспокойство вызывает ограничение в 400 КБ, однако, поскольку это текст, мы можем обойтись без сжатия?
  3. использовать реляционную базу данных; здесь нет реляционных данных, но, учитывая, что # 1 и # 2, похоже, есть проблемы, и нам не нужны молниеносные операции чтения/записи (просто нужно быть быстрее, чем S3), кажется, что это может заполнить пробел. Не должно быть никаких проблем с параллелизмом/блокировкой, так как одна служба только записывает, а другая только читает, и нет даже нескольких чтений одной и той же записи.

Я уверен, что есть варианты, о которых я не думал, возможно, даже услуги, которые я не понимаю, я могу использовать. Ограничения здесь в том, что я не могу изменить способ работы всего этого (хотя я не буду возражать, если у людей будут предложения на будущее, когда мы могли бы провести рефакторинг), и я бы предпочел придерживаться использования управляемых служб (поэтому никаких MongoDB или других неподдерживаемые хранилища данных AWS), так как мы небольшая команда и хотим сосредоточиться на том, в чем мы хороши, а не на управлении инфраструктурой.

Вы не рассматривали возможность использования EFS? Вы можете попробовать смонтировать один и тот же том на все процессы (включая лямбду), которые работают с данными.

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

Однако в вашем случае это может сработать. Я не проводил тестов скорости, но я уверен, что EFS превосходит S3 по количеству операций. Просто убедитесь, что вы выбрали правильный режим. General, как правило, быстрее, чем maxIO, но все зависит от ваших данных.


LetsCodeIt, 18 декабря 2022 г., 03:15