GrAndSE's blog

Думки про масштабованість

Перший варіант цієї статті, я написав для попереднього блога. Однак поглянувши на той варіант вирішив створити новий її варіант. З двох причин:

1. Перший варіант далеко не ідеальний.

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

Визначення

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

Здавалося б, тут все зрозуміло: більше ресурсів, більша швидкодія. Однак, щоб це й справді було так, потрібно знати, яких саме ресурсів не вистачає системі для підвищення швидкодії. Так би мовити, знайти "вузьке місце". В одному випадку не вистачає пам'яті, в іншому - процесорного часу, а в третьому - швидкості читання з диску. Зрозуміло, що можна підняти всю систему до "найвищого рівня", однак "вузьке" місце не дасть змогу системі використати весь потенціал, тобто витрати на оновлення обчислювальних ресурсів будуть невиправданими.

Інша проблема: на різних етапах виконання різні "вузькі місця". Інакше кажучи, кожний етап виконання може потребувати різні ресурси.

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

Зрозуміло, що обслуговування паралельно виконуваних завдань, та передача контексту виконання між ними (тобто поділ процесорного часу, додаткові ресурси на створення окремої нитки виконання) можуть звести всі переваги розпаралелювання на нівець.

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

Наведу приклад. Нещодавно довелось зіштовхнутись з системою пошуку в БД. Запит до БД на невеличких об'ємах даних виконувався за прийнятний час (виконання запиту та коду займало менше часу ніж завантаження та відображення сторінки браузером, тобто непомітним для користувача). Однак при збільшенні кількості записів у таблиці (зараз там близько 20 тис. записів, а теоретично може бути і в десятеро більше) швидкодія різко впала. Причому вузьким місцем був саме запит до БД, що виконувався близько 10 секунд. При "теоретичній максимальній заповненості" (тобто більше 100 тис. записів) виконання запиту перевищувало максимальний час виконання php скрипту і результату не приходило від серверу жодного. Ось такий жах перейшов мені у спадок. А вирішилось все досить легко: полегшив пошуковий запит, відкинувши непотрібні його частини, і в результаті швидкість його виконання зросла для 20 тис. записів більше ніж у 10 разів.

Вирішення проблеми шляхом нарощування потужностей виділеного сервера (себто перехід на новий тариф) обійшлось би в додаткові 30 євро щомісячно та могло принести більше ускладнень ніж оптимізація цього запиту.

Кроки до продуктів, здатних до масштабування

Наведу ряд рекомендацій у загальній формі. Перша частина рекомендацій буде стосуватись написаного програмного коду, тобто програмістської роботи.

- Оптимізація кожного елементу системи, з метою досягнення максимальної ефективності на кожному етапі виконання процесу.

- Пошук елементів системи (окремих, чи то цілих груп), що не дають змогу повноцінно розгорнутися системі в цілому та усунення проблеми.

Перший варіант є досить добрим. Однак як відомо жадібний алгоритм не завжди дає оптимальний результат. І система, кожен елемент якої здавалося б працює найкращим чином може працювати гірше ніж це могло б бути. Чому?

Проблеми виникають під час взаємодії елементів системи між собою. І це теж потрібно враховувати, або на етапі проектування (що дешевше і краще), чи то займатись цим потім. Тут вже в силу вступає друга рекомендація. Сюди входить і розпаралелювання, і кешування даних, і архітектура системи, які мають стояти на фундаменті доброго володіння тими інструментами, що використовуються в розробці. Не слід забувати, що прагнення писати кожен елемент системи оптимальним чином - здорова риса, яка може врятувати в подальшому не одну годину.

Перейдемо до апаратних методів досягнення масштабованості.

-Нарощування апаратних можливостей.

-Розбиття системи на окремі частини, що будуть функціонувати окремо одна від одної, на різних комп'ютерах.

Перший варіант досить непоганий, однак на певному етапі починається цінова перевага другого варіанту: Легше придбати окремий сервер для БД, окрему машину для зберігання статичних даних, а одну машину поставити як інтерпретатор java/php, а над усім цим поставити якийсь proxy, що об'єднає їх в єдину систему, аніж зібрати один сервер, який би міг все це виконувати так само швидко як ці чотири машини у зв'язці. До того ж тут є непогана можливість для пошуку і усунення слабких місць системи шляхом покращення апаратних ресурсів, що відповідають саме цьому ланцюжку.

Так до речі і працює Google: за їх словами, в них немає жодного "суперкомп'ютера", лише великі зали з звичайнісінькими машинами, що доступні кожному.

З точки зору безпеки, надійності як у першого так і у другого варіанту є переваги. Для випадку однієї потужної машини виключається втрата зв'язку між окремими елементами системи. Однак при виникненні проблем на потужному сервері вся система перестає функціонувати, і резервна система має одразу ж відтворювати всі функції системи. В другому ж випадку, необхідно розробляти резервну підсистему для кожного елементу.

Висновки

Для повних висновків ще зарано. Це лише поверхневий огляд. В мене вже є багатенько ідей стосовно розвитку окремих деталей побудови якісних програмних продуктів. Ще є і декілька рекомендацій стосовно написання php коду. Є думки стосовно кешування. Хочу написати про ті методи проектування, якими я користуюсь. А про що б в цьому плані хотілось прочитати Вам?

Сподіваюсь, не дуже втомились читати. Дякую за увагу!