Наверх ▲

Интеграция сайта с облачным хранилищем

Александр Сербул Александр Сербул C 2011 года курирует направление контроля качества интеграции и внедрений ООО «1С-Битрикс», активно участвует как архитектор и разработчик в проектах компании, связанных с высокой нагрузкой и отказоустойчивостью («Битрикс24»), консультирует партнеров и клиентов по вопросам архитектуры высоконагруженных...
Александр Демидов: Добрый день, меня зовут Александр Демидов. Сегодня я рассказываю об "облачных" хранилищах. Когда мы с Олегом Буниным обсуждали эту презентацию и обговаривали, что в нее стоит или не стоит включать, Олег говорил, что не надо добавлять лишних вводных слов о том, «что такое облачные хранилища». Все прекрасно знают, что это такое и зачем это нужно. Все мы знаем, что облачные хранилища нужны для того, чтобы гики могли закачать обратно в Интернет все то, что выкачали оттуда за многие годы.

Существуют разные хранилища. Есть такие, которые могут функционировать как совершенно отдельный сервис (например, "Amazon S3"). Есть такие, которые более полно интегрированы с "облачной" платформой в целом (например, "Google Cloud Storage"). Есть OpenSource-проекты (например, "OpenStack"). Давайте поговорим обо всем этом подробнее.

Практически все "облачные" хранилища очень схожи с точки зрения клиента. Они позволяют хранить практически неограниченное количество самых разных объектов, вплоть до терабайтов размером. Они позволяют напрямую отдавать их пользователям по HTTP, HTTPS. Все хранилища имеют достаточно простой REST- или SAP-интерфейс API для работы с ними, а также отличаются невысокой ценой. Практически все хранилища декларируют крайне высокую надежность и доступность.

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

За счет чего достигается надежность, отказоустойчивость тех или иных "облачных" хранилищ?

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

Если вы загружаете новый файл, ответ об успешной загрузке вы получите только тогда, когда файл загрузился не на одно устройство, а, как минимум, на несколько. Все это происходит прозрачно, быстро. Точки чаще всего географически распределены. Чтобы обеспечить надежность, они географически независимы друг от друга.

Например, тот же "Amazon" относительно своего сервиса "Amazon S3" говорит о том, что их архитектура устроена таким образом, что доступность находится на уровне двух девяток после запятой, а отказоустойчивость, вероятность потери данных – одна миллиардная процента. Если вы загрузили 10 тысяч файлов в хранилище "Amazon", то с некоторой долей вероятности один файлик примерно раз в десять миллионов лет вы можете потерять.

С технической точки зрения отказоустойчивость обеспечена, все хорошо. Возникает вопрос: стоит ли создавать резервные копии таких данных? Даже если провайдер нас заверил, мы ему поверили, что все хранится надежно, никто не застрахован от сбоев в собственном программном обеспечении или от человеческого фактора, когда мы пошли и удалили те или иные файлы, и что-то с ними случилось.

Самый простой вариант – можно реализовать обычное резервное копирование, или же использовать какие-то более умные, продвинутые механизмы. Например, тот же "Amazon" позволяет использовать версионность файлов, когда мы специальными запросами формируем, задаем хранение нескольких последних копий файла. Даже если мы его удаляем или перезаписываем, мы можем обратиться к более ранней версии. Единственный минус – мы платим за хранение всех файлов. Если мы загрузили файл в один мегабайт, и у нас есть его десять версий, то платим мы уже за десять мегабайт. Но, на самом деле, механизм удобный. Его крайне полезно использовать в своих проектах, чтобы максимально себя обезопасить.

Еще один вопрос безопасности – это сохранность, конфиденциальность данных. Часто мы хотим дать доступ к файлам не всем, а каким-то определенным пользователям. Практически каждый "облачный" провайдер, так или иначе, реализовал механизм access-листов, которые позволяют дать доступ на чтение, например, всем пользователям или каким-то определенным. ACL реализованы практически у всех.

Еще можно использовать шифрование на клиентской стороне. Тогда сам клиент отвечает за хранение и обработку всех ключей, посредством которых происходит шифрование. Или можно использовать сервер-сайт шифрования ("Amazon S3" предоставляет такую услугу), тогда эти вещи провайдер берет на себя.

Безопасность, надежность – это ключевой момент использования любого внешнего сервиса, особенно если речь идет о каких-то "облачных" сервисах. Люди часто говорят, возражая против использования "облака": "Я никогда в жизни не отдам свои данные куда-то наружу". По сравнению, например, с традиционными хостерами, это ничуть не менее надежно. Может быть, в чем-то даже более надежно. Это на самом деле клево и удобно.

Если мы все-таки решим это использовать, давайте посмотрим, какую пользу нам это может принести.

Мы не можем хранить там скрипты и выполнять их. Мы можем хранить там только статику.

Какие плюсы это может дать нам или вам как владельцу веб-проекта?

Во-первых, мы снижаем стоимость эксплуатации проекта. Часто говорят, что это достаточно спорный тезис. Начинают сравнивать напрямую и приводят доводы о том, что стоимость дисков снижается, хранение в "облачном" хранилище или напрямую на диске ничуть не выгоднее, а иногда на собственном диске, наоборот, дешевле. Неправильно сравнивать напрямую. Важно заложить в бюджет стоимость резервирования, копирования и администрирования всего этого. Если учесть эти затраты, получается, что при больших объемах (когда речь идет о терабайтах), использование "облачных" хранилищ оказывается выгоднее для проектов.

Почти каждый "облачный" провайдер предлагает для своих "облачных" хранилищ собственную (или в партнерстве с кем-то) CDN-сеть (Content Delivery Network), которая позволяет отдавать ваш контент посетителям вашего сайта из ближайшей к нему географической точки.

Мы вынесли всю статику наружу, и наше приложение Application занимается только приложением. Мы снижаем нагрузку на веб-узлы, не отдаем статику напрямую с веб-сервера. Снижаем нагрузку на диски и веб-сервер.

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

Наконец, мы ускоряем скорость рендеринга страниц в браузере. Даже если у нас суперпроизводительный сервер, все в порядке с сетью, и весь контент отдается максимально быстро – все браузеры по умолчанию открывают достаточно ограниченное количество подключений к одному домену. Обычно допустимо четыре-пять соединений. Если основные страницы ваших сайтов и вся статика (Java-скрипты, CSS и картинки) отдаются с одного домена, то при десятках страниц браузер будет загружать все это в четыре-пять потоков.

Если вы это разносите по разным доменам (даже если не используете "облачное" хранилище, а физически используете то же самое хранилище, просто по доменам разнесли), то браузер будет открывать независимое соединение каждому из поддоменов.

Казалось бы, мы здесь "экономим на спичках". Речь идет про какие-то доли секунды или секунды. Но, на самом деле, это весьма критичное значение.

Есть одна компания под названием Gomez... Занимается она как раз консалтингом в сфере производительности, аудитом сайтов, и так далее. Они проводили исследование 150 миллионов хитов со 150-ти разных сайтов. К какому выводу они пришли? Замедление загрузки страницы на одну секунду приводит к уменьшению количества просмотров страниц на 11 % и к уменьшению конверсии – на 7 %. Для онлайн-бизнеса это огромные цифры и огромные потери. Так что имеет смысл сэкономить и эти вещи не потерять.

Amazon S3

Замечательный, удобный инструмент. Давайте теперь выберем, какое конкретно хранилище мы будем использовать.

"S3" в названии "Amazon S3" расшифровывается как Simple Storage Service. Это и в самом деле простой сервис хранения. Он прост, как молоток, которым забивают гвозди. Молотком можно выполнять только одну функцию – забивать гвозди. Но это можно делать классно. Очень популярное хранилище, очень многие его используют. На мой взгляд, популярность связана с тем, что его можно использовать совершенно независимо от всей инфраструктуры Amazon. Можно использовать вместе, например, с той же CDN, через Cloudfront от Amazon отдавать файлы посетителям через их CDN. Но это хранилище можно использовать абсолютно независимо.

Очень развиты и официально поддерживаются различные SDK, Java, .NET, PHP, Ruby. Насколько я знаю, Amazon чуть ли не единственный провайдер "облачных" хранилищ, которые официально (первыми, по крайней мере) стали поддерживать SDK и для мобильных платформ, iOS и Android. Этим, наверное, и объясняется популярность именно этой платформы; ее используют очень многие разработчики.

Интересная особенность Amazon S3

Для этого хранилища предусмотрена такая услуга, как RRS (Reduced Redundancy Storage), то есть хранилище пониженной надежности. Данные реплицируются в меньшее количество точек по сравнению с обычным хранилищем. За счет этого снижается стоимость, RRS примерно на 25 % дешевле.

Где можно использовать RRS?

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

Как работать с таким хранилищем?

Есть API Rest. Оно достаточно простое. Через него можно получить список бакетов, список объектов в бакете. Можно загрузить файл, получить файл, управлять access-листами для файлов (определять, кто имеет доступ к файлам) и выполнять другие подобные операции, список которых достаточно ограничен. Это действительно очень простой инструмент.

Можно работать через веб-интерфейс самого провайдера, через внешних клиентов от сторонних производителей. Можно использовать такую интересную вещь, как s3fs. Можно применить решение на основе FUSE – это файловая система, которая просто монтируется к вашей системе и выглядит как отдельный раздел. Дальше можно с ним абсолютно прозрачно работать: копировать, перемещать, с него файлы удалять.

Финансовый вопрос

Стоимость хранения достаточно невысока – хранение 14 гигабайт данных стоит 12 центов в месяц. Трафик, насколько я помню, примерно также – 12 центов за гигабайт. Все зависит от объемов. Если речь идет уже о терабайтах, то стоимость может снижаться примерно до двух раз в зависимости от объема.

Google Cloud Storage

Следующее хранилище – это Google Cloud Storage.

Оно, по-моему, используется меньше, чем Amazon S3. На мой взгляд, это связано с тем, что данное хранилище во многом "завязано" на "облачную" платформу от Google под названием Google App Engine. Не существует даже SDK отдельно для работы с этим хранилищем. Оно используется для всей платформы. Исторически оно поддерживается для Java и Python. Набор инструментов там достаточно ограниченный.

Каковы интересные особенности Google Cloud Storage?

Стандартный механизм авторизации, который используется в Google Cloud Storage называется OAuth 2.0. Он документирован. Есть множество примеров работ именно с этим механизмом. Использовать его легко и просто.

Access-листы, которые используются в Google Cloud Storage основаны на аккаунтах Google. Если вы хотите отдавать файлы не всем, а каким-то определенным пользователям, то указываете их аккаунт в Gmail или Google+. Пользователь, если он авторизован в Google в своем браузере, и вы ему дали права на файл, файл скачает. Если он в своем браузере в этом аккаунте не авторизован, то он файл не получит. Достаточно удобный инструмент, потому что очень у многих (хотя и не у всех) есть аккаунты Google в тех или иных сервисах. Файлы удобно отдавать вполне конкретным людям.

Так же, как и в случае с Amazon S3, в Google Cloud Storage есть стандартный веб-интерфейс для работы с файлами в хранилище. Есть API, утилиты для работы с командной строкой, внешние клиенты для работы с файлами.

Финансовый вопрос

Стоимость практически такая же, как и в Amazon S3: те же 12 центов за хранение и 12 центов за трафик. Уменьшение стоимости в зависимости от объема примерно до полутора раз, в зависимости от того, сколько терабайт данных вы храните и передаете.

Windows Azure Storage

Следующее хранилище – это Windows Azure Storage. 

Windows Azure Storage – это составная часть облачной платформы от Microsoft под названием Windows Azure. У него есть главная ключевая особенность, говорящая в пользу выбора этого хранилища: CDN-сеть в России. Напримери, тот же Amazon S3 имеет достаточно большую CDN-сеть, но не имеет точек присутствия в России. CDN-сеть Microsoft в России имеет порядка 10-ти точек. Эта CDN реально удобна для российских пользователей. Если мы сгружаем контент из Новосибирска, то получим его из точки, ближайшей к Новосибирску. Если из Москвы – значит, из точки, ближайшей к Москве.

SDK для работы с Windows Azure Storage достаточно интересен. Естественно, поддерживаются .NET, Node. js, Java, PHP (достаточно распространенные инструменты). Существуют сторонние клиенты для работы с файлами, загрузки, получения данных из этого "облака". Интересная особенность – возможность использовать Windows Azure Drive. Можно монтировать "облако" как отдельный NTFS-раздел. Этот же инструмент позволяет быстро переносить данные из общедоступного "облака" в частное и наоборот.

Rackspace Cloud Files

Еще один "облачный" провайдер – это Rackspace. Наверное, это один из крупнейших провайдеров в мире.

Естественно, как и любой "облачный" провайдер подобного масштаба, Rackspace сделал свое облачное хранилище – Rackspace Cloud Files. Они не стали делать собственную сеть CDN, но работают в партнерстве с одним из крупнейших CDN-провайдеров в мире – Akamai. Пользователи Rackspace автоматически могут пользоваться услугами Akamai для дистрибуции контента.

Чем интересна облачная платформа, которую использует Rackspace?

Совместно с NASA (даже, наверное, по их заказу) они разрабатывали "облачную" платформу, которая в середине 2010-го года стала существовать в виде отдельного открытого проекта под названием "OpenStack". Сейчас это набор программного обеспечения для создания полноценной "облачной" платформы, которую, по сути, любой желающий может взять и развернуть у себя внутри для каких-то внутренних целей. Также можно развернуть общедоступное "облако" и начать предоставлять услуги на базе этого проекта.

Пока в России это сделала только компания Clodo, насколько я знаю. Это первая компания, которая публично предоставляет услуги "облачного" хранилища именно в России. Это очень удобно, как минимум, с точки зрения бухгалтерии, документов и платы за пользование услугами.

"OpenStack" поддерживается очень многими компаниями. Их порядка 50-ти, включая Dell, Citrix, AMD и Intel. Проект активно развивается, он очень интересен. "Облаков" на базе этого проекта будет много.

FTP Cloud FS

Есть интересный инструмент – FTP Cloud FS. Это некая прослойка, которая позволяет вам работать с "облачным" хранилищем через стандартный FTP. Если вы привыкли загружать файлы именно таким образом, то можете подключить данный инструмент на своем сервере и пользоваться им для загрузки файлов.

Допустим, хранилище мы выбрали.

Как это все будет работать?

Файлы, которые отдаются пользователям напрямую, будут иметь вот такой длинный URL относительно провайдера (вместо нашего привычного короткого URL относительно нашего домена). Если наше приложение должно что-то сделать с файлами, оно тоже возьмет их по такому URL. Так или иначе, обработает и потом, используя API, положит их обратно в "облако". Например, возьмет картинку, сделает превью, положит в "облако". Дальше пользователь будет его получать напрямую.

Давайте посмотрим, как реализована поддержка тех или иных облачных хранилищ в различных популярных CMS, которые вы можете использовать на своем проекте. Для нас это будет, естественно, интересно.

WordPress

Поддержка "облачных" хранилищ реализуется сторонними плагинами. Есть два основных сценария использования. Первый подразумевает вынос всех медиа-файлов (картинок, видео, музыки) и отдача их через "облачные" хранилища и CDN. Второй сценарий использования – это сохранение резервных копий в "облако".

Joomla

Примерно то же самое. Сценарии те же. Вынос медиа-контента, сохранение копий. Есть интересный плагин – jomCDN, который позволяет всю статику отдавать через CDN распространенных "облачных" провайдеров.

Drupal

Точно также. Через внешние модули, и те же самые сценарии использования.

Битрикс

Он указан не потому, что я там работаю, а потому, что это реально самая популярная платная CMS. Каким путем пошли мы, реализуя поддержку "облачных" хранилищ в нашей системе? Мы сделали поддержку "облачных" хранилищ на уровне ядра. Это встроенный в систему модуль, который распространяется во всех редакциях. Поддержка хранилищ далее реализована во всех внутренних модулях системы. Есть API, которые могут использовать все сторонние разработчики, реализуя собственные модули.

Как мы рассуждали, делая поддержку облачных хранилищ у себя в системе?

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

Мало взять файлы и загрузить их в "облако". Мало взять и на сайте поменять все ссылки на новые. Если вы захотите куда-то переехать, придется проделывать всю эту работу заново.

У вас на сайте существуют совершенно разные роли. Есть администратор сайта, есть контент-менеджер и пользователи вашего сайта, которые могут регистрироваться, загружать какой-то контент (например, аватары, фотографии, еще что-то). У вас работа со всем контентом должна происходить абсолютно прозрачно, независимо от того, где вы его хотите сохранять (локально на диске, в одном "облачном" хранилище или другом).

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

Как это реализовать?

Как мы рассуждали? Может быть, эти рассуждения помогут вам в реализации каких-то ваших проектов.

Первое, что должно у нас быть – это API для работы с самим "облачным" хранилищем. С этим у нас все в порядке, все хорошо. "Облачные" хранилища API для работы предоставляют.

Дальше. У нас должен быть некий новый уровень абстракции для работы с файлами в нашей системе. Мы не должны использовать стандартные функции для работы с файлами – для копирования, получения информации о файлах. Мы не знаем, где файл у нас хранится (локально, в одном "облаке", другом). Мы должны написать некий собственный API для работы с файлами. Может быть, это не очень удобно для нас как для разработчика. Но это гораздо удобнее в дальнейшем для поддержки, подключения нового любого хранилища, абсолютно прозрачно для контент-менеджера и пользователя.

Важная задача, которую нам надо решить – это постараться избежать наличия так называемых "диких" файлов, которые мы по FTP загрузили и в текстовом редакторе в страничку вставили, что этот файл грузится оттуда. Мы его никаким образом отследить не можем и работу с ним через наш API реализовать не можем. В идеале, все модули нашего сайта, всей нашей системы должны, так или иначе, регистрировать попадание любых файлов, получать какую-то информацию о каждом файле и фиксировать, где он хранится (на локальном диске, в хранилище или где-либо еще).

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

В идеале, мы должны уметь работать с разными хранилищами, чтобы, во-первых, просто в тестах посмотреть, какое из них лучше. Может быть, в разных сценариях стоит использовать разные хранилища. Это было бы реально удобно. Для любых сторонних разработчиков, которые работают с нашей системой, работа с файлами должна быть прозрачной.

Что мы можем сделать для того, чтобы все это обеспечить?

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

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

Когда мы разрабатывали поддержку облачного хранилища у себя в системе, мы сначала сделали поддержку Amazon S3 и Google Storage. Лишь позже мы подключили поддержку OpenStack. Готовая архитектура позволила написать ее, по-моему, за два-три дня.

"Дикие" файлы обычно не разбросаны по системе. Обычно они существуют в каких-то отдельных папках (например, в папке "Upload"). Как вариант, мы можем для конкретных папок, куда такие файлы могут попадать, настроить их обработку через обработку 404-й ошибки. Делать запрос по списку имеющихся у нас хранилищ, и где файл обнаруживаем, оттуда его и отдаем. Например, высылаем уведомление администратору сайта, что у нас есть такой неучтенный файл, и в дальнейшем его, может быть, стоит по-другому обработать.

Я сейчас объяснил, как все сделать правильно и удобно для всех ролей в системе.

Есть еще один отдельный вопрос: как сделать красиво?

Длинный URL, который дает "облачное" хранилище, использовать не хочется. Хочется использовать, как минимум, свой собственный поддомен.

Принцип работы практически у всех провайдеров очень схож. Объясню его на примере Amazon S3. По умолчанию файлы отдаются по двум путям. Либо это путь s3.amazonaws.com/, дальше название бакета, дальше полный путь к файлу. Либо название бакета точка s3.amazonaws.com, и дальше полный путь к файлу.

Мы можем бакет назвать именем нашего субдомена. Например, files.domain.ru. Прописать специальную запись в DNS вида IN CNAME s3.amazonaws.com, и тогда файлы будут доступны нам по пути относительно нашего субдомена. Простой, красивый, удобный способ.

Единственный минус – практически все провайдеры позволяют получать файлы не только по HTTP, но и по HTTPS, причем с абсолютно валидным сертификатом. Если мы используем собственный домен для такого подключения, свой сертификат мы почти никогда подключить не сможем. У нас происходит несовпадение имен. Возникают сложности.

Коллеги из Clodo машут руками, значит, они эту вещь реализовали. Но я на практике пока такого не видел.

Можно это обойти. Можно, например, поставить какой-нибудь собственный легкий сервер, "поднять" на нем Nginx и дальше проксировать запросы через него.

Что нам это в итоге дало? Каковы типичные сценарии использования облачных хранилищ? Как это может выглядеть?

Распространенный сценарий - резервное копирование. При создании резервной копии мы просто выбираем, куда ее сохранить (если у нас такая возможность предусмотрена непосредственно системой). Если мы делаем резервную копию не средствами операционной системы (базы данных и архив всех файлов), а средствами самого нашего проекта, мы выбираем, куда сохранить файл – локально или в то или иное хранилище. Обратно, если мы разворачиваем проект, мы точно так же выбираем, где взять резервную копию, и как ее развернуть.

Мы предусмотрели возможность подключения разных хранилищ, и это у нас происходит абсолютно прозрачно – мы можем абсолютно свободно файлы переносить туда-сюда между локальными дисками и разными хранилищами. Мы можем подключить несколько разных хранилищ и настроить правила для работы с ними. Например, файлы меньше 10-ти мегабайт хранить на Amazon, все видео хранить в Google, а все прочие файлы сложить в Clodo. Мы можем оценить работу каждого провайдера и легко и просто переключаться между ними.

Еще один большой очень важный пример использования "облачных" хранилищ – это использование в больших масштабируемых проектах.

Мы сами сейчас запускаем абсолютно новый для себя проект – "Битрикс 24". Кому интересно, у всех в раздаче есть приглашения на этот проект. Он сейчас работает в режиме закрытого бета-тестирования. Все желающие могут посмотреть. Мы сами прекрасно понимаем, что у нас никогда не будет второго шанса произвести первое впечатление. Проект на старте должен быстро "взлететь", быстро всем показываться, отдаваться. При этом у нас должна быть возможность очень быстро масштабироваться и выдержать, наверное, любую нагрузку.

Все это можно решить, обеспечив себе огромный запас. Закупив заранее много серверов, развернувшись на них, заложиться в 10 раз на возможную нагрузку. Все будет хорошо. Но для проектов, которые по каким-то причинам потом могут не "взлететь", это будет большой удар по бюджету. Деньги вложили, потратили, но никакой отдачи не получили. Это может отбить все желание запускать любые новые проекты, заниматься любым новым бизнесом.

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

Именно запуская "Битрикс 24", мы считаем, что важно предусмотреть резервирование на уровне дата-центра. Даже если у нас выйдет из строя целый дата-центр, мы должны быстро переключиться на второй (желательно сделать это практически незаметно для пользователей). В этом случае контент логично хранить где-то между всем этим. Например, в том же самом "облачном" хранилище.

Что у нас в итоге получается? Как это все выглядит в нашем конкретном живом проекте, который уже сейчас работает?

По сути, на веб-нодах, где работает непосредственно приложение Application, никакого контента, данных пользователей нет. По сути, все там в режиме "только чтение", кроме каких-то временных директорий. Пользователи, которые загружают файлы, сразу загружают их в "облако", получают они их тоже из "облака". По сути, у нас все машины с приложением просто становятся расходным материалом.

Если у нас происходит сбой, авария или непонятная аномалия на любой машине – сильно проще и сильно дешевле с точки зрения администрирования просто эту машину "загасить" и "поднять" новую и не разбираться, что произошло. Точно так же работать с обновлениями программного обеспечения, как системного, так и нашего собственного приложения. Мы создаем новый образ машины. Дальше разворачиваем новые машины из этого образа, а старые машины просто "гасим".

Пользовательский контент, данные хранятся либо в базе, либо в "облаке", но не на самих машинах, сбоями они не затрагиваются и не теряются.

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

Поэтому конкретно у нас в проекте сейчас для каждого нового пользователя, который регистрируется в системе, создается отдельная учетная запись. Мы делаем все в Amazon, применяя Amazon IAM (identity access management). Итак, создается отдельная учетная запись. Для нее получается пара AccessKey и SecretKey. Она прописывается для данного конкретного пользователя, и потом пользователь получает доступ только к конкретной директории, которая доступна только ему, но не его соседям. Мы тем самым обеспечиваем изоляцию пользователей друг от друга.

Резюме

Таким образом на нашем проекте получается "дешевое" использование больших объемов файлов. Есть простое масштабирование и простая возможность резервировать наши приложения на уровне разных дата-центров. "Облачное" хранилище (если мы его используем грамотно) позволяет нам получить высокую доступность наших данных, высокую их надежность, максимально резервировать их и обеспечивать быструю работу нашего сайта. По сути, это небольшой план захвата мира. Осталось только проработать детали.

Я сейчас с удовольствием отвечу на ваши вопросы. Пожалуйста, задавайте.

Вопросы и ответы

Реплика из зала: У меня вопрос технический, больше про опыт работы с Amazon. В частности, я сталкивался с такой странной ситуацией при работе с Amazon Cloud: приложение, казалось бы, стабильно работало на каждой ноде, на каждом сервере, и были нормальные данные профилирования, показывающие константное время ответа и производительность. Тем не менее, при вызове из внешней сети приложение показывает "плавающие" результаты во время неответа. Скорее всего, это связано как раз с внутренним устройством сети Amazon или какими-то сетевыми операциями в ней.

Вы с чем-нибудь подобным сталкивались? На CDN, на доставке контента большого объема вы, скорее всего, что-то подобное могли "словить".

Александр Демидов: Вы спрашиваете про балансировщик, про CDN, или напрямую с их EC2 машин отдачу?

Реплика из зала: На самом деле, про все.

Александр Демидов: Там возможны самые разные нюансы. Например, балансировщик может влиять. Он может определять, жива машина или нет. Из-за этого может быть некоторая задержка. Нужно конкретнее смотреть. Хотите, я вам свои контакты дам, мы с вами предметно поговорим. У нас опыт эксплуатации Amazon очень большой, мы им с удовольствием делимся. Подходите, поговорим, пообщаемся.

Хорошо, что тема Amazon вам интересна. Это значит, что "облака" уже не кажутся людям какой-то маркетинговой вещью. Спасибо вам.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Дмитрий Сатин

Дмитрий Сатин

Советник министра в Министерстве связи и массовых коммуникаций Российской Федерации, евангелист юзабилити

Дмитрий Сатин объясняет, как ввести команду в состояние потока и не потопить ее.

Участники: Сергей Рыжиков ("1С-Битрикс"), Илья Бублик ("СКБ Контур"), Дмитрий Сысоев (2ГИС), Тимур Амирханов ("Лаборатория Касперского"). Ведущий – Максим Спиридонов ("Рунетология").

Адриан Крупчанский

Адриан Крупчанский

Бизнесмен, руководитель компании «Нотамедиа», проектов «Москва, которой нет», «Энциклопедия нашего детства» и других.

Я хотел бы вам рассказать, что написано в великом трактате Патанджали Муни, который называется «Йога-сутры». Йога – это успокоение ума. Кто-то хочет успокоить свой ум?