aleksandrmatsko / crack-hash-lab-2

Second lab of NSU course distributed systems

Условия задачи

Предисловие

Мы стремимся реализовать распределенную систему для взлома хэша под кодовым именем CrackHash. Непосредственно взлом хэша будем реализовывать через простой перебор словаря сгенерированного на основе алфавита (brute-force). В общих чертах система должна работать по следующей логике: В рамках системы существует менеджер, который принимает от пользователя запрос, содержащий MD-5 хэш некоторого слова, а также его максимальную длину. Менеджер обрабатывает запрос: генерирует задачи в соответствии с заданным числом воркеров (вычислительных узлов) на перебор слов составленных из переданного им алфавита. Каждый воркер принимает задачу, вычисляет собственный диапазон в котором нужно проверять слова, генерирует и вычисляет их хэш. Находит слова у которых он совпадает, и результат работы возвращает менеджеру через очередь.

Task 1. Services Implementation

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

Примечание:

Настройка очередей и producer-ов/listener-ов для них в рамках данной задачи не предполагается!

Общие требования к сервисам:

1. Реализация приложений предполагается на языке Java (11+) с использованием фреймворка Spring Boot. (также разрешены другие языки)
2. Для сборки рекомендуется использовать Gradle (6+).
3. Для развертывания сервисов необходимо использовать docker-compose, конфигурация с одним воркером.
4. Запросы между менеджером и воркером необходимо передавать внутри сети docker-compose по протоколу HTTP, используя в качестве доменов имена сервисов.

Требования к менеджеру

1. Менеджер должен предоставлять клиенту REST API в формате JSON для взаимодействия с ним.

   Запрос на взлом хэша (слово abcd):

   POST /api/hash/crack
   Request body:
   {
       "hash":"e2fc714c4727ee9395f324cd2e7f331f",
       "maxLength": 4
   }
   

   В ответ менеджер должен отдавать клиенту идентификатор запроса, по которому тот сможет обратится за получением ответа.

   Response body:
   {
       "requestId":"730a04e6-4de9-41f9-9d5b-53b88b17afac"
   }
   

2. Для получения результатов менеджер должен представлять следующее API.

   GET /api/hash/status?requestId=730a04e6-4de9-41f9-9d5b-53b88b17afac
   

   Ответ, если запрос еще обрабатывается.

   Response body:
   {
       "status":"IN_PROGRESS",
       "data": null
   }
   

   Ответ, если ответ готов.

   Response body:
   {
       "status":"READY",
       "data": ["abcd"]
   }
   

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

4. Взаимодействие между менеджером и воркерами должно быть организовано в формате JSON.

5. Перед отправкой задач воркерам менеджер должен сохранить в оперативной памяти информацию о них с привязкой к запросу клиента в статусе IN_PROGRESS под идентификатором, который после должен быть выдан пользователю. При получении ответов от всех воркеров менеджер должен перевести статус запроса в READY. По истечению таймаута запрос должен перевестись в статус ERROR.

6. Для работы с состоянием запросов использовать потокобезопасные коллекции.

7. Взаимодействие с воркером организовать по протоколу HTTP с помощью Rest Template. Для этого в воркере необходимо реализовать контроллер для обработки запросов от менеджера, принимающий запрос по следующему пути: POST /internal/api/worker/hash/crack/task

Требования к воркерам:

1. Взаимодействие с менеджером организовать по протоколу HTTP с помощью Rest Template. Для этого в менеджере необходимо реализовать контроллер для обработки ответов от воркера по следующему пути: PATCH /internal/api/manager/hash/crack/request
2. Для генерации слов на основе полученного алфавита можно использовать библиотеку combinatoricslib. Она позволяет генерировать перестановки с повторениями заданной длины на основе заданного множества. Ключевое условие здесь, чтобы воркер не держал в памяти все сгенерированные комбинации т.к. при увеличении максимальной длины последовательности их банально станет очень много. Для этого библиотека предоставляет итератор по множеству комбинаций.
3. Расчет диапазона слов необходимо производить на основе значений PartNumber и PartCount из запроса от менеджера. Необходимо поделить всё пространство слов поровну между всеми воркерами.

Полезные ссылки:

1. Пример базового сервиса на Spring

   https://spring-projects.ru/guides/rest-service/

2. Генерация последовательностей

   https://github.com/dpaukov/combinatoricslib

3. Rest Template

   https://docs.spring.io/spring-android/docs/current/reference/html/rest-template.html

   https://www.baeldung.com/rest-template

Task 2. Fault tolerance

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

Основные требования:

1. Обеспечить сохранность данных при отказе работы менеджера

   1. Для этого необходимо обеспечить хранение данных об обрабатываемых запросах в базе данных
   2. Также необходимо организовать взаимодействие воркеров с менеджером через очередь RabbitMQ
      1. Для этого достаточно настроить очередь с direct exchange-ем
      2. Если менеджер недоступен, то сообщения должны сохраняться в очереди до момента возобновления его работы
   3. RabbitMQ также необходимо разместить в окружении docker-compose

2. Обеспечить частичную отказоустойчивость базы данных

   1. База данных также должна быть отказоустойчивой, для этого требуется реализовать простое реплицирование для не реляционной базы MongoDB
   2. Минимально рабочая схема одна primary нода, две secondary
   3. Менеджер должен отвечать клиенту, что задача принята в работу только после того, как она была успешно сохранена в базу данных и отреплицирована

3. Обеспечить сохранность данных при отказе работы воркера(-ов)

   1. В docker-compose необходимо разместить, как минимум, 2 воркера
   2. Организовать взаимодействие менеджера с воркерами через очередь RabbitMQ (вторая, отдельная очередь), аналогично настроить direct exchange
   3. В случае, если любой из воркеров при работе над задачей ”cломался” и не отдал ответ, то задача должна быть переотправлена другому воркеру, для этого необходимо корректно настроить механизм acknowledgement-ов
   4. Если на момент создания задач нет доступных воркеров, то сообщения должны дождаться их появления в очереди, а затем отправлены на исполнение

4. Обеспечить сохранность данных при отказе работы очереди

   1. Если менеджер не может отправить задачи в очередь, то он должен сохранить их у себя в базе данных до момента восстановления доступности очереди, после чего снова отправить накопившиеся задачи
   2. Очередь не должна терять сообщения при рестарте (или падении из-за ошибки), для этого все сообщения должны быть персистентными (это регулируется при их отправке)

Кейсы, которые будут проверяться:

1. стоп сервиса менеджера в docker-compose
   1. полученные ранее ответы от воркеров должны быть сохранены в базу и не должны потеряться
   2. не дошедшие до менеджера ответы на задачи не должны потеряться, менеджер должен подобрать их при рестарте
2. стоп primary ноды реплик-сета MongoDB в docker-compose
   1. primary нода должна измениться, а система продолжать работу в штатном режиме
3. стоп RabbitMQ в docker-compose
   1. все необработанные, на момент выключения очереди, сообщения после рестарта не должны потеряться
4. стоп воркера во время обработки задачи
   1. сообщение должно быть переотправлено другому воркеру, задача не должна быть потеряна

Примечания.

При рестарте RabbitMQ сбрасывает статус отправленных сообщений (персистентных) из unacked в ready. Поэтому, например, допускается повторная обработка одной задачи двумя воркерами, что нужно учесть в логике менеджера.

Полезные ссылки

1. Гайд по RabbitMQ Exchanges

   https://habr.com/ru/post/489086/

2. Деплой RabbitMQ в docker-compose

   https://www.section.io/engineering-education/dockerize-a-rabbitmq-instance/

3. Доки по реплицированию MongoDB

   https://www.mongodb.com/docs/manual/replication/

4. RabbitMQ Consumer Acknowledgements and Publisher Confirms

   https://www.rabbitmq.com/confirms.html

5. RabbitMQ Persistence Configuration

   https://www.rabbitmq.com/persistence-conf.html