Перспективы ЖЖ

vmenshov — 13.01.2013 Прочитал недавно пост Главного по ЖЖ на тему глюков сервиса. Я, как директор по разработке, хочу сказать, что ничего хорошего нас не ждет. И вот почему.

Рассмотрим выявленные проблемы:

1) Cбои в оборудовании (случающиеся хоть и крайне редко, но все-таки случающиеся).

Что у нас ломается из оборудования? По моему опыту экслуатации 40-ка сервеной системы полнотекстового поска, в 95% случаев это жесткие диски. В 4% случаев это проблемы с провайдером. В оставшийся процент входит все остальное. Насколько я знаю, у ЖЖ три копии базы данных. Каждая из копий, наверняка хранится на RAID массивах, для которых выход из строя части дисков не влечет потери данных и выхода копии из эксплуатации, а только уменьшает скорость доступа к той части базы, которая хранится на этом массиве. Но уменьшает не драматично. Любая самая левая система мониторинга при этом тут же начинает орать и визжать. Чинится это заменой поломанного винта. Через пару часов вылетевший узел выходит на штатный режим работы. При ЖЖ-ных объемах данных в несколько терабайт, и при троекратном дублировании должно было сломаться как минимум более половины оборудования, чтобы произошел такой сбой. Это просто невероятная ситуация. Из чего там это оборудование собрано, раз все так ломается? А если просто часть дисков вышла из строя, то оказать существенного влияния на работу ЖЖ это не могло. Если это не диски, то тогда виноват провайдер. Но это уже не проблема железа ЖЖ, это проблема голимого хостинга. Но про хостинг в ответе ни слова.

2) Значительный рост нагрузки, в данном случае вызванным вредоносным трафиком;

Для того чтобы завалить систему, рассчитанную на миллионы пользователей, надо сгенерировать вредоносный трафик на 10 миллионов пользователей. Конечно, генерить запросы проще, чем отвечать на них, но для того, что бы завалить уютненькую, у нее должны быть враги, обладающие системой по крайней мере сравнимой с ней самой. Почему, например, от DDOS не падает фэйсбук и вконтактик? Потому что только они сами могут заддосить друг друга. Яндекс может, Гугл, Ютуб. Системы рассчитаные на десятки а то и сотни миллионов одновременно работающих пользователей. У анонимных хакеров не хватит ни денег, ни трафика что бы хоть как-то ощутимо повлиять на их работу. А вот ЖЖ почему-то очень к такому трафику чувствителен. Даже кэш не спасает. Очень это все странно. Правда если накроется канал, то и обычный трафик «положит» ЖЖ. То есть сам ЖЖ будет работать как ни в чем не бывало, только пользователи будут лицезреть старину Фрэнки. Может проверить все-таки провайдера?

3) Неоптимальность некоторых SQL запросов, созданными еще во время основания ЖЖ;

Вот это единственная дельная причина. И очень печальная. Но она говорит нам о том, что в ЖЖ до сих пор никто не занимается оптимизацией движка. Как он был написан более 10 лет назад, так он и остался. И только когда все легло напрочь, разработчики удосужились заглянуть в ядро системы. А именно с этого надо было и начинать. И не сейчас, а несколько лет назад. Увеличение мощности железа тут результатов не даст. Толпа клонированных дистрофиков не выиграет марафон.

4) Перенос серверов, обслуживающих СУБД, на файловую систему ZFS, произведенную c целью улучшения DR составляющей ЖЖ.

Я не знаю что такое «DR составляющая ЖЖ» зато прекрасно знаю как работают базы данных и диски. Так вот по сути, БД — это несколько очень больших файлов. Внутри этих файлов хранятся так называемые «страницы» с данными, по нескольку килобайт. Управлением страницами внутри файла занимается сама база данных, а не операционная система, поэтому какую файловую систему не поставь, существенного толку от этого не будет. Диск-то работает также. Ну максимум там кэш можно включить-отключить, но и сама СУБД прекрасно умеет кэшировать данные с диска. Так что замена файловой системы, это выжимание последней капельки из дохлой кошки, упавшей в ведро с водкой. Никакого ощутимого прироста это не даст.

Но еще печальнее причин выглядят дальнейшие шаги:

1) Мы откатим файловую систему ZFS до предыдущей, в случае, если нам не удастся стабилизировать ее использование совместно с СУБД в момент пиковых нагрузок;

Это замена мыла обратно на шило, как я уже объяснял выше.

2) Мы обновим всю систему выдачи ошибок с целью их более детального отображения, включая сообщения о том, что некоторые пользователи не могут получить доступ к ЖЖ ввиду попадания их сетей в список блокируемых;

Как это поможет увеличению стабильности работы? Пользователь вместо Фрэнка увидит, что теперь он в заблокированной сети? Это совершенно бесполезное знание. Сам сервис как лежал так и будет лежать дальше.

3) Мы уже обновили систему мониторинга, сделав ее более глобальной, в плане возможности определения потенциальных проблем с доступом не только из США, но Европы и России;

То есть теперь, если проблема возникнет, пост о ней будет написан быстрее, так надо понимать? Как это увеличит надежность и производительность сервиса?

4) Мы уже изменили свои процедуры эскалации проблем с доступом и доступностью, что позволит нам в будущем решать их значительно быстрее, нежели раньше.

Теперь olegfreedom не сможет спокойно бухать с собаками, у него теперь душа будет болеть за ЖЖ во время сбоев. Это тоже, видимо, существенно увеличивает работоспосбность трех копий базы данных.

5) В связи с частичной недоступностью ЖЖ в течении новогодних каникул, действие всех платных аккаунтов будет продлено на 1 месяц в ближайшее время.

Это, конечно, приятно, но от этого уютненькая надежнее не станет.

Итого получается, что не будет предпринято ни одного реального шага по исправлению ситуации. Все меры будут направлены на то, чтобы руководство ЖЖ узнало о сбое не на четвертый день, а скажем, на второй. Это расстраивает.

Но есть еще один момент. Вопрос, что же делать в этой ситуации так и остался без ответа. Я не знаю, насколько серьезна ситуация с движком ЖЖ на самом деле, и на сколько там компетентные специалисты. Однако осмелюсь дать несколько советов, что бы я делал в первую очередь.

1) Проверить, что там с каналом от провайдера. Возможно он вовсе не такой широкий, каким кажется. У меня бывали случаи, когда со стороны провайдера бьют себя в грудь и мамой клянутся о 50-ти мегабитах, а тесты показывают 256 килобит. Даже если канал держит нагрузку, возможно его нужно расширить. Тогда ддосеры разобьются об кэш.

2) Увеличить количество серверов, работающих на получение и выдачу контента. Это поможет бороться с DDOs-ом и увеличит производительность ленты, как мне кажется, одного из самых ресурсоемких запросов ЖЖ. Опять таки, при наличии нормального кэша.

3) Провести тотальную ревизию движка. Выделить самого умного кодера, фаната бинарных деревьев, хэшей и алгоритмов слияния, которому по ночам снятся оптимальные планы SQL-запросов. Пусть он там все перешерстит. Может индексов где не хватает, а где наоборот, 10 лишних и не используемых, которые тормозят запись в базу и занимают место. В некоторых случаях тюнинг запросов может давать стократный прирос производительности. Конечно, скорость работы всей системы от этого в сто раз не вырастет, но прирост может быть весьма ощутимым.

4) Выполнить партиционирование таблиц с записями по дате, а таблиц с каментами по Id записи. Свежак хранить на SSD рэйдах, старье заливать на HDD. Проводить перепартиционирование раз в месяц. (Правда я не в курсе, насколько у mysql с этим хорошо, я давно не работал с этой базой). Это позволит львиную часть запросов осуществлять по гораздо меньшему объему данных. Что существенно увеличит производительность БД.

5) Ограничить максимальную глубину дерева каментов и ввести для них иерархический ключ. Тогда дерево коментов будет получатся одним запросом, вместо дерева нисходящих запросов. Плюс в страницах БД комментарии будут лежать рядом, что существенно уменьшит количество I/O reads. Сейчас, как я понимаю, каменты привязаны только к родителю. Поэтому вместо одного запроса приходится делать столько запросов, сколько всего потомков вниз по всем уровням от раскрываемого камента. Кроме того, при такой организации таблицы, комментарии одного дерева хранятся в разных местах на диске, потому что сортируются в по ключу Id, который зависит от времени создания комментария. Если же сделать иерархический ключ, то комментарии одной ветки будут хранится рядом друг с другом, что потребует существенно меньшего количества обращений к диску. Ведь жесткий диск, при случайном доступе к данным — самое тормозное по место системы. Скажем SATA диск на 7200 оборотов позволяет сделать не более 120 считываний из разных места диска в секунду. Не очень, скажем, совместимая с миллионами пользователей производительность.

6) Если осуществить пункты 4 и 5 на mysql невозможно, то имеет смысл поговорить с ребятами из Oracle или Microsoft, с целью перевода ЖЖ на любую из их баз. Да, там космические суммы за лицензии, особенно у Оракла. Но я думаю, с учетом популярности ЖЖ, общий язык можно будет найти.

Я понимаю, что мои советы, это титаническая работа. Но без нее, по моему мнению, никак. Не выживет козел. Нельзя его вечно, хм, доить. Надеюсь, к моим словам прислушаются. Иначе, как мне кажется, этой лодке плыть не долго.

Оставить комментарий

Популярные посты:

• Ранее
• Архив