Б Бёрнс - Распределенные системы. Паттерны проектирования

‰ ‰ какова роль кэша в вашей архитектуре;‰ ‰ нужен ли реплицированный и шардированный кэш;‰ ‰ в чем состоит функция шардирования?Зачем вам нужен шардированный кэш Как уже упоминалось во введении, шардирование в первую очередь необходимо для увеличения объема хранимых в сер-висе данных. Чтобы понять, как это помогает кэшированию, рассмотрим следующую систему. В каждом экземпляре кэша есть 10 Гбайт памяти для хранения результатов. Каждый эк-земпляр кэша может обслуживать до 100 запросов в секунду (RPS). Допустим, в нашем сервисе хранится 200 Гбайт данных, а ожидаемая нагрузка составляет 1000 RPS. Очевидно, требуется десять экземпляров кэша, чтобы удовлетворить 1000 запросов в секунду (десять экземпляров по 100 RPS на экземпляр). Про-ще всего будет развернуть этот сервис в реплицированном виде, как показано в предыдущей главе. Но, если развернуть его та-ким образом, распределенный кэш сможет хранить не более 5 % (10 из 200 Гбайт) общего набора данных. Так происходит потому, что каждый экземпляр кэша независим от остальных, а значит, хранит примерно те же данные, что и остальные. Это отличный подход для обеспечения избыточности, который совершенно не способствует эффективному использованию памяти. Если же мы развернем шардированный на десять частей кэш, то все так же сможем обслуживать нужное количество запросов в секунду Глава 6. Шардированные сервисы 105

(10 × 100 все еще равно 1000). Однако, поскольку каждый эк-земпляр кэша работает со своей отдельной частью данных, мы можем хранить там 50 % данных (10 × 10 из 200 Гбайт). Десяти-кратное увеличение объема кэшируемых данных означает, что кэш-память используется гораздо более эффективно, поскольку каждый элемент данных попадает только в один кэш. Роль кэша в производительности системы В главе 5 мы обсудили, как использовать кэш с целью оптими-зации производительности для конечного пользователя и со-кращения задержек. Не была, однако, рассмотрена роль кэша в производительности, надежности и стабильности приложения. Проще говоря, важно задать себе следующий вопрос: если кэш откажет, как это повлияет на ваших пользователей и на работу сервиса в целом?

Когда мы обсуждали реплицированный кэш, этот вопрос был менее актуален, так как кэш масштабировался горизонтально, то есть отказ одного из экземпляров приводил бы только к крат-ковременным неисправностям. Аналогичным образом рассмо-тренный кэш поддерживал масштабирование в связи с вырос-шей нагрузкой, не влияя при этом на конечных пользователей. В случае с шардированным кэшем все оказывается несколько иначе. Поскольку конкретный пользователь или запрос всегда соответствует одному и тому же шарду, в случае его отказа кэш-промахи будут происходить до тех пор, пока шард не бу-дет восстановлен. Учитывая временность нахождения данных в кэше, такие кэш-промахи не являются проблемой сами по себе — система должна знать, где взять данные. Однако извле-чение данных в отсутствие кэша происходит намного медлен-нее, что означает снижение производительности для конечных пользователей.

106Часть II. Паттерны проектирования обслуживающих систем Производительность кэша выражается в виде коэффициента попадания запросов . Коэффициент попадания — доля запросов, ответ на которые содержится в кэше. В конечном итоге коэффи-циент попадания характеризует общую максимальную нагрузку на распределенную систему и влияет на производительность и мощность системы в целом.

Представьте, что уровень обработки запросов вашего приложе-ния поддерживает обработку 1000 запросов в секунду. При превышении этого показателя система начинает воз-вращать HTTP-ошибки с кодом 500. Если вы добавите кэш с 50%-ной вероятностью попадания, количество обрабатыва-емых запросов возрастет до 2000 в секунду. Так происходит потому, что из 2000 запросов одна половина может быть обслу-жена кэшем, а другая — уровнем обработки запросов. В данном примере кэш довольно критичен для работы сервиса, поскольку в случае его отказа уровень обработки запросов окажется пере-гружен и половина запросов завершится ошибкой. Именно по-этому имеет смысл оценить емкость сервиса в 1500 запросов секунду, а не в полные 2000. Это позволит удержать сервис в стабильном состоянии даже при отказе половины экземпляров кэша.

Производительность системы, однако, не ограничивается коли-чеством обрабатываемых в единицу времени запросов. Произ-водительность, с точки зрения конечного пользователя, также определяется задержкой выполнения запросов. Получить ре-зультат из кэша, как правило, гораздо быстрее, чем сформиро-вать его с нуля. Следовательно, кэш повышает не только коли-чество одновременно обрабатываемых запросов, но и скорость их обработки. Почему? Представьте, что система обслуживает запрос пользователя за 100 миллисекунд. Добавим кэш с ве-роятностью попадания 25 %, который возвращает результат за 10 миллисекунд. Средняя задержка обработки запроса, таким Глава 6. Шардированные сервисы 107

образом, уменьшилась до 77,5 миллисекунд. Кэш не только увеличивает количество обрабатываемых в секунду запросов, но и ускоряет выполнение каждого отдельного запроса, поэтому замедление обработки запросов в результате отказа части экзем-пляров кэша или развертывания новой его версии беспокоит нас не слишком сильно. Однако в некоторых случаях влияние на производительность окажется настолько велико, что запросы начнут скапливаться в очередях и часть из них будет отклонять-ся по истечении времени ожидания. Никогда не будет лишним выполнять нагрузочное тестирование сервиса как при наличии, так и при отсутствии кэша, чтобы понять его влияние на общую производительность системы.

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

Или же нагрузка на определенный шард становится слишком велика и вам приходится его масштабировать, чтобы он выдер-живал объем работ. Указанные причины могут подтолкнуть вас к развертыванию одновременно реплицированного и шардирован-ного сервиса. Шардированный сервис с репликацией совмещает паттерн построения реплицированного сервиса, рассмотренный в предыдущей главе, с паттерном шардирования, описанным 108Часть II. Паттерны проектирования обслуживающих систем в предыдущих разделах. По сути, каждый шард кэша в таком слу-чае реализуется не одним сервером, а реплицированным сервисом. Такая архитектура более сложна в реализации и развертывании, но имеет определенные преимущества перед просто шарди-рованным сервисом. Что наиболее важно, замена одиночного сервера реплицированным сервисом повышает устойчивость шардов к отказам и обеспечивает их доступность в случае от-каза одной из реплик. Вместо того чтобы закладывать в систему устойчивость к снижению производительности из-за отказа шардов, можно рассчитывать на улучшение производитель-ности за счет использования кэша. Если вы готовы обеспечить избыточный резерв вычислительной мощности для шардов, развертывание новой версии даже в периоды пиковой нагрузки для вас не представляет никакой опасности. Теперь нет необхо-димости ждать, когда нагрузка спадет.