Всему своё время
Банки.ру — проект с 10-летней историей. В разные времена banki.ru испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас средняя посещаемость примерно 2 миллиона просмотра страниц, т.е. проект уже не маленький, но ещё и не совсем большой.
Эта статья — расшифровка доклада Романа Ивлиева (CIO Banki.ru) на обучающей конференции HighLoad++ Junior, которая прошла пару месяцев назад в Москве в рамках фестиваля «Российские интернет-технологии».
В этой статье мы хотим поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
- Настолько ли ваш highload — highload?
- Считать ли хабрэффект поводом для внедрения высоких технологий?
- «Костыль» или «высокотехнологичное решение» — что выбрать? Плюсы и минусы.
- Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки «по-взрослому».
- Как можно использовать «список Бунина» для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
- Как работать с техническим долгом, чтобы он не зарастал мхом?
В заключение Роман Ивлиев расскажет про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
Всему свое время
Роман Ивлиев (Банки.ру)
Я перед вами тут стою, потому что я уже 15 лет всем этим IT«шным безобразием занимаюсь, за достаточно долгое время прошел путь от инженера до начальника.
Поработал в различных известных в своих кругах компаниях:
А это про Банки.ру:
Надеюсь, вы про нас слышали. Любой, кто пользуется банковскими услугами, наверное, знает, что такое Банки.ру.
Я объясню, откуда взялись такие цифры и, вообще, зачем они здесь. Никакой рекламы, это то, что у нас на самом деле есть. Трафик ни к чему, но тем не менее, мы в сутки обслуживаем примерно полмиллиона человек, т.е. это не число запросов, это число уникальных людей, число запросов, естественно, больше — оно там к двум миллионам, может быть, даже к трем, а когда бывают «чудеса» с валютой или отзывают лицензию у какого-нибудь клевого банка, у нас бывают и цифры, которые зашкаливают. В 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 пунктов, это паттерные разработки высоконагруженных систем. Чтобы вам было проще, то вот так на самом делеJ:
Рекомендую поискать в YouTube «Олег Бунин разработка высоконагруженных систем», там он про это все рассказывает, про каждый пункт, их у него в рассказе штук 20. На самом деле их не 20, но, тем не менее, чаще всего, это как на картинке вышеJ
Т.е. человек, который впервые на это смотрит, говорит, е-мое. Объясню, почему «е-мое».
Потому что часть из этих замечательных пунктов, про которые Олег рассказывает, вам не пригодятся, скорее всего, никогда. Потому что, будем честными, не все мы с вами будем работать в каких-нибудь мегапроектах типа Badoo. Скорее всего, конечно, будем, потому что у них спрос на людей большой, но тем не менее. Например, в Банки.ру добрая половина из вот этого всего списка не нужна, и не будет нужна никогда, потому что количество вкладчиков в этой стране не может вырасти реактивно, т.к. люди реактивно не рождаются. Соответственно, количество запросов, которое у нас будет, скорее всего, будет всегда одинаковое. Ну, там есть сезонность и все такое…
На самом деле, если не быть таким категоричным, я почему сказал про проекты? В проекте, скорее всего, вам не нужно это все. Когда у инженера, который всегда делает то, что ему интересно, сайт начинает тормозить, он берет списочек и начинает проверять: «Ага, так, шардирование. Пойду почитаю». Почитал, посмотрел. «Давай я своих пользователей поделю по букве А и Ё». Не важно, что у него при этом всего 700 тыс. пользователей, одноядерный, слабенький сервачок с любой базой данных, и он может сделать селект по ID и вернуть ему данные по этому пользователю… Он начинает их шардировать, делать с ними всякие шутки — реплицировать, бэкапить, делать резервные шины. Ну, короче, развлекается, как хочет. У меня для этих целей выделен специальный человек, у которого работа «развлекаться, как хочет» — он просто целыми днями развлекается, ищет узкие, слабые места и т.д.
В этом списке (я почему вас к нему отправ
