Уходим в облака. Подключение Windows Azure CDN к Blogger
Связанность - это характеристика взаимосвязи подсистем одной системы. Связанностью обладают любые системы: как программные, так и политические; как web-приложения, так и эукариотические клетки.
В программных комплексах сильная связанность (coupling) между компонентами, относящимися к разным логическим слоям является большим «ограничителем» гибкости (и причиной жесткости). Такая связанность – зло, которое сложно переоценить.
Привычка подсознательно искать сильную связанность внутри сложных систем недавно натолкнула меня на одну из проблем, связанных с моим «блоготворчеством» – содержимое моих постов в blogger слишком сильно завязано на саму платформу blogger. Что, в свою очередь, приводит к растущей, пропорционально количеству постов, зависимости от blogger, и, как следствие, внушительному количеству потраченных человеко-часов при миграции на другую блогоплатформу.
Выделю следующие проблемы:
- отсутствие контроля над хранилищем содержимого постов;
- слабый контроль над статическим содержимым постов.
Вышеперечисленные проблемы, на мой взгляд, являются причиной (именно причиной, а не следствием) сильной связанности между слоем хранения и представлением (view), за которое отвечает web-приложение blogger. Причем эта связанность проявляется не на уровне функционирования самого web-приложения blogger, a на уровне инфраструктуры, предоставляемой blogger авторам блогов.
В данном посте я расскажу об архитектурном подходе, который я применил для «отвязки» от web-приложения blogger и создания инфраструктуры публикации со слабой связанностью между слоями хранения статического содержимого и представления этого содержимого.
Подходы к хранению статического содержимого
Основные подходы к хранению статического содержимого:
- «on-premises»-подход:
- хостинг-площадка (непрямое владение);
- собственные мощности (прямое владение).
- «on-demand»-подход:
- сервис Amazon Simple Storage (Amazon S3);
- сервис Windows Azure Blog Storage (WABS);
- прочие сервисы хранения данных в облачных хранилищах.
В таблице ниже рассмотрим основные интересующие нас характеристики для описанных выше подходов.
| On-demand | On-premises | ||||
| Blogger | Amazon S3 | WABS | Хостинг | Собственный ДЦ | |
| Отказоустойчивость | + | + | + | ограниченная | - |
| Доступность | 99,95% | 99,99% | 99,9% | 99,50% | 99,50% |
| CDN (as a Service) | + | + | + | +* | +* |
| Пользовательский домен | - | + | + | + | + |
| Контроль | |||||
| над структурой хранилища | - | +** | +** | + | + |
| над политиками доступа | - | + | + | + | + |
| Безопасность хранения | высокая | высокая | высокая | средняя | средняя |
| Ограничения | |||||
| по типу файлов | только изображения | любые файлы | любые файлы | любые файлы | любые файлы |
| по размеру файла | 8 Mb | 5 TB | 200 GB / 1 TB | отсутствует | отсутствует |
| по кол-ву файлов | отсутствует | отсутствует | отсутствует | отсутствует | отсутствует |
| по размеру хранилища | 5 Gb*** | отсутствует | 100 TB | отсутствует**** | отсутствует**** |
| Стоимость владения | бесплатно | средняя | средняя | средняя | высокая |
| первоначальные вложения | отсутствуют | отсутствуют | отсутствуют | минимальный | значительные |
| затраты на администрирование | отсутствуют | отсутствуют | отсутствуют | незначительные | существенные |
| ежемесячные затраты (за искл. администрирования) |
отсутствуют | + | + | + | + |
| ограничения законодательства при хранение конфиденциальных данных |
+ | + | + | + | - |
* Необходимо подключении стороннего CDN сервиса.
** Глубина иерархии папок ограничена 2 уровнями (хотя и это обходится добавлением '/' в имя файла).
*** Объем хранилища расширяем.
**** Ограничен объемом хранилища у хостера/датацентра.
Архитектура хранилищ
Первое, что нам стоит ввести, это понятие границы, за которой слою, внешнему к этой границе, не будет видно внутреннего устройства компонетов, находящихся за этой границе. На роль этих границ отлично подходят пользовательские домены (custom domain).
Для наших нужд выделим отдельный пользовательский домен для приложения и отдельный для статических данных, отображаемых приложением.
Демонстрация архитектуры «родного» решения blogger и нового решения приведена на иллюстрациях ниже. Дополнительную информацию можно подчеркнуть из легенды.
Реализация
В качестве домена для блога был приобретен «codeinstinct.pro». Воспользовавшись настройками blogger и панелью управления регистратора, была сделана привязка (инструкция) домена codeinstint.pro к домену третьего уровня, любезно выданному Google.
После чего был зарегистрирован эккаунт на Windows Azure. Через контрольную панель Azure было создано облачное хранилище в сервисе Windows Azure Storage, а затем и Windows Azure CDN Endpoint, указывающий на ранее созданный WABS (инструкция).
В заключение, с помощью личного кабинета регистратора и контрольной панели Windows Azure был создан поддомен static.codeinstinct.pro и осуществлена привязка (инструкция) последнего в качестве «custom domain» к созданной CDN Endpoint.
После нескольких часов ожидания на распространение (propagation) созданных DNS-записей была запущена трассировка маршрутов к Google CDN, используемой blogger, и Windows Azure CDN, подключенной мною.
Команды трассировки и соответствующие результаты приведены ниже:
// Blogspot’s CDNs
tracert -d -h 20 1.bp.blogspot.com
tracert -d -h 20 2.bp.blogspot.com
tracert -d -h 20 3.bp.blogspot.com
tracert -d -h 20 4.bp.blogspot.com
// Windows Azure Blob Storage
tracert -d -h 20 codeinstinct.blob.core.windows.net
// Windows Azure CDN
tracert -d -h 20 az412806.vo.msecnd.net
// Custom domain on Windows Azure CDN
tracert -d -h 20 static.codeinstinct.pro
Заключение
Проблемы миграции значительно легче решаются в слабосвязанных системах. В отношении к web-приложению, хорошей практикой является разделение представления от данных, данных от логики их получения, логики получения от представления.
Уменьшение количества связей между подсистемами, входящими в систему, значительно увеличивают гибкость этой системы и, в конечном итоге, способность этой системы к эволюциии и отзывчивости на изменяющиеся условия окружения.
