Wikimedia является платформой для Wikipedia, Wiktionary и еще семи менее крупных wiki-проектов. Этот документ очень пригодится новичкам, пытающимся довести свои проекты до масштабов гигантских вебсайтов. Здесь можно найти множество интересных деталей и инновационных идей, которые уже успели доказать свою работоспособность на самых посещаемых сайтах всего Интернета.

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

Перевод статьи. Автор - Todd Hoff.

Платформа

Статитстика

  • 8 миллионов статей распределены по сотням языковых подпроектов (английские, голландские, ...)
  • В десятке самых высоконагруженных проектов по данным Alexa
  • Экспоненциальный рост: в терминах посетителей, трафика и серверов удвоение происходит каждые 4-6 месяцев
  • 30000 HTTP запросов в секунду в периоды пиковой нагрузки
  • 3 GBps трафик данных
  • 3 датацентра: Тампа, Амстердам, Сеул
  • 350 серверов, конфигурации варьируются от однопроцессорных Pentium 4 с 512 MB оперативной памяти до двухпроцессорных Xeon Quad-Core с 16 GB RAM.
  • Управляется ~6 людьми
  • Три кластера на трех разных континентах

Архитектура

  • Географическая балансировка нагрузки, основываясь на IP клиента, перенаправляет их на ближайший кластер. Происходит статическое отображение множества IP адресов на множество стран, а затем и на множество кластеров.
  • Кэширование с помощью Squid группируется по типу контента: текст для wiki отдельно от изображений и больших статических файлов.
  • На данный момент функционирует 55 Squid серверов, плюс еще 20 подготавливается к запуску.
  • 1000 HTTP запросов в секунду на каждый сервер, в периоды повышенной нагрузки эта цифра может достигать 2500.
  • ~ 100-250 MBps на сервер.
  • ~ 14000-32000 открытых соединений на каждом сервере.
  • До 40 GB дискового кэша на каждом Squid сервере.
  • До 4 дисков в каждом сервере (1U серверы).
  • 8 GB оперативной памяти, половину использует Squid.
  • PowerDNS предоставляет геораспределение.
  • В основном и региональных датацентрах текстовые и медиа кластеры построены на LVS, CARPSquid, кэш Squid. В основном датацентре также находится хранилище медиа-данных.
  • Для того, чтобы обеспечить предоставление только последних версий страниц, всем Squid-серверам отправляются инвалидационные запросы.
  • Централизованно управляемая и синхронизированная установка программного обеспечения для сотен серверов.
  • MediaWiki отлично масштабируется с несколькими процессорами, так что закупаются двухпроцессорный четырех ядерные серверы (8 ядер на сервер).
  • Одно и то же оборудование выполняет как задачи внешнего хранения данных, так и кэширования Memcached.
  • Memcached используется для кэширования метаданных изображений, данных парсера, различий между ревизиями, пользователей, сессий. Метаданные, такие как история ревизий, отношений статей (ссылки, категории и так далее), учетные записи пользователей хранятся в основных базах данных
  • Сам текст находится во внешних хранилищах данных.
  • Статические (загруженные пользователями) файлы, например изображения, хранятся отдельно на сервере изображений, а метаданные (размер, тип и так далее) кэшируются в основной базе данных и объектном кэше.
  • Отдельная база данных для каждой вики (не отдельный сервер!).
  • Один master и много реплицированных slave серверов.
  • Операции чтения равномерно распределяются по slave серверам, операции записи направляются на master.
  • Иногда master используется и для операция чтения, когда репликация на slave еще не завершена.
  • Внешнее хранение данных:
    • Текст статей хранится на отдельных кластерах, которые представляют собой простой средство хранения данных с возможностью только дописывания новых данных. Такой подход позволяет сохранить дорогостоящее место в высоконагруженных основных базах данных от редко используемой информации.
    • Благодаря этому появляются дополнительные неиспользованные ресурсы на серверах приложений (порой 250-500 GB на сервер).
    • На данной момент используются реплицируемые кластеры из 3 MySQL серверов, но в будущем это может измениться, так как требуется более удобное управление ими.

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

  • Сфокусируйтесь на архитектуре, а не на операциях или чем-то другом.
  • Иногда кэширование обходится дороже, чем повторные вычисление или поиск данных в исходном источнике.
  • Старайтесь избегать сложных алгоритмов, запросов к базе данных и тому подобного.
  • Кэшируйте каждый результат, который дорого вам обошелся и является относительно локальным.
  • Сфокусируйтесь на "горячих точках" в коде.
  • Масштабируйтесь разделением:
    • операций чтения и записи (master/slave);
    • сложных операций и более частых и простых (группы запросов);
    • больших, популярных вики и более мелких.
  • Улучшайте кэширование: временная и пространственная локализация данных, а также уменьшение набора данных на каждом сервере.
  • Выполняйте компрессию текстовых данных, храните только изменения в статьях.
  • Казалось бы простые вызовы библиотечных функций порой на практике могут занимать слишком много времени.
  • Скорость поиска данных на диске ограничена, так что чем больше дисков - тем лучше!
  • Масштабирование с использованием обычного оборудование не означает использование самых дешевых вещей, которые удастся найти. Серверы баз данных Wikipedia сегодня представляют собой 16GB RAM, двух- или четырех-ядерные серверы с 6 15000 rpm SCSI дисками, организованными в RAID 0. Возможно они бы и использовали более дешевые системы, но 16 GB как раз хватает для размещения основного объема данных, а остальное берут на себя жесткие диски, это вполне соответствует потребностям системы, которую они построили. Примерно по таким же причинам их веб-сервера имеют 8 ядер, так как это позволяет достичь неплохой производительности PHP при достаточно простой организации балансировки нагрузки.
  • Для масштабирования требуется выполнение массы работы, но если заранее этого не предусмотреть - понадобится сделать еще больше. MediaWiki изначально была написана для одного master сервера баз данных. Затем добавилась поддержка slave. Затем добавилось распределение по языкам и проектам. Дизайн системы с тех пор прекрасно выдерживает все нагрузки, но без очистки от новых узких мест системы не обошлось.
  • Каждый, кто хочет разработать свою базу данных таким образом, чтобы она позволила недорого масштабироваться с уровня одного сервера до уровня десятки лучших сайтов Интернета, должен начать с обработки слегка устаревших данных на реплицированных slave серверах, при этом не забывать балансировать нагрузку операций чтения между slave серверами. Если это возможно - блоки данных (группы пользователей, учетных записей, или чего угодно) должны размещаться каждый на разных серверах. Можно делать это с самого начала используя виртуализацию, чтобы удостовериться в работоспособности архитектуры, когда вы еще "маленькие". Это намного проще, чем когда вы делаете то же самое, но под ежемесячно удваивающейся нагрузкой.