Перед вами третья статья из цикла «Внутреннее устройство и архитектура сервиса AtContent.com». Из нее вы узнаете как и для чего при использовании платформы Windows Azure можно сократить количество обращений к хранилищам данных Azure Table Storage и Azure Blob Storage. В нашем сервисе авторы размещают свои публикации, которые затем встраиваются в различные сайты. Таким образом однажны опубликованный контент отображается на большом количестве ресурсов, при этом доставляется на эти сайты через наш сервис. Поэтому чтобы сократить количество обращений к хранилищу Azure мы применяем кеширование публикаций в хранилище экземпляра, так как дополнительной платы за это не взимается.
Также в статье будут затронуты вопросы о том как управлять кешированием при наличии более одного экземпляра приложения и как синхронизировать между экземплярами состояние кеша.
Начать следует с того, что все данные приложения в Windows Azure следует хранить вне экземпляра приложения или сервиса, так как при перезагрузке роли все данные, которые находятся в хранилище экземпляра теряются. У нас это происходит в среднем 1 раз в 1-2 дня, так как сервис сейчас находится в стадии очень активного развития и деплои приходится делать очень часто. Поэтому самым эффективным решением является расположение этих данных в хранилище Azure, таких как Azure Table Storage или Azure Blob Storage. Но за каждую операцию с этим хранилищем с нас взымают плату. Хотя она и не такая большая все же хочется сократить затраты на обращения к хранилищу Azure.
С введением кеширования нам удалось существенно снизить затраты на операции с хранилищем Azure. Так, при просмотре публикации она выбирается из хранилища Azure только в первый раз, а все последующие – из кеша. Так как авторы достаточно редко редактируют свои публикации – то на данном этапе основным инициатором обновления кеша выступает новый деплой. Даже если брать в расчет, что деплой происходит раз в сутки – то для публикации, которую просматривают, например, 100 раз в сутки экономия для хранилища Azure составит 99%. И это ведь ещё не самая популярная публикация.
Для решения задачи кеширования мы воспользуемся хранилищем экземпляра. Чтобы иметь возможность с ним работать потребуется подключить соответсвующие пространства имен:
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.ServiceRuntime;
После этого потребуется определить локальное хранилище. Сделать это можно в настройках роли:
По умолчанию размер хранилища устанавливается в 1000 Мб, минимальный размер может быть 1 Мб, а максимальный зависит от размера роли. Для Small Instance этот размер будет 165 Гб. Подробнее об этом можно почитать в MSDN (http://msdn.microsoft.com/ru-ru/library/ee758708.aspx).
После настройки хранилища с ним можно работать как с обычной файловой системой лишь с некоторыми особенностями. Чтобы определить расположение файла нужно совместить путь до хранилища и относительный путь до файла от корня хранилища:
var Storage = RoleEnvironment.GetLocalResource(LocalResourceName);
var FinalPath = Path.Combine(Storage.RootPath, RelativePath);
Для того, чтобы можно было хранить объекты .NET в файловой системе их нужно сериализовать. Для этого мы применяем библиотеку JSON.Net (http://json.codeplex.com/).
Далее, если вы в своем приложении используете более одного экземпляра – то возникает проблема актуальности кеша. Даже если вы будете обновлять кеш на экземпляре, который участвует в изменении данных в хранилище Azure – то остальные экземпляры не будут об этом ничего знать. Чтобы справиться с этим мы как раз и разработали механизм обмена сообщениями между экземплярами и ролями, описанный в предыдущей статье (http://habrahabr.ru/post/140461/).
Здесь он используется чтобы сообщить экземпляру о необходимости удалить часть кеша, которая только что стала неактуальной.
Как уже говорилось ранее, в AtContent.com мы используем кеширование публикаций. При этом публикация кешируется экземпляром в момент выбора её из хранилища Azure. Таким образом кеш экземпляров заполняется по мере обращения к публикациям. В момент обновления публикации автором на все экземпляры роли рассылается сообщение о необходимости очистки кеша для данной публикации и после его обработки кеш вновь становится актуальным.
Данный механизм позволяет нам снизить затраты на хранилище Azure и эффективно использовать все возможности экземпляра.
В качестве кеша в Windows Azure можно использовать не только жесткий диск, но и оперативную память или Windows Azure Cache. Их использование оправдано, если вам нужно повысить быстродействие работы с какими-либо данными. Причем объем этих данных не может быть большим. Количество оперативной памяти на экземпляре значительно меньше, чем объем жесткого диска. Windows Azure Cache тоже не предоставляет больших объемов данных – максимальный объем, который можно получить – 4 Гб, и за него придется выкладывать $325 в месяц (http://www.windowsazure.com/ru-ru/home/tour/caching/).
Поэтому если вам необходимо именно уменьшить количество обращений к хранилищу Azure для данных, которые редко изменяются, но очень часто требуются для чтения – то описанный в статье механизм может очень вам пригодиться. Он также будет доступен в составе OpenSource библиотеки CPlase, которая в скором времени появится в открытом доступе.
Читайте в серии:
- «AtContent.com. Внутреннее устройство и архитектура»
- «Механизм обмена сообщениями между ролями и экземплярами»,
- «Эффективное управление обработкой облачными очередями (Queue)»,
- «Расширения для LINQ, реализующие операции Or и Contains к Azure Table Storage»,
- «Практические советы по разделению данных на части, генерация PartitionKey и RowKey для Azure Table Storage».
Автор: VadNov
