Перевод статьи «Scalability: Growing a System in Different Directions».
Вокруг распределенных систем ходит много разговоров, но все они крутятся, собственно, вокруг размеров. Причем, говоря о размере, люди обычно подразумевают размер самой системы. И когда дело касается распределенных систем, оказывается, размер действительно имеет значение.
Сфера компьютерных вычислений имеет удивительно длинную историю. Но если мы говорим о распределенных системах, то история немного отличается. Распределенные вычисления в нашем современном понимании начали появляться в поздние 1960-е и ранние 1970-е, когда компьютеры начали взаимодействовать в сетях (Ethernet).
В течение следующего десятилетия распределенные вычисления становились все более распространенными. Любопытно, что системы начали становиться «распределенными», когда появилась одна массивная распределенная система – интернет.
К 1980-м компьютеры уже использовались повсеместно, а доступ к интернету (и другим сетям) стал более обыденным. Не углубляясь в детали, можно заключить, что машин стало больше, а кроме того, они стали гораздо больше взаимодействовать друг с другом.
Такой тип «роста» имеет собственное название в царстве распределенных систем. Фактически, сегодня многие инженеры (и не только занимающиеся распределенными системами) довольно широко используют этот термин. Я говорю, конечно же, о масштабируемости. Итак, давайте рассмотрим, что такое масштабируемая распределенная система, а также – каким образом система может расти.
Как происходит масштабирование?
Масштабируемость системы может означать много различных вещей в зависимости от того, с чем имеет дело эта система, а также от того, какая часть системы растет. Но в общих чертах можно сказать, что если система обладает масштабируемостью, значит, она может продолжать справляться со своей работой и действовать эффективно в условиях своего роста.
Но что такое «рост»? Какая часть системы увеличивается?
Говоря о том, что система растет, в разных случаях мы, скорее всего, будем иметь в виду разные вещи. Другими словами, система запросто может расти в разных направлениях.
Например, мы можем утверждать, что система растет, если растет число пользователей, взаимодействующих с ней. Если с системой работало 5 тысяч пользователей и вдруг их число возросло до 50 тысяч, это определенно своего рода рост системы!
Но система также может расти и в плане ее собственных ресурсов. Например, однажды она может получить особенно высокий трафик, а следовательно, очень большое количество данных, которые нужно обрабатывать. Или система может особенно интенсивно использоваться в определенный период времени, что приведет к значительному росту количества одновременно запущенных процессов. Или вот еще пример: единая система может расти за счет числа физических машин (серверов) внутри нее.
Все эти вещи – данные, процессы, машины – представляют собой различные направления, по которым может происходить рост системы. И, как мы выяснили ранее, наплыв пользователей это тоже один из видов роста системы.
На самом деле в реальном мире распределенные системы растут не в одном направлении, а в нескольких одновременно. Например, мы можем заметить, что в результате наплыва пользователей возросло и количество данных. А для обработки большего количества данных мы добавляем новые серверы или базы данных.
В реальном мире распределенная система имеет тенденцию расти в больше, чем в одном направлении.
С учетом того, что система может расти по-разному, имеет смысл говорить о масштабируемости системы в привязке к тому, как именно она растет. Чтобы конкретизировать форму масштабируемости, придумано несколько терминов. Основные из них – масштабируемость по размеру, географическая масштабируемость и административная масштабируемость. Это три формы часто называют измерениями масштабируемости. Давайте рассмотрим каждую из них подробнее.
Рост, измеряемый количественно
Первое измерение масштабируемости лежит на пересечении двух вещей, которые мы уже обсуждали: количества пользователей и количества ресурсов (какими бы эти ресурсы ни были). Мы знаем, что и то, и другое может возрастать количественно. Когда такое происходит, мы говорим, что система увеличилась в размерах.
Если система обладает масштабируемостью по размеру, это означает, что она сохраняет свою производительность и остается пригодной к использованию независимо от того, как много ресурсов она может получить.
Возьмем пример. Скажем, наша распределенная система в какой-то день получает высокий трафик. На основе этого мы можем понять, что объем нашей базы данных или существующее количество серверов нашей системы просто не могут справиться с многочисленными запросами в день с особенно высоким трафиком.
Мы можем решить увеличить объем базы данных или на несколько часов добавить серверы для обработки большего потока данных. Но если наша система масштабируется по размеру, добавление новых узлов не должно отрицательно сказаться на производительности. То есть, если мы решили добавить больше узлов для обработки ресурсов или обслуживания пользователей, в результате не должны упасть производительность и эффективность работы всей системы. Наша система должна иметь возможность продолжать работу на уровне, который ожидают от нее пользователи, и, разумеется, для пользователей работа с этой системой не должна замедлиться.
Рост с увеличением сложности
До сих пор мы говорили о добавлении ресурсов или пользователей в функционирующую систему. Но по мере роста системы мы можем обнаружить, что добавление узлов не решает проблему. Фактически, порой само это добавление может приводить к непредсказуемым последствиям.
На первый взгляд может показаться, что добавить узлы или ресурсы в систему довольно легко. Однако это очень наивный подход к сложной проблеме. Если речь идет о распределенной системе, географическая и административная масштабируемость имеют много нюансов, которые могут быть не слишком очевидными.
Увеличение расстояний
Когда система начинает существенно увеличиваться в размерах, мы должны обдумать еще один вопрос: где конкретно расположены наши ресурсы? Здесь и выходит на сцену географическая масштабируемость.
Если система обладает географической масштабируемостью, она может продолжать эффективно функционировать и использоваться вне зависимости от расстояния между пользователями и ресурсами системы.
Вначале это может показаться странным или смешным, но погодите. Скажем, чтобы сделать нашу систему масштабируемой по размеру, мы добавляем больше узлов, которые помогут справиться с возросшей нагрузкой. Если эти узлы – серверы, они могут располагаться в одном месте или в разных местах. И если мы добавляем в нашу систему что-то значительное, такое как целый дата-центр, этот наш новый дата-центр может располагаться достаточно далеко от того дата-центра, который у нас был изначально.
Добавление еще одного узла в нашу систему может казаться простым делом. Но мы помним, что наша цель – создание системы, которая продолжит эффективно функционировать, и к которой по-прежнему смогут легко получать доступ пользователи. В этих условиях добавление нового узла осложняет достижение нашей цели.
Мы, конечно, можем добавлять новые узлы в нашу систему и без учета дистанций между ними. Но это зависит от расположения узлов и расстояния между ними и пользователями. Под расстоянием следует понимать буквальное физическое пространство между ними, т. е., расстояние в географическом смысле.
Но почему вообще расстояние имеет значение? Потому что пересылка данных и взаимодействие разных частей системы занимают определенное время. Два узла, находящиеся в одной комнате, обмениваются информацией гораздо быстрее, чем два узла, находящиеся в два раза дальше друг от друга. К сожалению, существуют физические (географические?) ограничения, справиться с которыми не поможет даже очень хороший wifi.
Если система обладает географической масштабируемостью, добавление новых узлов не увеличивает количество времени, необходимого для коммуникации между ними.
Таким образом, добавляя каждый новый узел, нужно учитывать его физическое расположение по отношению к остальным частям системы.
Рост затрачиваемых усилий
Наконец, если система растет по размеру и в географическом плане, возникает последний вопрос: кто будет наблюдать за новыми частями расширяющейся системы? Мы подобрались к административной масштабируемости.
Если система обладает административной масштабируемостью, добавление новых узлов не должно вызывать существенного роста количества усилий, необходимых для управления этими новыми узлами.
Это особенно важно, если система используется многими администраторами (людьми или организациями, запускающими эту систему наравне с другими людьми и организациями). Каждый из них должен иметь возможность использовать систему, даже когда ею уже пользуются другие.
Административная масштабируемость это еще одно измерение масштабируемости, о котором часто забывают. И если нам легко счесть добавление еще одного узла простым решением проблемы роста системы, нам так же легко забыть, что добавление ресурсов в систему означает, что в будущем понадобятся дополнительные усилия для их поддержки.
В системе, обладающей административной масштабируемостью, добавление ресурсов по мере роста системы не должно вызывать сильного увеличения управленческих усилий.
Если для масштабирования нашей системы нам потребовалось добавить целый дата-центр узлов, мы должны суметь прикинуть количество человеко-часов, которое потребуется на поддержку этих узлов и их работоспособности.
Очень часто, говоря о том, что нужно сделать систему масштабируемой, разработчики на самом деле думают только об увеличении размеров системы. Однако, как и многие другие вещи, распределенные системы развиваются больше, чем в одном направлении. Масштабируемость по размеру это лишь один из аспектов проблемы. Очень важно учитывать также географическую и административную масштабируемость. А обратив внимание на каждый из этих аспектов, мы обнаружим множество нюансов и своих сложностей.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
