Приветствую всех читателей Хабра! Меня зовут Игорь Рыбаков и я технический директор в казахстанской IT-компании DAR. Сегодня я поделюсь с вами пониманием и использованием принципов параллельных вычислений в современных информационных системах. Чтобы глубже разобраться в этом, я хотел бы привести аргументы в пользу изучения и практического применения концепций параллельных и распределенных вычислений при разработке современных информационных систем.
Параллельные вычисления или при чем тут основатель Intel
Сначала немного истории. В 1965 году Гордон Мур, один из основателей Intel, обнаружил закономерность: появление новых моделей микросхем наблюдалось спустя примерно год после предшественников, при этом количество транзисторов в них возрастало каждый раз приблизительно вдвое. Получается, что количество транзисторов, размещаемых на кристалле интегральной схемы, удваивалось каждые 24 месяца. Такое наблюдение стало называться законом Мура. Основатель Intel предсказал, что количество элементов в чипе вырастет с 2^6 (порядка 60) в 1965 году до 2^16 (65 тыс.) уже к 1975 году.
Сейчас, чтобы получить возможность задействовать на практике эту дополнительную вычислительную мощность, которую предсказывал закон Мура, стало необходимо задействовать параллельные вычисления. В течение нескольких десятилетий производители процессоров постоянно увеличивали тактовую частоту и параллелизм на уровне инструкций, так, чтобы на новых процессорах старые однопоточные приложения исполнялись быстрее без каких-либо изменений в программном коде.
Примерно с середины 2000-х годов производители процессоров стали отдавать предпочтение многоядерной архитектуре, но для получения всей выгоды от возросшей производительности центрального процессора программы должны переписываться в соответствующей манере. Тут возникает проблема, ведь согласно закону Амдала , не каждый алгоритм поддается распараллеливанию, определяя, таким образом, фундаментальный предел эффективности решения вычислительной задачи на суперкомпьютерах.
Для преодоления этого предела используются подходы распределенных вычислений. Это такой способ решения трудоемких вычислительных задач с использованием нескольких компьютеров, которые, чаще всего, объединены в параллельную вычислительную систему. Последовательные вычисления в распределенных информационных системах выполняются с учетом одновременного решения многих вычислительных задач. Особенностью распределенных многопроцессорных вычислительных систем, в отличие от локальных суперкомпьютеров, является возможность неограниченного наращивания производительности за счет масштабирования.
Примерно с середины 2005 года компьютеры массово комплектуются многоядерными процессорами, что позволяет проводить параллельные вычисления. А современные сетевые технологии позволяют объединить сотни и тысячи компьютеров. Что привело к появлению так называемых «облачных вычислений».
Применение параллельных вычислений
Нынешние информационные системы, например, системы электронной торговли, остро нуждаются в предоставлении качественных услуг своим клиентам. Компании ведут конкурентную борьбу, изобретая все новые сервисы и информационные продукты. Сервисы должны быть рассчитаны на высокую нагрузку и высокую отказоустойчивость, так как пользователи сервисов, не один офис, не одна страна, а весь мир.
При этом, важно сохранить экономическую целесообразность проектов и не тратить излишние средства на дорогостоящее серверное оборудование, если на нем будет работать старое программное обеспечение, использующее только часть вычислительных мощностей.
Перед разработчиками прикладных систем встала новая проблема — необходимость переписать информационные системы, чтобы соответствовать требованиям современного бизнеса и осознанию необходимости лучшей утилизации серверных ресурсов для снижения общей стоимости владения. Задачи, которые необходимо решать современным информационным системам разнообразны.
Начиная от машинного обучения и аналитики больших данных, до обеспечения стабильной работы существующего базового функционала системы в периоды пиковой нагрузки. Для примера здесь можно привести массовые распродажи в интернет-магазине. Все эти задачи можно решить используя комбинацию параллельных и распределенных вычислений, например реализуя микро-сервисную архитектуру.
Контроль качества сервисов
Для измерения фактического качества сервисов для клиента используется понятие service-level agreement (SLA), то есть, некоторые статистические метрики производительности системы.
Например, разработчики могут поставить перед собой задачу, чтобы 95% всех пользовательских запросов обслуживались со временем отклика не превышающим 200 ms. К слову сказать, то вполне реальные нефункциональные требования, потому что пользователи не любят ждать.
Для оценки удовлетворенности пользователей сервисом можно использовать показатель Apdex, который отражает отношение успешных (satisfied) откликов к неудовлетворительным (unsatisfactory). Например, наше пороговое значение SLA = 1,2 секунды, тогда при 95% времени отклика запросов <= 1,2 секунды результат будет успешным. В случае появлении большого числа запросов более 1,2 секунды, но менее 4T (4,8 секунды), результат считается удовлетворительным, а при появлении большого числа запросов превышающим 4T, те > 4,8 секунд результат считается провалом.
Выводы
В итоге хотелось бы сказать, что разработка микросервисов фактически предполагает понимание и практическое применение Распределенных и Параллельных вычислений.
Конечно, при этом придется пожертвовать некоторыми вещами:
- Простотой разработки и сопровождения — усилия разработчиков на реализацию распределенных модулей;
- При работе с базами данных строгую может отнять согласованность (ACID) и потребовать других подходов;
- Тратятся вычислительные мощности на сетевые коммуникации и сериализацию;
- Потратим время на внедрение практик DevOps на более сложный мониторинг и развертывание.
Взамен этому мы получаем, на мой взгляд, гораздо больше:
- возможность повторного использования целых модулей, готовых к работе, и, как следствие, быстрый запуск продуктов на рынке;
- высокую масштабируемость систем, что означает большее количество клиентов без потери SLA;
- Используя согласованность в конечном счете (eventual consistency), основываясь на CAP теореме, мы получаем возможность управлять огромными массивами данных, опять же, без потери SLA;
- возможность записывать любое изменение в состоянии системы для дальнейшего анализа и машинного обучения.
Mishiko
— ага, неконсистентные данные в продуктовом хранилище и геморой по их ручной починке
DARGroup Автор
Спасибо, за комментарий.
Во-первых, надо сказать что за consistency надо следить всегда, даже при использовании реляционных СУБД. И если неправильно работать с транзакциями, то "ручну починку" можно получить и в реляционной базе.
Вторе, если просто попытаться заменить базу данных (с реляции на NOSQL) без внесения изменений в архитектуру, например, оставить stateless сервисы, которые раньше работали с реляционной базой, то результат будет печальный.
По-сути я и говорю о том, что нельзя просто взять и запилить микросервисы, нужно понимать что меняются подходы к проектированию системы — это распределенные вычисления. Нужно использовать кластера, распределенные журналы событий (Apache Kafka), event sourcing и тд.
Только в этом случае выгоды будут очевидными.
P.S. Ручная починка состояния — это вообще не вариант. Мы голосуем за Self-Healing Services.