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

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

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

• Архитектура Wikimedia
• Серверы Wikimedia
• scale-out vs scale-up из блога "Oracle to MySQL"

Платформа

• Apache
• Linux
• MySQL
• PHP
• Squid
• LVS
• Lucene для поиска
• Memcached для распределенного кэширования объектов
• lighttpd для работы с изображениями

Статитстика

• 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 серверами. Если это возможно - блоки данных (группы пользователей, учетных записей, или чего угодно) должны размещаться каждый на разных серверах. Можно делать это с самого начала используя виртуализацию, чтобы удостовериться в работоспособности архитектуры, когда вы еще "маленькие". Это намного проще, чем когда вы делаете то же самое, но под ежемесячно удваивающейся нагрузкой.