Об архитектуре Reddit
В предыдущей заметке Супервизоры для систем высокой доступности я уже давал ссылку на статью
7 LESSONS LEARNED WHILE BUILDING REDDIT TO 270 MILLION PAGE VIEWS A MONTH
А сейчас хочу провести небольшой анализ обсуждаемой архитектуры. В статье приводится 7 правил - рассмотрим их все.
LESSON ONE: CRASH OFTEN
The essence of this lesson is: automatically restart failed and cancerous services.
Согласен полностью.
LESSON 2: SEPARATION OF SERVICES
The essence of this lesson is: group like processes and data on different boxes.
Идея здравая, а вот обоснование совершенно невразумительное - утверждается, что все проблемы от потоков в питоне и некорректной работе с кэшем в СУБД, и с какого-то перепугу эти два фактора обобщаются на абсолютно все виды систем. Вот что стоило бы сказать, так это автоматизацию развертывания разделенных сервисов и возможность их неадминистрируемой работы.
LESSON 3: OPEN SCHEMA
The essence of this lesson is: don't worry about the schema.
Рекомендация верная, но перечисленные ограничения слишком надуманные. Для таблиц вида "thing id, key, value" прекрасно работают join-ы в форме "join mytable on mytable.thing_id=thing_id and mytable.key=key". Соответственно, одну такую таблицу подключаем столько раз, сколько разных key нас интересуют. Вероятно, для автора просто не нужны join-ы в силу решаемой им задачи, но вовсе незачем было придумывать лишнее ограничение.
LESSON 4: KEEP IT STATELESS
С первого взгляда не очевидно, но правило избыточно. Добавлю, что, когда приложение это позволяет, нам повезло и многих проблем просто не возникнет, но что делать в противном случае?.. Для ясности стоит ввести понятия макро- и микросостояний. Макросостояние - когда ход обработки запроса определяется состоянием всей системы, а микро - только текущего узла. Первое требует глобальной синхронизации, зато второе совершенно автономно. Потеря микросостояния приведет, максимум, к разрыву сессии пользователя. Частным случаем сервисов с микросостоянием являются сервисы без собственного состояния. Если мы придерживаемся совета LESSON 2: SEPARATION OF SERVICES, то автоматически выполняется и текущая рекомендация. А если мы реализуем сохранение состояния при перезапуске сервиса согласно идее LESSON ONE: CRASH OFTEN, то никто ничего и не заметит. Потому уточним рекомендацию так: замените все макросостояния на микро.
LESSON 5: MEMCACHE
The essence of this lesson is: memcache everything.
Совершенно неверно, автор ставит телегу впереди лошади. Не нужно серверу приложений работать с кэшем, его задача - возвращать вычисляемые актуальные данные, устанавливая заголовки, контролирующие кэширование, такие, как expires, cache-control, etc. Нужен кэш - поставим кэширующий прокси перед фронтэндом или отдельным бэкэндом. В предлагаемом мной варианте значительную часть работы возьмут на себя прокси-серверы провайдеров, т.к. они тоже смогут эффективно кэшировать контент, таким образом мы совершенно бесплатно получаем CDN - распределенную сеть раздачи нашего контента.
LESSON 6: STORE REDUNDANT DATA
The essence of this lesson is: the key to speed is to precompute everything and cache it.
Отнюдь нет. Путь к эффективности - вычислять лишь то,что необходимо, и только тогда, когда это необходимо. Иначе говоря, "ленивые вычисления". Каждый сервис должен заниматься своей работой - вычислять результат, а с помощью контроля кэширования в браузере и на прокси-серверах мы контролируем, когда же именно следует отправлять запросы к сервисам, а когда возвращать кэшированный результат.
LESSON 7: WORK OFFLINE
The essence of this lesson is: do the minimal amount of work on the backend and tell the user you are done.
Технически противоречит пункту LESSON 4: KEEP IT STATELESS. Действительно, если операция производится независимо от запроса пользователя, необходим планировщик для выполнения задач плюс, опционально, поддержка сессий пользователя для оповещения о результатах. В случае, когда требуется оповестить конкретного пользователя, появляется необходимость хранения состояния задачи на сервере. И только в том случае, когда безопасностью пренебрегают, можно сразу же предоставить пользователю адрес для получения сведений о состоянии задачи по ее идентификатору - но тогда любой пользователь сможет увидеть это состояние. Несомненно, в каких-то системах такой подход допустим, но это лишь частный случай и притом с весьма серьезными противопоказаниями к применению.
В качестве резюме. Статья достаточно интересная, но весьма поверхностная, автор смешивает принципиальные ограничения и частные проблемы используемых технологий, а зачастую об ограничениях предлагаемого подхода не говорит вовсе или называет нечто не имеющее отношения к рассматриваемому вопросу.
7 LESSONS LEARNED WHILE BUILDING REDDIT TO 270 MILLION PAGE VIEWS A MONTH
А сейчас хочу провести небольшой анализ обсуждаемой архитектуры. В статье приводится 7 правил - рассмотрим их все.
LESSON ONE: CRASH OFTEN
The essence of this lesson is: automatically restart failed and cancerous services.
Согласен полностью.
LESSON 2: SEPARATION OF SERVICES
The essence of this lesson is: group like processes and data on different boxes.
Идея здравая, а вот обоснование совершенно невразумительное - утверждается, что все проблемы от потоков в питоне и некорректной работе с кэшем в СУБД, и с какого-то перепугу эти два фактора обобщаются на абсолютно все виды систем. Вот что стоило бы сказать, так это автоматизацию развертывания разделенных сервисов и возможность их неадминистрируемой работы.
LESSON 3: OPEN SCHEMA
The essence of this lesson is: don't worry about the schema.
Рекомендация верная, но перечисленные ограничения слишком надуманные. Для таблиц вида "thing id, key, value" прекрасно работают join-ы в форме "join mytable on mytable.thing_id=thing_id and mytable.key=key". Соответственно, одну такую таблицу подключаем столько раз, сколько разных key нас интересуют. Вероятно, для автора просто не нужны join-ы в силу решаемой им задачи, но вовсе незачем было придумывать лишнее ограничение.
LESSON 4: KEEP IT STATELESS
С первого взгляда не очевидно, но правило избыточно. Добавлю, что, когда приложение это позволяет, нам повезло и многих проблем просто не возникнет, но что делать в противном случае?.. Для ясности стоит ввести понятия макро- и микросостояний. Макросостояние - когда ход обработки запроса определяется состоянием всей системы, а микро - только текущего узла. Первое требует глобальной синхронизации, зато второе совершенно автономно. Потеря микросостояния приведет, максимум, к разрыву сессии пользователя. Частным случаем сервисов с микросостоянием являются сервисы без собственного состояния. Если мы придерживаемся совета LESSON 2: SEPARATION OF SERVICES, то автоматически выполняется и текущая рекомендация. А если мы реализуем сохранение состояния при перезапуске сервиса согласно идее LESSON ONE: CRASH OFTEN, то никто ничего и не заметит. Потому уточним рекомендацию так: замените все макросостояния на микро.
LESSON 5: MEMCACHE
The essence of this lesson is: memcache everything.
Совершенно неверно, автор ставит телегу впереди лошади. Не нужно серверу приложений работать с кэшем, его задача - возвращать вычисляемые актуальные данные, устанавливая заголовки, контролирующие кэширование, такие, как expires, cache-control, etc. Нужен кэш - поставим кэширующий прокси перед фронтэндом или отдельным бэкэндом. В предлагаемом мной варианте значительную часть работы возьмут на себя прокси-серверы провайдеров, т.к. они тоже смогут эффективно кэшировать контент, таким образом мы совершенно бесплатно получаем CDN - распределенную сеть раздачи нашего контента.
LESSON 6: STORE REDUNDANT DATA
The essence of this lesson is: the key to speed is to precompute everything and cache it.
Отнюдь нет. Путь к эффективности - вычислять лишь то,что необходимо, и только тогда, когда это необходимо. Иначе говоря, "ленивые вычисления". Каждый сервис должен заниматься своей работой - вычислять результат, а с помощью контроля кэширования в браузере и на прокси-серверах мы контролируем, когда же именно следует отправлять запросы к сервисам, а когда возвращать кэшированный результат.
LESSON 7: WORK OFFLINE
The essence of this lesson is: do the minimal amount of work on the backend and tell the user you are done.
Технически противоречит пункту LESSON 4: KEEP IT STATELESS. Действительно, если операция производится независимо от запроса пользователя, необходим планировщик для выполнения задач плюс, опционально, поддержка сессий пользователя для оповещения о результатах. В случае, когда требуется оповестить конкретного пользователя, появляется необходимость хранения состояния задачи на сервере. И только в том случае, когда безопасностью пренебрегают, можно сразу же предоставить пользователю адрес для получения сведений о состоянии задачи по ее идентификатору - но тогда любой пользователь сможет увидеть это состояние. Несомненно, в каких-то системах такой подход допустим, но это лишь частный случай и притом с весьма серьезными противопоказаниями к применению.
В качестве резюме. Статья достаточно интересная, но весьма поверхностная, автор смешивает принципиальные ограничения и частные проблемы используемых технологий, а зачастую об ограничениях предлагаемого подхода не говорит вовсе или называет нечто не имеющее отношения к рассматриваемому вопросу.
Comments