Книга Мартина Клеппмана «Высоконагруженные приложения»

Недавно дочитал книгу Мартина Клеппмана «Высоконагруженные приложения. Программирование, масштабирование, поддержка». В оригинале книга называется «Designing Data-Intensive Applications», а при переводе на русский язык название стало менее конкретным, потому что под высоконагруженными приложениями можно понимать разные виды нагрузки: вычислительную нагрузку на процессор и «высоконагруженные» в том плане, что нужно обрабатывать большой объем данных. Во втором случае основная нагрузка ляжет не на плечи процессора, а узким местом будет сеть или система ввода-вывода. В книге рассматриваются высоконагруженные системы, относящиеся ко второму случаю.

Книга посвящена в основном системам хранения и обработки данных, т.е. базам данных различного типа (SQL и noSQL) и системам, которые анализируют большой поток данных, например, Hadoop. Основная тема книги — это проблемы, которые могут возникнуть в распределенных системах, когда нужно поддерживать согласованное состояние базы данных, сервера которых запущены на машинах, которые могут располагаться даже в разных странах, и не известно, к какому из них будет обращаться пользователь в каждый момент времени. В книге речь идет в основном про архитектурные решения, а не конкретные реализации, хотя в тексте постоянно приводятся ссылки на тот или иной инструмент и говорится, как и насколько хорошо в них решаются описываемые проблемы.

Что мне понравилось в книге, так это то, насколько автор аккуратно и скрупулезно относится к используемым терминам, коих в книге не мало. Первая глава книги начинается с того, что даются аккуратные определения того, что понимается под словами «надежность», «масштабируемость», чем «сбой» отличается от «отказа», по каким критериям можно оценивать нагрузку и производительность, чем термин «время ожидания» отличается от термина «время отклика» и тому подобное.

Подходящая для определенного уровня нагрузки архитектура, вероятно, не сможет справиться с десятикратным ее увеличением. Если вы имеете дело с быстрорастущим сервисом, то, вероятно, вам придется пересматривать архитектуру при каждом возрастании нагрузки на порядок или даже еще чаще.

В первой части книги помимо ввода терминов и определений, речь идет также и о системах хранения данных в целом: реляционные базы данных, базы данных noSQL (документоориентированные и графовые базы данных), в чем их преимущества и недостатки, какие реализации этих идей существуют, какие существуют языка запросов для разных моделей хранения данных.

Отдельная глава посвящена тому, как базы данных хранят данные на диске, какие используются структуры данных, какие используются приемы для оптимизации чтения и записи. В этой главе используются (с описанием, разумеется) такие термины как SS-таблицы, B- и LSM-деревья. Говорится о том, как строятся индексы в базах данных. Говорится о том, что запросы, которые выполняются в процессе взаимодействия пользователя с вашим сервисом, и запросы, которые выполняют аналитики компании, принципиально отличаются, и поэтому часто имеет смысл для аналитических запросов, которые намного тяжелее, заводить отдельную базу данных, куда периодически сбрасывать копию данных с боевых серверов. Иначе аналитики будут сильно нагружать базу данных, с которыми работают пользователи сервиса.

Вторая часть книги посвящена распределенным данным, то есть тому случаю, когда данные хранятся не на одном физическом сервере, и проблемам, которые с этим связаны. Здесь рассматриваются такие приемы «размазывания» данных, как репликация и секционирование. Вообще две трети книги посвящена проблемам, связанным с тем, что сеть не надежна, время отклика может быть произвольным, да еще и сервера могут иногда отказывать (например, харды помирать). Как во всем этом ужасе сделать рабочий сервис, чтобы пользователь не замечал этого ада, его данные не пропадали и не дублировались, чтобы два человека, которые подключаются к серверам, расположенным на противоположных концах земного шара, при покупке билетов на самолет не купили билет на одно и то же место. А в каких случаях это допустимо? Как обеспечить репликацию базы данных на разных машинах в тот момент, когда пользователи продолжают что-то писать в эти базы данных. Как обеспечить работоспособность приложения, когда не известно, мы не получили подтверждение от базы данных потому что сервер упал и не выполнил наш запрос (тогда запрос надо повторить) или потому что ответ об удачной транзакции потерялся по дороге из-за ненадежности сети, и тогда запрос повторять не надо (вы же не хотите у пользователя списать деньги дважды?).

А если пользователь написал пост в блог, он сохранился в базе на одном из серверов и не успел продублироваться на других серверах, а через секунду тот же пользователь обновляет свою страницу, но обращение в другой раз происходит к другому серверу, куда еще не успел дойти его пост, и пользователь видит, что пост, который он писал на протяжении двух часов, пропал. Как оградить пользователей от такого стресса? Большая часть книги посвящена тому, как архитектурно решаются подобные проблемы, чем за это приходится платить, и всегда ли мы можем решить подобные проблемы, а когда приходится с ними смириться, но хотя бы минимизировать вероятность возникновения подобных ситуаций. Множество подобных проблем возникает в случае, когда несколько пользователей обращаются к одним и тем же данным, модифицируют и читают их, а эти данные тоже могут быть размазаны по разным серверам.

Отдельная глава посвящена транзакциям, как можно обеспечить атомарность и согласованность операций с распределенных системах при тех же условиях, когда сеть не надежна, а сервера могут умирать в самый неподходящий момент, например, после выполнения транзакции, но до того, как успел отправить клиенту подтверждение ее успешности.

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

Стоимость программного обеспечения состоит по большей части из затрат не на изначальную разработку, а на текущее сопровождение — исправление ошибок, поддержание работоспособности его подсистем, расследование отказов, адаптацию к новым платформам, модификацию под новые сценарии использования, возврат технического долга и добавление новых возможностей.

Последняя часть книги посвящена обработке данных в распределенных системах. Рассматривается пакетная обработка, когда есть набор данных, когда есть некий набор данных, который нужно прогнать через определенные операции и получить результат, а также потоковая обработка, когда данные поступают непрерывно. В этих главах рассматривается технология MapReduce и различные ее реализации, одна из наиболее известных — это Hadoop, но упоминаются и другие. Рассматривается, как происходит параллельная обработка данных, что можно распараллелить, а что приходится делать последовательно. Что делать, если пользователь шлет данные слишком часто, и сервер не успевает их обрабатывать, какие в этом случае существуют алгоритмы поведения.

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

Не сказал бы, что книга читается легко, у меня она шла очень тяжело. Вроде и материал, который в ней описывается, понятный и интересный, но многие абзацы и даже целые страницы приходилось перечитывать по несколько раз, потому что по мере чтения понимаешь, что потерял нить повествования или отвлёкся от содержания на свои мысли.

Но если вы разрабатываете действительно высоконагруженное приложение, то книгу стоит почитать хотя бы для того, чтобы понять, с какими проблемами вы столкнетесь в процессе работы, и что может пойти не так.

В общем, то, что сайты вроде Facebook, Twitter и Google вообще работают — это большое чудо, и пользователям лучше не знать, что происходит под капотом после того, как их браузер отправил казалось бы маленький запрос к серверу этих сайтов.

А еще в книге перед каждой главой нарисованы забавные карты, которые интересно разглядывать. Вот, например одна из них:

Вы можете подписаться на новости сайта через RSS, Группу Вконтакте или Канал в Telegram.

Пожалуйста, оцените запись

УжасноПлохоТак себеХорошоОтлично (Количество голосов: 3, средняя оценка: 4,67)
Загрузка...

Leave a comment

Subscribe without commenting