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

Фактично це продовження давно розпочатої теми про оптимізацію коду, а саме про оптимізацію php. Однак цього разу мова піде про більш глобальні питання. А саме про “масштабованість” написаних Вами і не тільки програмних продуктів.

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

Визначення

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

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

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

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

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

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

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

Є декілька загальних рекомендацій, щодо побудови таких систем. Буду перераховувати попарно з поясненнями:

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

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

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

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

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

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

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

Висновки

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

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