Всьому свій час

image
Банки.ру — проект з 10-річною історією. В різні часи banki.ru випробовували різні навантаження. Портал перебудовувався під нові вимоги як логічно, так і технологічно, що ми міняли в авральному режимі, щось — еволюційним шляхом. Зараз середня відвідуваність приблизно 2 мільйони перегляду сторінок, тобто проект вже не маленький, але ще й не зовсім великий.
Ця стаття — розшифровка доповіді Романа Ивлиева (CIO Banki.ru) на навчальній конференції HighLoad++ Junior, яка пройшла кілька місяців тому в Москві в рамках фестивалю «Російські інтернет-технології».
У цій статті ми хочемо поговорити про оптимізацію, її своєчасності, і про субоптимизации, про те, що далеко не завжди кращі практики розробки навантажених систем йдуть на користь бізнесу.
Подивимося приклади і пошукаємо відповіді на питання:
  1. Настільки ваш highload — highload?
  2. Вважати хабрэффект приводом для впровадження високих технологій?
  3. «Милиця» або «високотехнологічне рішення» — що вибрати? Плюси і мінуси.
  4. Як вибрати момент для початку нової ери? Є критерії, коли має сенс починати оптимізувати ваш додаток і впроваджувати круті штуки «по-дорослому».
  5. Як можна використати «список Буніна» для досягнення дуже непоганих показників, і всі пункти реально потрібні вам?
  6. Як працювати з технічним боргом, щоб він не заростав мохом?
На закінчення Роман Ивлиев розповість про кілька прикладів з життя banki.ru в частині заміни технологічних рішень в області високих навантажень, і що з цього вийшло.

Всьому свій час
Роман Ивлиев (Банки.ру)
Я тут стою перед вами, тому що я вже 15 років всім цим ЦЕ шних неподобством займаюся, за досить довгий час пройшов шлях від інженера до начальника.
Попрацював в різних відомих у своїх колах компаніях:



А це про Банки.ру:



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

Я поясню, звідки взялися такі цифри і, взагалі, навіщо вони тут. Ніякої реклами, це те, що у нас насправді є. Трафік ні до чого, але тим не менш, ми в добу обслуговуємо приблизно півмільйона людей, тобто це не число запитів, це число унікальних людей, число запитів, природно, більше   воно там до двох мільйонів, може бути, навіть до трьох, а коли бувають «чудеса» з валютою або відкликають ліцензію у якогось класного банку, у нас бувають і цифри, які зашкалюють. У 2014-му році, коли Центробанк відпустив долар, навантаження на сервіс курсу валют виросла в один день у 85 разів, тобто вчора у нас було 10 запитів, а потім було 850 запитів. В секунду, природно.

Про що я хотів розповісти?



Про те, як розвиваються проекти, в принципі, тобто про те, що, можливо, те, що ви вважаєте HighLoad'ом — це зовсім не HighLoad. Про хабрэффект — напевно всі чули про це неподобство і що це таке. Про те, як з усім цим можна боротися методом встромляння «милиць» або високотехнологічних рішень, і коли ж все-таки настає розуміння, що треба все кинути і починати робити здорово, як роблять дорослі хлопці з крутих компаній. І, за великим рахунком, що робити з усім, що залишається в процесі цього неподобства.



Дуже важливо: все, що я вам зараз розповім, перед тим, як ви будете це пробувати у себе, спочатку спробуйте у сусіда, тому що те, що я розповім — це мій досвід, і він зовсім не обов'язково корелює з вашим досвідом. Більш того, якісь речі, які я розповім, взагалі, напевно, краще не робити ніколи. Але тим не менш…



Все-таки HighLoad або не HighLoad? Тобто так чи ваш проект навантажений, і є він, взагалі, навантаженим?



ось цих питань можна зрозуміти, чи є ваш проект навантаженим чи не є? Наприклад, за кількістю запитів, числа серверів, числа записів в базі даних, можна зрозуміти, навантажений проект або не навантажений?

насправді, зрозуміти за ось цим конкретних питань досить складно, тому що дослідження повинне бути комплексним. Якщо у вас, наприклад, 100 тис. серверів, які обслуговують 100 тис. запитів — по одному на сервер, то, напевно, це все-таки не HighLoad, а якщо у вас трейдингова система, яка одним сервером обслуговує 100 тис. запитів на секунду, напевно, варто задуматися.



А ось з таких питань можна зрозуміти HighLoad або не HighLoad? Тобто справляються ваші сервера з навантаженням, є необхідність чого-то з цим робити або, наприклад, можна просто вічний цикл прибрати якийсь, і все у вашому житті стане добре? Або, взагалі, треба думати, наприклад, як прикрутити Tarantool до того місця, до якого ви ще не прикручували? Можна з таких питань зрозуміти?

Це вже, насправді, ближче до істини, тому що в принципі HighLoad — це коли у вас щось перестає справлятися з тими завданнями, які у вас вирішуються. Якщо ваша маленька VPS раптово почала дохнути, то ви, в принципі, вже приїхали в HighLoad. HighLoad для себе. Тому що немає такого розуміння, що, наприклад, 10 запитів в секунду — це не HighLoad, 100 запитів в секунду — це HighLoad. Тому я далі буду говорити про ситуацію, коли ви приїжджаєте із своїм поточним рішенням в той стан, коли цей стан починає, як мінімум, деградувати, а як максимум — просто перестає працювати.



Один з таких прикладів, коли вам стає не дуже добре — це хабраэффект. Напевно ви всі про нього чули. Для тих, хто не чув — це коли у вас раптово звідкись з'являється навантаження, причому ступінь раптовості дійсно буває дуже дивовижна. У свій час, коли я працював в «Касперському», хтось повісив скріншот, намальований в paint brash'е, про те, що Головну сторінку «Касперського» задефейсили, і там зараз гола жінка. І   о диво! — трафік виріс в хвилини, просто до якихось космічних висот, тому що всім відомо, що цим людством рухає. І в тому числі відповідного типу картинки.



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

Це може бути процес, який ви можете вгадати, тобто, наприклад, коли ваші рекламщики беруть і роблять розсилку якусь дуже круту про те, що у вас сталося диво і у вашому інтернет-магазині знижка 90% на Iphone 6, умовно. Далі це все потрапляє в якусь соц.сіточку типу Вконтактика, там народ починає скажено репостить, і починається лавиноподібний процес   халява теж рухає людьми, тому до вас приходить дуже багато людей. Вони приходять. Перші 10 чоловік завалюють вам ваше рішення, решта 100 осіб матюкають вас проклинають, більше ніколи не приходять. Тим не менш, факт є факт.

А є випадковий процес, коли, наприклад, ваш колега або ще хтось написав якусь вдалу статтю на Хабре, і її так вдало засмоктало в індекс. Загалом, звідки взялися люди. Або підступи конкурентів — це насправді DDoS банальний, тобто ви можете потрапити в ситуацію, що це не хабраэффект, а DDoS.

Тим не менш, є це приводом для того, щоб приймати рішення, що ви нарешті стали HighLoad? Насправді — ні фіга. Тому що хабраэффект у вас через 20 хвилин закінчиться, відлягло. І в це «відлягло» ви можете свято вірити далі, тому що, швидше за все, так і станеться. Я це знаю, тому що у 2014-му році нас трусило три дні — три дні люди цікавилися курсами валют, т. к. долар був 30-40 руб., потім став 90, а в якийсь момент більше 100. Ось нас три дні поколбасило, потім відпустило. Чи було це для нас ознакою того, що щось сталося? Так, було.

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

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

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



Що зламалося першим? Перше, що приходить в голову — розібратися, а що ж все-таки відвалилося? Чому стався зростання? Є шанси, що це повториться?

Це дуже важливо. Якщо ви виходите на якийсь наступний рівень, то це потрібно розуміти (знову ж таки, як це зрозуміти   про це трохи пізніше). Тим не менше, якщо ви зрозуміли, що це система, то це вже привід для того, щоб замислитися. До того. Це більше для вашої інформації.

Звичайно, в ситуації, коли ви валяєтеся як дохла риба на сонці, непогано б чогось спробувати зробити для того, щоб людям стало краще, і вони почали вас якимось чином чути, бачити і т. д. Для цього є «милиці».



«Милиці» — це не засіб пересування, це спосіб змусити ваше рішення працювати.

Є два варіанти «милиць»: перший «милиця» звичайний «по-швиденькому», другий — високотехнологічний «милиця». Найчастіше це одне і те ж, і багато, коли вирішують свої завдання, дуже соромляться говорити, що вони вставили «милиця». Чомусь вважається, що це погано. Насправді це ні фіга не погано. Я вам чесно скажу — це навіть добре.



Ви можете швидко вирішити завдання. Так, це буде не завжди просто, так, це буде не завжди спритно — це очевидно. Більш того, швидше за все, ви на наступний день подивіться на це рішення, прозрієте і пообіцяєте собі більше ніколи так не робити, але, тим не менш, за фактом ви вирішуєте задачу — ви знаходите слабке місце, це слабке місце забирається, і люди — ваші клієнти– вони починають отримувати. Нехай не всі, але їх буде більше.

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

І саме головне — пам'ятати при цьому, що ви тепер стали повинні. Повинні самим собі, повинні системі, повинні людям — всім повинні, в загальному, за великим рахунком, по колу ви всім повинні.



Якщо ж технологічне рішення… Що я маю на увазі, коли кажу про технологічне рішення? Це коли те, що ви робите, ви робите, по суті, більш усвідомлено, чи що. Це якесь проектування, розуміння, усвідомлення, прикидки на майбутнє — як це все буде працювати або не буде працювати. Це той же самий «милиця», тільки вставлений «по науці», тобто по процесам — ви заклали задачку, задачка потрапила в планування, ви це запланували, зробили, оцінили і т. д.

Найчастіше це буде зроблено добре, добре, акуратно, але в ситуації, коли вас накрило, ви нічого з цим зробити не зможете, у вас просто немає на це часу. Буває така ситуація, як у нас, наприклад. У свій час, коли теж приплохело, вкрутили Varnish по-швиденькому на продакшн і, в принципі, там його потім і залишили, тільки донастроили, тому що в моменті, коли прикрутили просто так, він працював не дуже добре. Зокрема, він кешувати починав міста, з яких йдуть люди, банери, які люди бачать, якісь особисті повідомлення, а в кінцевому підсумку він закэшировал 404-шу помилку чиюсь і всім дружно роздавав 404-шу помилку, хвилин 5, напевно. Але швидко, знову ж таки, зрозуміли, що щось тут не те. Потім ми все це довели до розуму, доконфигурировали і т. д.



до Речі, ось він, один з алгоритмів. Дуже важливий пункт третій — він часто поширений, особливо в невеликих компаніях, коли є такий шеф driven development, коли вдається шеф, і каже: «Мені тут сказали, що ось так треба зробити». Перше, що приходить в голову: «Але це шеф, ялинки-палиці, не можна образити людину». Ось тоді народжуються «милиці», навіть не технологічно, а просто лише б він зник з очей, а потім вже якось вечерком доробимо.

Ось алгоритм. Насправді алгоритм класний, але він не працює, тому що в підсумку ви, виходить, повинні ще і шефу — до питання про борги і «милицях». Самі розумієте, він вам винен грошей, а тепер ви йому повинні, тобто недобре.



Коли ж все-таки має сенс починати щось робити для того, щоб уникати таких ситуацій? Тобто чи є якийсь алгоритм, є точка неповернення, коли ви розумієте, що всі? Загалом, коли прийшов час для того, щоб все-таки взятися за розум, перестати вважати, що у тебе штанці, і згадати про те, що повна система «милиць», і що з цим будемо робити?



Єдиний спосіб пошукати — це моніторинг. Тобто як зрозуміти? Зрозуміти насправді буде складно, я зараз покажу, чому. Але по факту, якщо у вас немає моніторингу, якщо у вас є тільки крик з сусідньої кімнати, то навряд чи ви за такими критеріями зрозумієте. Але, знову ж таки, хто волає? Якщо волає той хлопець з третього пункту, то швидше за все пора. До тих пір, поки ви не розумієте, що з вашою системою відбувається, шансів зрозуміти, що їй стає гірше, насправді немає.

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

Ось, з приводу «заздалегідь».



До питання про прогнозування. Чисто теоретично це можна було, якщо б так був влаштований світ, і не було б проблем, взагалі. Тобто якщо у вас 10% CPU (CPU тут для прикладу), які генерує 10 користувачів, 20% — 20, 30% — 30 і т. д. до 1000 умовно, якщо у вас 10-ти ядерних. Насправді так майже ніколи не буває. Тобто, напевно, буває, але я не зустрічав. Частіше буває, коли у вас 100 користувачів — це 10% CPU, а 200 користувачів — це вже, на жаль, пипец, припливли. Буває так, що і 200 користувачів — це нічого, але при цьому ви сідаєте в іншому місці. Тому є, умовно кажучи, 4-5 точок у вашій системі, які потрібно моніторити завжди.

Моніторинг — це CPU, пам'ять, канал, диск і кількість запитів до бази даних, тому що база даних теж не гумова, і якщо ви примудрилися на додатку зробити кількість підключень більше, ніж можливо в базі даних, вас це не торкнеться рівно до тих пір, поки люди, які прийшли, їх не отожрут.

Буває помилка конфігурації. Найпоширеніша причина того, що щось йде не так — це помилка конфігурації. Тобто беруть, наприклад, postgress з коробки, ставлять його, він працює. На тестовій машині працює, на 5-ти користувачів працює, на 10-ти працює, на 20-ти — не працює. Така ж петрушка відбувається практично з усім, т. е. якщо ви запрограмували своє рішення, і воно у вас шикарно працює, взагалі не обов'язково, що воно буде працювати далі. Тому єдиний спосіб тут щось зробити — це проводити періодичні дослідження, проводити періодичні зрізи цих порогових значень, грубо кажучи, зловити момент, коли ваша подається навантаження починає змінювати якусь криву. У вас є, наприклад, навантаження на CPU, вона майже лінійна. Ви починаєте подавати, вона починає трохи відхилятися, в якийсь момент вона відхилиться ось так от, чи не відхилиться, але при цьому відхилиться в іншому місці… Тому, якщо взяти який-небудь Zabbix, то можна на один екран вивести п'ять мониторчиков, на якому видно кожен з кожним. Краще виводити їх у стовпчик. Чому в стовпчик? Тому що у вас чітко буде видно, що відбувається з усіма параметрами при зростанні навантаження.



Робиться це дуже просто — мишкою клац-клац, в Zabbix — там ніяких проблем. Якщо у вас цього ще немає, моя порада — прикрутіть. У нас такі телики висять по дорозі в туалет — це те місце, повз якого проходить кожен інженер протягом дня і не по одному разу. Він приходить повз нього на роботу і йде повз нього з роботи. Так склалося, що шлях прокладений. І, проходячи повз, він дивиться. Там висять ці графіки в стовпчик — три мониторчика, і все видно чітко, навіть плазму не треба.

у результаті, якщо У вас виникає хоч найменший побоювання, що щось піде не так при наступному зростанні навантаженні, ви зверніть на це увагу тих людей, які зможуть вам допомогти. Або це тестери, якщо у вас є такі люди, або візьміть JMeter самий примітивний, напишіть на ньому дві строчки коду, і він вам покаже, що буде далі. Тобто ситуації, коли у вас пішло відхилення, якщо воно йде-йде і не падає — це не якесь там а ля «ви сьогодні невдало закоммитили», це теж причина багатьох хабраэффектов. Ви чого там напрограммировали таке, що все, що працювало, раптом перестало працювати. Зате це класна відмазка, коли приходять і кажуть: «Чого це ми валяємося?» — «Ну, це користувачі прийшли, дивись, там багато», а сам швидко-швидко виправляєш. Тому що люди з вулиці, я маю на увазі не з технічного підрозділу, звідки вони знають, що там сталося. Вони вам в перший раз повірять.



Можна пошукати якісь закономірності в поведінці? Звичайно, можна. Але кожна закономірність — вона дуже умовна. Або вам потрібно реально в це врубаться конкретно, витрачати силу-силенну часу, розуміти, як веде себе ваше залізо. Потім ви раптом зрозумієте, що залізо у вас вже інше… Hetzner — чули про такого провайдера німецької? А чи чули ви, з чого зроблені його дата-центри? З десктопів всяких і б/у серверів, коротше, з купи всякої незрозумілою фігні. І в який момент часу ваше рішення працює на якому залозі, ви не дізнаєтесь ніколи, бо іноді складається враження, що вони навіть не знають, де у який момент у них працює. Тим не менше, коли ви побачите, що у вас щось шатануло, краще все-таки протикати це далі, дослідити, тому що реально, навіть на наших навантаженнях, коли у нас 400-500 запитів в секунду приходить в додаток, ми можемо собі дозволити, не сильно напружуючись, дати туди 1000. 1000 — це в два рази. У два рази — це, в принципі, досить пристойний запас для того, щоб зрозуміти, що реально відбулося.

Є ще така штука, як профіль навантаження. Це коли протягом доби у вас змінюється число запитів. Якщо ви не яка-небудь система моніторингу, яка отримує регулярно, то, швидше за все, ваш профіль виглядає приблизно ось так:



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

Ось така штука — про що вона говорить? Вона говорить про те, що у вас є 1000 запитів в секунду, є 10 тис. запитів на секунду. Стежити за цією штукою дуже важливо, тому що вам потрібно бачити тренди. Тренди класно бачить google-аналітика, наприклад. Коли ви можете винести порівняння двох періодів — за цей місяць і за минулий місяць за одним і тим же показникам, наприклад, за кількістю користувачів. Якщо у вас їх не дуже багато, то вам ця інформація нічого не дасть. Але якщо у вас їх там реально пристойну кількість, то на око не видно, а така штука покаже. І по цій штуці можна спробувати пошукати…



Але є така любов у людства — до середнього. Всі люблять середня. Тобто всі кажуть: «Скільки у тебе?» — «Ну, в середньому 500-600». Зазвичай приблизно так звучить. Як це виглядає насправді? А ось так, як на графіку вище (добовий профіль навантаження). Тобто в середньому у вас 4 тис. з копійками. Тобто можна сказати, що «наша система у середньому приймає 4.5 тис. осіб на годину», умовно. Але при цьому 10 тис., які відбудуться у вас, вони насправді відбудуться, тому коли застосовуються різні системи моніторингу, збору аналізів і т. д., потрібно дуже акуратно підходити до питання вибору цієї самої метрики, про яку ви збираєтеся міряти. Середня — це дуже палена метрика, чесно вам скажу. Вона реально підходить для, по досвіду, лову трендів. Тобто за середнім можна ловити тренд. Тобто якщо середнє починає відхилятися в якусь сторону, вгору-вниз, тоді у вас сто пудів всередині десь щось змінилося. Це привід для того, щоб полізти всередину, більш детально вивчати, повертатися до повноцінного графіку і т. д.

Ми такий графік використовуємо для часу відгуку. Тобто беремо час відгуку. Що це таке? Це людина прийшов, щось там отримав і пішов. Ми його використовуємо виключно для того, щоб ловити тренди, тому що у нас є сторінки, наприклад, які відповідають за півтори секунди, а є сторінки, які відповідають за півсекунди. У середньому, вони відповідають за секунду.



Відповідно, якщо ми беремо сторінку, яка відповідає за 50 мс, та сторінку, яка відповідає за 2 с, то в середньому вони відповідають за 1 с. Знову ж таки, тому що там ± похибка, тобто повільно. А насправді повільно відповідає тільки одна з них, друга відповідає дуже швидко, і в принципі чіпати її і не потрібно. Тому що існує відомий программистский патерн, як в анекдоті про сонечко, що якщо ти бачив, що сонце зійшло на сході, а зайшло на заході, не чіпай його, нехай воно так і далі працює.



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

Знову ж таки, повертаючись до властивості програмістів — програміст любить робити цікаві завдання, а нецікаві завдання він робити не любить. Тому, швидше за все, коли у вас щось почне працювати не так, ви обов'язково почнете щось робити цікаве, але при цьому забудете про те, що, наприклад, потрібно вичистити, логи на Nginx, що вони вже там під Тб, і бідна ваша машина вже не може їх читати і все таке інше…

Замість того, щоб займатися передчасної оптимізацією, заздалегідь краще витратити час на ту саму автоматизацію, про яку я говорив, тобто про пошуки, про моніторинги та про роботу з тех. боргами. Тих. борг — це вишпортування тих самих «милиць», яких ми з вами напхали, коли нам стало погано від хабраэффекта.

Я не зустрічав ще людей, які не додають якісь «милиці» у свої рішення. Навіть круті хлопці з Badoo або Yandex про це розповідають на конференціях (можна подивитись записи попередніх HighLoad), вони чесно зізнаються: «Так, це «милиця». І що? Я теж кажу: «Так, це «милиця». У мене є Бітрікс, який теж не дуже добре працює, я вмію робити швидко працюючим шляхом вписування йому не зовсім правильних рішень. «Милиці» — це якесь рішення, яке рятує в даній ситуації, але потім їм потрібно займатися далі.



З приводу того, що я говорив, що у вас не все відразу зламається. Обов'язково десь щось відвалиться в першу чергу, десь щось відвалиться у другу чергу… Тому є така штука — я її обізвав «компонентна оптимізація».

Вам ні до чого прокачувати систему, ціла система вам цього не пробачить, якщо ви будете прокачувати її цілком. По-перше, ви витратите на це купу часу, прям от багато, тому що вона у вас велика, і, швидше за все, будь-яка зміна потягне за собою потенційні помилки. Тому, чим більше ви змінюєте щось, особливо в конфігурації, тим більше шансів, що у вас щось піде не так. Більш того, сучасні засоби — СУБД, операційні системи та інше — дуже чуйно ставляться до змін своїх власних конфігурацій. Наприклад, у вас значення параметрів в «1» виставлено — це добре, а в «1.1» — це вже недобре, тому що для «1.1» потрібно підкручувати ще 34 параметра, які там десь припрятались. Про це дуже класно розповідає Ілля Космодемьянский, знайдіть його в Інтернеті відео про оптимізацію ось таких штук.

Припустимо, ви знайшли вузькі місця. Треба зрозуміти, чи можливо, взагалі, все це покращити? Тому що, в принципі, як я вже сказав, у будь-якої системи є обмеження по своїм можливостям. Якщо ваша СУБД не може робити 100 тис. селектов одночасно, то вона не зможе, чого ви з нею не робіть. Швидше за все, прийшов час вибирати якесь інше рішення   наприклад, той же самий популярний зараз у розмовах Tarantool. Він не вирішить всі ваші питання NoSQL, він не вирішить питання навіть Postgress (підставте будь-яке інше слово), він вирішить якісь інші ваші питання, які потрібно вирішувати в цей момент.



Гроші і час. Навряд чи хтось з вас працює в державних компаніях. Але запитаю — є? В аудиторії таких дві людини. Це ті компанії, в яких питання грошей стоїть гостро, але не так гостро, як в інших компаніях. Я сам працював у державному підприємстві. Я знаю, які там обсяги, і я знаю, як у них відбирають бюджетів і віддають їх назад, але, тим не менш, це не так критично, як, наприклад, у нас. Ми не можемо собі дозволити взяти 30 інженерів і змусити їх займатися оптимізацією. Вони, звичайно, заоптимизируют, і все це буде пекельно працювати швидко, спритно і класно, але час, який ми витратимо на це, по суті, неодержаний прибуток — це збиток. За цей час, ми не зробимо чогось нового, кльового, і компанія буде рада.

Плюс ще є шеф, той самий, у якого завжди є дедлайн. Наприклад, класична ситуація, яка дуже часто зустрічається — це рекламні контракти на телик. Якщо ваша компанія примудрилася витратити купу грошей на рекламу на телик, то телику взагалі пофіг на то, готові чи не готові. В призначений день і годину на призначеному каналі з'явиться ваш ролик, в якому буде ваше посилання і, швидше за все, до вас прийдуть люди. Ви навіть не знаєте, скільки прийде людей, більше того, телик сам не знає, скільки прийде людей, ніхто не знає, скільки прийде людей. Здавалося б, ситуація патова — все, хана, одягаємо шолом, ховаємося і чекаємо, поки прилетить. Тим не менш, є чудовий «милиця»/технологічне рішення, яке називається Landing Page.

Що робить Landing Page? Ви берете статичну html, на якій ваш дизайнер малює красиву картинку, і ви всіх Nginx'му на неї приземляете. Nginx роздає цю картинку зі швидкістю 80 тис. запитів на секунду, не обламываясь навіть з самого маленького сучасного стільникового телефону — він зможе роздати з такою продуктивністю. І 80 тис. чоловік в секунду дивляться вашу картинку. При цьому ваш портал знати не знає, що до вас хтось прийшов, тому що до нього ще не дійшли. А далі — традиційна маркетингова воронка продажів — з кожним наступним кроком, з кожним наступним скролом кількість людей, яке доїхало до низу, де кнопка «увійти» або «купити», або ще чогось, воно зменшується. «Милиця»? «Милиця». Рішення? Чому ні? Ви, по суті, нічого не роблячи, використовуючи ту ж саму інфраструктуру, взяли і врятували себе від смерті. Тому що, якщо до вас прийде 80 тис. запитів на секунду в додаток, воно взагалі не зрадіє, я вас запевняю.

Кешування в таких ситуаціях, напевно, теж можна було б розглянути як рішення, але тоді вам потрібно, щоб у вас було дуже багато пам'яті або дуже швидкі диски.



Список Буніна, Олега Буніна — ви, напевно, чули про цього персонажа? У нього є список, список виглядає ось так:



Це не все, там ще 100500 пунктів, це паттерные розробки високонавантажених систем. Щоб вам було простіше, то ось так на самому делеЈ:



Рекомендую пошукати в YouTube «Олег Бунін розробка високонавантажених систем», там він про це все розповідає, про кожен пункт, їх у нього в оповіданні штук 20. Насправді їх не 20, але, тим не менш, частіше за все, це як на картинці вышеЈ

тобто людина, яка вперше на це дивиться, каже, е-моє. Поясню, чому «е-моє».



Тому що частина з цих чудових пунктів, про які розповідає Олег, вам не знадобляться, швидше за все, ніколи. Тому що, будемо чесними, не всі ми з вами будемо працювати в якихось мегапроекти типу Badoo. Швидше за все, звичайно, будемо, тому що у них великий попит на людей, але тим не менш. Наприклад, Банки.ру добра половина з ось цього всього списку не потрібна, і не буде потрібна ніколи, тому що кількість вкладників в цій країні не може вирости реактивно, т. к. люди реактивно не народжуються. Відповідно, кількість запитів, що у нас буде, швидше за все, буде завжди однакове. Ну, там є сезонність і все таке…

насправді, якщо не бути таким категоричним, чому я сказав про проекти? У проекті, швидше за все, вам не потрібно це все. Коли у інженера, який завжди робить те, що йому цікаво, сайт починає гальмувати, він бере списочок і починає перевіряти: «Ага, так, шардирование. Піду почитаю». Почитав, подивився. «Давай я своїх користувачів поделю за буквою А і Е». Не важливо, що у нього при цьому всього 700 тис. користувачів, одноядерний, слабенький сервачок з будь-якою базою даних, і він може зробити селект по ID і повернути йому дані по цьому користувачеві… Він починає їх шардировать, робити з ними всякі жарти — повторити, бэкапить, робити резервні шини. Ну, коротше, розважається, як хоче. У мене для цих цілей виділено спеціальний людина, у якого робота «розважатися, як хоче» — він просто цілими днями розважається, шукає вузькі, слабкі місця і т.д.

В цьому списку (чому я вас до нього відправляю?) є частина речей, які можна зробити, взагалі не маючи ніякої кваліфікації. Тобто швиденько прогуглити — «в Nginx як роздати статику?», «як її зипануть?», «як збільшити розмір буфера при сортуванні в Postgress?» або, наприклад, «як який-небудь slow log налаштувати в MySQL?». Ви знайдете дуже швидко. Це, взагалі, не треба бути навіть DBA. Ви просто прийшли зі своєю маленькою завданням «у мене тупить запит». І вам Google швидко розповів, чому він тупить. Спочатку Google розповість, що ви тупі, а не ваш запит, тому що він завжди так робить.

Звідки взагалі беруться всі проблеми? Тому що немає стандарту розробки. Не шукайте його. Його немає. Немає стандарту, який говорить: «Розробка
високонавантажених систем. Версія 1 від 2016 року, Сколково». Я думаю, що ми коли-небудь до цього доживемо, але тоді я піду з індустрії, чесно. Коли з'являться такі документи. Хлопці інноваційні — вони зараз можуть, в принципі.



Не все треба тут і зараз   те, про що я говорив.

Ось шардирование — класна штука, вона дуже круто працює і, наприклад, Badoo'шники без неї давно б здохли, або, наприклад, Яндекс б теж без нього здох. І взагалі, всі великі портали використовують зі списку Буніна всі пункти, які там є, і ще купу пунктів, яких там немає. Тому що там є всякі ноу-хау і т. д.

Той самий «милиця». Просте рішення   найефективніше. Тобто вставка якоїсь примітивної конструкції в код. Для прикладу можна взяти який-небудь форум, неважливо на якій платформі. Найчастіше внизу у нього є список активних користувачів — хто в даний момент дивиться цей пост. Цей списочок у класичній версії движка форуму будь-якого кожному користувачеві генерується. Тобто ви прийшли на сторінку, вам цей select * from (якась табличка) — бац, з'явилася ось ця штука. Природно, коли у вас приходить 200 тис. користувачів, то база робить цю операцію 200 тис. разів. Чи Так важливо, що через секунду або через 2 секунди, навіть якщо хтось з'явиться в цьому списку, від того, що він там з'явився, вам за великим рахунком, ні тепло ні холодно, тому такі конструкції можна, наприклад, складати в кеш, або, наприклад, складувати в окремі структури і прогрівати їх, наприклад, кроном.

Чому я згадую Badoo'шників? Реально круті чуваки. Вони дуже багато сил вкладають у розвиток, але це, знаєте, такий Тема Лебедєв від веб-розробки. Тобто це довго, дорого і ще одне слово. Тобто за дорого не візьмуся, за довго — швидше за все, немає, але останнє слово — 100 пудів про них, тому що всі їх рішення найчастіше потім знаходять якусь індустріальну обгортку, ніж вони кладуть велику свиню половині людства, тому що люди беруть ці рішення і починають їх використовувати.

А що таке використання будь-якого рішення? Це хайп. Це коли вам починають активно впарювати. Тобто ця така активна реклама. Хайп — це в IT страшніше не придумати. Якщо у вас немає спеціально навченого хлопця, який займається дослідженнями. Хайп — це модні тенденції, модні фішки, модні фреймворки, не побоюся цього слова, модні мови, модні рішення. Загалом, все, що, як мовиться, на гребені хвилі. Те, що тільки що з'явилося, це з'являється в інтернетах зі словами «Очманіти, хлопці, якщо у вас цього немає, то не треба вам взагалі більше в інтернеті сидіти, йдіть, ви ніхто».



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

Це корисно, але завжди є ризики. Ризики — це те, про що люди забувають. Тобто перебуває інженер, який класно все це підхоплює, який
суперфахівець. Він бере «еклмн джс» фреймворк, який щось робить, якісь селектори модні або ще що-то, і вам це по-швиденькому вкручує. А потім звільняється на фіг. Ну, набридло йому, що ви його вилаяли за цей фреймворк. А я хочу ще більше-більше фреймворків. Посаду дослідника у вас зайнята тим хлопцем, що те ж саме робив з бекендом. Ну, по-іншому ніяк, на жаль, бо технологій багато. Це шалені обсяги документації. Проект реально може просто взяти і закритися — людина приходить і каже: «Та ну вас».

Пам'ятайте, історія була, коли один з джаваскриптологов крутих взяв і відкликав з NPM свій шматочок коду. І що сталося? Стався ахтунг. Всі такі «Е-мое! Розвалилася». Якби чуваки це передбачили заздалегідь, як ми це зробили… Хвилинка саморекламыЈ — ми собі поставили їх сервера, і у нас все пакетики перед тим, як потрапити на продакшн, спочатку осідають на нашому кэширующем серваці й. Рішень для цього — вагон. І пакети операційної системи, і javascritp фреймворки… загалом, все, що ми тягнемо з вулиці, ми тягнемо насправді не з вулиці, а з якоїсь проміжної коробки, яка все це зберігає. І навіть, якщо на вулиці хтось щось убив чи, наприклад, змінив url… Класна фішка — змінити url у пакета, а у вас він, наприклад, захардкожен де-небудь у вашому чудовому композере. У вас захардкожен url, і «ой-ой-ой, не зібралося», а у вас це продакшне працює, і там «ой», і у вас така картинка класна, ви всі її бачили, коли стилі не завантажуються, наприклад. Найчастіше, це класно. Ми це питання вирішили ось так. Тобто ми не стали морочитися, новий-не новий, старий-не старий, у нас є місце, яке завжди зберігає ті версії, які ми використовуємо, і навіть якщо весь інтернет помре, то у мене з локалочки все це справа підтягнеться, і все буде працювати.

Це актуально стало. Ми почали цим займатися, тому що РосКомНадзор заблокував GitHub, зараза така. І він це робив із завидною регулярністю. У підсумку ми залишалися без наших чудових пакетів. У підсумку знайшли рішення, поставили маленьку коробочку, вона це все зберігає.

Про людей — це, взагалі, тема хвора в вебі. Спеціаліста по всьому вебу ви не знайдете, вам потрібен спеціаліст з цілком конкретного вебу. Тому, коли у вашому господарстві з'являється slow черговий, то, швидше за все, вам потрібен спеціаліст з цього slow. Якщо у вас цього фахівця немає, то ви будете писати на php як на Сі, наприклад, або на javascript писати як на Сі. Зате читається офігенно. Добре написаний Си'шний код прочитати, по-моєму, може будь-яка людина, який володіє англійською мовою. По-моєму, це один з останніх мов, у якому це збереглося. Спробуйте прочитати сучасний javascritp без підготовки.

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



Про «милиці», тех. борг і інше. Ще і з приводу цього хайпи. Це я не до того, що взагалі не треба нічого чіпати, це я до того, що якщо ви вирішили помацати, то, як в старій російській приказці, пам'ятайте, що як тільки ви поторкали, у вас залишаються наслідки, і з цими наслідками вам доведеться жити. Так от, про наслідки «милиць». Є така штука –технічний борг. Всі про нього чули. Це коли ви знаєте, що у вас щось не працює, але при цьому ви не чините. Тому що або це вам не сильно заважає, або це вам заважає, але не дуже… Це штука, яка є. Хтось його записує, хто його не записує. У когось є списочок завдань, які треба зробити потім? Є. Ось, це технічний борг, практично.

Як з ним працювати? Розповім, як з ним працюємо ми.



Ми вважаємо, що один «милиця» — це одна задача технічний борг. Тому, якщо, наприклад, ми в моменті, коли нам погано, і до нас приходить якийсь бот, ми пхаємо «милиці» у конфігурацію Nginx, як доведеться, типу, «тільки б він відвалив». Ми потім заносимо задачку, в якій написано: «Приходить ось такий гад, у нього є такі параметри. Зробити так, щоб він і аналогічні гади більше ніколи до нас не приходили». Адмін сідає, пише скрипт, який генерує шматок конфига Nginx, всі щасливі.

Борг — це повноправний учасник процесу планування, тобто якщо ви це все відкладаєте на потім, то це все ніколи не буде реалізовано. Тому що, по суті, потім — це ніколи. Якщо ви не зробили зараз, то шансів практично немає. За пріоритетами така ж нісенітниця. Хтось вважає, що завдання бізнесові, поточні — це завдання більш важливі, ніж технічний борг. Фігня це все. Якщо у вас технічний борг буде накопичуватися, він буде збільшуватись-збільшуватись, одне завдання буде нашаровуватися на другу, потім на третю, потім виявиться, що задача, яку породив новий «милиця», вже не вимагає рішення попередніх чотирьох завдань… загалом, у вас буде якийсь «ящик Пандори», чи що. Тобто коробка, в якій лежить «що-то».



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

Для прикладу, у нас на деяких командах в тех. борг бовтається приблизно 170 завдань — це десь командо-місяць. Ось, експериментальним шляхом було доведено, що це стеля. І коли ми цього показника досягаємо, я йду до бізнесу і прошу їх між проектами дати нам тиждень чи півтора, щоб ми витратили на те, щоб цю «Авгиеву стайню» вичистити і викинути звідти, що ми там напрограммировали. Не завжди працює, але у нас працює, тому що зазвичай пояснюється це просто — якщо ми це не зробимо, то це все перестане працювати. Далі ви слухаєте, які ви «молодці», і «кого я найняв, кому я плачу гроші, якого...» і ще багато різних слів. Але тим не менше, це єдиний спосіб.

Борг накопичується завжди, я не бачив жодного разу, жодної компанії… Я читав про одну, яка стверджує, що вони вміють працювати без дефектів, тобто у них появу дефекту — це «червона ганчірка», яка говорить: «все кинули, пішли лагодити дефект». Я, чесно, не знаю, з якою швидкістю вони рухаються вперед. Я не доисследовал це питання, тим не менш, мені здається, що це не дуже добре працює.



І на закінчення. Важлива стратегія! Чому стратегія? Люди, які працюють з вами, всі повинні думати однаково. Тобто в ситуації, коли трапляється якийсь факап, всі повинні діяти приблизно однаково. Тому людство придумало спілкування — щоб можна було поговорити зі своїми колегами. Я розумію, що програмісти не дуже люблять говорити зі своїми колегами, але тим не менш. Непогано б зібратися і хоча б знайти крайнього, тобто сказати: «Якщо трапляється якась біда, ти будеш виправляти все це». Швидше за все, так не станеться. Тобто природно, лагодити будуть допомагати все, але я бачив, як це відбувається наживо. Зазвичай виглядає так: половина команди, каже: «Ну, йо-майо!», і типу думає, що робити. Друга половина команди каже: «Ну, це все,
коротше, блін… Було 100 запитів в секунду, а тепер 500! Гаразд, коротше». Потім знаходиться хтось один, називає хлопчиків дівчаток, дівчаток — хлопчиками, щоб підбадьорити внутрішнє его і т. д. і каже: «Ну, давайте трохи подумаємо».

Подумаємо. Це важливо! Взагалі, програмістам властиво думати. Про це потрібно думати теж   про те, що якщо станеться чого, що робити. У нас є певний план такий короткий, на 5 пунктів, що робити, якщо сталася біда.



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

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

Ризики оцінювати треба завжди. Що таке оцінювання ризиків? У нас це виглядає приблизно так: скільки я втрачу грошей, якщо я проваляюсь хвилину. Ну, $100, умовно кажучи. А на скільки мені за це потім прилетить? Або на скільки компанії від цього буде погано?

Ще є класна річ, про яку варто говорити окремо — це репутаційні ризики, тобто кожен ваш факап — це не факап грошовий, це факап репутаційний. Тобто якщо ви молода соціальна мережа facebook2, то краще б вам, звичайно, не валятися, інакше шансів досягти facebook1, у вас не буде жодних. Це, до речі, показали хлопці з китайського чатика, аналога WhatsApp'а, які гордо вийшли на ринок і їм сказали: «Ей, ти хто, йди звідси». І вони зі своїм мільярдом користувачів в Китаї так і залишилися. Бо щось не передбачили, де щось не подумали, не прикинули, і у них просто не було стратегії, що з усім цим робити.

Пробувати на кішках. Зараз дуже дешевий хостинг, віртуальний — берете, робите свою систему десь в кутку на коліні збираєте, пхали туди, що хочете, будь-які технології, будь-які зоопарки. Нехай падає, хай дохне. Можете навіть, заради сміху, туди відправити шматочок свого трафіку. Nginx це вміє — пам'ятайте про балансування? Відправте туди 10 осіб, і подивіться, що станеться реально. Так роблять хлопці з Badoo. Це не реклама, просто вони про це розповідали.
Вони свої сервіси аналізують на, по-моєму, исландцах. Ну, типу, взяли самих сейсмостійких чуваків, яким за великим рахунком начхати, що в цьому світі відбувається, вони сидять на своєму острові і у них все добре, і цей Эйяфьякудль, у них все класно. Туди їм вантажать нові рішення, потім дивляться. Вони такі:
«Ах, підемо ще пивка поп'ємо». Це реальна історія, вони про це розповідали.



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



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




Більш детально про розвиток highload-системи ми поговоримо на вебінарі Романа Ивлиева “HighLoad-розробка з нуля і по кроках". Це буде одноденний інтенсивний майстер-клас, в рамках якого ми поговоримо про розвиток системи, рефакторинге і реінжинірингу набагато більш грунтовно:
Розвиток системи
  • Коли пора починати щось робити?
  • Еволюція класичного навантаженого веб-порталу (на прикладі banki.ru)
  • Методи оптимізації різних елементів системи
  • Керована деградація і підготовка до неї
  • Підготовка системи до зростання: гнучкість і надійність
  • Hype — його плюси і мінуси
Рефакторинг або реінжиніринг
  • Безперервність бізнесу при розвитку системи
  • Коли ще можна безпечно використовувати можливості поточної системи?
  • Коли потрібно починати будувати заново?
  • Цикл PDCA і «бережливе» розвиток системи.
Джерело: Хабрахабр

0 коментарів

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