Как мы сделали GitHub быстрым

Original on: https://github.com/blog/530-how-we-made-github-fast

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

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

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


Понимание протоколов

Мы выставить три основных протоколов для конечных пользователей GitHub: HTTP, SSH, и Git. При просмотре сайта с вашего любимого браузера, вы используете HTTP. При штамповке, тянуть, толкать или к частному, как git@github.com URL: mojombo / jekyll.git вы делаете это через SSH. При штамповке или вытащить из общего хранилища через URL, как git :/ / github.com / mojombo / jekyll.git вы используете Git протокола.

Самый простой способ понять, архитектура, прослеживая, как каждый из этих запросов распространяется через систему.


Отслеживание HTTP-запроса

В этом примере я покажу вам, как просьбу о дереве страниц, таких как http://github.com/mojombo/jekyll происходит.

Первое, что ваш запрос попадает после сошедших с Интернет активной балансировки нагрузки. Для решения этой задачи мы используем пару случаев Xen работает ldirectord. Они называются lb1a и lb1b. В любой момент времени один из них активный, а другой ждет, чтобы взять на себя в случае неудачи в мастера. Нагрузки не делает ничего фантазии. Он перенаправляет TCP пакетов на различных серверов на базе IP и просил порт и можете удалить неправильно серверов с баланса бассейна, если необходимо. В случае, если серверы не доступны для данного бассейна может служить простой статический сайт, а не отказа от подключения.

Для запросов на основном веб-сайте, балансировки нагрузки судов ваш запрос в один из четырех машин интерфейсе. Каждый из них является 8 основных, 16 Гб оперативной памяти сервера голый металл. Их имена Fe1, ..., Fe4. Nginx принимает соединение и посылает его на сокет Unix домена на которых шестнадцать процессов Единорог работника выбора. Один из этих рабочих хватает запрос и запускает Rails кода, необходимого для его выполнения.

Многие страницы требуется поиск в базе данных. Наша база данных MySQL работает на двух 8 основных, 32GB оперативной памяти серверов голый металл с дисков 15K RPM SAS. Их имена и db1a db1b. В любой момент времени, один из них мастер и один раб. MySQL репликация выполняется с помощью DRBD.

Если страница требует информации о Git репозитории, и эти данные не кэшируются, то он будет использовать наши Грит библиотеки для извлечения данных. Для того, чтобы разместить наши Rackspace установки, мы изменили Грит сделать что-то особенное. Начнем с того, абстрагируясь каждый звонок, который необходим доступ к файловой системе в Грит :: Git объекта. Затем мы заменим Грит :: Git с заглушкой, что делает RPC вызовы нашего дыма услуг. Дым имеет прямой доступ к диску в хранилищах и по сути представляет Грит :: Git в качестве службы. Она называется, потому что дым дым просто Грит в облаке. Понимаете?

Ушиб Грит делает RPC вызовы курить который с балансировкой нагрузки, что имя карты к Fe машин. Каждый интерфейс запускающиеся четыре ProxyMachine случаях за HAProxy которые выступают в качестве прокси для маршрутизации вызовов дыма. ProxyMachine мое содержание известно (слой 7) TCP маршрутизации прокси, который позволяет писать логика маршрутизации в Ruby. Прокси рассматривает запрос и извлекает имя пользователя из хранилища, который был указан. Затем мы используем собственную библиотеку дымоходов (он направляет дым!) Для поиска маршрута для этого пользователя. Маршрут пользователя это просто имя файла, сервер, на котором хранилищ этого пользователя хранятся.

Дымоход находит маршрут, сделав вызов Redis. Redis работает на серверах баз данных. Мы используем Redis как постоянный ключ / значение магазин для маршрутизации информации и множество других данных.

Как только дым прокси определил маршрут пользователя, он устанавливает прозрачный прокси для надлежащего файлового сервера. У нас есть четыре пары файловых серверов. Их имена fs1a, fs1b, ..., fs4a, fs4b. Это 8 основных, 16 Гб оперативной памяти серверов голый металл, каждая с шестью 300GB 15K RPM SAS дисков, расположенных в RAID 10. В любой момент времени на одном сервере в каждой паре является активным, а другой ждет, чтобы взять на себя в случае возникновения фатальной неудачи в мастера. Все хранилища данных постоянно реплицируются от ведущего к ведомому с помощью DRBD.

Каждый файловый сервер работает два Эрни RPC серверов за HAProxy. Каждый Эрни нерестится 15 рубиновых работников. Эти работники принимают RPC вызовов и восстановить и выполнить Грит вызова. Ответ отсылается обратно через дым прокси Rails приложения, где зернистость заглушки возвращает ожидаемый ответ песка.

Когда Единорог заканчивается Rails действий, ответ отсылается обратно через Nginx и непосредственно клиенту (исходящие ответы не возвращаются через балансировки нагрузки).

Наконец, вы увидите довольно веб-страницу!

Выше потока то, что происходит, когда нет обращений в кэш. Во многих случаях Rails код использует Ruby Эван Уивер Memcached клиента запросить Memcache серверов, которые работают на каждом сервере файл раб. Так как эти машины в противном случае простоя, мы размещаем 12 Гб Memcache на каждом. Эти серверы псевдоним memcache1, ..., memcache4.
BERT и Берт-RPC

По нашим данным, сериализация и RPC протокола мы используем BERT и Берт-RPC. Вы не слышали о них раньше, потому что они новые. Я придумал их, потому что я не был удовлетворен любым из доступных вариантов, которые я оценил, и я хотел экспериментировать с идеей, что у меня было на некоторое время. Прежде чем волноваться о NIH синдром (или, чтобы помочь вам улучшить ваше Freak Out), пожалуйста, прочитайте мои сопровождающие статью Представляем BERT и Берт-RPC о том, как эти технологии пришли, чтобы быть и то, что я намерен их решать.

Если вы не хотите просто проверить спецификацию, над головой http://bert-rpc.org.

Для голодных код, проверить мои Рубин BERT сериализации библиотеки BERT, моя Руби BERT-RPC клиент BERTRPC, и мой Erlang / Ruby гибридных BERT-RPC сервер Эрни. Это точная библиотеки мы используем в GitHub служить все хранилища данных.
Трассировка запроса SSH

Git использует SSH для шифрования связи между вами и сервером. Для того чтобы понять, как наша архитектура занимается соединений SSH, сначала важно понять, как это работает в более простой установки.

Git опирается на тот факт, что SSH позволяет выполнять команды на удаленном сервере. Например, команда SSH том @ мороз LS-аль работает LS-Аль в домашнем каталоге моего пользователя на сервере мороза. Я получаю вывод команды на моем локальном терминале. SSH существенно подключения STDIN, STDOUT и STDERR на удаленной машине моего локального терминала.

Если вы работаете в команде, как Git клон Том @ мороз: mojombo / Берт, как Git делает за кулисами в SSHing к морозу, идентифицируется как пользователь том, а затем удаленно выполнения загрузки Git-пак mojombo / Берт. Теперь клиент может общаться с этим процессом на удаленном сервере, просто чтение и запись через соединение SSH. Аккуратные, да?

Конечно, позволяющая выполнить произвольный команды небезопасно, поэтому SSH включает в себя возможность ограничить то, что команды могут быть выполнены. В простейшем случае, можно ограничить выполнение в ГИТ-оболочку, которая входит в Git. Все это скрипт делает это проверить команду, которую вы пытаетесь выполнить и убедиться, что это один из Git upload-пакет, git-pack получить или загрузить мерзавец-архива. Если это действительно один из тех, он использует Exec, чтобы заменить текущий процесс, что новый процесс. После этого он, как будто вы только что выполнили эту команду непосредственно.

Итак, теперь вы знаете, как Git, SSH рабочих операций в простом случае, позвольте мне показать вам, как мы справляемся с этой архитектурой на GitHub.

Во-первых, ваш Git клиент инициирует SSH сессии. Подключение сводится через интернет и попадает наш нагрузки.

Оттуда, соединение передается на одну из оболочек, где SSHD принимает его. Мы пропатчен наш SSH демон на выполнение государственных ключ поиска в нашей базе данных MySQL. Ваш ключ идентифицирует пользователей GitHub и эта информация отправляется вместе с оригинальной команды и аргументы наших собственных скрипт Gerve (Git служить). Подумайте о Gerve как супер умный версии GIT-оболочки.

Gerve проверяет, что пользователь имеет доступ к хранилищу, указанных в аргументах. Если вы являетесь владельцем хранилища, не поиск в базе данных должны быть выполнены, в противном случае несколько SQL запросов, чтобы определить права доступа.

Как только доступ был проверен, Gerve использует дымохода, чтобы найти пути для владельца репозитория. Цель теперь выполнить исходную команду на правильный файл-сервер и подключить локальную машину до этого процесса. Что может быть лучше для этого, чем с другой удаленный запуск SSH!

Я знаю, это звучит глупо, но он прекрасно работает. Gerve просто использует Exec (3), чтобы заменить себя Git вызова tossh @ <route> <command> <arg>. После вызова этой функции, ваш клиент подключен к процессу на интерфейс машины, которая, в свою очередь, подключены к процессу на файловом сервере.

Подумайте об этом следующим образом: после определения прав доступа и расположения хранилища, интерфейс становится прозрачным прокси для остальной части сессии. Единственным недостатком такого подхода является то, что внутренний SSH излишне обременены накладные расходы шифрования / дешифрования, когда ни одна является строго необходимым. Вполне возможно, мы можем заменить этого внутреннего вызова SSH с чем-то более эффективным, но такой подход просто чертовски прост (и до сих пор очень быстро), чтобы заставить меня волноваться об этом очень много.


Трассировка Git Запрос

Выполнение общественных клонов и тянет с помощью Git подобно тому, как метод работает SSH. Вместо того чтобы использовать SSH для аутентификации и шифрования, однако, она опирается на Git Демон на стороне сервера. Этот демон принимает соединения, проверяет команду для выполнения, а затем с помощью вилки (2), Exec (3) на нерест работника, то становится команда процесса.

Имея это в виду, я покажу вам, как общественное действие клон работает.

Во-первых, ваши вопросы Git клиента запрос, содержащий команды и имя репозитория вы хотите клонировать. Этот запрос входит в нашу систему на нагрузки.

Оттуда, запрос отправляется на одну из оболочек. Каждый интерфейс запускающиеся четыре ProxyMachine случаях за HAProxy которые выступают в качестве прокси для маршрутизации протокола Git. Прокси проверяет запрос и извлекает имя пользователя (или суть имя) репо. Затем он использует дымохода для поиска маршрута. Если нет маршрута или любой другой ошибка, прокси говорит Git протокол и отправляет соответствующие сообщения для клиента. После того, маршрут известен, имя репо (например, mojombo / Bert) переведен на своем пути на диске (например, a/a8/e2/95/mojombo/bert.git). На нашей старой установки, которые не имели прокси, мы должны были использовать модифицированную демон, который может конвертировать пользователей / репо в правильный путь файла. Делая этот шаг, в прокси-сервер, теперь мы можем использовать немодифицированные демон, что позволяет гораздо проще модернизации.

Далее, Git прокси устанавливает прозрачный прокси с соответствующей файл-сервер и посылает модифицированный запрос (с преобразованным пути в хранилище). Каждый файл-сервер управляет двумя Git демон процессов за HAProxy. Демон говорит протокола пакета файлов и потоков данных обратно через прокси-сервер и Git прямо на Ваш Git клиента.

После того как клиент имеет все данные, вы клонировали хранилище и может приступить к работе!
Суб-и сторона-Systems

В дополнение к основному веб-приложений и хостинг Git системы, мы также выполнить ряд других подсистем и боковых систем. Sub-системы включают в себя работу очереди, архив загрузок, биллинг, зеркальное отображение, и SVN импортером. Боковые системы включают в себя GitHub страницы, суть, жемчужина сервер, и куча внутренних инструментов. Вы можете рассчитывать на объяснения того, как некоторые из этих работ в рамках новой архитектуры, и какие новые технологии, которые мы создали, чтобы помочь нашему приложению работать более плавно.


Заключение

Архитектура, изложенные здесь позволила нам правильно масштабировать сайта и привело к массовому увеличению производительности на всем сайте. Наш средний ответ Rails время нашей предыдущей установки было где-то от 500 мс до нескольких секунд в зависимости от загруженной срезы. Переход на голый металл и федеративных хранения на Rackspace принес наш средний отклик Rails время последовательно в 100 мс. Кроме того, очереди заданий теперь не имеет никаких проблем в ногу со 280 000 фоновых заданий мы обрабатываем каждый день. У нас есть еще много запаса расти вместе с текущим набором оборудования, и, когда придет время, чтобы добавить больше машин, мы можем добавить новые серверы на любом уровне, с легкостью. Я очень доволен тем, как хорошо, что все работает, и если вы похожи на меня, вы, наслаждаясь новыми и улучшенными GitHub каждый день!

Информация о тарифах и ценах на рекламные услуги, продвижение и раскрутку, создание сайтов, представленная на сайте носит справочно-информационный характер и не является публичной офертой. Сайт web-meister.ru работает в информационно-справочном режиме, оказание и заказ услуг создания сайтов и поисковой оптимизации возможны только после заключения договора с ООО"Путевкин". Информационно-справочные сведения, включая цены и любую другую информацию на сайте, не являются ни рекламой, ни офертой. Для получения полной информации по стоимости рекламных услуг, и для заключения договора на оказание информационно-рекламных услуг по созданию и раскрутке сайтов, пожалуйста, обращайтесь в наши офисы продаж. По всем вопросам работы сайта обращаться по email: info@web-meister.ru