Экземпляры противядра при использовании EC2

Question

Работая над тем, что часто можно назвать проектами "со средними данными", я смог распараллелить свой код (в основном для моделирования и прогнозирования на Python) в одной системе с использованием от 4 до 32 ядер.Теперь я рассматриваю возможность масштабирования до кластеров на EC2 (возможно, с помощью StarCluster / IPython, но открыт и для других предложений), и был озадачен тем, как согласовать распределение работы между ядрами в экземпляре сэкземпляры в кластере.

Практично ли вообще распараллеливать между экземплярами, а также между ядрами в каждом экземпляре?Если да, может ли кто-нибудь дать краткое изложение плюсов и минусов запуска множества экземпляров с несколькими ядрами в каждом?несколько экземпляров с большим количеством ядер?Существует ли эмпирическое правило для выбора правильного соотношения экземпляров к ядрам в каждом экземпляре?

Пропускная способность и оперативная память являются нетривиальными проблемами в моих проектах, но легко определить, когда это узкие места, и скорректировать их.Я бы предположил, что гораздо сложнее сопоставить правильное сочетание ядер с экземплярами без повторного тестирования, а мои проекты слишком сильно различаются, чтобы какой-то один тест можно было применить ко всем обстоятельствам.Заранее спасибо, и если я просто не смог правильно погуглить этот вопрос, не стесняйтесь указать мне правильный ответ где-нибудь в другом месте!

Answer 1

При использовании IPython вам почти не нужно беспокоиться об этом (за счет некоторой потери эффективности / увеличения затрат на связь).Параллельный плагин IPython в StarCluster по умолчанию запускает по одному движку на физическое ядро на каждом узле (я полагаю, что это настраивается, но не уверен, где именно).Вы просто запускаете все, что хотите, во всех движках, используя DirectView api (map_sync, apply_sync, ...) или волшебные команды %px.Если вы уже используете IPython параллельно на одной машине, использование его в кластере ничем не отличается.

Решение некоторых ваших конкретных вопросов:

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

"Практично ли вообще распараллеливать между экземплярами, а также между ядрами в каждом экземпляре?" - Да :) Если код, который вы запускаете, ошеломляюще параллелен (точно такой же алгоритм для нескольких наборов данных), то вы можете в основном игнорировать, где работает конкретный движок.Если ядру требуется много взаимодействия между движками, то, конечно, вам нужно структурировать его таким образом, чтобы движки в первую очередь взаимодействовали с другими движками на той же физической машине;но я думаю, что такого рода проблемы не идеально подходят для IPython.

"Если да, может ли кто-нибудь дать краткое изложение плюсов и минусов запуска множества экземпляров с несколькими ядрами в каждом?несколько экземпляров с большим количеством ядер?Существует ли эмпирическое правило для выбора правильного соотношения экземпляров к ядрам на экземпляр?" - Используйте самые большие экземпляры c3 для задач, связанных с вычислениями, и самые маленькие для задач, связанных с пропускной способностью памяти;для проблем, связанных с передачей сообщений, также используйте самые большие экземпляры, но постарайтесь разбить проблему на разделы так, чтобы каждый раздел выполнялся на одной физической машине и большая часть сообщений передавалась в пределах одного раздела.Проблемы, которые выполнялись бы значительно медленнее на N экземплярах quadruple c3, чем на 2N double c3, редки (искусственным примером может быть запуск нескольких простых фильтров для большого количества изображений, когда вы просматриваете все изображения для каждого фильтра, а не все фильтры для одного и того же изображения).Использование самых больших экземпляров - хорошее эмпирическое правило.

Answer 2

Общее эмпирическое правило - не распространять, пока вам не придется. Обычно более эффективно иметь n серверов определенной мощности, чем 2N -серверы половины этой мощности. Больше доступа к данным будет локальным и, следовательно, быстро в памяти по сравнению с медленной по всей сети.

В определенный момент масштабирование одной машины становится неэкономичной, потому что стоимость дополнительных ресурсов масштабирует больше, чем линейно. Однако этот момент все еще удивительно высок.

В частности, на Amazon экономика каждого типа экземпляра может сильно различаться, если вы используете экземпляры спотового рынка. Ценообразование по умолчанию более или менее означает, что одинаковая сумма ресурсов стоит примерно одинаково независимо от типа экземпляра, что может сильно различаться; Большие экземпляры могут быть дешевле, чем маленькие, или n небольших экземпляров могут быть намного дешевле, чем одна большая машина с эквивалентными ресурсами.

Одним из огромных соображений здесь является то, что парадигма вычислений может сильно измениться, когда вы переходите от одной машины на несколько машин. Компромисс, которые вызывают накладные расходы, могут заставить вас, например, принять параллельную парадигму данных для масштабирования. Это означает другой выбор инструментов и алгоритма. Например, SGD выглядит совершенно иначе в памяти и в Python, чем на MapReduce. Таким образом, вам придется рассмотреть это, прежде чем параллелизировать.

Вы можете распределить работу по кластеру, даже если один узел и не распределенные парадигмы работают для вас, для надежности. Если один узел не удается, вы теряете все вычисления; Распределенное вычисление может потенциально восстановить и завершить только ту часть вычисления, которое было потеряно.

Answer 3

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

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

Предполагая, что вы используете какой-то схема перекрестной проверки чтобы оптимизировать некоторые мета-параметр для вашей модели присвойте каждому ядру значение для тестирования и выберите столько экземпляров, сколько необходимо, чтобы охватить все пространство параметров за такое количество раундов, сколько вы сочтете нужным.

Если ваши данные не помещаются в память одной системы, конечно, вам нужно будет распределить их по экземплярам.Тогда это вопрос балансировки задержки памяти (лучше со многими экземплярами) с задержкой в сети (лучше с меньшим количеством экземпляров), но, учитывая природу EC2, я бы поспорил, что вы часто предпочитаете работать с несколькими экземплярами fat.