Примірники проти ядер при використанні EC2

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

Чи можливо навіть паралельно застосовувати між окремими примірниками, а також по всіх ядрах у кожному екземплярі? Якщо так, чи може хто-небудь дати швидке завершення плюсів і мінусів запуску багатьох екземплярів з декількома ядрами в порівнянні з кількома екземплярами з багатьма ядрами? Чи існує правило визначення правильного відношення екземплярів до ядер на екземпляр?

Пропускна здатність та оперативна пам’ять є нетривіальними проблемами в моїх проектах, але це легко помітити, коли вони є вузькими місцями та переналагодженими. Думаю, набагато важче порівняти правильну суміш ядер з екземплярами без повторного тестування, і мої проекти занадто сильно відрізняються, щоб будь-який єдиний тест застосувати до всіх обставин. Дякую заздалегідь, і якщо я щойно не зміг переглянути гугл на цьому, сміливо вкажіть мене на правильну відповідь десь ще!

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

Звернення до конкретних питань:

"як узгодити розподіл роботи по ядрах на екземпляр проти екземплярів кластера" - Ви отримуєте один двигун на ядро ​​(принаймні); робота автоматично розподіляється по всіх ядрах і по всіх інстанціях.

"Чи навіть практично практично паралельно застосовувати між примірниками, а також по всіх ядрах у кожному екземплярі?" - Так :) Якщо код, який ви використовуєте, бентежно паралельний (точно такий же альго на декількох наборах даних), то ви можете здебільшого ігнорувати, де працює певний двигун. Якщо ядро ​​вимагає великої комунікації між двигунами, то, звичайно, потрібно його структурувати так, щоб двигуни в першу чергу спілкувалися з іншими двигунами на тій же фізичній машині; але така проблема не ідеально підходить для IPython, я думаю.

"Якщо так, чи може хто-небудь дати швидке завершення плюсів і мінусів запуску багатьох екземплярів з декількома ядрами по відношенню до декількох екземплярів з багатьма ядрами? Чи є правило: вибір правильного відношення екземплярів до ядер на екземпляр? " - Використовуйте найбільші екземпляри c3 для обчислених обчислень, а найменші - для проблем, пов’язаних із пропускною здатністю пам'яті; для проблем, пов’язаних з передачею повідомлень, також використовуйте найбільші екземпляри, але спробуйте розділити проблему так, щоб кожен розділ працював на одній фізичній машині, а більшість передач повідомлень знаходилися в одному розділі. Проблеми, які працюватимуть значно повільніше на N чотирикратних екземплярах c3, ніж на 2N подвійних c3, є рідкісними (штучний приклад може запускати кілька простих фільтрів на великій кількості зображень, де ви переглядаєте всі зображення для кожного фільтра, а не всі фільтри для одне зображення).

Загальне правило - не розповсюджувати, поки не доведеться. Зазвичай ефективніше мати N серверів певної ємності, ніж 2N-сервери наполовину цієї ємності. Більша частина доступу до даних буде локальною, а отже, швидкою у пам’яті та повільною по всій мережі.

У певний момент масштабування однієї машини стає неекономічним, оскільки вартість додаткових ресурсів масштабується більш ніж лінійно. Однак ця точка все ще дивовижно висока.

Зокрема, на Amazon економіка кожного типу примірників може сильно відрізнятися, якщо ви використовуєте екземпляри точкового ринку. Ціноутворення за замовчуванням більш-менш означає, що однакова кількість ресурсів коштує приблизно однаково, незалежно від типу екземпляра, яка може сильно відрізнятися; великі екземпляри можуть бути дешевшими, ніж маленькі, або N малих примірників можуть бути значно дешевшими, ніж одна велика машина з еквівалентними ресурсами.

Тут важливим є те, що парадигма обчислень може сильно змінитись при переході від однієї машини до декількох машин. Компроміси, які спонукають накладні комунікації, можуть змусити вас, наприклад, прийняти паралегму даних паралельних даних для масштабування. Це означає різний вибір інструментів та алгоритму. Наприклад, SGD виглядає зовсім по-іншому в пам'яті і в Python, ніж у MapReduce. Тож вам би довелося це розглянути, перш ніж паралелізувати.

Ви можете вибрати розподіл роботи по кластеру, навіть якщо один вузол і нерозподілені парадигми працюють для вас для надійності. Якщо один вузол виходить з ладу, ви втрачаєте всі обчислення; розподілене обчислення потенційно може відновити та виконати лише ту частину обчислень, яка була втрачена.

Усі речі, які вважаються рівними (вартість, CPU perf тощо), ви можете вибрати найменший екземпляр, який може вмістити весь мій набір даних у пам'яті та масштабувати. Цей шлях

• ви переконайтеся, що не викликаєте зайвих затримок через мережеві комунікації та
• ви прагнете максимально використовувати загальну доступну пропускну здатність пам'яті для своїх процесів.

Якщо припустити, що ви використовуєте якусь схему перехресної перевірки для оптимізації якогось мета-параметра вашої моделі, призначте кожному ядру значення для тестування та виберіть безліч екземплярів, необхідних для покриття всього простору параметрів за кілька раундів, як вам здається потрібним.

Якщо ваші дані не вміщуються в пам'яті однієї системи, звичайно, вам потрібно буде поширювати їх по всіх примірниках. Тоді мова йде про збалансування затримки пам’яті (краще для багатьох примірників) з мережевою затримкою (краще з меншою кількістю екземплярів), але, враховуючи природу EC2, я б заперечив, що ви часто віддаєте перевагу працювати з кількома жировими екземплярами.