Insight IT

Sun Unified Storage

Иван Блинков — Wed, 13 Jan 2010 20:34:00 +0300

По работе мне доводилось активно "иметь дело" с железкой от Sun под названием Sun Unified Storage 7410. Представляет собой достаточно мощную систему хранения данных с установленным Solaris, но доступом и управлением исключительно через веб-интерфейс. Основной "фишкой" системы является модульность: дисковый массив наращивается подключаемыми внешне дисковыми модулями по примерно 20-50ТБ, сетевой интерфейс также модульный - на выбор начиная от нескольких обычных Ethernet по 1GBps и заканчивая оптоволокном, CX4 или InfiniBand. Две таких машины можно легко объединить в одну виртуальную для повышения надежности доступа к данным, подключив к ним общий дисковый массив. RAID используется софтверный средствами ZFS, вполне стандартный набор опций из зеркалирования, stripe, RAID5/6 и их комбинаций.

С точки зрения производительности тоже достаточно интересная штука: при подключении через 4x 1GBps Ethernet (с использованием LACP, но это тема для отдельного поста) определенно упирается в сеть, но все равно отлично подходит для использования в решении многих прикладных задач. Из интересных опций можно отметить прозрачное использование нескольких SSD-дисков в каждом дисковом массиве в роли кэша.

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

К чему я это все вспомнил? На почту пришел очередной рекламный буклет от Sun с предложением попробовать Sun Unified Storage в виртуальной машине VirtualBox или VMWare, сам еще не установил - времени не нашлось, но возможно Вам покажется интересным. Конечно это не совсем то же самое, что и физическая железка - производительность дисковых и сетевых подсиситем не померять, но веб-интерфейс заценить можно.

Архитектура LinkedIn

Иван Блинков — Thu, 11 Sep 2008 04:00:00 +0400

LinkedIn является крупнейшей в мире социальной сетью для профессионалов. Популярность этого проекта может быть далека, от более общетематических социальных сетей, таких как, скажем Facebook, но, тем не менее, нагрузка на серверную часть проекта создается пользователями серьезная. О том как этот проект с ней справляется и пойдет речь далее.

Предисловие

Сообщение о публикации двух презентаций c JavaOne 2008 о LinkedIn и их обобщении от Overn Hurvitz пронеслось по русскоязычным новостным ресурсам уже достаточно давно, но время черкнуть пару строк обо всем этом нашлось у меня только сейчас.

Статистика

22 миллиона пользователей;
4+ миллиона уникальных посетителей в день;
40 миллионов просмотров страниц в день;
2 миллиона поисковых запросов в день;
ежедневно отправляются 250 тысяч приглашений;
1 миллион ответов в день;
2 миллиона электронных сообщений ежедневно.

Платформа

Solaris (как x86, так и SPARC)
Tomcat и Jetty
Oracle и MySQL
Никакого ORM
ActiveMQ для JMS
Lucene в качестве основы для поиска
Spring в роли "клея"

Серверная архитектура

2003-2005

одно монолитное веб-приложение;
одна общая база данных;
сетевой граф кэшируется в памяти в "Облаке";
поиск пользователей реализован с помощью Lucene, он работал на той же машине, что и "Облако", так как поиск был отфильтрован в соответствии с сетью пользователя, таким образом было удобно совмещать эти две функции на одной машине;
веб-приложение напрямую обновляет базу данных, а она, в свою очередь, обновляет "Облако".

2006

Добавлена репликация для уменьшения нагрузки на основную базу данных. Реплики предоставляют данные в режиме "только для чтения", а репликация ведется в асинхронном режиме с помощью дополнительного компонента под названием Databus, с его появлением обновление данных стало выглядеть следующим образом:
- сначала какие-либо изменения происходят в веб-приложении;
- веб-приложение обновляет основную базу данных;
- она, в свою очередь, отправляет обновления на Databus;
- далее уже Databus обновляет: реплики, Облако и поисковый индекс.
Поиск был вынесен на отдельный сервер.

2008

веб-приложение само по себе практически ничего не делает: бизнес логика распределена по отдельным сервисам;
веб-приложение все так же предоставляет пользователям графический интерфейс, но для его генерации она теперь вызывает сервисы;
каждый сервис имеет свою специфическую базу данных (т.е. вертикальное сегментирование);
такой подход позволяет другим приложениям (помимо основного) получать доступ к LinkedIn, такие приложения были созданы для работодателей, рекламных служб, и так далее.

Облако

"Облаком" в LinkedIn называют сервер, который кэширует весь граф социальной сети в памяти;
его размеры: 22 миллиона вершин и 120 миллионов ребер;
занимает 12GB оперативной памяти;
одновременно держится в памяти в 40 экземплярах;
построение Облака из данных, в дисковой системе, занимает 8 часов;
обновления происходят в режиме реального времени с помощью Databus;
во время остановки данные записываются на диск;
кэш реализован с помощью C++, а доступ предоставляется по JNI;
они выбрали именно C++ так как требовалось использовать минимум оперативной памяти, а также, задержки, связанные с Garbage Collection, были неприемлемыми.
размещение всех данных в памяти является ограничением, но, как удалось выяснить в LinkedIn, разбиение графов на части - не самая тривиальная задача.

Облако кэширует целиком весь граф социальной сети LinkedIn, но на практике же пользователям требуется видеть его со своей точки зрения. Данная задача является вычислительно сложной, по-этому она выполняется лишь один раз при создании новой сессии, а затем система поддерживает результат в кэше. Такой подход требует 2 MB оперативной памяти на каждого активного пользователя. В течении сессии такой кэш обновляется только если сам пользователь сделал какие-либо изменения в нем, если же изменение вызвано другими пользователями - владелец сессии не заметит изменений.

Помимо этого используется кэширование профилей пользователей средствами EHcache. Одновременно в памяти хранится до 2 миллионов профилей (из 22 миллионов). Изначально планировалось использовать алгоритм LFU, но оказалось, что иногда EHcache зависал секунд на 30 во время перерасчета LFU, таким образом было принято решение о использовании вместо него алгоритма LRU.

Архитектура коммуникации

Как известно, пользователи практически любой социальной сети генерируют огромное количество сообщений в единицу времени, причем каждый тип сообщений обычно требует индивидуального подхода, но в целом их можно разделить на две категории: постоянные и временные. В LinkedIn разработчики построили по отдельному сервису, для обработки каждой из этих категорий. Каждый из них определенно заслуживает отдельного внимания, так как общего в них мало.

Сервис постоянных сообщений

Этот коммуникационный сервис выполняет все операции, связанные с постоянными сообщениями: приватными сообщениями и электронной почтой. Перед ним ставится вполне тривиальный ряд задач: доставлять сообщения получателям и сохранять их на постоянной основе, но на самом деле этим все не ограничивается: должны также поддерживаться, скажем, доставка сообщений с задержкой, массовые рассылки, отмена отправки сообщения, возможность добавления в сообщения какого-либо интерактивного контента. Реализован он был примерно следующим образом:

вся система работает асинхронно и активно использует JMS;
клиенты отправляют сообщения так же через JMS;
далее сообщения перенаправляются с помощью сервиса маршрутизации в соответствующий почтовый ящик или напрямую в обработку электронной почты;
доставка сообщений происходит как с помощью Pull (клиенты запрашивают свои сообщения), так и с использованием Push (т.е. отправки сообщений);
помимо этого используется Spring с их собственными закрытыми расширениями, использующими HTTP-RPC.

Приемы, способствующие масштабируемости

Функциональное сегментирование: отправленные, полученные, архивные сообщения. (т.е. вертикальное сегментирование)
Классовое сегментирование: пользовательские, гостевые, корпоративные почтовые ящики.
Сегментирование по диапазонам: по идентификаторам пользователей или по лексикографическим диапазонам самих сообщений. (т.е. горизонтальное сегментирование)
Асинхронное выполнение операций.

Сервис сетевых обновлений

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

Изначальная архитектура (до 2007 года)

используется много серверов, которые могут содержать обновления;
клиенты отправляют запросы на каждый сервис отдельно: вопросы, обновления профилей и т.д.
на сбор всех данных требовалось относительно много времени.

В 2008 году вся эта система поэтапно эволюционировала собственно в сам сервис сетевых обновлений:

Первая итерация

клиент отправляет единственный запрос сервису сетевых обновлений;
этот сервис в свою очередь параллельно отправляет всем остальным сервисам соответствующие запросы.
результаты агрегируются и все вместе возвращаются клиенту;
весь процесс основывается на Pull.

Вторая итерация

стал использоваться метод Push: каждый раз, когда происходит какое-либо событие, они помещаются в пользовательский "почтовый ящик", в момент запроса пользователя ему возвращается просто содержимое, уже ожидающее своего звездного часа в специально том самом "ящике";
такой подход сильно ускоряет процесс чтения, так как на тот момент данные уже готовы;
с другой стороны, какая-то часть данных может так никогда и не понадобиться, что приводит к бесполезным передвижениям данных и лишнему используемому дисковому пространству;
небольшая часть обработки данных все же производится уже в момент запроса пользователя (например, объединение нескольких обновлений от определенного пользователя в одно);
обновления хранятся в CLOB'ах: по одному CLOB'у на каждый тип обновления для каждого пользователя (то есть в сумму около 15 CLOB'ов на каждого пользователя);
сначала использовался размер CLOB'ов равный 8 KB, что было явно больше требуемого и приводило к существенному количеству неиспользуемого дискового пространства.
вместо CLOB'ов можно было бы использовать дополнительные таблици по одной на каждый тип обновлений, но в этом случае пришлось бы постоянно удалять из них устаревшие записи, что было бы чрезвычайно неэффективно.
в дополнение к этому использовался JMX для мониторинга и изменения конфигурации в реальном времени, что оказалось очень удобным и полезным.

Третья итерация

Цель: повысить производительность путем сокращения количества обновлений CLOB'ов, так как они требуют много вычислительных ресурсов.
Был добавлен буфер: колонки в таблицах типа varchar(4000), в которых данные помещались изначально. При полном заполнении ячейки данные перемещаются в CLOB; это позволило на порядок сократить количество их обновлений.
Уменьшен размер самих сообщений об обновлениях.

И напоследок пару советов от LinkedIn

нельзя бесконечно долго ограничиваться одной базой данных: используйте много баз данных как с вертикальным, так и с горизонтальным сегментированием данных;
забудьте о ссылочной целостности и кросс-серверных JOIN'ах;
забудьте о 100% целостности данных;
при большом масштабе издержки могут стать проблемой: оборудование, базы данных, лицензии, системы хранения данных, электроэнергия и так далее;
как только вы станете достаточно крупны и популярны, спаммеры и прочие злые люди не заставят себя долго ждать;
не забывайте про кэширование!!!
используйте асинхронные потоки данных;
аналитика и построение отчетов может стать непростой задачей, постарайтесь задуматься о них заранее в процессе планирования системы;
имейте всегда ввиду, что Ваша система может упасть в любой момент;
не стоит недооценивать траекторию своего роста.

P.S.

Когда уже закончил переводить в голову пришла мысль, что если читателям будет интересно взглянуть на оригинальные презентации (хотябы ради иллюстрационного материала, который там вполне нагляден), то было бы проще сделать это прямо здесь, так что вот, для Вашего же удобства:

Кстати если Вы еще не успели подписаться на RSS - сейчас самое время!

Архитектура Twitter

Иван Блинков — Sat, 10 May 2008 12:36:00 +0400

Twitter стартовал как побочный подпроект, но не смотря на это темпы его роста были впечатляющими: путь от 0 до миллионов просмотров страниц занял всего несколько коротких месяцев. Ранние решения о проектировании системы неплохо справлялись с небольшими нагрузками, но они быстро таяли под напором огромного количества пользователей, желающих разослать весточки всем своим друзьям с ответом на простой вопрос: а чем ты занимаешься?

Поначалу все винили Ruby on Rails во всех проблемах с масштабированием, но Blaine Cook, главный архитектор Twitter, встал на его защиту:

Основной для нас на самом деле является проблема горизонтального масштабирования, с этой точки зрения Ruby on Rails ничем не хуже других языков программирования или framework'ов: переход на "более быстрый" язык программирования дал бы нам 10-20% прирост производительности, в то время архитектурные преобразования, легко реализованные средствами Ruby on Rails, сделали Twitter быстрее на 10000%.

Даже если Ruby on Rails оказался невиновен, как же тогда Twitter научился с его помощью рости до все больших и больших высот?

Источники информации

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

Scaling Twitter Video от Blaine Cook.
Scaling Twitter Slides
Good News блог пост от Rick Denatale
Scaling Twitter блог пост от Patrick Joyce
Twitter API Traffic is 10x Twitter’s Site
A Small Talk on Getting Big. Scaling a Rails App & all that Jazz

Платформа

Статистика

Более 350000 пользователей. Точная цифра, как обычно, держится в секрете.
Около 600 запросов в секунду.
В среднем система поддерживает 200-300 соединений в секунду. Максимум обычно достигается при значении 800.
MySQL обрабатывает примерно 2400 запросов в секунду.
180 экземпляров приложений на Rails, использующих Mongrel как веб-сервер.
1 MySQL сервер (одна большая машина с 8 ядрами) и 1 slave, используемый лишь для статистики и отчетов.
30+ процессов для выполнения произвольных работ.
8 Sun X4100
Обработка запроса обычно занимает у Rails 200 миллисекунд.
В среднем ответ на запрос к базе данных занимает 50-100 миллисекунд.
Более 16 GB выделено под memcached.

Архитектура

Проект столкнулся с массой проблем, связанных с масштабируемостью. Маленькая птичка частенько давала сбои.
Изначально не было реализовано никаких форм мониторинга, графиков или статистики, это очень затрудняло обнаружение м решение возникающих проблем. Впоследствии были внедрены Munin и Nagios. Разработчики столкнулись с некоторыми трудностями при использовании этих продуктов в Solaris. Помимо этого был использован сервис Google Analytics, но от него обычно мало толку, особенно когда страницы даже не загружаются.
Активное использование кэширования средствами memcached:
- Например, если подсчет количества чего-либо выполняется медленно, намного эффективнее один раз запомнить результат в memcached, чем каждый раз считать его заново.
- Получение информации о статусе своих друзей - непростая задача. Вместо использования запросов информация о статусе друзей обновляется в кэше. База данных совсем не используется. Такой подход позволяет получить предсказуемое время отклика (ограниченное сверху примерно 20 миллисекундами).
- Объекты ActiveRecord настолько велики, что кэширование их нецелесообразно. Критичные атрибуты хранятся в хэше, а остальная их часть подвергается "ленивой загрузке" в момент запроса на доступ.
- 90% запросов являются запросами к API. Таким образом кэширование страниц или их фрагментов становится бессмысленным, зато никто не мешает им кэшировать сами API запросы.
Внутренняя организация работы с сообщениями:
- Сообщения очень активно используются: производители генерируют сообщения, они образуются в очереди, а затем распространяются по потребителем.
- Основная функция Twitter заключается в реализации своеобразного моста между различными форматами электронных сообщений (SMS, электронная почта, сервисы мгновенного обмена сообщениями и так далее).
- Чтобы инвалидировать в кэше информацию можно просто отправить внутреннее сообщение, зачем выполнять все действия синхронно?
- Изначально этот механизм основывался на DRb (distributed Ruby) - библиотека, позволяющая отправлять и принимать сообщения сообщения между удаленными Ruby-объектами по TCP/IP. Но она была несколько странноватой, да и являлось потенциально слабым местом с точки зрения стабильности.
- Со временем сервис перевели на Rinda, представляющую собой набор общих для всей системы очередей. Но и у нее были недостатки: все очереди были постоянными, а данные терялись при сбоях.
- Следующей попыткой был Erlang. Но однажды возникла проблема: каким образом сломавшийся сервер может продолжать работать, но при этом в очереди откуда-то возникли целых 20000 ожидающих пользователей? Разработчики не знали. На лицо явный недостаток документации...
- В конце концов решение было разработано своими силами: Twitter выпустил Starling, распределенный легковесный сервер очередей, написанный на Ruby и поддерживающий протокол memcache. Сейчас серверная часть Twitter управляется именно им.
- Распределенные очереди позволяют переживать сбои путем записи их на диск в критических ситуациях. Другие крупные интернет-проекты также часто пользуются таким подходом.
Работа с SMS осуществляется с помощью сторонних сервисов и предоставляемых ими шлюзов. Достаточно дорогое удовольствие.
Развертывание:
- Просто запускаются дополнительные сервера с mongrel, более элегантного решения пока нет.
- Все внутренние ошибки выдаются пользователям, если обслуживающий их mongrel сервер на данный момент заменяется.
- Все сервера останавливаются одновременно. Отключение их по одному по определенным причинам не используется.
Неправильное использование сервиса:
- Много времени сервис был не доступен, так как люди проходились специальными программами по сайту с целью добавить всех кто попадался под руку в друзья. 9000 друзей за 24 часа. Это просто-напросто останавливало работу сайта.
- Были разработаны средства для своевременного обнаружения таких ситуаций.
- Будте беспощадными, таких пользователей нужно просто удалять.
Сегментирование:
- Пока оно только в планах, сейчас оно не используется.
- В будущем оно будет основываться на времени, а не на пользователях, так как запросы обычно очень локальны по времени.
- Сегментирование будет не так просто реализовать благодаря автоматическому запоминанию результатов выполнения функций для последующего повторного их использования. Никто не даст гарантии, что операции "только для чтения" на самом деле будут таковыми являться. Запись в slave, работающий в режиме read-only, - не самая лучшая идея.
API Twitter генерирует в 10 раз больше трафика, чем сам сайт.
- Их API - самая важная вещь из всех, что они разработали.
- Простота сервиса позволила разработчикам строить свои приложения поверх инфраструктуры Twitter, привнося все новые и новые идеи. Например, Twitterrific - красивый способ использовать Twitter в небольшой команде.
Мониторинг используется для остановки слишком больших процессов.

Подводим итоги

Общайтесь со своим сообществом. Не прячьтесь и не пытайтесь решить абсолютно все проблемы самостоятельно. Много отличных людей будут готовы помочь, достаточно лишь попросить.
Рассматривайте вашу стратегию масштабирования как бизнес-план. Соберите советы помощников для того чтобы облегчить для себя принятие решений.
Стройте свой проект сами. Twitter потратил много времени, пытаясь приспособить готовые решения других людей, которые казалось бы должны работать, но это оказалось не совсем так. Лучше построить какие-то вещи самостоятельно, чтобы иметь высокую степень контроля над ситуацией и иметь возможность привносить новые возможности как только они понадобились.
Ставьте перед своими пользователями разумные ограничения. На обычных пользователей это не повлияет, но когда кому-нибудь взбредет в голову попытаться сломать систему (а такой человек рано или поздно найдется) - они сыграют свою роль и спасут работоспособность системы.
Не делайте базу данных центральным узким местом системы, врядли Ваше приложение на самом деле требует гигантских операций по объединению данных из нескольких таблиц. Используйте кэширование, или проявите свою смекалку для поиска альтернативных способов достижения того же результата.
Предусмотрите возможность сегментирования с самого начала, тогда перед Вами всегда будут открыты пути для дальнейшего масштабирования.
Очень важно вовремя осознать, что сайт начинает работать медленно. Сразу стоит задуматься о системе отчетов для отслеживания потенциальных проблем.
Оптимизируйте базу данных:
- Индексируйте все таблицы, Rails не будет делать это за Вас.
- Используйте "explain" для анализа выполнения запросов. Результаты могут не совпадать с Вашими ожиданиями.
- Денормализуйте данные. Один только этот совет порой может спасти ситуацию. Для примера, в Twitter хранят все ID друзей каждого пользователя вместе, это позволило избежать многих ресурсоемких запросов.
- Избегайте комплексного объединения данных из нескольких таблиц.
- Избегайте сканирования больших наборов данных.
Кэшируйте все, что только можно.
Тестируйте все максимально тщательно:
- Когда Вы развертываете приложение, Вы должно быть уверены, что оно будет работать корректно.
- Они используют полный набор средств для тестирования. Таким образом, когда произошла неполадка в кэшировании, они узнали о ней еще до того как она на самом деле произошла.
Длительно функционирующие процессы стоит оформить в виде daemon'ов.
Используйте уведомления об исключительных ситуациях в совокупности с ведением логов, это необходимо для своевременного реагирования на них.
Не делайте глупостей!
- Масштаб проект несколько меняет понятие "глупость".
- Пытаться загрузить 3000 друзей в память одновременно может заставить сервер временно перестать функционировать, хотя когда друзей было всего 4 - этот механизм прекрасно работал.
Большая часть производительности зависит не от использованного языка программирования, а от продуманной структуры приложения.
Превратите свой сайт в открытый сервис с помощью создания API. Их API является ключом к успеху Twitter. Он позволяет пользователям создавать постоянно расширяющуюся экосистему вокруг Twitter, соревноваться с которой не так-то просто. Вы никогда не сможете сделать столько же работы, сколько смогут Ваши пользователи для Вас, Вам просто не хватит креативных идей. Так что не стесняйтесь, откройте свое приложение и сделайте интеграцию Вашего приложения с другими максимально простой и удобной!