Мы собрали, кажется, тысяч 6 или 7 долларов или около того, купили два больших Dell и поставили их у провайдера Speakeasy в деловом центре Сиэтла, Кто-то порекомендовал нам эти Dell, огромные шести-юнитовые громадины, килограммов под пятьдесят каждая. Логическое разделение было следующим: сервер базы данных и веб-сервер. Это единственное разделение, которое я знал, поскольку работал с двумя процессами — MySQL и Apache.
Какое-то время все работало как надо. Веб-серверы торчали напрямую во внешний мир, у них было по две сетевые карты и небольшой кабель к серверу базы данных. Потом веб-сервер перестал справляться с нагрузкой, но это не было проблемой, поскольку на тот момент у меня имелось несколько одноюнитовых серверов. Итак, у нас было три вебсервера и один сервер базы данных. Тогда я попробовал три-четыре программы балансировки нагрузки для протокола HTTP — mod_backhand, modproxy и Squid — и возненавидел их все. С тех пор не люблю балансировщики нагрузки.
Потому упала база данных. «Вот черт», — сказал я себе. Веб-серверы прекрасно масштабируются, ведь они не сохраняют состояния. Просто добавляешь новые серверы и распределяешь нагрузку. Это был долгий напряженный период. «Так, я могу слегка оптимизировать запросы», но это дает лишь неделю, а потом они опять перестают справляться с нагрузкой. В какой-то момент я задумался, что же нужно каждому конкретному запросу.
Тогда я решил — казалось, мне первому в мире пришла такая мысль, — разбить все это на разделы (partition). Я подготовил документ с рисунками, в котором говорилось, как наш код будет работать. «В главной базе данных будут храниться только метаданные каких-то глобальных вещей, которые дают небольшую нагрузку, а все данные, связанные с индивидуальными блогами и комментариями, для каждого пользователя будут выделены в кластер базы данных. Пользователям с такими-то идентификаторами предназначен определенный раздел базы данных». Задним числом я понимаю, что именно так все и поступают. Но тогда потребовалось много усилий, чтобы переделать код на работающей системе.
Сейбел: Был ли назначен день перевода со старой версии на новую?
Фицпатрик: Нет. У каждого пользователя был флаг, определяющий номер кластера: если он был равен нулю, значит данные находились в основной базе, если отличался от нуля, значит данные уже находились в каком-то разделе. Потом была версия «Ваша учетная запись заблокирована». Учетная запись блокировалась и выполнялась попытка переноса данных, программа пыталась переместить данные и снова сделать это, е£ли вы в это время вносили какие-то изменения. Примерно в таком духе: «Ждите, пока мы не переместим данные, и не вносите никаких изменений в данные в основном кластере, скоро мы переместим вас в ваш индивидуальный кластер».
Такой перевод в фоновом режиме длился несколько месяцев. Мы прикинули, что если бы мы просто выгрузили данные, написали что-то для разбивки SQL-файлов и залили данные назад, то это потребовало бы около недели. Неделя простоя или два месяца медленного переноса? Но в процессе переноса данных 10% пользователей работоспособность сайта снова становилась приемлемой для других пользователей, так что мы смогли увеличить темпы переноса данных с загруженных кластеров.
Сейбел: Это было еще до memcached и Perlbal.
Фицпатрик: До Perlbal — это точно. Memcached, пожалуй, тоже была позднее. По-моему, я создал memcached сразу после колледжа, когда переехал. Помню, как ко мне пришла эта идея. Сайт был на грани, я пошел в душ и вдруг понял, что у нас ведь есть вся эта свободная память повсюду! Я набросал прототип тем же вечером, написал на Perl сервер и клиент, но сервер упал, потому что для сервера на Perl было слишком много обращений к процессору. Поэтому мы начали переписывать его на Си.
Сейбел: И вам не понадобилось покупать новые серверы для базы данных.
Фицпатрик: Да, серверы были дорогими, а процесс перехода с одного на другой — очень медленным. Веб-серверы были дешевы, и добавление новых сразу давало эффект. А при покупке новой базы данных где-то неделя уходит только на запуск и проверку: нужно проверить диски, все установить и настроить.