В данной статье хочется поделиться моим собственным видением как позитивных, так и негативных моментов в эволюции Сети Интернет. Общеизвестно, что Интернет - это сеть сетей, но с литературной точки зрения постоянное повторение слова сеть будет идеей не из лучших, поэтому я предлагаю использовать более техническое название для каждой из сетей составляющих Интернет - автономная система.
Хочется начать сильно издали, от баз данных. Казалось бы, при чем здесь базы данных, когда мы говорим про Сети? Я попробую объяснить. Последние 5 лет наблюдается процесс экстенсивного укрупнения Интернет компаний.
Если раньше Интернет был множеством автономных систем, каждую из которых можно было отнести к малой, средней либо крупной и у каждого из типов было довольно много представителей. Солидное количество корпораций мирового уровня, большое число средних компаний, Университетов, исследовательских лабораторий и неисчислимое множество малых автономных систем.
Честно говоря, я затрудняюсь объяснить формальным языком, почему именно такой подход хорош. Но мы изо дня в день видим иллюстрацию эффективности и потрясающей жизнеспособности данного механизма - взгляните на окружающий нас животный мир!
Но последнее время баланс стал нарушаться - заметна крайне активная тенденция к образованию огромных сетей транснационального масштаба, которые в десятки и иногда тысячи раз больше сетей, которые считались ранее. Это своего рода Интернет в Интернете. За одним исключением - автономная система, а следовательно компания, которая управляет этой сетью одна единственная.
К примерам таких сетей можно отнести - Facebook, Google, Youtube, Twitter (список совершенно не претендует на полноту). Это довольно разные по своей сути компании - социальные сети, хранилища контента, поисковые системы. Но их объединяет глобальный характер и популярность планетарного масштаба. Я специально не указал здесь сети, которые распространены в масштабах определенных стран, чтобы подчеркнуть именно глобальный масштаб оценки.
Так сложилось, что почти все подобные компании имеют головные офисы в США, этому есть множество причин, описание которых выходит за рамки как моей компетенции, так и статьи в целом.
И тут мы подходим к самому Интересному, базам данных. Любой кто работал с базами данных MySQL, PostgreSQL, MSSQL и Oracle сталкивался с запросами, а как же обеспечить полное резервирование этих баз данных на случае сбоя. Кроме этого, почти всегда накладывается требование - сделать это на уровне базы данных, без внесения изменений на уровне бизнес-логики приложения. К сожалению, обобщенный ответ на этот вопрос почти всегда - "никак". Каждый из вариантов резервирования - master/master, master/single slave, master/multiple slaves является компромиссом и требует очень высокого уровня как квалификации архитектора подобного решения, так и предъявляет высокие требования к квалификации персонала и резко увеличивает необходимый для поддержки решения штат.
Безусловно, решения задачи резервирования баз данных существуют и для реляционных баз данных (SQL), так и для нереляционных, так называемых key-value или document-oriented баз данных, но каждый из них требует серьезных инвестиций и серьезных изменений в архитектуре приложения.
Но самое интересное, что когда рассматривается любой вопрос обеспечения надежности хранения данных он решается в рамках LAN, локальной сети, одного города либо одной страны. Но решения задачи репликации крупной базы данных на несколько различных континентов в данный момент не существует и во многом это вина скорости света :)
И здесь мы подходим к самому интересному моменту, что даже крупные компании из перечисленных выше эту задачу не решают в полной мере. На 2014й год вся запись информации (например, публикация нового сообщения) на сайте Facebook безусловно уходила в США. В то время как графика и статический контент могли загружаться из Дата Центра в Швеции (Лулль). Казалось бы, ничего страшного, но в масштабе сети это очень неприятное явление. Так как нарушение связанности с сетями США в виду каких-либо проблем приведет к полной потере работоспособности сервиса и последующей потери его ценности для конечного пользователя.
Может показаться, что в статье я критикую недостаточную компетенцию указанных компаний. Честно говоря, это бы звучало очень странно, тем более, что в компании Google есть прототип реально работающей географически распределенной базы данных, которая является ядром всего технологического стека этого гиганта - Google Big Table. Но, к сожалению, это проприетарная платформа и информация о ней крайне скудна. Конечно же, появление подобных продуктов на массовом рынке дало бы огромный скачек к повышению надежности как отдельных сервисов, так и сети Интернет в целом
Их нужно знать в лицо - наиболее устойчивые к сбоям протоколы.
Есть ли примеры реализации полностью устойчивых к нарушениям связанности протоколов и сервисов? Безусловно! Это наш любимый сервис - root DNS, который тоже в своем роде является очень большой географически распределенной сетью насчитывающей около тысячи узлов. Но в случае протокола DNS у нас нет необходимости менять значения для корневых зон, чаще всего меняются данные в листьях (записи в конкретной доменной зоне и записи для конкретного домена). И протокол DNS отлично справляется с обеспечением надежного хранения изменений. Несмотря на это, единая точка отказа все равно присутствует, как раз на ней хранятся данные о всех корневых серверах. Но, к счастью, в связи с довольно медленным процессом изменения данных в DNS (сравните с базой транзакций банка!) такой сбой пройдет скорее всего незамеченным даже если продлится несколько десятков часов.
Также отличной иллюстрацией абсолютно устойчивого протокола - сервиса является BitTorrent, который при использовании функционала DHT позволяет добиться полной де-централизации и независимости от какого-либо мастера (его просто не существует). Но тут также не решается проблема с изменением данных - изменение не предусмотрено в принципе.
К таким же бравым де-централизованным и очень надежным протоколам можно отнести и протокол BGP, который по своей архитектуре рассчитан на работу в сетях, где сбои - постоянный процесс.
Что в будущем?
Кроме этого, уже появилась реально работающая (и даже используемая в коммерческой услуге компанией Korea Telecom) реализация multipath tcp, которая позволяет добиться повышенного уровня надежности. Ранее данный функционал был реализован в протоколе sctp, но, к сожалению, он так и не обрел какой-либо серьезной популярности.
Также технологической проблемой на пути к построению реально надежных сервисом является отсутствие встроенной поддержки обеспечения высокой доступности как в протоколе HTTP, так и в протоколе HTTP2.
Выводы
Процесс укрупнения автономных систем и последующей централизации Интернета, к сожалению, неотвратим. Он очень похож на тенденции развития новых рынков. Все начинается со множества небольших компаний компаний и постепенно выкристаллизовываются несколько огромных ключевых игроков, которые замыкают на себе почти всех клиентов.
Дата написания: 10 декабря 2015 г., 22:09.
Хочется начать сильно издали, от баз данных. Казалось бы, при чем здесь базы данных, когда мы говорим про Сети? Я попробую объяснить. Последние 5 лет наблюдается процесс экстенсивного укрупнения Интернет компаний.
Если раньше Интернет был множеством автономных систем, каждую из которых можно было отнести к малой, средней либо крупной и у каждого из типов было довольно много представителей. Солидное количество корпораций мирового уровня, большое число средних компаний, Университетов, исследовательских лабораторий и неисчислимое множество малых автономных систем.
Честно говоря, я затрудняюсь объяснить формальным языком, почему именно такой подход хорош. Но мы изо дня в день видим иллюстрацию эффективности и потрясающей жизнеспособности данного механизма - взгляните на окружающий нас животный мир!
Но последнее время баланс стал нарушаться - заметна крайне активная тенденция к образованию огромных сетей транснационального масштаба, которые в десятки и иногда тысячи раз больше сетей, которые считались ранее. Это своего рода Интернет в Интернете. За одним исключением - автономная система, а следовательно компания, которая управляет этой сетью одна единственная.
К примерам таких сетей можно отнести - Facebook, Google, Youtube, Twitter (список совершенно не претендует на полноту). Это довольно разные по своей сути компании - социальные сети, хранилища контента, поисковые системы. Но их объединяет глобальный характер и популярность планетарного масштаба. Я специально не указал здесь сети, которые распространены в масштабах определенных стран, чтобы подчеркнуть именно глобальный масштаб оценки.
Так сложилось, что почти все подобные компании имеют головные офисы в США, этому есть множество причин, описание которых выходит за рамки как моей компетенции, так и статьи в целом.
И тут мы подходим к самому Интересному, базам данных. Любой кто работал с базами данных MySQL, PostgreSQL, MSSQL и Oracle сталкивался с запросами, а как же обеспечить полное резервирование этих баз данных на случае сбоя. Кроме этого, почти всегда накладывается требование - сделать это на уровне базы данных, без внесения изменений на уровне бизнес-логики приложения. К сожалению, обобщенный ответ на этот вопрос почти всегда - "никак". Каждый из вариантов резервирования - master/master, master/single slave, master/multiple slaves является компромиссом и требует очень высокого уровня как квалификации архитектора подобного решения, так и предъявляет высокие требования к квалификации персонала и резко увеличивает необходимый для поддержки решения штат.
Безусловно, решения задачи резервирования баз данных существуют и для реляционных баз данных (SQL), так и для нереляционных, так называемых key-value или document-oriented баз данных, но каждый из них требует серьезных инвестиций и серьезных изменений в архитектуре приложения.
Но самое интересное, что когда рассматривается любой вопрос обеспечения надежности хранения данных он решается в рамках LAN, локальной сети, одного города либо одной страны. Но решения задачи репликации крупной базы данных на несколько различных континентов в данный момент не существует и во многом это вина скорости света :)
И здесь мы подходим к самому интересному моменту, что даже крупные компании из перечисленных выше эту задачу не решают в полной мере. На 2014й год вся запись информации (например, публикация нового сообщения) на сайте Facebook безусловно уходила в США. В то время как графика и статический контент могли загружаться из Дата Центра в Швеции (Лулль). Казалось бы, ничего страшного, но в масштабе сети это очень неприятное явление. Так как нарушение связанности с сетями США в виду каких-либо проблем приведет к полной потере работоспособности сервиса и последующей потери его ценности для конечного пользователя.
Может показаться, что в статье я критикую недостаточную компетенцию указанных компаний. Честно говоря, это бы звучало очень странно, тем более, что в компании Google есть прототип реально работающей географически распределенной базы данных, которая является ядром всего технологического стека этого гиганта - Google Big Table. Но, к сожалению, это проприетарная платформа и информация о ней крайне скудна. Конечно же, появление подобных продуктов на массовом рынке дало бы огромный скачек к повышению надежности как отдельных сервисов, так и сети Интернет в целом
Их нужно знать в лицо - наиболее устойчивые к сбоям протоколы.
Есть ли примеры реализации полностью устойчивых к нарушениям связанности протоколов и сервисов? Безусловно! Это наш любимый сервис - root DNS, который тоже в своем роде является очень большой географически распределенной сетью насчитывающей около тысячи узлов. Но в случае протокола DNS у нас нет необходимости менять значения для корневых зон, чаще всего меняются данные в листьях (записи в конкретной доменной зоне и записи для конкретного домена). И протокол DNS отлично справляется с обеспечением надежного хранения изменений. Несмотря на это, единая точка отказа все равно присутствует, как раз на ней хранятся данные о всех корневых серверах. Но, к счастью, в связи с довольно медленным процессом изменения данных в DNS (сравните с базой транзакций банка!) такой сбой пройдет скорее всего незамеченным даже если продлится несколько десятков часов.
Также отличной иллюстрацией абсолютно устойчивого протокола - сервиса является BitTorrent, который при использовании функционала DHT позволяет добиться полной де-централизации и независимости от какого-либо мастера (его просто не существует). Но тут также не решается проблема с изменением данных - изменение не предусмотрено в принципе.
К таким же бравым де-централизованным и очень надежным протоколам можно отнести и протокол BGP, который по своей архитектуре рассчитан на работу в сетях, где сбои - постоянный процесс.
Что в будущем?
Кроме этого, уже появилась реально работающая (и даже используемая в коммерческой услуге компанией Korea Telecom) реализация multipath tcp, которая позволяет добиться повышенного уровня надежности. Ранее данный функционал был реализован в протоколе sctp, но, к сожалению, он так и не обрел какой-либо серьезной популярности.
Также технологической проблемой на пути к построению реально надежных сервисом является отсутствие встроенной поддержки обеспечения высокой доступности как в протоколе HTTP, так и в протоколе HTTP2.
Выводы
Процесс укрупнения автономных систем и последующей централизации Интернета, к сожалению, неотвратим. Он очень похож на тенденции развития новых рынков. Все начинается со множества небольших компаний компаний и постепенно выкристаллизовываются несколько огромных ключевых игроков, которые замыкают на себе почти всех клиентов.
Дата написания: 10 декабря 2015 г., 22:09.
No comments :
Post a Comment
Note: only a member of this blog may post a comment.