Некоторое время назад зам.главы московского офиса разработки Badoo Алексей Рыбак и ведущие IT-Компот записали выпуск подкаста «Архитектура высоконагруженных приложений. Масштабирование распределенных систем".Сейчас мы сделали расшифровку подкаста, привели ее в удобный для чтения вид и разбили на 2 части.
О чем говорили в первой части:
- Общая информация о проекте Badoo: стек технологий, характер и объем нагрузки, посещаемость.
- Горизонтальное масштабирование проекта:
— веб-сервера, кеширование, мониторинг etc;
— подводные камни при масштабировании проекта;
— масштабирование баз данных, как правильно делать шардинг.
Ведущие: Всем привет, вы слушаете 45 выпуск подкаста «IT-компот», и с вами его ведущие — Антон Копылов и Антон Сергеев.
Сегодня мы решили поговорить про back-ends, про веб-разработку, а точнее про архитектуру высоконагруженных приложений и про то, как масштабировать распределённые системы. В этом нам будет помогать наш гость, Алексей Рыбак. Алексей, привет!
Алексей Рыбак: Привет!
Вед.: Сайт «Мой Круг» говорит, что Алексей — руководитель платформенной разработки и зам. главы московского офиса разработки компании Badoo. Еще Алексей очень давно разрабатывает различные сложные распределённые высоконагруженные системы с использованием самых разных технологий, в том числе мониторинг серверов Pinba и ещё какие-то штуки. Может быть, я что-то не знаю — Алексей меня дополнит или поправит. Кроме того, наш гость активно принимает участие в конференциях, состоит в оргкомитете HighLoad, большой и мощной конфы, в PHPConf и, наверное, где-то еще.
А.Р.: Я бы хотел чуть-чуть поправить. Pinba сделал мой коллега Антон Довгаль, а первую версию вообще сделал Андрей Нигматулин. Я больше там что-нибудь подсказывал, придумывал.
И да, я действительно являюсь заместителем главы разработки Badoo и в основном занимаюсь платформенными проектами, курирую большие «open source» проекты. И вообще всё, что я рассказываю, скорее делаю не я сам, а делают наши ребята. У нас работает достаточно большой состав инженеров. Со многими мы работаем ещё со времен «Мамбы». Поэтому говорить, что я там в одно лицо разрабатываю такую гигантскую систему это, конечно, неправильно – я больше занимаюсь административной работой, в последнее время руковожу несколькими группами разработки.
Вед.: Понятно. Но мы и не собирались, так сказать, сильно тебя возвышать на фоне остальных разработчиков, говорить о том, что ты один такой молодец в Badoo. У нас ещё будут вопросы и по поводу команды, нам слушатели задали такие вопросы в комментариях.
Я сейчас озвучу небольшой план нашим слушателям. Алексей расскажет вкратце о себе, как он начинал, чем занимался, к чему пришёл и так далее; мы поговорим про то, что такое Badoo, если вдруг кто-то не знает, что это за проект. Затронем вопрос горизонтального масштабирования и расскажем, как вообще масштабироваться, какие технологии есть, какие проблемы бывают, на примере опыта большого сервиса всё это дело рассмотрим. И ещё очень интересная у нас сегодня будет тема – это про всяческие разные асинхронные задачи в высоконагруженных системах (это очереди job queues, message queues).
Алексей, тебе слово, расскажи вкратце, как ты пришёл в мир разработки, чем занимаешься сейчас и что планируешь делать в будущем вообще, какие планы.
А.Р.: Ну, хорошо. Вкратце — я не собирался становиться программистом, когда учился в школе, и вообще программированием практически не занимался. В 9-10 классе я ходил в университет изучать Fortran, но прежде чем попасть на эти занятия, мы частенько заходили куда-то выпить пива или вина. В общем, с программированием как-то у меня совсем не сложилось, я поступил на физический факультет МГУ и хотел заниматься физикой. Но так получилось, что заниматься физикой в 90-х годах особого смысла не было, все мои друзья уехали, и я решил пойти заниматься веб-разработкой. И первое, что я делал, это было на самом деле не веб-программирование — я был веб-мастером. Помимо того, что я писал какие-то скрипты на Perl’е и что-то автоматизировал, я рисовал баннеры, что-то там резал в Photoshop и так далее. Потом поработал в разных компаниях и мне повезло — в 2004 году я попал в «Мамбу». Это очень большой проект, который мгновенно стал популярным в русскоязычных странах.
Вед.: Все знают, наверное, этот сайт знакомств, первая большая известная социальная сеть. По крайней мере, я её помню еще со времен «dial-up» Интернета.
Вед.: Да, я помню очень популярно было «партнёрки» с «Мамбой» делать, когда домен свой прикручиваешь к этой системе и получаешь комиссию от своих пользователей.
А.Р.: «Мамба» и развивалась за счёт крупных и мелких партнёров. Это был гигантский шаг вперёд и переворот в моей карьере. Это была очень маленькая, но очень профессиональная команда. Частично пришлось там учиться на собственных ошибках. Мы допустили гигантское количество ошибок, связанных именно с разработкой на несколько лет вперёд. Но выстоял — проект этот жив до сих пор. Правда, там, скорей всего, всё уже переделали. Где-то с 2006 года или с конца 2005 года мы уже этим проектом не занимаемся — там сейчас есть своя команда, а мы стали заниматься проектом Badoo.
В Badoo с самого начала была очень небольшая команда, буквально десяток инженеров, включая удалённых сотрудников, сисадминов — вообще всех. С тех пор компания выросла. Я там отвечал за всю разработку серверной части back-ends, за исключением C-демoнов, то есть за все деплои основных фич, просто за разработку сайта. Там фактически был ещё только один «техно-менеджер» — технический директор, который был ещё руководителем админов и «сишников».
Вед.: А я хотел вот что узнать. Ты сейчас упомянул, что back-end у вас сишный — неужели у вас в приложении много сишного кода?
А.Р.: На самом деле, кода довольно много, но, если позволите, я чуть попозже расскажу почему у нас такой стек технологий.
Вед.: Хорошо. Алексей, получается, что у тебя уже был хороший багаж, опыт разработки именно сервисов знакомств, некоторые представления о том, какие вещи там делать нужно и не нужно, и вот так ты, собственно, в Badoo и вошёл?
А.Р.: Да, мы выросли очень сильно за последние несколько лет, и поэтому от разработки мне пришлось уйти. Но опыт, который мы здесь накопили — достаточно интересный, и мы его конвертируем в статьи, в выступления. У нас даже есть семинар — мой семинар по разработке больших проектов. Поэтому эта тема мне очень интересна и я с удовольствием расскажу о том, чему мы научились, какие методы и прочее мы используем.
Касательно стека технологий: мы используем Linux и кучу «open source» софта. И даже если вы не разрабатываете ничего на С или С++, то у вас часто бывает так, что происходит какой-то подземный стук, и вы не знаете, в чём дело. Вам нужно иметь внутри компании компетенцию: взять, открыть исходники, прочитать, разобраться и поправить. Начиная с определённого масштаба проекта, с определённой нагрузки, такая компетенция должна быть. Представим себе, что у вас есть хорошие системные администраторы, и хорошие системные администраторы, как правило, код на С читать умеют. Но если у вас есть в штате сишники, которые могут это прочитать и поправить, то это вообще замечательно. Поэтому одно из направлений, которое покрывают сишники у нас, это доработка и разработка разного рода «open source» софта.
Вед.: Ага. А так в основном, насколько я знаю, Badoo написан на нашем родном PHP?
А.Р.: Да, в основном это язык PHP, а базу данных мы используем MySQL, то есть такие самые-самые, казалось бы, простые технологии. Тем не менее, на них всё можно сделать — большое и замечательное.
Вед.: Да. А сколько у вас сейчас аудитория активная суточная?
А.Р.: Хороший вопрос. Я сейчас конкретные цифры, наверное, не вспомню, могу ошибиться на десятки процентов. Интересует суточная или месячная? Думаю, что суточная аудитория в районе 10 миллионов. Это я говорю об авторизованных пользователях. А если говорить о тех, кто просто иногда приходит и смотрит какие-то анкеты, я думаю, там и все 20 миллионов.
Вед.: И при этом у вас довольно большое разрозненное приложение. Я имею в виду, что оно активно представлено на мобильной платформе — это телефоны, планшеты, веб-версия… Вас случаем нет на консолях Xbox, PlayStation?
А.Р.: Это интересный вопрос. Дело в том, что когда-то разработку действительно делали так, чтобы она работала, грубо говоря, и в телевизоре, в котором и JavaScript если и есть, то он какой-то там кастрированный и так далее. Если говорить о том, какие приложения, Badoo — это гибрид социальной сети и dating-сайта. Но у нас есть отдельные приложения, которые так или иначе просто повторяют функциональность Badoo. Но они могут быть совершенно отдельно стоящими. Это могут быть приложения в Facebook, это могут быть приложения на телефоне, которые отдельно распространяются через свои каналы, как бы не Badoo. Есть основной сайт Badoo, приложение ― там просто «голосовалка»: красивая фотография или нет, хорошая или нет. Всякие такие вещи. Приложений действительно много, и я боюсь, что их уже десятки. Но, так или иначе, back-end для всех для них — это PHP и база данных (если используется, то MySQL).
Вед.: И вот как всегда начинается проект. У него, в случае если это действительно успешный, интересный пользователям проект, начинает быстро расти аудитория. Соответственно, нужно как-то это всё дело нормально поддерживать, чтобы сервис не падал, чтобы сервис адекватно реагировал. Соответственно, здесь такая очень банальная вещь, о которой сейчас не говорит только ленивый — это горизонтальное масштабирование. Здесь есть разные способы и технологии — Amazon, не Amazon, облака, физический хостинг; используется всё что угодно — PHP, Python, Ruby, Java, не знаю… даже Erlang — может быть, кто-то есть такой, кто сразу его использует, упаси господь. Как вы к этому подходили, что вы используете и почему именно эти технологии?
А.Р.: Мне сложно ответить в самом-самом общем виде, больше расскажу о том, что используем мы. Мне кажется, что «зоопарк технологий» в мире вообще таков, что очень многие ребята, выбрав ту или иную технологию, вынуждены изобретать рано или поздно велосипед. Но поскольку вокруг одного или другого языка community достаточно большое, в конце концов этот велосипед становится велосипедом для community целиком, и так или иначе, выбрав тот или иной язык, скорее всего, задача масштабирования решаема.
Мы достаточно легко научились масштабировать непосредственно сервера приложений. Для того чтобы, условно говоря, масштабировать сервера приложений, все, что нужно — это сделать так, чтобы как можно меньше было хранения состояний в самом приложении, и чтобы обработка запроса могла легко перетечь с одного сервера приложений на другой, и чтобы как можно меньше было нагрузки на процессор. Здесь со скриптовыми языками не очень хорошо.
Задачи, которые мы здесь решали, были в основном связаны даже не с масштабированием, а с reliability. Начиная с 2005, по моему, года мы патчили PHP. Проект в результате превратился в так называемый PHP FastCGI process manager или PHP-FPM и вошёл в 2008 или 2009 году уже в ядро PHP. А это на самом деле наша разработка. Делал изначально всё это Андрей Нигматулин, и сделано это было скорее даже не для масштабируемости, а для удобства поддержки, чтобы можно было плавно перезапускать и так далее.
А масштабирование непосредственно серверов приложений — вещь достаточно простая, нужно просто грамотно раскидать трафик. Сложности появляются при масштабировании баз данных: вот как сделать так, чтобы было горизонтальное масштабирование непосредственно баз? А с кэшем тоже всё достаточно просто, потому что кэш — это такая вещь, которую достаточно каким-то простым способом размазать, а в случае если вы добавляете новые сервера, то ничего страшного, если у вас это размазывание данных полностью перебросит с одного сервера на другой. В случае если вы не сможете поднять систему с кэшами при таком переразмазывании данных — скорее всего, у вас там просто в архитектуре что-то не так, то есть “добивка” серверов или перераспределение данных по ним — это ерунда.
А с базами данных так не получается. Есть несколько методов масштабировать их, но все они, так или иначе, должны основываться на удобстве работы. У нас на данный момент — сейчас я не помню, где-то могу ошибиться — приблизительно 500 серверов баз данных. На самом деле достаточно крупная инсталляция, это живёт всё в нескольких data-центрах и управляется, по сути, одним человеком. Вот один человек у нас отвечает за базы данных. Мы всё сделали для того, чтобы это было оптимально удобно.
Вед.: А вот управления одним человеком вы добились с помощью автоматизации, поднятием новых нод, бэкапами и так далее?
А.Р.: Да.
Вед.: А инструменты для этого у вас свои или вы какими-то решениями пользуетесь?
А.Р.: Дело в том, что, наверное, сейчас есть какие-то решения, которые можно было бы рассмотреть. Но такой research дорогой, а мы проектировали всё в 2005 году, и на тот момент ничего подобного не было. Поэтому нам сейчас выгоднее работать в рамках того, что у нас уже есть. То есть я не буду рекомендовать людям с нуля всё придумывать, но мы находимся в рамках тех технологий, которые заложили ещё в 2005 году. Но надо сказать, что заложили мы их достаточно здорово — из одного data-центра мы переехали в два. Если будет третий data-центр, мы совершенно спокойно будем масштабироваться и дальше, и скорее всего, этот stack у нас меняться не будет. А смысл такой: одна из основных ошибок, которую допускают люди, когда начинают сначала масштабировать базы данных, заключается в том, что они раскидывают данные по серверам. Я называю этот подход детерминированным — по ключам, то есть, грубо говоря, самый простой пример — это какая-то функция от значения ключа.
Вед.: Угу.
А.Р.: Остаток от деления, первая буква логина, есть всякие способы — все они не работают в саппорте. То есть они там простые и красивые, но все они в саппорте не работают. Потому что как только оказывается, что какая-то нода вылетает и нужно сразу же вместо десяти серверов вдруг использовать только восемь по каким-то причинам, две ноды нужно временно выключить, данные с них куда-то перенести, и тут появляется засада полная, потому что эта формула даёт сбой. Дальше люди, которые так или иначе работают с поддержкой, понимают, что надо как-то видоизменять этот способ, придумывают всякие разные хитрости, но они уже такими получаются полу-детерминированными.
Самый удобный способ – это так называемые virtual buckets или виртуальные корзины, виртуальные «шарды». Смысл заключается в том, что используется некий mapping того же идентификатора или чего-то на какой-то номер, но этот номер виртуальный, и их много. И потом уже эти виртуальные номера или виртуальные шарды «маппятся» специальным конфигурационным файлом на физические таблицы или сервера. И таким образом решается сразу две задачи – одна задача заключается в том, что mapping всё равно, так или иначе, routing данных — откуда данные загружать или куда данные сохранять. Он оказывается детерминированным, в том плане, что функцию вычислить достаточно легко. А с другой стороны, в случае если какая-то нода выходит из строя, то администратору достаточно поменять конфигурационный файл, при наличии бэкапа «перевлить» какие-то данные и запустить это всё в production. На этом практически все проекты останавливаются, но такая задача не решает проблему нескольких data-центров и проблему connectivity.
Юзер переехал из одной страны в другую. Поскольку у нас остаётся некая детерминированная часть, мы пользователя всегда можем «отмаппить» только на один определённый шард. Условно, да, ну потому что у нас работает функция. Мы не можем взять и сказать, вот конкретно этот пользователь переезжает с одного шарда на другой. А у нас такая задача появилась, потому что мы иногда мигрируем между data-центрами юзеров, для того чтобы всё у них работало быстрее. Но для того чтобы так делать, нам приходится делать самый сложный mapping: мы как бы каждого пользователя привязываем к конкретному шарду через, грубо говоря, отдельный storage – очень быстрый storage, но мы конкретно одного пользователя можем между шардами переселять.
Я таким образом описал, наверное, весь спектр решений, так или иначе завязанных на горизонтальном масштабировании баз – простом детерминированном, через виртуальные бакеты и с привязкой каждого пользователя к своему шарду.
Вед.: У нас, кстати, по поводу этого и спрашивает пользователь Андрей. Он спрашивает: «Алексей, интересно, как у вас устроена архитектура хранения данных, кэш и БД?» С базой понятно. И как вы определяете необходимость перемещения пользователя, то есть почему данным пользователю может потребоваться переехать на другую шарду. Как вы определяете?
А.Р.: Я очень простой приведу кейс, секретного тут ничего нет. Примеров вообще много, но этот кейс — он вопиющий и немного смешной. У нас два data-центра, один в Америке, другой — в Европе. И когда мы запускали американский data-центр, мы подумали, а кого мы хотим там «приземлять» — и очевидно, что приземлять там нужно американцев, канадцев, а также жителей Латинской Америки. В общем всех, кто живёт в Южной и Северной Америках. Отлично! И вот мы пожили так какое-то время и вдруг поняли, что у нас очень сильно тормозит Азия. И мы провели ряд исследований и поняли, что если бы мы кое-какие азиатские страны приземляли в Америке, а не в Европе, то было бы здорово. А теперь представьте себе: у вас есть страна, в которой уже есть несколько миллионов пользователей активных, и конкретно этих пользователей надо переселить с одного data-центра в другой. Вот, «эпичная» задача, она была у нас недавно решена.
Вед.: Здорово, и теперь у вас получается ещё и сама система, автоматизированные средства есть. Через эту прослойку вы можете гибко и легко, если вам это потребуется, пользователей перераспределять. Вообще здорово.
А.Р.: Мы изначально заложили это, да.
Вед.: Вот ещё тогда по поводу масштабирования. Вернёмся к нашим комментам, потому что пользователи много чего хотят узнать у тебя, Алексей. Федотов Вячеслав спрашивает: «А поделись-ка успешными результатами, какую Вы нагрузку держали». И тут ещё много что его интересует: размеры, интенсивность запросов, скорость обработки, сбор, хранение, длительность стабильной работы системы под этой нагрузкой — вот так вот.
А.Р.: Так, хорошо, я попробую перечислить какие-то ключевые штуки. Если я что-нибудь забуду, просто добавьте. Значит, что здесь важно. Важно, что та или иная часть отказывает всегда в большой системе. Просто потому, что много подкомпонентов, и с некоторой долей вероятности что-нибудь вылетает. Сказать, что мы держим кучу девяток в периоде, это, наверное, неправильно, но сервис у нас достаточно стабилен. Какой-то недоступности основных фич для пользователей в течение года у нас бывает, может быть, несколько часов. А что касается каких-то времён, то, наверное, я скажу про среднее время обработки одного запроса.
Запросы, конечно, разные. Если у вас есть нативное приложение для какого-нибудь iPhone или Android'а, то оно вообще «разговаривает» по http, но, грубо говоря, данные оно передаёт по специальным бинарным протоколам. Соответственно, получает данные не html, а тоже как по какому-то бинарному протоколу — это очень лёгкий запрос, это где-то, я думаю, микросекунды, может быть — десятки микросекунд, из которых процессорного времени — приблизительно треть, а остальное — это запросы к тем или иным storage-серверам, авторизованным серверам и так далее.
Если это непосредственно сайт, то, конечно, «реквест» потяжелее, но мы считаем нормальной ситуацией, если на серверной стороне время обработки скрипта держится в районе 0,1-0,2 секунд, причём 0,2 секунды — это уже, конечно, многовато для нас. Я опять же говорю не о процессорном времени, а о времени общем, которое включает в себя запросы к базе данных, если понадобится, запросы к кэшам и так далее. А в случае, если это время превышает 0,5 секунд на серверной стороне — для нас это сигнал к тому, чтобы лезть и разбираться, что не так. Пока этот порог не превышен, мы туда не лезем. Мы собираем практически с каждой application-ноды как раз средствами той самой упомянутой Pinba, всю-всю информацию о времени реквеста – url, сколько процессорного времени, сколько общего времени, какие дополнительные таймеры, и всё это у нас собирается на отдельном сервере и строится статистика, то есть мы можем построить любое распределение для любого URL.
Вед.: Алексей, я ещё такой вопрос хотел задать актуальный: если очень много серверов баз данных, то как организовывать процесс бэкапов? Как вообще у вас это сделано и какие вы инструменты используете, и еще есть ли у вас какая-то автоматика, если какой-то узел падает, то есть замена «на лету» или ещё какая-то замена?
А.Р.: Тут сразу всё намешано, давай по порядку. Первое, с бэкапами. Как правило, когда делаются такого рода решения на сотни серверов, то встаёт выбор следующий: а хотим ли мы иметь возможность, в случае отказа какого-то сервера, мгновенно дать возможность пользователям работать с системой на другом сервере? Или мы готовы терпеть то, что в течение какого-то времени — например, вылетел диск и по какой-то причине rebuild занимает какое-то время или нужно просто быстро что-то заменить с отключением питания, с выводом из строя ноды? Почему это вопрос важный с точки зрения бизнеса? Потому что, представь себе, социальная сеть, 100 миллионов пользователей, например, живёт на тысяче серверов. Беру, цифры, может быть, слишком большие, но чтобы легче было считать. В этом случае на одном сервере будет жить — сколько у нас там 0,001 от 100 миллионов — 100 000 юзеров. Дальше два варианта: либо нам нужно не 1000 серверов, а какое-то другое число серверов, сильно больше и с возможностью «горячей замены», бэкапов, то есть чтобы какой-то новый сервер полностью подхватил нагрузку, и при этом пользователи не пострадали. Либо мы готовы терпеть, что одна тысячная нашего кластера будет недоступна в течение нескольких часов. Мы приняли решение, что мы готовы терпеть. Поэтому, в случае если у нас неожиданно полностью выйдет из строя какая-то из баз данных, где живёт какой-то пользователь, то этот пользователь получит вежливое предупреждение, что мы сейчас отдыхаем, но буквально через несколько часов всё будет нормально. Вероятность такого события достаточно невелика. Потому что тут вопрос именно в вероятностях: вероятность выхода из строя какая и сколько денег нужно потратить и вложиться, в том числе в разработку.
Вед.: Ну да, цена вопроса ещё, системы бэкапа дорогие получаются.
А.Р.: Я говорил на самом деле не про бэкап, а про горячую замену. А бэкапы можно сделать другими средствами, но с отставанием каким-то. Можно настроить репликацию, но мы, когда делали свою систему, фактически вынуждены были сделать свою замену стандартной репликации.
В 2005 году у нас было очень много всяких разных идей, и одна из них — сделать так, чтобы у нас репликация была фактически наша, statement based. И так получилось, что мы гоняем данные сейчас между data-центрами и между разными нодами через нашу собственную репликацию, она работает хорошо, но может быть чуть медленней, чем репликация родная. Она очень удобна нам в качестве отладки и всего прочего, но при этом мы опаздываем на какое-то количество минут, иногда и часов при большой нагрузке. То есть если у нас данные откажут вдруг, какой-то сервер откажет, то нужно будет полностью данные откуда-то перевливать — может быть, мы опоздаем с этим снэпшотом на какое-то время.
Опять же, поскольку мы говорим о таких данных, как апдейт юзерского профиля, я не говорю сейчас про деньги (деньги — это вообще отдельная подсистема), то мы готовы это терпеть. А что касается горячего, то это бэкап, который делается так или иначе в таком режиме, всегда и постоянно. При этом время от времени мы делаем горячий бэкап. Но это уже делают админы специализированными средствами для MySQL.
Вед.: Mysqldump какой-нибудь, что-то такое базовое, да, или что-то более сложное?
А.Р.: Я не хочу сейчас вам врать. Если интересно, то можете спросить меня чуть позже об этом, и я узнаю у админов.
Вед.: Понятно. Смысл в том, что просто делается как бы руками и в какие-то определённые моменты, когда это требуется, да?
А.Р.: Да, связано это с тем, чтобы не гонять данные, например, через океан, и чтобы быстро получить локальную копию данных.
Вед.: Вот ещё такой вопрос: скорость роста данных, она вообще какая? То есть «грузовики» с жёсткими дисками вам с какой скоростью надо покупать?
А.Р.: Мы вообще в этом смысле — в плане данных в базах — не очень сильно растём. То есть то, как растут, например, у нас фотографии: мы загружаем, кажется, по несколько миллионов фото на каждый data-центр в сутки. Так фотографии куда больше у нас «отжирают» места, нежели базы данных. Мы закупаем, наверное, несколько десятков машин — условно 10-15 машин в год на каждый data-центр.
Вед.: Алексей, если всё-таки вернуться к стеку технологий, получается вы используете в основном на ваших front-end, на серверах — PHP, да, а сервер какой? Вы что выбрали, nginx?
А.Р.: Конечно, nginx.
Вед.: Кстати, отдельный респект за PHP-FPM. Я, честно говоря, не знал — видимо, в то время я был ещё совсем молод и зелен, потому что я ещё помню, как я пришёл вот работать в компанию, там где я сейчас работаю — FlySoft, и вот тогда ещё там только начинались разговоры, что вот FPM-ку включат в поставку PHP уже по дефолту, а для меня тогда это было ещё такая сфера несколько неизведанная и я только начал это изучать, но помню, уже тогда мы перешли и отказались от Apache полностью, использовали nginx и PHP-FPM, в общем-то, обработки запросов «пыхой». Что ещё интересует: используете ли вы или как-то облачные сервисы, не знаю, Amazon S3 для хранения статики, EC2 для каких-то вспомогательных вещей. Вот некоторые поднимают инстансы при критической нагрузке, чтобы хоть себя кратковременно как-то обеспечить, или вы изначально всегда своими силами всё это делаете на своём хостинге в своих data-центрах?
А.Р.: Мы всё делаем в своих data-центрах. Вообще, если говорить про облака, я не большой специалист во всём этом — всё, что я могу здесь сказать, это то, что если используется «чужое облако», то скорее всего, вас так или иначе подрежут по ресурсам, и вы никогда не узнаете, где и как. Вот в этом вся проблема. То есть если вы пытаетесь сделать что-то такое, что у вас живёт на одном-двух серверах, а потом вам вдруг понадобилось десять краткосрочно, может быть, это сработает. В случае, если у вас тысячи серверов, необходимость использования каких-то облачных решений для меня сомнительна. Разве что у вас там что-то очень простое, и вам совсем не нужен штат, и вы готовы платить деньги. А что касается того, где мы так или иначе с облаками соприкоснулись, как ни странно, это две вещи: во-первых, CDN, а во-вторых — наша площадка разработки. Назвать её «облачной» будет не совсем правильно, но мы достаточно активно здесь используем виртуализацию.
Дело в том, что в нашем офисе, на самом входе, есть большая комната с серверами, которая мигает лампочками. Там несколько стоек. У нас внутри офиса маленький data-центр. Нам это нужно для того, чтобы всю нашу инфраструктуру, включая деплой, повторить, иметь здесь дата-центр хотя бы, в каком-то микромасштабе, иначе нормальным образом разрабатывать мы не можем. И естественно, для этого дела мы активно используем виртуализацию. Поэтому у нас там есть такое маленькое облако из нескольких десятков, и, наверное, уже скоро будет больше сотни разных виртуальных машин, которые выполняют разные роли.
Вед.: Понятно.
А.Р.: Это что касается нашей девелоперской площадки. Что касается CDN'а, то да, мы используем там какие-то решения, но сейчас мы понимаем, что на них очень тяжело влиять. То есть если мы хотим сделать какой-то очень-очень хитрый research по connectivity, например, почему у пользователей из Южной Кореи среднее время загрузки картинки занимает такое-то время. Вот взять и получить от CDN'а какую-то детальную статистику и каким-то образом её обработать — достаточно сложно, если это большой CDN. Ну и просто потому, что все, все хотят зарабатывать деньги и предоставить какую-то достаточно стабильную вещь. А там, где идёт борьба за какие-то там доли секунды при загрузке — там уже нужно привлекать инженеров, чтобы у вас был выделенный инженер, чтобы под вас делался какой-то research. Это, конечно, делать никто не хочет. Поэтому сейчас у нас только часть кластера использует CDN. Мы экспериментируем и сравниваем, то есть мы отдаём что-то через свои точки, где-то делаем локальные CDN и используем чужой CDN, и делаем всякие разные интересные сравнения.
Вед.: Ну в принципе это здорово, что у вас есть такая микроинфраструктура внутри вашего же офиса. Мы сейчас тоже думаем, стоит — не стоит, я смотрю в сторону Vagrant, с ним разбираюсь, в принципе, хорошая вещь. А что вы используете для кэширования? Ты упоминал про memcached да?
А.Р.: Да, самый прекрасный и «тупой» memcached — наше всё.
Вед.: Ага, а смотрели что-то типа этих новомодных Redis'ов, прочие вещи такие?
А.Р.: Конечно, смотрели. Но мы в production не стали использовать. То есть где-то там, временно, Redis прожил на каком-то из побочных проектов. В production нас полностью устраивает memcached.
Вед.: То есть вы его хорошо знаете, всего его стороны, все тонкости настройки и работы, поэтому вы решили его и использовать и используете, и довольны, я так понял?
А.Р.: Да, причём он настолько тупой, что его там знать? И своей тупостью он не даёт ничего нагородить, это вообще один из прекрасных инженерных принципов создания тех или иных инструментов — сделать инструмент настолько тупым, чтобы даже инженер с большой и богатой фантазией не смог использовать этот инструмент так, чтобы (смех)…чтобы всё сломалось.
Вед.: Ага, кстати, мы здесь подходим ещё (смех) к одному интересному вопросу. Спрашивает нас Роман Скваж, и у меня такие мысли тоже были: «Какие вы подходы используете в разработке? Вы стараетесь писать что-то элегантное и легко поддерживаемое или грязное, но более производительное?» Вот так вот меня спросили. То есть я здесь немножко перефразирую: вы стараетесь использовать всяческие решения типа, допустим, ORM для базы данных, вот такие всякие красивые обёртки, что-то дающее, может быть, синтаксический сахар, упрощающее количество, я не знаю, кликов, либо вы стараетесь писать более низкоуровневый код, более быстро выполняющийся? Какое твое мнение? Я знаю, что у тебя был доклад какой-то, ты там что-то плохое говорил, что есть неправильные решения архитектурные типа ORM и так далее. Вот расскажи про это, как вы на это смотрите, что используете, а что не используете?
А.Р.: Давай разделим вопрос на две части — ORM уйдёт во вторую часть, потому что это вообще отдельная история, и она фундаментальная и никак не связана с методологией разработки «элегантно — не элегантно». Нельзя ответить на вопрос однозначно, потому что, что такое, например, «сделать красиво»? Сделать красиво — долго. Поэтому если что-то на production сломалось, то чаще всего используется подход такой: если сломалось что-то очень важное и, допустим, оно всё-таки должно быть красивое, потому что к этому всё время приходят новые разработчики, они должны легко разобраться там и так далее, мы правим грязно, но это сразу же идёт в среднесрочную перспективу задач на рефакторинг. Это задача менеджера — так «разрулить» ситуацию, чтобы с одной стороны и бизнес не пострадал, а с другой стороны, в долгосрочной перспективе, чтобы технический долг не накапливался.
Инженер в такой ситуации часто скажет: «Нет, вот пусть всё лежит и не работает, я буду делать всё правильно». Ну, естественно, я утрирую. Но часто такое бывает, что инженер с самого начала хочет сделать всё хорошо и не хочет делать криво. Иногда нужно сначала сделать криво, но при этом договориться, чтобы сразу же на ближайшую перспективу заложили рефакторинг — вот это самый лучший способ.
Продолжение следует...
И мы будем рады вашим отзывам о том интересен ли такой формат и продолжать ли выкладывать расшифровки.
Слушать подкаст полностью
Скачать выпуск подкаста
