Фицпатрик: В основном Живым Журналом. Мы также пытались запустить фотохостинг, но Flickr нас уделал. Видимо, наш сервис был переусложнен - с прекрасными абстракциями и возможностью встраивания куда угодно. Создавая новый инфраструктурный компонент для Живого Журнала, мы спрашивали себя: "Как это будет работать с FotoBilder?", так что все начали делать абстрактным. Memcached был абстрактным, потому что не было смысла завязывать его с Живым Журналом. Потом мы создали файловую систему наподобие GFS и очередь заданий. Мы создавали эти компоненты, чтобы они могли работать с любым из наших продуктов, но еще и потому, что чем меньше в системе запутанных взаимозависимостей, тем легче ее поддерживать. Даже если это требует больше работы, убрать часть зависимостей - уже большое дело. Поэтому мы начали создавать все эти обобщенные компоненты.
Сейбел: Интересно было бы услышать о развитии Живого Журнала, о том, как вы начинали и как в процессе усваивали необходимые уроки.
Фицпатрик: Все начиналось с одного компьютера с UNIX. На нем одновременно работали несколько пользователей, но постепенно Живой Журнал вытеснил их всех.
Сейбел: Выполнялся как набор CGI-скриптов?
Фицпатрик: Да. То был, кажется, CGI в самом буквальном смысле - пожертвуй всем и умри. Тот провайдер приставил ко мне одного парня. У меня были проблемы, потому что сервер все время сдыхал, и я сказал ему: "Я плачу десять долларов в месяц. Почему он не работает?" Парень ответил: "Ага, сделай-ка вот это". Вскоре я освоил UNIX и понял, что происходит на самом деле.
Затем я переделал все под FastGCI, настроил Apache и вырубил обратный поиск по DNS. После того как все эти этапы пройдены, упираешься в ограничения ввода/вывода или в ресурсы процессора. Потом я получил собственный выделенный сервер, но он был только один, и когда он умирал, у меня начинались проблемы с ресурсами. Я дал доступ на него своим друзьям и просто оставил страницу регистрации открытой. Потому друзья пригласили своих друзей, которые, в свою очередь, пригласили своих друзей, хотя сайт не задумывался как общедоступный. Страница регистрации осталась открытой случайно. Так что потом я поместил на страницу новостей Живого Журнала объявление: "Помогите. Нам нужно купить серверы".
Мы собрали, кажется, тысяч 6 или 7 долларов или около того, купили два больших Dell и поставили их у провайдера Speakeasy в деловом центре Сиэтла, Кто-то порекомендовал нам эти Dell, огромные шести-юнитовые громадины, килограммов под пятьдесят каждая. Логическое разделение было следующим: сервер базы данных и веб-сервер. Это единственное разделение, которое я знал, поскольку работал с двумя процессами - MySQL и Apache.
Какое-то время все работало как надо. Веб-серверы торчали напрямую во внешний мир, у них было по две сетевые карты и небольшой кабель к серверу базы данных. Потом веб-сервер перестал справляться с нагрузкой, но это не было проблемой, поскольку на тот момент у меня имелось несколько одноюнитовых серверов. Итак, у нас было три вебсервера и один сервер базы данных. Тогда я попробовал три-четыре программы балансировки нагрузки для протокола HTTP - mod_backhand, modproxy и Squid - и возненавидел их все. С тех пор не люблю балансировщики нагрузки.
Потому упала база данных. "Вот черт", - сказал я себе. Веб-серверы прекрасно масштабируются, ведь они не сохраняют состояния. Просто добавляешь новые серверы и распределяешь нагрузку. Это был долгий напряженный период. "Так, я могу слегка оптимизировать запросы", но это дает лишь неделю, а потом они опять перестают справляться с нагрузкой. В какой-то момент я задумался, что же нужно каждому конкретному запросу.
Тогда я решил - казалось, мне первому в мире пришла такая мысль, - разбить все это на разделы (partition). Я подготовил документ с рисунками, в котором говорилось, как наш код будет работать. "В главной базе данных будут храниться только метаданные каких-то глобальных вещей, которые дают небольшую нагрузку, а все данные, связанные с индивидуальными блогами и комментариями, для каждого пользователя будут выделены в кластер базы данных. Пользователям с такими-то идентификаторами предназначен определенный раздел базы данных". Задним числом я понимаю, что именно так все и поступают. Но тогда потребовалось много усилий, чтобы переделать код на работающей системе.
Сейбел: Был ли назначен день перевода со старой версии на новую?
Фицпатрик: Нет. У каждого пользователя был флаг, определяющий номер кластера: если он был равен нулю, значит данные находились в основной базе, если отличался от нуля, значит данные уже находились в каком-то разделе. Потом была версия "Ваша учетная запись заблокирована". Учетная запись блокировалась и выполнялась попытка переноса данных, программа пыталась переместить данные и снова сделать это, е£ли вы в это время вносили какие-то изменения. Примерно в таком духе: "Ждите, пока мы не переместим данные, и не вносите никаких изменений в данные в основном кластере, скоро мы переместим вас в ваш индивидуальный кластер".
Такой перевод в фоновом режиме длился несколько месяцев. Мы прикинули, что если бы мы просто выгрузили данные, написали что-то для разбивки SQL-файлов и залили данные назад, то это потребовало бы около недели. Неделя простоя или два месяца медленного переноса? Но в процессе переноса данных 10% пользователей работоспособность сайта снова становилась приемлемой для других пользователей, так что мы смогли увеличить темпы переноса данных с загруженных кластеров.
Сейбел: Это было еще до memcached и Perlbal.
Фицпатрик: До Perlbal - это точно. Memcached, пожалуй, тоже была позднее. По-моему, я создал memcached сразу после колледжа, когда переехал. Помню, как ко мне пришла эта идея. Сайт был на грани, я пошел в душ и вдруг понял, что у нас ведь есть вся эта свободная память повсюду! Я набросал прототип тем же вечером, написал на Perl сервер и клиент, но сервер упал, потому что для сервера на Perl было слишком много обращений к процессору. Поэтому мы начали переписывать его на Си.
Сейбел: И вам не понадобилось покупать новые серверы для базы данных.
Фицпатрик: Да, серверы были дорогими, а процесс перехода с одного на другой - очень медленным. Веб-серверы были дешевы, и добавление новых сразу давало эффект. А при покупке новой базы данных где-то неделя уходит только на запуск и проверку: нужно проверить диски, все установить и настроить.
Сейбел: Значит, все элементы созданной вами инфраструктуры, такие как memcached и Perlbal, были разработаны в ответ на реальные потребности, связанные с масштабированием Живого Журнала?
Фицпатрик: Да, конечно. Все, что мы создали, делалось только потому, что наш сайт падал, и мы ночь напролет выдумывали новые штуки. Однажды мы даже решили купить систему хранения данных NetApp. Это выглядело так. Мы спросили: "Сколько она стоит?", а они в ответ: "Расскажите нам о вашем бизнесе". - "У нас платные учетные записи". "Сколько у вас клиентов? Какая нагрузка?" - "Мы знаем только, что их число растет, вот и все". - "Тогда цена такая: весь доход, который вы можете заплатить, чтобы не развалиться". - "Да пошли вы". Но все же нам была нужна эта штука, и мы ее купили. Скорость ввода/вывода нас не слишком впечатлила, цена была слишком высока, и здесь по-прежнему оставалась единственная точка отказа. Они попытались продать нам конфигурацию с высокой скоростью доступа, но мы сказали: "Да пошли вы. Мы эту ерунду больше не купим".
Итак, мы начали работу над файловой системой. Я даже не уверен, что к этому моменту был опубликован документ по GFS, кажется, я просто услышал о ней от кого-то. В то время я всегда использовал хеш-значение ключа для указания на фрагмент памяти. Почему бы не сделать то же самое с файлами? Файлы постоянны, поэтому нам нужно записывать, где они хранятся, поскольку при добавлении новых узлов хранения меняется и конфигурация. И дело не только в вводе/выводе и отслеживании местонахождения файлов, но и в высокой доступности системы. Мы нашли решение, и я пришел к следующей схеме: "Нам нужно хранить все обращения к файлам, чтобы знать, где что лежит".
Я написал схему для MySQL, сначала главного устройства, а потом для устройства отслеживания файлов. И меня осенило: "Черт! Да эту роль может выполнять протокол HTTP! Это же совсем не сложно".
Помню, как пришел на работу, всю ночь обдумывая это. У нас в здании была общая комната для совещаний - большая и мрачная. "Итак, ребята, прекращаем работу. Все идем вниз и будем рисовать". Я говорил это каждый раз, когда нам предстояло заняться проектированием, и мы просто находили доску, на которой можно было бы рисовать.
Я объяснил схему, и кто с кем должен общаться, и кто что будет делать с запросом. Потом мы поднялись наверх, и я первым делом заказал все оборудование, потому что на его доставку уходило недели две. Потом мы занялись кодированием, надеясь завершить его до получения оборудования. Нам всегда что-то угрожало. Что-нибудь постоянно ломалось, так что нам все время приходилось создавать новые компоненты инфраструктуры.
Сейбел: Если бы кто-нибудь в самом начале сказал: "Вам нужно знать А, Б и В", - упростило бы это вашу жизнь?
Фицпатрик: Всегда легче сделать что-то как надо с первого раза, а не переносить с уже работающего сервиса. Это всегда большой геморрой. Все, о чем я говорил, вы можете сделать на одном компьютере. Проектируете систему таким образом, чтобы было с чего начать. И не делаете предположений о возможности объединений вот этих пользовательских данных с этими и так далее. Предположим, вам нужно загрузить 20 объектов, и ваша реализация может загрузить их из одной таблицы, но код более высокого уровня, которому нужны эти 20 объектов, может собирать их с нескольких машин. Если бы я делал так с самого начала, куда меньше было бы головной боли с переносом.
Сейбел: Итак, урок в основном таков: "Имейте план на тот день, когда ваши данные перестанут влезать в одну базу".
Фицпатрик: Думаю, сегодня это уже общеизвестный факт в сообществе веб-разработчиков. Сейчас многие перегибают палку, считая что их сайт разрастется до неимоверных размеров. Но в то время все считали, что Apache и MySQL достаточно.
Сейбел: Думаю, вы разрабатывали все эти штуки не только по необходимости, но вам было интересно делать все это.
Фицпатрик: Конечно. Я определенно пытался найти повод применить или изучить что-то новое. Никогда не изучишь что-либо, не написав для этого программу и не начав жить и дышать этим. Одно дело выучить язык ради удовольствия, но нельзя говорить о том, что знаешь его, пока не напишешь на нем большую сложную систему.
Сейбел: Итак, какие языки вы можете назвать своими, какими языками вы жили и дышали?
Фицпатрик: Perl. Си. Когда-то Бейсик, но не уверен, что его стоит учитывать. Еще я много писал на Лого. В школе у нас были уроки по Лого. Ребята что-то рисовали, а я сумел выйти из графического режима - это можно сделать, когда знаешь, как, - и писал функции. Учитель подошел и сказал: "Что ты делаешь? Ты должен рисовать домики". - "Нет, я пишу на Лого. Посмотрите". - "Ты все делаешь не так". В конце урока у меня уже была библиотека, позволяющая рисовать буквы алфавита любого размера и повернутые под любым углом. Я мог выводить целые сообщения на волнистых баннерах, которые отдалялись, приближались и все такое, и все стали спрашивать: "Какого черта?" Не знаю, считать этот язык или нет.
Но я много писал на Perl и на Си, потом в колледже много писал на C++ по работе и для Windows. Потом я забыл C++, за ненадобностью, но за последний год, работая в Google, я много писал на C++, Python и Java. Я много писал на Java, когда этот язык только появился, но потом он мне осточертел. Сейчас я опять много пишу на Java, и он меня уже снова достал.
Сейбел: Насколько для вас важен язык, на котором вы пишете?
Фицпатрик: Полностью мне все еще не нравится ни один из них. И я не знаю, какой язык понравился бы мне полностью. Мне не нравится, что в текущем проекте приходится перепрыгивать с одного языка на другой. Я хочу статически типизированный язык, который бы проверял все во время компиляции, когда я этого захочу. Perl очень близок к этому - он позволяет мне кодировать так, как я хочу. Он не выполняет достаточное количество проверок во время компиляции, но я могу заставить делать их во время выполнения. Но и он все же недостаточно хорош.
Я хочу необязательную статическую типизацию. В Perlbal нет нужды в высокой производительности половины всех возможностей, за исключением ядра и копирования байтов туда-сюда. Я хочу, чтобы у меня была возможность во время выполнения давать подсказки в определенных частях кода и объявлять типы. Но если мне лень и хочется что-то протестировать, то могу оформить код соответствующим образом.
Сейбел: То есть типы вам нужны в основном, чтобы улучшить оптимизацию кода компилятором?
Фицпатрик:. Нет. Я хочу, чтобы компилятор говорил мне что-то вроде: "Ты делаешь глупость". Но иногда мне плевать на такие предупреждения и я хочу заставить код выполняться независимо ни от чего. Не хочу показаться слишком большим оптимистом по поводу Perl 6, но они обещают много вещей, которых мне не хватает. Правда, не думаю, что он вообще когда-либо будет выпущен.
Сейбел: А C++ вам нравится?
Фицпатрик: Даже говорить о нем не хочу. Жуткий синтаксис, совершенно непоследовательный, а сообщения об ошибках - по крайней мере компилятора GCC - просто нелепы. Можно получить 40 страниц сообщения только потому, что забыл поставить точку с запятой. Но, как и во многих других случаях, основные шаблоны быстро запоминаешь. Даже не вчитываешься в слова, а просто смотришь на структуру сообщения и понимаешь: "Ага, кажется, я забыл закрыть пространство имен в заголовочном файле". Думаю, новая версия спецификации C++, хотя и добавляет огромное количество сложностей, содержит много всего, что сделает процесс ввода не таким мучительным, по крайней мере, потребуется меньше стучать по клавишам. Переменные auto и нововведения в циклах for. Очень напоминает Python. И лямбда-выражения. Можно даже подумать, что пишешь на Python, а не на C++.
Сейбел: А C++ вы используете из-за его эффективности.
Фицпатрик: Скорее всего, да. В основном я пишу на нем в Google. Там все, что более или менее требует производительности, пишется на C++. Кроме того, в Google я много пишу на Java.
Сейбел: Насколько я понимаю, в компании Google сложилась "С++-центрическая культура", поскольку они использовали этот язык с самого начала, построив на его основе обширную программную инфраструктуру. Хотя и нельзя просто так взять и забыть свою историю - пожалуй, на C++ в Google написана значительная часть кода, которая не требует такой эффективности.
Фицпатрик: Особенно учитывая, что со временем Java стал быстрее, a JVM - значительно умнее. В Java мне не нравится то, что у всех сложилось стойкое отвращение к JNI. Есть библиотеки на C++. Разработчикам, использующим Python, как внутри компании Google, так и за ее пределами, все равно. Их первая мысль: "Да мы просто обернем все это с помощью SWIG". У них есть собственный путь, и они счастливы. Разработчики на Python могут сразу же использовать все, что написано на C++, потому что они не относятся так благоговейно к языку источника.
А сторонники Java говорят: "Надо писать только на чистом Java. Мы не можем использовать JNI, потому что если JVM рухнет, то мы не узнаем, почему". Проблема в том, что все приходится писать дважды - один раз для C++, Python и прочих языков, а второй раз для Java. Так что если они найдут хороший способ взаимодействия или избавятся от страха перед JNI, то я не буду иметь ничего против Java.
Сейбел: А как насчет вопроса "ручное управление памятью против автоматического"? Об этом все еще спорят. У вас есть твердое мнение на этот счет?
Фицпатрик: По правде говоря, нет. Занятно смотреть, как люди высказывают твердое, ничем не подкрепленное мнение. Лично мне ручное управление памятью не кажется таким уж раздражающим, по крайней мере, в C++ с умными указателями. Я могу днями писать на C++, ни разу не применив явно оператор new или delete. Вот так.
Я переписал memcached, уже работая в Google, для работы с инфраструктурой Google и для добавления ее к Арр Engine. Она написана целиком на C++, потому что мне было нужно очень строгое управление памятью для уменьшения фрагментации. И я очень рад возможности ручного управления памятью в C++.
Сейбел: Изначально программа memcached была написана на Си. Вы переписали ее на C++, потому что этот язык предпочтительнее в Google или у него есть другие преимущества?
Фицпатрик: Сперва я хотел просто взять существующую реализацию и перенести ее на C++, но работы оказалось слишком много. Оказалось не так много кода, которым я мог бы воспользоваться, поэтому было гораздо быстрее просто переписать его на C++. Объем кода уменьшился вдвое.
Сейбел: Это из-за C++ или из-за того, что вы стали опытнее?