Плануючи нову тему в Apache Kafka, питання про кількість партицій неминуче виникає одним із перших. Команда Confluent Developer пропонує підходити до цього не інтуїтивно, а через прості розрахунки, які враховують пропускну здатність, паралелізм споживачів та майбутнє зростання навантаження.
Пропускна здатність: рахуємо від продюсерів і споживачів
Відправна точка — цільова пропускна здатність теми: скільки даних на секунду система має стабільно приймати й віддавати.
Далі потрібні два виміряні показники:
- Пропускна здатність продюсера на одну партицію
- Пропускна здатність споживача на одну партицію
Після цього обчислюється, скільки партицій потрібно, щоб:
- продюсери встигали записувати дані з потрібною швидкістю;
- споживачі встигали їх обробляти.
Результат для продюсерів і для споживачів може відрізнятися, тож береться більше з двох значень. Саме воно визначає мінімальну кількість партицій, яка дозволить обом сторонам «не захлинатися» від навантаження.
Обмеження паралелізму споживачів
Kafka накладає важливе обмеження: в межах однієї групи споживачів на одну партицію може працювати не більше одного інстансу споживача. Це означає, що кількість партицій напряму визначає максимальний рівень паралелізму обробки.
Якщо, наприклад, планується запускати 12 інстансів сервісу, які споживають одну й ту саму тему в складі однієї consumer group, то:
- потрібно щонайменше 12 партицій,
- інакше частина інстансів простоюватиме без призначених партицій.
Тож при розрахунку варто окремо враховувати не лише пропускну здатність, а й бажаний рівень паралельної обробки.
Ключі, порядок і ризики зміни кількості партицій
Ще один фактор — ключі повідомлень і порядок. Якщо використовується ключування і важливий порядок подій для певного ключа, збільшення кількості партицій у майбутньому може призвести до:
- перерозподілу ключів між партиціями;
- зміни того, де саме опиняються повідомлення з конкретним ключем.
Це потенційно порушує очікування щодо впорядкованості для ключа, якщо логіка системи на неї спирається. Тому рішення про зміну кількості партицій пізніше варто приймати дуже обережно, особливо в системах, де порядок критичний.
Чому не варто «роздувати» кількість партицій
Поширена порада — трохи перепартиціонувати тему, орієнтуючись на майбутнє зростання навантаження. Але ключове слово тут — «трохи».
Надмірна кількість партицій має низку побічних ефектів:
- Більше відкритих файлових дескрипторів на брокер
- Довший failover і періоди недоступності: час простою при збоях зростає приблизно пропорційно кількості партицій
- Додаткова затримка реплікації, коли брокер змушений обслуговувати велику кількість партицій
Тобто більше партицій дійсно може підвищити пропускну здатність, але водночас ускладнює роботу кластера та погіршує поведінку при збоях.
Оптимальна стратегія — врахувати:
- поточну цільову пропускну здатність;
- потрібний паралелізм споживачів;
- прогнозоване зростання навантаження,
а потім обережно округлити в більший бік, без «про всяк випадок» у десятки разів.
Джерело
YouTube: https://www.youtube.com/watch?v=4eZWk7yY26E