Ми в Skyeng користуємося Amazon Redshift, у тому числі паралельним масштабуванням, тому стаття Стефана Громолла, засновника dotgo.com для intermix.io, здалася нам цікавою. Після перекладу — небагато нашого досвіду від інженера за даними Даніяр Белходжаєв.
дозволяє масштабування шляхом додавання нових вузлів кластер. Необхідність справлятися з піковою кількістю запитів може призвести до надмірного резервування вузлів (over-provisioning). Паралельне масштабування (Concurrency Scaling), на відміну додавання нових вузлів, збільшує обчислювальну потужність за необхідності.
Паралельне масштабування Amazon Redshift дає кластерам Redshift додаткові потужності для обробки пікової кількості запитів. Воно працює шляхом перенесення запитів на нові «паралельні» кластери у фоновому режимі. Запити маршрутизуються на основі конфігурації та правил WLM.
Ціноутворення для паралельного масштабування ґрунтується на кредитній моделі з нормою безкоштовного користування. Понад норму безкоштовних кредитів оплата ґрунтується на часі, коли кластер паралельного масштабування опрацьовує запити.
Автор протестував паралельне масштабування на одному із внутрішніх кластерів. У цьому посту він розповість про результати тестування та дасть поради про те, як розпочати роботу.
Вимоги до кластера
Для використання паралельного масштабування кластер Amazon Redshift повинен відповідати таким вимогам:
- платформа: EC2-VPC;
- Тип вузла: dc2.8xlarge, ds2.8xlarge, dc2.large або ds2.xlarge;
- Число вузлів: від 2 до 32 (кластери з одним вузлом не підтримуються).
Допустимі типи запитів
Паралельне масштабування не підходить для всіх типів запитів. У першій версії воно опрацьовує лише запити на читання, які задовольняють трьом умовам:
— SELECT-запити лише для читання (хоча планується більше типів);
- Запит не посилається на таблицю зі стилем сортування INTERLEAVED;
- Запит не використовує Amazon Redshift Spectrum для посилання на зовнішні таблиці.
Для маршрутизації до кластера паралельного масштабування запит повинен стати в чергу. Крім того, запити, які підходять для черги , не виконуватимуться в кластерах паралельного масштабування.
Черги та SQA вимагають правильного налаштування . Ми рекомендуємо спочатку оптимізувати ваш WLM – це зменшить потребу в паралельному масштабуванні. І це важливо, тому що паралельне масштабування здійснюється безкоштовно лише протягом певної кількості годин. AWS стверджує, що паралельне масштабування буде безкоштовним для 97% клієнтів, що підводить нас до ціноутворення.
Вартість паралельного масштабування
Для паралельного масштабування AWS пропонує кредитну модель. Кожен активний кластер щогодини накопичує кредити, до однієї години безкоштовних кредитів паралельного масштабування на день.
Ви сплачуєте лише тоді, коли використання кластерів паралельного масштабування перевищує суму кредитів, які ви отримали.
Вартість розраховується за посекундним тарифом на вимогу для паралельного кластера, який використовується понад безкоштовну норму. Плата здійснюється тільки за час виконання ваших запитів, з мінімальною оплатою за одну хвилину, щоразу при активації кластера паралельного масштабування. Посекундний тариф на вимогу обчислюється на підставі загальних принципів ціноутворення , тобто залежить від типу вузла та кількості вузлів у вашому кластері.
Запуск паралельного масштабування
Паралельне масштабування запускається для кожної черги WLM. Перейдіть в консоль AWS Redshift і оберіть «Workload Management» у лівому меню навігації. Виберіть групу параметрів WLM кластера в наступному меню, що розкривається.
Ви побачите новий стовпець під назвою "Concurrency Scaling Mode" (Режим паралельного масштабування) поряд з кожною чергою. За замовчуванням встановлено значення "Вимкнено". Натисніть "Змінити", і ви зможете змінити налаштування для кожної черги.
Конфігурація
Паралельне масштабування працює шляхом надсилання відповідних запитів до нових виділених кластерів. Нові кластери мають той самий розмір (тип і кількість вузлів), як і основний кластер.
Кількість кластерів, що використовуються для паралельного масштабування, за замовчуванням дорівнює одному (1) з можливістю налаштування до десяти (10) кластерів.
Загальна кількість кластерів для паралельного масштабування може бути встановлена параметром max_concurrency_scaling_clusters. Збільшення цього параметра забезпечує додаткові резервні кластери.
моніторинг
У консолі AWS Redshift є кілька додаткових графіків. Діаграма Max Configured Concurrency Scaling Clusters відображає значення max_concurrency_scaling_clusters з часом.
Кількість кластерів активного масштабування відображається в інтерфейсі користувача в розділі «Concurrency Scaling Activity»:
У вкладці «Запити» є стовпець, який показує, чи виконувався запит в основному кластері або в кластері паралельного масштабування:
Незалежно від того, чи виконувався конкретний запит в основному кластері або через кластер паралельного масштабування, він зберігається в stl_query.concurrency_scaling_status.
Значення 1 говорить про те, що запит виконувався в кластері паралельного масштабування, інші значення говорять про те, що він виконувався в основному кластері.
Приклад:
Інформація про паралельне масштабування також зберігається в деяких інших таблицях та уявленнях (views), наприклад, SVCS_CONCURRENCY_SCALING_USAGE. Крім того, є ряд catalog таблиць, в яких зберігається інформація про паралельне масштабування.
Результати
Автори запустили паралельне масштабування для однієї черги у внутрішньому кластері приблизно о 18:30:00 за Грінвічем 29.03.2019 р. Змінили параметр max_concurrency_scaling_clusters на 3 приблизно о 20:30:00 29.03.2019 р.
Щоб змоделювати чергу запитів, та зменшили кількість слотів для цієї черги з 15 до 5.
Нижче наведена діаграма дешборда intermix.io, що показує кількість запитів, що виконуються і стоять у черзі після зменшення кількості слотів.
Ми бачимо, що час очікування запитів у черзі збільшився, при цьому максимальний час становив понад 5 хвилин.
Ось відповідна інформація з консолі AWS про те, що сталося за цей час:
Redshift запустив три (3) кластери паралельного масштабування відповідно до налаштування. Схоже, що ці кластери були використані не повністю, навіть незважаючи на те, що багато запитів у нашому кластері стояли в черзі.
Графік використання корелює з графіком активності масштабування:
За кілька годин автори перевірили чергу, і, схоже, 6 запитів виконували з паралельним масштабуванням. Також вибірково перевірили два запити через інтерфейс користувача. Не перевіряли, як користуватися цими значеннями, коли активні відразу кілька паралельних кластерів.
Висновки
Паралельне масштабування може зменшити час перебування у черзі запитів під час пікових навантажень.
За результатами базового тесту вийшло, що ситуація із завантаженням запитів частково покращала. Однак саме собою паралельне масштабування не вирішило всіх проблем з паралелізмом.
Це пов'язано з обмеженнями типу запитів, які можуть використовувати паралельне масштабування. Наприклад, у авторів є багато таблиць з ключами сортування, що чергуються (interleaved), і велика частина нашого робочого навантаження - це запис.
Хоча паралельне масштабування та не універсальне рішення у налаштуванні WLM, у будь-якому випадку користуватися цією функцією просто і зрозуміло.
Тому автор рекомендує використовувати її для ваших WLM-черг. Почніть з одного паралельного кластера і відстежуйте пікове навантаження через консоль, щоб визначити, чи повністю використовуються нові кластери.
У міру того, як AWS додаватиме підтримку додаткових типів запитів і таблиць, паралельне масштабування поступово має ставати все більш ефективним.
Коментар від Белходжаєва Даніяра, інженера за даними Skyeng
Ми в Skyeng теж відразу звернули увагу на можливість паралельного масштабування, що з'явилася.
Функціонал дуже привабливий, особливо з огляду на те, що за оцінкою AWS більшості користувачів навіть не доведеться за це доплачувати.Так вийшло, що в середині квітня ми мали незвичайний шквал запитів до кластера Redshift. У цей період ми часто вдавалися до допомоги Concurrency Scaling, іноді додатковий кластер працював по 24 години на добу без упину.
Це дозволило якщо не повністю вирішити проблему з чергами, то, як мінімум, зробити ситуацію прийнятною.
Наші спостереження багато в чому збігаються із враженням хлопців із intermix.io.
Ми також помітили, що незважаючи на наявність запитів, що чекають у черзі, не всі запити відразу перенаправлялися на паралельний кластер. Мабуть, це відбувається через те, що паралельний кластер все-таки вимагає часу для старту. Як результат, під час короткочасних пікових навантажень у нас все одно утворюються невеликі черги і встигають спрацьовувати відповідні аларми.
Позбувшись аномальних навантажень у квітні, ми, як і передбачав AWS, вийшли в режим епізодичного використання — в рамках безкоштовної норми.
Відстежувати витрати на паралельне масштабування можна в AWS Cost Explorer. Потрібно вибрати Service — Redshift, Usage Type — CS, наприклад USW2-CS:dc2.large.Детально про ціни російською мовою можна почитати
Джерело: habr.com