Здравствуйте.
Прочитал пост, стало интересно так как я практически не имею отношения к IT-разработке, проверить данное ТЗ моими методами работы с FPF и посмотреть на результат.
Результат неожиданно оказался простынёй текста с детальным указанием критериев и оговорок. (Хотя почему неожиданно - это ж FPF, так что вполне ожидаемо).
Однако как неспециалист я не могу определить, насколько полезно такое подробное разбиение, или в данном случае достаточно той степени детализации которая содержится в вашем варианте ТЗ. Субъективно кажется полезным, но не уверен.
Если не сложно, ответьте пожалуйста как специалист - полезна ли та степень подробности (и как следствие заземлённости), которая предложена в варианте ТЗ ниже, возможно полезна частично (тогда в какой части), или это совершенно излишнее уточнение.
Вот “мой” вариант с FPF:
Исследование возможности переноса контроля дублей из БД в Apache Ignite
1. Контекст
В существующей системе сервис принимает документы в обработку и перед отправкой документа во внешний компонент, далее — конечная система, проверяет, не был ли этот документ отправлен ранее.
Текущий порядок работы:
- сервис получает запрос на обработку документа;
- выполняет проверку наличия ранее зарегистрированной отправки в БД;
- если документ признан дублем, сервис возвращает инициатору предусмотренный для этого ответ;
- если документ не признан дублем, сервис отправляет его в конечную систему и регистрирует результат обработки.
До начала разработки необходимо уточнить:
- критерий идентичности документов;
- назначение и правила формирования
requestId;
- момент, после которого документ считается отправленным;
- контракт взаимодействия с конечной системой;
- существующие состояния обработки документа.
2. Проблема и основание для исследования
Предполагается, что при увеличении потока документов операции контроля дублей в БД могут ограничить пропускную способность сервиса.
На текущий момент это является гипотезой. Необходимо:
- определить фактическую производительность существующего решения;
- установить, является ли работа с БД существенным ограничением;
- проверить, позволит ли использование Apache Ignite повысить производительность при сохранении требуемой корректности обработки;
- определить, оправдано ли усложнение архитектуры и эксплуатации системы.
Apache Ignite рассматривается как проверяемый технический вариант. Его применение не считается заранее принятым решением.
3. Цель работы
Подготовить обоснованное решение о целесообразности использования Apache Ignite для контроля дублей.
Результат работы должен позволять выбрать одно из следующих решений:
- сохранить существующий механизм;
- оптимизировать работу с БД;
- продолжить исследование;
- разработать промышленный вариант с Apache Ignite;
- отказаться от Apache Ignite;
- рассмотреть другой архитектурный вариант.
Первый этап не включает промышленное внедрение Apache Ignite и автоматического переключения между Ignite и БД.
4. Проверяемые гипотезы
Гипотеза 1
При нагрузке, соответствующей ожидаемому рабочему профилю, операции контроля дублей в БД становятся существенным ограничением пропускной способности или задержки обработки.
Гипотеза подтверждается, если измерения показывают, что насыщение БД либо связанных с ней ресурсов непосредственно ограничивает устойчивую производительность сервиса.
Гипотеза опровергается, если ограничение возникает в другом компоненте либо запас производительности БД достаточен для ожидаемой нагрузки.
Гипотеза 2
Замена либо разгрузка существующего механизма контроля дублей с помощью Apache Ignite позволяет увеличить устойчивую пропускную способность или уменьшить задержку обработки на согласованную величину без ухудшения корректности.
До испытаний необходимо согласовать:
- минимально значимый прирост производительности;
- допустимые значения задержек;
- допустимую долю технических ошибок;
- требования к потреблению ресурсов;
- допустимое усложнение эксплуатации.
Гипотеза 3
Можно спроектировать переключение между Apache Ignite и БД, при котором сохраняются согласованные правила контроля дублей и обработки незавершённых операций.
Эта гипотеза исследуется только после подтверждения целесообразности Apache Ignite по результатам первых двух этапов.
Альтернативные объяснения ограничения производительности
При анализе необходимо проверить, не вызвано ли ограничение:
- производительностью конечной системы;
- сетевыми задержками;
- сериализацией или десериализацией;
- настройками пула потоков;
- пулом подключений к БД;
- индексами, блокировками или планом запросов;
- транзакционной моделью;
- журналированием;
- недостатком процессора, памяти, диска или сетевой пропускной способности;
- неэффективностью существующего алгоритма контроля дублей.
5. Границы работ
В первый этап входят
- уточнение требований к контролю дублей;
- описание текущего процесса и модели состояний документа;
- профилирование существующего решения;
- определение текущего узкого места;
- разработка исследовательского прототипа контроля дублей на Apache Ignite;
- функциональное и нагрузочное тестирование двух вариантов;
- сравнение результатов;
- подготовка рекомендации;
- при положительном решении — архитектурная проработка переключения на БД при недоступности Ignite.
В первый этап не входят
- промышленное внедрение Apache Ignite;
- миграция накопленных данных;
- промышленная реализация автоматического переключения;
- изменение контракта конечной системы;
- изменение бизнес-правил обработки дублей;
- ввод решения в промышленную эксплуатацию.
Эти работы могут быть начаты только после отдельного решения по результатам исследования.
6. Функциональные требования к исследовательскому прототипу
Прототип должен:
- реализовывать тот же внешний контракт контроля дублей, что и существующий механизм;
- использовать согласованный идентификатор логического документа;
- обеспечивать атомарное принятие решения при одновременном поступлении нескольких запросов для одного документа;
- допускать запуск нескольких экземпляров сервиса;
- фиксировать результат проверки и изменение состояния документа;
- возвращать инициатору предусмотренный ответ при обнаружении дубля;
- журналировать решения о признании документа новым или повторным;
- позволять выбирать механизм контроля дублей через конфигурацию без изменения сценария нагрузочного теста;
- предоставлять технические показатели для мониторинга работы Ignite.
Использование структуры «ключ — значение» рассматривается как исходный вариант. Окончательный состав ключа и значения определяется после уточнения правил идентификации документа и модели состояний.
7. Обязательные свойства и ограничения
7.1. Идентификация дубля
До разработки необходимо определить:
- является ли дублем запрос с одинаковым
requestId;
- может ли один документ поступить с разными
requestId;
- существует ли устойчивый бизнес-идентификатор документа;
- зависит ли идентичность документа от версии, типа, инициатора или содержимого;
- допустимо ли использовать вычисляемый идентификатор или хеш содержимого.
requestId нельзя использовать как ключ контроля дублей, пока не подтверждено, что он однозначно идентифицирует логический документ, а не отдельную попытку обработки.
7.2. Состояния документа
Необходимо определить как минимум следующие состояния либо их аналоги:
- документ принят;
- обработка зарезервирована;
- выполняется отправка;
- отправка подтверждена;
- отправка завершилась ошибкой;
- результат отправки неизвестен;
- документ признан дублем.
Для каждого состояния должны быть определены разрешённые переходы и действия после перезапуска или сбоя.
7.3. Конкурентная обработка
При одновременном поступлении нескольких запросов для одного логического документа только один запрос может получить право на первичную отправку.
Остальные запросы должны обрабатываться по согласованному правилу:
- получать ответ о наличии дубля;
- ожидать завершения первой обработки;
- получать результат первой обработки;
- обрабатываться иным утверждённым способом.
7.4. Семантика отправки
Необходимо согласовать требуемую гарантию:
- документ отправляется не более одного раза;
- документ должен быть доставлен хотя бы один раз;
- конечная система обеспечивает идемпотентную обработку повторных запросов;
- используется иной согласованный вариант.
Отдельно необходимо определить поведение в ситуации, когда внешний запрос был передан, но сервис не получил достоверного подтверждения результата.
До выяснения результата такого вызова система не должна автоматически считать документ как однозначно неотправленным.
7.5. Хранение данных
Необходимо определить:
- источник достоверных данных о состоянии отправки;
- состав хранимой записи;
- срок хранения;
- правила удаления;
- необходимость постоянного хранения данных в Ignite;
- количество резервных копий;
- требования к восстановлению после перезапуска;
- допустимость потери последних изменений;
- требования к журналированию и аудиту.
8. Этапы выполнения
Этап 1. Уточнение требований и анализ текущей системы
Исполнитель должен:
- описать существующий алгоритм контроля дублей;
- определить используемый запрос к БД, индексы и транзакции;
- построить схему последовательности обработки;
- описать состояния документа;
- определить точку фиксации успешной отправки;
- составить перечень неоднозначных и отсутствующих требований;
- согласовать определение дубля и назначение
requestId.
Результат этапа — согласованное описание текущего механизма и требований к корректности.
Этап 2. Профилирование существующего решения
Необходимо измерить вклад основных компонентов в общее время обработки и определить фактическое узкое место.
Если работа с БД не является существенным ограничением, это должно быть зафиксировано. В таком случае допускается остановить разработку прототипа либо продолжить её только по отдельному решению.
Этап 3. Разработка прототипа Apache Ignite
Необходимо реализовать минимальный прототип, достаточный для проверки:
- корректности контроля дублей;
- конкурентной обработки;
- работы нескольких экземпляров сервиса;
- производительности;
- поведения при перезапуске и отказе отдельных компонентов.
Версия Apache Ignite, топология кластера, режим хранения, количество копий и настройки согласованности должны быть зафиксированы в отчёте.
Этап 4. Функциональное тестирование
Необходимо проверить:
- два последовательных запроса для одного документа;
- параллельные запросы для одного документа;
- разные документы;
- одинаковый
requestId для разных входных данных;
- разные
requestId для одного логического документа;
- повторную доставку сообщения;
- работу нескольких экземпляров сервиса;
- перезапуск экземпляра сервиса;
- перезапуск узла Ignite;
- сбой между регистрацией документа и внешней отправкой;
- сбой после внешней отправки до регистрации подтверждения;
- обработку записи с неопределённым состоянием;
- очистку или истечение срока хранения записи.
Ожидаемый результат каждого теста должен быть определён до его выполнения.
Этап 5. Нагрузочное тестирование
Существующий вариант и прототип с Ignite должны тестироваться:
- на одном и том же стенде;
- с одинаковой версией приложения;
- при одинаковой конфигурации внешних зависимостей;
- с одинаковыми тестовыми данными;
- по одному нагрузочному сценарию;
- при одинаковом начальном состоянии;
- с изменением только исследуемого механизма контроля дублей.
Этап 6. Анализ и принятие решения
По результатам испытаний необходимо:
- сопоставить показатели двух вариантов;
- определить причины выявленных различий;
- проверить воспроизводимость результатов;
- оценить сложность разработки и эксплуатации;
- сформировать решение о дальнейшем использовании Apache Ignite.
Этап 7. Проработка переключения
Этап выполняется только при подтверждённой целесообразности Apache Ignite.
На этом этапе разрабатывается архитектурная концепция переключения между Ignite и БД. Промышленная реализация переключения в объём данного задания не входит.
9. Методика нагрузочного и функционального тестирования
До начала испытаний необходимо зафиксировать:
- конфигурацию оборудования;
- версии ОС, БД, Apache Ignite и приложения;
- настройки БД и Ignite;
- количество экземпляров сервиса;
- количество узлов Ignite;
- характеристики сетевого взаимодействия;
- состав и объём исходных данных;
- размер записи контроля дублей;
- срок хранения записей;
- долю повторных документов;
- долю конкурентных запросов для одного документа;
- размер документов;
- распределение типов документов;
- ожидаемую среднюю и пиковую нагрузку;
- характер поступления запросов: равномерный, ступенчатый или пакетный;
- длительность прогрева;
- длительность измерения;
- количество повторных прогонов.
Следует отдельно проверить:
- холодное состояние;
- прогретое состояние;
- постепенное увеличение нагрузки;
- кратковременные всплески;
- длительную стабильную нагрузку;
- различные доли дублей;
- рост объёма накопленных данных;
- восстановление после отказа.
Под максимальной устойчивой пропускной способностью следует понимать наибольшую нагрузку, которая может поддерживаться в течение согласованного периода без выхода за допустимые значения задержки, ошибок и корректности обработки.
Кратковременное пиковое значение не считается максимальной устойчивой пропускной способностью.
10. Измеряемые показатели
Для каждого показателя необходимо указать единицу, период измерения, условия получения и источник данных.
Производительность
- количество принятых документов в секунду;
- количество завершённых обработок в секунду;
- количество операций контроля дублей в секунду;
- максимальная устойчивая пропускная способность.
Задержки
Для общего времени обработки и отдельно для контроля дублей:
- медиана;
- 95-й перцентиль;
- 99-й перцентиль;
- максимальное наблюдаемое значение.
Корректность
- количество повторно отправленных документов;
- количество дублей, ошибочно признанных новыми;
- количество новых документов, ошибочно признанных дублями;
- количество документов с неопределённым состоянием;
- количество потерянных либо необработанных документов.
Ошибки
- доля технических ошибок;
- доля тайм-аутов;
- доля отказов конечной системы;
- количество ошибок чтения и записи в хранилище.
Использование ресурсов
Отдельно для сервиса, БД и Apache Ignite:
- загрузка процессора;
- использование памяти;
- дисковая нагрузка;
- сетевой обмен;
- количество подключений;
- длина очередей;
- ожидание блокировок;
- время выполнения запросов;
- операции перераспределения данных в Ignite.
Отказоустойчивость
- время обнаружения сбоя;
- время восстановления;
- время переключения;
- количество незавершённых операций;
- количество ошибок и дублей во время сбоя и восстановления.
11. Критерии успешности и правила принятия решения
Числовые критерии должны быть согласованы до начала испытаний.
Apache Ignite может быть рекомендован для дальнейшей промышленной проработки, если одновременно выполнены следующие условия:
- подтверждено, что существующий механизм контроля дублей ограничивает производительность либо не обеспечивает необходимый запас;
- прототип проходит согласованные функциональные тесты;
- отсутствует ухудшение корректности контроля дублей;
- достигнут согласованный прирост устойчивой производительности либо снижение задержки;
- результат воспроизводится в повторных прогонах;
- потребление ресурсов соответствует согласованным ограничениям;
- эксплуатационная сложность и стоимость признаны приемлемыми;
- существует технически реализуемый способ восстановления и переключения без нарушения согласованных правил обработки документов.
Основания отказаться от Apache Ignite
- БД не является существенным ограничением;
- необходимая производительность достигается оптимизацией существующего решения;
- прирост производительности ниже согласованного уровня;
- результат нестабилен или невоспроизводим;
- нарушается корректность контроля дублей;
- невозможно обеспечить требуемое поведение при сбоях;
- эксплуатационная стоимость превышает ожидаемую пользу.
Основания продолжить исследование
- результаты неоднозначны;
- стенд недостаточно соответствует промышленной среде;
- выявлены ограничения, которые можно устранить дополнительной настройкой;
- требуется проверить другой режим работы Ignite;
- отсутствуют данные для окончательного выбора.
Решение должно оформляться отдельным документом с исходными показателями, результатами тестов, ограничениями и обоснованием выбранного варианта.
12. Требования к исследованию отказов и переключения
При положительных результатах нагрузочного тестирования необходимо проработать следующие сценарии:
- недоступен один узел Ignite;
- недоступно несколько узлов;
- недоступен весь кластер;
- отсутствует сетевое соединение между сервисом и Ignite;
- возникает сетевое разделение;
- запрос к Ignite завершается тайм-аутом;
- сервис завершается во время регистрации документа;
- сервис завершается во время внешней отправки;
- внешний вызов выполнен, но его результат неизвестен;
- переключение выполняется при наличии запросов в обработке;
- Ignite восстанавливается после работы через БД;
- выполняется обратное переключение на Ignite;
- данные Ignite и БД различаются.
Необходимо сравнить как минимум следующие архитектурные варианты:
- БД является источником достоверных данных, Ignite используется для ускорения чтения и координации;
- Ignite является основным хранилищем контроля дублей, данные синхронизируются с БД;
- состояние отправки хранится в отдельном устойчивом журнале, а БД и Ignite используют его данные;
- другой вариант, предложенный исполнителем.
Для каждого варианта необходимо определить:
- какие операции выполняются синхронно;
- какие операции выполняются асинхронно;
- источник достоверных данных;
- порядок переключения;
- порядок обратного переключения;
- правила обработки активных запросов;
- правила разрешения расхождений;
- риск повторной отправки;
- риск потери документа;
- требования к конечной системе;
- стоимость реализации и эксплуатации.
Необходимо использовать термины:
- переключение на резервный механизм;
- обратное переключение;
- восстановление данных;
- согласование данных.
Термин «откат» следует использовать только для возврата состояния системы или версии программного обеспечения.
13. Ожидаемые результаты и передаваемые материалы
Исполнитель должен передать:
- описание текущего процесса;
- определение дубля и состояний документа;
- архитектурную схему текущего решения;
- схему последовательности обработки;
- исходный код исследовательского прототипа;
- конфигурацию Apache Ignite;
- функциональные тесты;
- нагрузочные сценарии и скрипты;
- описание тестового стенда;
- исходные результаты измерений;
- сводные таблицы и графики;
- анализ узких мест;
- сравнение БД и Apache Ignite;
- перечень ограничений эксперимента;
- рекомендацию по дальнейшим действиям;
- при положительном решении — концепцию переключения и восстановления;
- предварительную оценку трудоёмкости промышленной реализации.
Результаты испытаний должны быть воспроизводимыми по переданным материалам.
14. Открытые вопросы и допущения
До начала разработки необходимо получить ответы на следующие вопросы:
- Что считается одним логическим документом?
- Что именно идентифицирует
requestId?
- Может ли один документ поступить с разными
requestId?
- Когда документ считается успешно отправленным?
- Поддерживает ли конечная система идемпотентные запросы?
- Как сейчас атомарно связаны проверка дубля и регистрация отправки?
- Какая БД и какая схема данных используются?
- Как долго необходимо учитывать ранее отправленные документы?
- Какой поток ожидается в перспективе?
- Какие ограничения по задержке и ошибкам действуют?
- Какая версия Apache Ignite должна исследоваться?
- Допустима ли потеря последних записей при полном отказе кластера?
- Какое поведение требуется при неопределённом результате внешней отправки?
- Кто принимает итоговое решение о дальнейшем внедрении?
До получения ответов запрещено считать, что requestId является достаточным ключом контроля дублей либо что требование полного отсутствия повторной отправки технически обеспечено.