Кодеры за работой. Размышления о ремесле программиста
Шрифт:
Потому упала база данных. “Вот черт”, - сказал я себе. Веб-серверы прекрасно масштабируются, ведь они не сохраняют состояния. Просто добавляешь новые серверы и распределяешь нагрузку. Это был долгий напряженный период. “Так, я могу слегка оптимизировать запросы”, но это дает лишь неделю, а потом они опять перестают справляться с нагрузкой. В какой-то момент я задумался, что же нужно каждому конкретному запросу.
Тогда я решил - казалось, мне первому в мире пришла такая мысль, - разбить все это на разделы (partition). Я подготовил документ с рисунками, в котором говорилось, как наш код будет работать. “В
Сейбел: Был ли назначен день перевода со старой версии на новую?
Фицпатрик: Нет. У каждого пользователя был флаг, определяющий номер кластера: если он был равен нулю, значит данные находились в основной базе, если отличался от нуля, значит данные уже находились в каком-то разделе. Потом была версия “Ваша учетная запись заблокирована”. Учетная запись блокировалась и выполнялась попытка переноса данных, программа пыталась переместить данные и снова сделать это, еlbли вы в это время вносили какие-то изменения. Примерно в таком духе: “Ждите, пока мы не переместим данные, и не вносите никаких изменений в данные в основном кластере, скоро мы переместим вас в ваш индивидуальный кластер”.
Такой перевод в фоновом режиме длился несколько месяцев. Мы прикинули, что если бы мы просто выгрузили данные, написали что-то для разбивки SQL-файлов и залили данные назад, то это потребовало бы около недели. Неделя простоя или два месяца медленного переноса? Но в процессе переноса данных 10% пользователей работоспособность сайта снова становилась приемлемой для других пользователей, так что мы смогли увеличить темпы переноса данных с загруженных кластеров.
Сейбел: Это было еще до memcached и Perlbal.
Фицпатрик: До Perlbal - это точно. Memcached, пожалуй, тоже была позднее. По-моему, я создал memcached сразу после колледжа, когда переехал. Помню, как ко мне пришла эта идея. Сайт был на грани, я пошел в душ и вдруг понял, что у нас ведь есть вся эта свободная память повсюду! Я набросал прототип тем же вечером, написал на Perl сервер и клиент, но сервер упал, потому что для сервера на Perl было слишком много обращений к процессору. Поэтому мы начали переписывать его на Си.
Сейбел: И вам не понадобилось покупать новые серверы для базы данных.
Фицпатрик: Да, серверы были дорогими, а процесс перехода с одного на другой - очень медленным. Веб-серверы были дешевы, и добавление новых сразу давало эффект. А при покупке новой базы данных где-то неделя уходит только на запуск и проверку: нужно проверить диски, все установить и настроить.
Сейбел: Значит, все элементы созданной вами инфраструктуры, такие как memcached и Perlbal, были разработаны в ответ на реальные потребности, связанные с масштабированием Живого Журнала?
Фицпатрик: Да, конечно. Все, что
– “У нас платные учетные записи”. “Сколько у вас клиентов? Какая нагрузка?” - “Мы знаем только, что их число растет, вот и все”.
– “Тогда цена такая: весь доход, который вы можете заплатить, чтобы не развалиться”.
– “Да пошли вы”. Но все же нам была нужна эта штука, и мы ее купили. Скорость ввода/вывода нас не слишком впечатлила, цена была слишком высока, и здесь по-прежнему оставалась единственная точка отказа. Они попытались продать нам конфигурацию с высокой скоростью доступа, но мы сказали: “Да пошли вы. Мы эту ерунду больше не купим”.
Итак, мы начали работу над файловой системой. Я даже не уверен, что к этому моменту был опубликован документ по GFS, кажется, я просто услышал о ней от кого-то. В то время я всегда использовал хеш-значение ключа для указания на фрагмент памяти. Почему бы не сделать то же самое с файлами? Файлы постоянны, поэтому нам нужно записывать, где они хранятся, поскольку при добавлении новых узлов хранения меняется и конфигурация. И дело не только в вводе/выводе и отслеживании местонахождения файлов, но и в высокой доступности системы. Мы нашли решение, и я пришел к следующей схеме: “Нам нужно хранить все обращения к файлам, чтобы знать, где что лежит”.
Я написал схему для MySQL, сначала главного устройства, а потом для устройства отслеживания файлов. И меня осенило: “Черт! Да эту роль может выполнять протокол HTTP! Это же совсем не сложно”.
Помню, как пришел на работу, всю ночь обдумывая это. У нас в здании была общая комната для совещаний - большая и мрачная. “Итак, ребята, прекращаем работу. Все идем вниз и будем рисовать”. Я говорил это каждый раз, когда нам предстояло заняться проектированием, и мы просто находили доску, на которой можно было бы рисовать.
Я объяснил схему, и кто с кем должен общаться, и кто что будет делать с запросом. Потом мы поднялись наверх, и я первым делом заказал все оборудование, потому что на его доставку уходило недели две. Потом мы занялись кодированием, надеясь завершить его до получения оборудования. Нам всегда что-то угрожало. Что-нибудь постоянно ломалось, так что нам все время приходилось создавать новые компоненты инфраструктуры.
Сейбел: Если бы кто-нибудь в самом начале сказал: “Вам нужно знать А, Б и В”, - упростило бы это вашу жизнь?
Фицпатрик: Всегда легче сделать что-то как надо с первого раза, а не переносить с уже работающего сервиса. Это всегда большой геморрой. Все, о чем я говорил, вы можете сделать на одном компьютере. Проектируете систему таким образом, чтобы было с чего начать. И не делаете предположений о возможности объединений вот этих пользовательских данных с этими и так далее. Предположим, вам нужно загрузить 20 объектов, и ваша реализация может загрузить их из одной таблицы, но код более высокого уровня, которому нужны эти 20 объектов, может собирать их с нескольких машин. Если бы я делал так с самого начала, куда меньше было бы головной боли с переносом.