Страх і ненависть в окремо взятому стартапі. Частина 2 — Ненависть

Як сисадмін, я раджу взяти найдорожчий выделеный сервер без підтримки, RAID, великий storage для особливих файлів, шаблон для сайту яскравіше, і закупити AdWords принаймні на два дні.
попередній частині я описав загальну архітектуру програми, та деякі особливості інфраструктури. Сьогодні я б хотів зупинитися на деяких пунктах детальніше і розповісти, які проблеми були створені буквально на рівному місці. Паралельно розповім, чому були вжиті деякі, прямо скажемо, сумнівні рішення (з розмов з попередником).
Відсутність моніторингу
Платформа не мониторилась від слова зовсім. При цьому користувачі постійно скаржилися на гальма деяких частин сайту. Попередник вирішував проблему горизонтальним масштабом — раз в 2-3 місяці просто докупался ще один сервер і додавався в конфіг Nginx на балансировщике. Забігаючи вперед, скажу, що після того, як я почав знімати статистику використання потужностей — виявилося, що 90% інфраструктури тупо простоює. Гроші на оренду серверів витрачалися даремно. Причина такого підходу — «Ну, якщо чото працювати не буде — клієнти скажуть, навіщо ще один демон крутить».
Gentoo в продакшені
За роки роботи в індустрії для мене особисто всі дистрибутиви злилися в один. Якщо раніше при плануванні інфраструктури я зав'язувався на якийсь один дистрибутив просто тому що у мене з ним більше досвіду (або тому що захотілося спробувати новеньке), то тепер я частіше керуються міркуваннями вартості підтримки того чи іншого рішення в конкретній ситуації.
У проекті, який я описую зараз мій попередник десь прочитав, що Gentoo відмінно масштабується на десятки серверів, і один раз зібравши пакет-його можна просто rsync'ом розливати на інші машини. Теорія красива (і я навіть бачив таке остаточне рішення-для адмінських робочих станцій), на практиці ж — синхронізувати дерево портежей хоча б раз в тиждень ніхто не здогадався, що з плином часу зробило практично нереальним установку пакетів. Про оновлення безпеки мови взагалі не було. За пару тижнів я привів все в божеський вид, і задумався про переїзд на бінарний дистрибутив. Витрачати кожен місяць по кілька днів на оновлення і перезбирання зворотних залежностей я не хотів (привіт, брокер ZeroMQ реалізоване на Ruby через libffi). Причина використання Gentoo- «Ну дивись як швидко можна за допомогою моїх скриптів розкачати новий сервер і додати його в інфраструктуру».
Брокер
Раз вже заговорив про брокер — розповім, які з ним були проблеми. Моніторинг стану. Його не було (точніше, код брокера були заглушки для функцій
ping_service()
,
get_service_state()
,
get_stats()
і подібним). Єдина реализованая функція
ping_broker()
— працювала тільки з одного сервісу, і її можна було викликати з Rails консолі:
ServiceName.ping_broker()
. Всі. Сервіси не знали, коли брокер лежить. Сервіси не вміли перереєструватися у разі перезапуску брокера. Брокер був stateless, відповідно «забував» про все сервіси після рестарту, треба було руками ходити по серверам, підключатися до screen'ам і рестартовать всі сервіси та їх обробники подій. Ну і як вишенька на торті — брокер відповідав за призначення портів для сервісу. Тобто, в налаштуваннях брокера задавався пул min_port:max_port, сервіс при запуску питав у брокера, на який порт йому биндиться, і намагався почати слухати на цьому порту. Якщо брокер працює на одному сервері, а сервіс запускається на іншому — порт, який видав брокер вже може бути зайняти і сервіс просто не стартане з помилкою «Address already in use». Моніторити сервіси з такою схемою роботи не представлялося можливим. Мета використання цього брокера — розподілити навантаження на сервер і мати можливість крутити кожен сервіс на своєму сервері — досягнуто так і не було.
Synctool
Кому цікаво — посилання на проект: http://walterdejong.github.io/synctool/. В принципі — воно мало право на життя. Але по-перше — гора bash-скриптів + rsync — це не управління конфігураціями, по-друге я тоді якраз познайомився з Ansible, який виявився сильно гнучкіше. Тут особливо навіть сказати нічого, просто за пару днів переніс всю логіку з synctool в Ansible і забув як страшний сон. Причини використання synctool — «Ну я подивився на Puppet, мені здалося складно, а в synctool можна все скриптами вирішити». Про Absible/Chef чоловік просто не знав.
Falcon
першої частини я згадав falcon, але забув дати посилання на нього, виправляюся: http://www.falconpl.org/. Помісь процедурного і функціонального скриптової МП з підтримкою багатопоточності і власної віртуальної машиною. В принципі — потужна і цікава штука з низьким порогом входу, але навіщо це було використовувати тільки для того, щоб виконувати
ssh dba@db01 "echo 'SELECT stuff FROM table' | psql -U postgres app_db"
— залишилося за гранню мого розуміння. Питання «Нахера це тут?» щодо falcon так і не був мною поставлено.
Поділ production/development оточень в коді
Останній пункт на сьогодні. У Rails є дивовижний механізм, який покриває 99% випадків, коли потрібно по-різному налаштувати додаток для продакшену і для розробки. Цей механізм використаний не був, і в коді були прибиті цвяхами імена хостів для сервісів, адреса Redis, адреса і порт бази даних, і доменне ім'я програми. Якось мені довелося мігрувати Redis і базу даних на інші сервера — платформа лежала більше доби, поки я выгрепывал всі такі місця. Причини — модель розробки, і не дуже висока кваліфікація програміста. Проект писався практично «на коліні» спочатку, нові фічі додавалися і додавалися, рефакторинг ніхто не робив, і в якийсь момент це перетворилося в те, що на картинці:
image
В останній частині я розповім про те, як платформа виглядає зараз, які технології використовуються і чому, як використання відповідних під завдання інструментів допомагає економити гроші, і чому сисадмін не повинен кодити, а програміст — админить.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.