Итак, вы пытаетесь оценить надежность своего облачного сервиса

    SLA (Service Level Agreement) – часто встречающаяся у поставщиков сервиса форма гарантии надежности сервиса. Обычно SLA предлагается в виде оферты – и либо вы довольны и пользуетесь сервисом, либо ищете другой сервис. Типичная формулировка – «industry leading 99,95% monthly uptime SLA», который вроде бы должен устроить большинство пользователей.

    Обычно потенциальный пользователь, прочитав про «99,95% monthly uptime SLA», бывает очень даже доволен – гарантия отсутствия простоев в течение более чем 21 минуты в месяц длиной 30 дней звучит довольно многообещающе.

    Все относительно просто, пока вы только потребляете услугу облачного сервиса для собственных нужд. Посмотрели на 99,95%, подумали о не более чем 21 минуте в месяц – впечатлились и довольны. Что если вы сами создаете сервис на основе другого сервиса и решаете, какой SLA вы могли бы предложить?

    Вот, например, сервис обработки изображений (подозрительно похожий на ABBYY Cloud OCR SDK). Какой SLA можно предложить к такому сервису? Казалось бы, нужно взять все зависимости от других сервисов, внимательно прочитать их SLA, посмотреть на число девяток, и решить, сколько девяток после запятой можно написать в свой SLA.

    Предположим, сервис обработки изображений работает в Windows Azure и использует так называемые web и worker роли из Azure Cloud Services для исполнения кода и Azure Storage для хранения данных. Отлично. Открываем SLA по Cloud Services и видим там, что TL;DR; гарантируется доступность экземпляров ролей в течение 99,95% в течение месяца (при условии, что у каждой роли не менее двух экземпляров). Открываем SLA по Azure Storage и видим там, что TL;DR; гарантируется выполнение не менее 99,9% запросов к хранилищу. В случае если уровень качества не соответствует гарантированному, нужно обращаться в поддержку – и тогда поставщик вернет часть денег.

    Это было очень краткое содержание SLA двух указанных сервисов. Если вы используете любой из этих сервисов, вам стоит внимательно прочитать и учесть все оговорки.

    Принципиально важно следующее: даже в самом худшем случае вам вернут относительно небольшую сумму денег, которая покроет… да ничего она не покроет, потому что привязана к доле стоимости потребленной услуги, а стоимость использования облачных сервисов очень низкая по сравнению, например, с оплатой труда сотрудника, который будет обращаться в поддержку поставщика услуги. Смысл SLA с тремя девятками очень простой: «дорогие пользователи, это очень надежный сервис, мы очень стараемся, УЗБАГОЙТЕСЬ и пользуйтесь, счет выставим до 10 числа следующего месяца», SLA по сути задает ожидания от сервиса, что тоже очень важно. Если бы «гарантировалась» доступность в течение, например, 15% времени, ожидания от сервиса были бы принципиально другими.

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

    Соответственно, после скольких-то совещаний и двух недель переписки со всеми в копии мы можем все на все перемножить и решить, что можем предложить, например, работоспособность сервиса в течение 99,9% времени в течение месяца. Сформулировав такой SLA, мы говорим своим пользователям «у нас сервис надежный, пользуйтесь, все будет хорошо, а если нет – починим очень быстро, БЕЗ ПАНИКИ».

    Вы публикуете такой SLA и через какое-то время КРАЙНЕ НЕОЖИДАННО…

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

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

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

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

    Логично тогда посмотреть на SLA этого сервиса управления, чтобы понимать, чего от него ожидать.

    В Windows Azure для управления инфраструктурой используется Management API (портал управления и cmdlet’ы тоже работают через него). Значит, открываем SLA сервиса Management API и…

    …а нет, не получится ознакомиться с этим документом, потому что его просто нет. И у Amazon EC2 тоже нет SLA сервиса управления инфраструктурой.

    Wait… OH SHI~

    Да, мы только что едва не проигнорировали полное отсутствие SLA у сервиса, от которого наш сервис зависит существенным образом. Речь не только об обновлениях кода (которые как будто можно отложить, а на самом деле иногда и их нужно публиковать очень срочно) — способность масштабироваться нужна постоянно.

    Почему же нет SLA к сервису управления? Можно только предполагать.

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

    Можно вместо этого предположить, что пользователи не рассматривают сервис управления как важный сервис и вполне довольны нынешними формулировками SLA на «основные» сервисы.

    Как вариант, можно предположить и то, и другое одновременно (и можно без хлеба).

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

    Дмитрий Мещеряков,
    департамент продуктов для разработчиков
    ABBYY
    114.04
    Решения для интеллектуальной обработки информации
    Share post

    Comments 12

      +1
      Понимаю, что это общая для всех облачных провайдеров тема. Но кто конкретно вас так разочаровал? Azure или кто то другой?
        0
        Пост был о том, что пользователи сервисов не читают мелкий шрифт и не хотят вдаваться в подробности, — они и разочаровывают больше всего.
        0
        Мне кажется, речь идет о проблеме «курицы и яйца»:
        Чтобы обеспечить «горячее» переключение при отказе узла на другой (избыточный), необходим узел «верхнего уровня», который прозводит мониторинг и непосредственно переключение (load balancer или кто-то подобный).
        Указаная «отказонеустойчивость» описана именно среди узлов таких «load balance»-ов. Т.е, нужен «load balancer» для «load balancer»-ов. А соответственно, он ведь тоже может отказать, и тогда…
        Вот и не хотят делать «бесконечную рекурсию».
          +2
          Для этого есть ансамбли конфиг серверов, которые знают друг о друге и сообщают о том же клиенту. Например, у вас может быть 3 конфиг сервера, которые знают друг про друга и, при соединении от клиента, отдают ему весь список. Если один из конфиг серверов падает, клиент тут же перенаправляет запросы на другой. Ну а конфиг сервера уже могут держать любую необходимую клиенту для бесперебойной работы информацию (например, список лоад балансеров).

          Из опен сорса для этого есть, например, ZooKeeper, который предоставляет древовидную структуру для сохранения конфигов.
            0
            В описанной вами системе присутствует зависимость «клиент знает о лоад балансере(ах), которые его обслуживают», а это не всегда возможно. Например, в AWS у клиента может не быть ни малейшего понятия где он и почему запрос пришел именно к нему.
              0
              Что вы подразумеваете под клиентом? Я говорю о клиенте, который обращается к сервису, например, мобильный клиент твиттера или сайт, обращающийся к базе MongoDB.
                0
                Под клиентом я имел ввиду «клиента» лоад балансера, т.е web server или processing unit сети типа MapReduce.
                  0
                  А, вы про бек-енд. В общем-то, на бек-енде архитектура может быть вообще другой (те же processing units в MapReduce как правило пассивные, и управляются они центральным мастером), но даже если таким «клиентам» нужен центральный лоад-балансер, то не вижу причин реализовать его по той же схеме, что я описал выше. Т.е. если клиент хоть раз контачит с центральным сервером, то нет никаких приград отдать клиенту список резервных центральных серверов. Или я вас опять неправильно понял?
                    0
                    Я про пассивное управление и говорю. При этом часто управляющий элемент знает своих «подчиненных», а они его — нет, так что выбирать кого-либо они не могут (отношения «caller -> callee»).
                    К примеру, живет себе web сервер (только что созданный из темплейта — так называемый «instance on demand») и в ус не дует — он и знать не знает что запросы к нему приходят не из внешнего интернета, а через прокси/лоад балансер
                      0
                      А, я наконец-то понял вашу идею :) Но нет, под клиентом в своём самом первом комментарии я подразумевал именно программу на стороне пользователя. На бекенде всё зависит от требований к конкретной ситуации.
          +2
          Да, вот сегодня у Windows Azure проблемы, уже часа 3, с WebSites расположенными в West Europe.
          www.windowsazure.com/en-us/support/service-dashboard/
            +2
            > Почему же нет SLA к сервису управления? Можно только предполагать.

            Потому что, как любят говорить разработчики таких сервисов, они делают только некий пульт управления с кнопками, а реакция на нажатие кнопки — это уже SLA исполнительного органа, т.е. самого «облака». И, мол, они не видят смысла «зуб давать» за работу своей системы управления, т.к. между нею и облаком разные еще прослойки, задержки, и предсказать им, как разработчикам, ничего решительно невозможно.

            Правда, это все по-детски выглядит, конечно.

            Only users with full accounts can post comments. Log in, please.