Обращение к облачным хостинг-провайдерам и их потенциальным клиентам

    Как очень правильно озвучил автор приведённой картинки, перед многими начинающими (и не очень начинающими) стоит проблема высокого входного порога на знание и понимание.


    Непонятно выражаюсь?
    Вот и мне, как неопытному молодому человеку с идеей, которая перевернёт мир, непонятно: откуда взять все эти количества GET, POST, INSERT, а главное CPU.

    Есть масса решений этой проблемы


    Например, публиковать стандартные кейсы типа «сайт на вордпрессе с 10к хостов в день генерирует вот такой профиль загрузки». Удобно? Да. Просто и недорого для хостера? Да. Широко применимо, точность оценки достаточна? Как отметил один из участников дискуссии в предыдущем посте, «один модуль в вордпрессе может повысить нагрузку на процессор в десять раз».

    Можно давать демо-доступ (или, с другой стороны, купить у облачного хостера стакан семок погонять недорогой вариант начального уровня). Просто? Относительно. Широко применимо? Да, ведь сайт можно перенести туда целиком и прогрузить тестовым ab'ом. Удобно? Отнюдь нет.

    И вот тут мне пришла в голову мысль, которая давно уже стучала пеплом Клааса в сердце


    А если создать виртуальный сервер на хостере, залить туда сайт целиком и натравить на него стресс-тестер, но не извне, а изнутри? Если скормить стресс-тестеру не абстрактный список URLов и правил, а живой лог веб-сервера?

    Для сайта такой тест не будет отличаться от реальной загрузки: можно даже не выключать защиту от DoS, банящую «прожорливые» адреса — ведь стресс-сервер может прикидываться для сайта всем интернетом целиком.

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

    Этот тест можно запустить как «ускоренно», прогружая весь лог ASAP, так и на скорости 1 к 1, да и вообще на любой выбранной. Да, тестирование суточного лога займёт сутки, но так ли это мешает? Зато хостер может распланировать тест так, штобы максимальное количество запросов из лога было обработано в момент минимальной загрузки площадки. Более того, пока задержки не начинают влиять на логику работы самого сайта, такое тестирование можно заприоритезировать в минус бесконечность: ну, получат «виртуальные» пользователи свою страницу не за 2 секунды, не за 0.2, а за 22. Зато количество тактов CPU, запросов к базе, IOPS, трафика будет посчитано верно.

    Входной лог можно и нужно править, моделируя слешдот-моменты (и сделать это достаточно просто — взять и подмешать копии реальных сессий с модифицированными IP-адресами).

    Все шаги вполне прозрачны и понятны даже полному новичку.

    Недостатков у этого способа масса


    Это создаёт нагрузку на хостера, сравнимую с реальным хостингом. Минус выходные каналы, плюс выравнивание по суточной загрузке, плюс приоритеты — это всё равно съест CPU, IOPS и тому подобного на вполне реальные деньги.

    Это достаточно трудоёмко в разработке: надо будет создать структуру виртуальных серверов, оторванную от интернета, заизолированную и уприоритезированную. Не ракетная хирургия, возможно, но разработка стоит денег.

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

    Это налагает немало условий к клиенту: уже не просто стартапер, а мигрант с имеющимся сайтом и живым логом. Каковой лог ещё не с каждого шаред-хостера можно получить. «Неживой» лог трудно создать с нуля, не каждый сможет предугадать, какая часть сайта будет посещаться наиболее часто. Пресловутый «один плагин в вордпрессе» может сидеть на странице, куда заходит 1 пользователь из 1000 — а может на странице, где сидят 999 из 999 (а на остальные разделы они и не ходят вовсе).

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

    Есть вариант-паллиатив


    Хостер выкладывает образ виртуалки (точнее, связку из двух машин, хостера и стрессера), который клиент запускает у себя на ноутбуке, на NASе, да на чём угодно — это уже вопрос для клиента-вебмастера.

    Плюсы по сравнению с вышесказанным: нет утечки юзерских данных, нет расхода ресурсов хостера.

    Минусы тоже вполне очевидны: во-первых, если у вебмастера домашняя машина справится с такой нагрузкой на сайт (хотя бы и в «очень низком темпе»), то ему, скорее всего, не нужен облачный хостинг. Во-вторых, утечка системы биллинга и собственно хостинга в предоставляемом образе виртуалки; однако можно отдавать урезанную версию, годную только для подсчёта ресурсов. В-третьих, надо очень тонко учитывать влияние виртуализации на неизвестном заранее железе.

    Дополнительный бонус — возможность разработки под конкретную платформу хостера.



    И последнее: оба варианта, как мне кажется, были бы полезны и для не-облачных хостеров.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 57

      +2
      Проблемы с авторизацией. В логах не пишутся (по понятным причинам) имена пользователей и пароли, а то, что видит по ссылке человек с правильной кукой может разительно отличаться от содержимого для анонима.
        0
        Да, там вообще масса тонкостей выплывает. В логах ещё и полные GET-запросы не всегда пишутся. Конкретно с авторизацией, к примеру, можно решить, проставив виртуальному сайту «автоматически залогиненного юзера» и сравнив получающиеся числа с «анонимными посещениями».
          0
          юзеру? Одному? А ничего, что у пользователя а get выполняется за 0.01с, а у пользоваетя b за 0.9с?
            0
            Стоп-стоп-стоп, у меня нет реального сайта с такими закидонами и реального облачного хостинга под руками. Я не могу спорить о конкретных числах на абстрактных примерах на основе несуществующего опыта.

            Мой текст — это идея о виртуальной проверке реального сайта реальным логом, которая даст бОльшую точность, чем «абстрактный вордпресс с тысячью абстрактных юзеров» из кейсов. Даст не бесплатно, а в обмен на усложнение процедуры (в том числе и за счёт вот таких тонкостей, с которыми должен будет справляться клиент-вебмастер, а не хостер). Даст не абсолютную точность, но всё-таки повыше, как мне кажется.
          0
          Подобную задачу можно решить поставив прокси напримаер от tsung, правда он ориентирован на прикручивание к конкретному браузеру, но направление движения думаю понятно.

          После этого воспроизвести все POST, GET, HEAD и другие типы запросов, а также все заголовки включая куки, если присутствуют в полном соответствии.
            0
            Цена развёртывания такого в продакте (перед переносом) слишком высока. Потребуется, как минимум, человек очень высокой квалификации. А в такой ситуации, я думаю, он и сам посчитает.
          +24
          1. «Новички», берите VPS и не страдайте «облаками»;

          2. Шансов на то, что Ваша идея перевернет мир — очень мало, и если такое случится — Ваши пользователи будут спокойно терпеть простои, пока Вы будете улучшать архитектуру (такое происходило с twitter, с flickr и еще с морем других сервисов);

          3. Есть совершенно реальные пути улучшения архитектуры от простой до супер-навороченной и они не начинаются с облаков, iops и т.п.: 1 vps -> 1 сервер -> 3 сервера (приложение, база данных, статика) -> увеличение количества серверов баз банных через репликацию, увеличение числа серверов приложений и какой-нибудь nginx перед ними… но реально говоря, даже 3 сервера (сервер приложения, сервер с базой данных, сервер статики) Вам дадут ТАКОЙ мощный запас мощности, что надолго хватит — десятки миллионов запросов в день — на настолько уж нереально на трех современных серверах, за которые Вы будете платить фиксированную сумму без учета всяких IOPS и прочего (только траффик, но он более чем предсказуем на такой посещаемости);

          4. «сайт на вордпрессе с 10к хостов в день генерирует вот такой профиль загрузки»
          Сайты в облаках (а только они и берут за CPU, IOPS и т.п.) — они для тех, кто УЖЕ точно знает сколько у него будет IOPS, и прочего.

          4а. «вот такой профиль загрузки» один хреново написанный плагин для вашего вордпресса и профиль будет СОВСЕМ другой; а может Вы посередине какой-нибудь страницы захотите записать файл размером в 50 мегабайт куда-нибудь — вот Вам и совсем другой профиль. Может у Вас картинка будет одна на 10кб, а может Вы тему используете с PNGшками размером под несколько мегов — совсем другой профиль загрузки будет.

          5 (и самое важное) «Преждевременная оптимизация — корень всего зла» Д. Кнут Использование облаков на этапе когда Вы не знаете сколько Ваш сайт вообще требует ресурсов и НУЖНЫ ли ему «облака» — это самая настоящая преждевременная оптимизация.
            0
            Кстати, вот с четвёртым пунктом я негласно и спорю. Возможно, есть такое сочетание цены и труда, когда даже личный хомяк уместно залить в облако. Оно маргинально, согласен, типа недавно пробежавшего варианта «почти CGI на базе дропбокса» и «хостинг картинок в аттачах гмыла», но кто знает?
              0
              Не понимаю я смысла держать хомяк (или даже вордпресс с 10к посещениями) в облаках. Взяли VPS за 5-10-20$ и расслабились — не такие это огромные деньги и все предсказуемо.

              (поскольку этот вопрос всегда задают — то за 5$ это firstvds, дешево и сердито)
                +1
                Эти «реальные пути улучшения архитектуры» — они очень правильные и полезные. Не спорю. Но как и любые хороши, проверенные годами и выстраданные из реального опыта догмы, они нуждаются в периодической проверке.

                Зачем хомяк на облаке? Завтра появится функционал у дропбокса и твиттера, которые удобно использовать на хомяке, а хромос в планшете внезапно станет социальной нормой, например. Послезавтра мой хомяк вырастет в медведя, а цены на облако упразднят вдс как услугу. Понимаете, отработка «на хомяках» — очень хороший инструмент обучения, популяризации и исследования, полезный как клиентам, так и индустрии.

                … но это я к вопросу о конкретно хомяках на облаке, а не в целом по статье. В конце концов, социальные сети вырасли из блогов очень быстро.

                Вопрос статьи, скорее, «согласны ли облачники-хостеры (и не только облачники, смотрите приписку внизу) гласно или негласно разворачивать мелких стартаперов по стандартному пути апгрейда, или же могут рассмотреть этот сложный для них, но, возможно, интересный для потенциальных клиентов вариант»
              0
              Я не соглашусь со 2м пунктом.
              Почему все, всегда думают, что «стартап» это обязательно что-то «социальное» или «для всех»?! Есть стартапы, которые направлены на бизнес, а бизнес, как многие знают не любит простаивать, потому что время — деньги!
              И если вы затеяли какой-то стартап, который бы перевернул индустрию, к примеру, а он у вас загнулся через 2-3 дня запуска, то бизнес разочаруется и уйдет к другому (сто процентов будет кто-то, кто дышит вам в спину и будет ждать любой вашей ошибки, чтобы воткнуть нож в спину).
              Хватит думать материями твиттера, фликра и морем других социальных сервисов, которые созданы были «Just for fun», а по стечению обстоятельств вышли в топ.
                +3
                Как же Вы все любите жить в теоретическом царстве.

                1. Облака — не дают НИКАКОЙ гарантии по поводу того, что Ваш стартап не загнется. Это все равно Ваша задача — обеспечивание надежности, будь то регулярные бэкапы на VPS или снэпшоты на EC2. Это все равно Ваша задача — обеспечивание масштабируемости — будь то дополнительные сервера на репликации или дополнительные app-сервера на EC2/RackSpace/где угодно. Единственные, кто дают какую-то «надежность» тут — это Google App Engine. Но он — едва ли «облачный хостинг провайдер», скорее «облачный провайдер приложений» — он дает свое приложение (BigTable, HTTP(s) и т.п.), с которым Вы можете работать.

                Теперь давайте про ерунду про «уйдет к другому»…

                Назовем условно «стартап» «провайдером», а его клиента «потребителем».
                «Провайдер» не может быть большим — иначе бы он знал, сколько его приложение требует затрат на облака, сервера и т.п. (то есть для него статья бесполезна).

                Значит «провайдер» маленький.

                «Потребитель» не может быть большим, потому что большие компании не работают с маленькими (слишком большой риск, что загнется через 2-3 дня).

                Значит «потребитель» маленький.

                Значит обе компании маленькие. Значит обе компании гибкие. Значит вторая спокойно может потрепеть 2 дня простоя, неделю простоя или даже больше. Никто не будет использовать мелкого партнера в misson-critical местах.

                Если же не вытерпел и ушел — можно найти нового (все-таки речь идет о маленьких компаниях, а не о контрактах с Кока-Колой, а о компаниях уровня «Пупкин и ко», что я выше уже и доказал).

                Итого: все оригинальные аргументы остаются в силе.
                  +1
                  Просто поймите — Вы все рассчитываете на:
                  1) внезапный успех за ночь (практически не бывает в жизни, в основном все бизнесы развиваются медленно);
                  2) что этот успех будет единственным шансом на успех (я кстати также не говорил про что-то «социальное» или «для всех») — тоже не так, как правило шансов много и их надо использовать, упущенная одна возможность не разрушит бизнес. А если разрушит — хреновый это был бизнес.
                    +1
                    Все же, я считаю, что вы не правы.
                    Опять же, как вы говорили в 5м пункте, что «Преждевременная оптимизация — корень всего зла». Так вот при разработке какого-то продукта я могу протестировать его, попробовать какие-то стресс-тесты, но они из-за неимения больших финансов и, возможно, опыта не смогут создать 100% картину той ситуации, которая может быть при «боевых условиях». Т.е. возможно при своих тестах я упустил какое-то узкое место, которое при реальной нагрузке повалит сервер (VPS), а вот ежели размещаться в облаках и прочих «гибких» VPSах, которые работают по принципу «Scale On-Demand», то тут я получаю хоть какую-то (опять же про 100% не говорю), но гарантию, что приложение и сервер ВЫСТОЯТ, а я уже посмотрев на то, как работают пользователи, как ведет себя система смогу сложить более четкую картину и уже заняться оптимизацией.
                    А по поводу клиентов скажу вам вот что — есть сферы бизнеса ОЧЕНЬ, ОЧЕНЬ консервативные, куда войти-то просто так не всегда получается, а если уж тебе удалось туда войти и ПРИВЛЕЧЬ К СЕБЕ ВНИМАНИЕ, то тут позволять упасть в грязь лицом себе нельзя! Это первое, а второе — когда вы создаете стартап на свои средства, то это не просто прожить в случае «ну один ушел, будут другие», потому что как правило вы живете на 500 рублей в месяц и лишний клиент, который от вас ушел — это лишний кусок хлеба, который вы не съели на обед. Я считаю на этапе старта нельзя раскидываться клиентами, их надо на руках носить, а вот когда вы уже задали стандарт в отрасли, то там можно и фыркать и позволять себе всякие шалости.
                    –1
                    > Google App Engine. Но он — едва ли «облачный хостинг провайдер», скорее «облачный провайдер приложений»

                    Это называется PaaS. Походу вы не в теме и облака тоже разные бывают.
                  +2
                  По поводу 5 пункта. Облака это не только оптимизация (вообще этот момент не самый основной). Разработка в облаке это использование готовых каналов обмена данными между приложениями, готовых каналов поставки приложений на конечные устройства, это последние технологии, которые преподносятся на блюдечке и разработчику остается их использовать мизинцем правой руки.

                  Когда вы делаете сайт на «хостинге» вы строите деревню в которой нет инфраструктуры, разработка в облаке это город, это готовая инфраструктура. Так что «новчикам» для опыта можно попробовать хостинг, это как большинство проходят разработку на ассемблере и потом переходят на уровень выше, облако это и есть уровень выше.
                    0
                    «большинство проходят разработку на ассемблере»
                    Может быть в 80ых, сейчас большинство начинает как раз, зачастую с высокого уровня — с PHP/Delphi/C++/C#/Java/Perl. Поспрашивайте людей рожденных около 90го года что такое «jnz» и потом делайте такие утверждения.

                    «Разработка в облаке это использование готовых каналов обмена данными между приложениями»
                    Это вообще бред. Облако — это тот же VPS, с той лишь разницей, что можно программно поднимать другие VPS. О каком «готовом канале» идет речь, который есть в облаках, но нет в VPS?

                    И, пожалуйста, отвечайте на то, что я говорю, а не на свои домыслы. Слово «хостинг», которое Вы так упорно мне цитируете, я вообще не использовал нигде в комментарии.
                      +2
                      Вообще то я про PaaS, например GAE, MS Azure, какие там VPS??? Разработка ведется так если бы вы программировали для своего компа, все прозрачно. Не надо мыслить VPS ами относительно облаков, если вы работаете с VPS, то это нифига не облако, а жалкое подобие.
                        0
                        А здесь вы сами противоречите своему высказыванию про то, что облака бывают разные. Есть же облака типа IaaS, в которых как раз мыслят юнитами и ресурсами для VPS к примеру Rackspace Cloud. Тот же Azure дабы дать большую гибкость спускается и на уровень IaaS планируя предоставлять RDP доступ внутри виртуального облачного сервера.
                          0
                          Считаю что IaaS переходный период, с развитием PaaS, доля IaaS начнет падать, но ни как не наоборот. IaaS для меня лично недалеко ушли от хостингов, единственно что есть удаленное управление юнитами и набор примочек в виде админки с контролем ресурсов. Это все детский сад.
                    0
                    1. «Новички», берите VPS и не страдайте «облаками»;

                    Так говорят олдфаги которые сами не осилили облака, а говорят они так потому, что уних будет боль в допе если «новичек» все осилит. Облака как разз в первую очередь новичкам и нужны. Потому, что:
                    a) Pay as you use
                    b) Дешевле
                    c) Если ресурс затратный и vps'a не хватает — когда загнетесь можно забыть и все
                      0
                      Облако это всего-лишь возможность увеличивать ресурсы по мере необходимости.
                      Это нисколько не круче обычного VDS/VPS по практическим возможностям.
                      При этом облака стоят заметно дороже чем их аналоги VDS.

                      По надежности они не лучше правильно настроенных ферм VDS-нод.
                      По скорости они хуже, т.к. есть накладные расходы на облако.

                      Тут нечего осиливать, зато можно потрясти модным словом в смете на новый проект перед спонсором.
                      Не более того.
                        0
                        И это тоже.

                        >По надежности они не лучше правильно настроенных ферм VDS-нод.
                        По скорости они хуже, т.к. есть накладные расходы на облако.

                        Иначе говоря облако на коленках у кого-то недо хостера надежнее чем облако от Амазона? Я посчитал свои нагрузки и понял, что «впски за 5 баксов не хватит», если у меня сейчас свой сервер еле справляется с нагрузкой то о какой впс идет речь? Посчитал сколько будет стоит облако — облако обойдется дешевле дедика и его можно отмаштабировать.

                        А теперь давайте расмотрим стартап, такое реальный стартап или сервер, а не гостевуху «ололо потсаны^W хабрапиплы, зацените чо я сделал вчера в пьяном угаре! тут вот загладки синхронизируеются, а тут в пакмана можно играть!!1111». Например завязаный на работе с музыкой/видео. Если там, что-то надо кодировать — одной vps'ки уже не хватит, если вы уважаете свои пользователей, то все кодирование вы вынесите в облако (ничего не кодируется — облако простаивает, кодируется — работает). Или аналог дропбокса, далеко бы они ушли на впске?

                        А для 70% блогов на WP хватило бы любого статического блога, захостить можно где угодно ибо затраты ресурсов минимальны (считай cat index.htm | nc чототам), можно даже в том же дроп боксе захостить.
                          0
                          Сколько там раз за последние пол года лежало облако Амазона?
                          Я могу сказать что простой по каналам и нодам у нас за последний год в отличие от Амазона нулевой.
                            0
                            Не одним амазоном же живы облака! Что все думают, раз амазон был первым, то только их и надо использовать?
                              0
                              Речь шла об облаках Амазона и обычных VDS нодах хостеров.
                              Понятно что есть альтернативы, но все они не панацея.
                              Они нестабильны, т.к. не до конца протестированы.
                              Они дороже, т.к. провайдер пытается отбить немалые расходы на программистов и свое ноу-хау.

                              Может быть года через 3 это будет хорошим подспорьем, но сейчас это просто новая волна.
                    +2
                    Идеи не переворачивают мир. Переворачивает мир сила, приложенная к рычагу ;)
                      +2
                      «Lost in the cloud? Unfluff your hosting!» © Mediatemple.
                      Они вообще молодцы: не выдают каждый нанометр попугая, которым меряют CPU, а измеряют Grid Performance Unit'ами. 1 GPU = 7.24% of 1 CPU for 1 hour.

                      mediatemple.net/webhosting/gs/faq.php#63
                        0
                        Они очень правильно делают.
                        Нечего мерять в этих самых сферических попугаях привязанных к количеству просмотров.
                        По сути они измеряют именно в нагрузке на CPU.
                          0
                          А в mediatemple.net/labs/cs/ будет еще лучше :)
                            0
                            Не факт.
                            Усложнение структуры редко идет на пользу.
                        0
                        Не совсем понятно — а чего вы, собственно, пытаетесь добиться? Вычислить минимум ресурсов и денег, которые вам необходимы для поддержки вашего продукта? А зачем такая точность?

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

                        Может, конечно, я говорю не о тех облаках, но я плотно работаю с Амазоновским облаком и просто не вижу необходимости во всех этих телодвижениях.

                        Предположим, что у нас есть либо а) продукт, спроектированный для управления потребными облачными ресурсами (т.е. в сам продукт встроено умение запускать новые сервера под себя), например, Animoto, либо б) продукт запущенный через сервис, который занимается тем, что масштабирует облачные ресурсы под этот сервис (скажем, CloudFoundry). Тогда задача, в принципе, решена — при отсутствии нагрузки будет использоваться минимум ресурсов, при росте нагрузке — столько, сколько нужно на этот момент. И когда нагрузка упадет — все снова вернется к минимуму.

                        Конечно, самый минимум и Амазона — 8 центов в час — слегка кусается. Я бы хотел, чтобы они дали возможность запускать еще мЕньшие сервера за еще меньшие деньги. Но, в приципе, их подход «платишь только за то, чем реально пользуешься» позволяет не тратить силы, время и деньги (в пересчете на зарплату даже одного программиста — не очень маленькие) на предварительно планирование, которое все равно не может давать точные результаты по определению.

                        Возможно, я просто не понял проблемы, стоящие перед автором топика.

                          0
                          Насколько я понял автор топика мечтает о понятной PaaS платформе с легко прогнозируемой стоимостью при разной нагрузке на сервис и автоматическим увеличением и уменьшением ресурсов в зависимости от нагрузки на приложение, при этом без написания каких либо специальных программных инструментов.

                          Грубо говоря, чтобы он пришел на сайт облачного провайдера, указал допустим тип CMS и двигая счетчик количества посетителей увидел приблизительную стоимость за час работы при такой нагрузке.
                            –1
                            Опять же, а зачем? Чтобы убедить бухгалтерию, что на облаке дешевле?
                              0
                              Затем, что когда делаешь стартап на свои деньги (без инвесторов и пр.), то дорога каждая копейка и не хочется брать на много тыщ денег дедик, а хочется где-то сэкономить. Понятно, что когда ты увидишь реальную нагрузку на сервер и работу самой системы, то поймешь как и куда лучше идти, а пока ты гоняешь на своей домашней машине/ноуте свой продукт хоть головой в стенку бейся — непонятно сколько нужно будет тратить денег на инфраструктуру.
                                –1
                                >когда делаешь стартап на свои деньги (без инвесторов и пр.), то дорога каждая копейка и не хочется брать на много тыщ денег дедик, а хочется где-то сэкономить

                                Именно для таких случаев и придумано облако — нулевой порог входа. Запустил в облаке и смотришь на нагрузку в _реальности_. Какой бы безденежный стартап ни был, деньги на самый минимум облачных ресурсов должны же быть.

                                Ладно, я, видимо, просто не въезжаю.
                                  0
                                  Я про это какбы и говорил ;)
                                    –1
                                    Тогда зачем городить весь этот огород с оценкой нагрузки и прочими сложностями, которые дают точность просто никакую?
                                      0
                                      А для того, чтобы прогнозировать свой бюджет, что тут непонятного-то? Если вы будете знать, скажем, что у вас потратится примерно $100 на первый месяц, а у вас $250, то можно оставить 150 на про запас (высчитаный), а остальные 100 пустить в дело (раскрутка, копирайтеры, дизайнеры, etc).
                              0
                              Автор всего лишь предложил идею, как можно сделать платформу более прогнозируемой. А вот стоит ли игра свеч — вопрос открытый.
                            0
                            Прогнозируемость стоимости услуг провайдера облачной платформы — важный фактор, влияющий на привлекательность того или иного облачного провайдера.

                            Путь «кейсов» выглядит очень привлекательно, как со стороны клиента, так и со стороны хостера. Однако, чтобы предоставить информацию о кейсах, должен выполняться ряд условий:
                            — Провайдер ограничивает действия пользователя, гарантирует оптимальность работы серверного ПО, в том числе и приложения пользователя (тем самым исключая «эффект кривого плагина для wordpress»)
                            — Провайдер накопил достаточный опыт для достаточного количества кейсов.

                            На рынке облачных услуг в РФ есть только одна компания, которая выолняет первое условие, и ни одной, которая бы выполняла второе и/или оба.

                            На мой взгляд, чаще достаточно знать минимальную и максимальную планку: сколько я заплачу, если нагрузка прыгнет до небес и как согласовать оплату больше, если мне действительно это нужно?
                            Это компромисное решение.
                              0
                              Что-то непонятно, зачем такая фишка хостерам: гемору много, а увеличения клиентов-то, скорее всего, не будет.
                                +1
                                Вот и мне, как неопытному молодому человеку с идеей, которая перевернёт мир, непонятно: откуда взять все эти количества GET, POST, INSERT, а главное CPU.


                                … а потом…

                                Входной лог можно и нужно править, моделируя слешдот-моменты (и сделать это достаточно просто — взять и подмешать копии реальных сессий с модифицированными IP-адресами).

                                Все шаги вполне прозрачны и понятны даже полному новичку.


                                Мне одному кажется что прикинуть какая будет загрузка у проекта легче чем «моделировать слешдот-моменты»?

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

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

                                Ну и конечно тестировать всегда полезно. Я для себя выбрал пока следующий сценарий — выбираю самое тяжелое (на мой взгляд) место проекта, выключаю кэширование и прочую оптимизацию, натравливаю туда стресс-тест типа Apache Benchmark и смотрю на результат. Если я получаю, скажем, 20 запросов в секунду в среднем, то меня это устраивает, и на этом стресс-тест можно заканчивать (для начинающих проектов). До сих пор такой метод не подводил, но позволял заметно сэкономить время.
                                  0
                                  Пилить облако вроде EC2 зачастую действительно не имеет смысла. Но в защиту автора хочу кивнуть на такой сервис как Heroku, где облачность объединяется с простотой развёртывания и подключения дополнительных сервисов.
                                    +1
                                    А в чём проблема положить минимальную сумму на счёт облачного провайдера, залить туда сайт, перенаправить туда обычный повседневный трафик (не трогая, не отключая старый хост — разве что БД надо аккруатно перенести туда-обратно), и посмотреть, что получится. Только эксперимент покажет реальную нагрузку. Можете два дня посмотреть, все логи записать, и вернуться обратно на любимый VPS. Эти логи можно уже изучать сколько угодно, экстраполируя нагрузку при разном числе пользователей и характере их действий на сайте.

                                    Между прочим, подобный безболезненный и недорого «тестовый переезд» может быть отдельной услугой у профи-админов.

                                    Успехов.

                                    PS: К слову, можно держать в облаке «выключенный» образ сайта, пока он не понадобится, и не платить за трафик и процессор (только за хранение образа в боеготовности). Написать скрипт, который при перегрузке VPS будет «будить» образ в облаке и перенаправлять трафик туда. Тогда VPS будет просто рулить трафиком, а всю нагрузку возьмёт на себя облако. Когда «слешдотовость» понизится, можно отключать облаков и возвращать VPS в обычный режим.
                                      0
                                      Ну и да, сказанное ничуть не противоречит основному тезису статьи: облачным хостерам следует таки указать стоимость обслуживания в сутки при «типичной нагрузке» для различных ситуаций.
                                        +1
                                        Подозреваю, что зачастую основная проблема не инстанс веб-сервера поднять, а БД синхронизировать.
                                          +1
                                          Их не надо одновременно запускать.
                                          Пишется скрипт, который останавливает VPS, переливает БД напрямую из VPS в облако, запускает облако, перенаправляет трафик.
                                          Время этой операции зависит только от объёма БД и ширины канала между VPS и облаком.
                                          Можно потренироваться днём без отключения VPS, а боевую версию поставить в крон на ночь.

                                          Успехов.
                                            0
                                            Звучит красиво, но как планируется поддерживать актуальность БД во время «переливания»? Я пока вижу выход в распределённых хранилищах без мастера, но это особая песня со своими куплетами.
                                              0
                                              Я подразумевал полную остановку сервиса на время миграции.
                                                0
                                                Для однократной миграции вполне вариант. Но делать это дважды в день, причём в час пик — это совсем неправильно. ;)
                                                  0
                                                  Если проследить таки за логикой мысли, то очевидно речь идёт только о том, чтобы один раз попробовать перенести свой работающий сайт в облако и выяснить, какую нагрузку он порождает в нормальном режиме.

                                                  Наверное понедельник негативно сказывается на лёгкости взаимопонимания :-)
                                                    0
                                                    Я думаю мы в целом поняли друг друга. ;) Я отреагировал на PS в исходном сообщении.
                                              +1
                                              Вы сами пробовали таким заниматься? Видимо нет.
                                              Самый правильный, в этом случае, сценарий — остановить работу сервиса на вашем VPS (чтобы данные не писались), перелить БД в облако, переключиться на облако. Но это опять же — простой от нескольких десятков секунд, до нескольких десятков минут (в зависимости от размеров БД).
                                              Можно, конечно, сделать репликацию в облако, но это опять же лишние затраты.

                                              Самое идеальное — держать БД в облаках, но это для старта слишком дорого.
                                                +1
                                                > Самый правильный, в этом случае, сценарий — остановить работу сервиса на вашем VPS (чтобы данные не писались), перелить БД в облако
                                                >> Пишется скрипт, который останавливает VPS, переливает БД напрямую из VPS в облако, запускает облако, перенаправляет трафик.

                                                По-моему я именно это и написал, разве нет?

                                                > Но это опять же — простой от нескольких десятков секунд, до нескольких десятков минут (в зависимости от размеров БД).
                                                >> Время этой операции зависит только от объёма БД и ширины канала между VPS и облаком.

                                                Я пишу невидимыми буквами? :-)

                                                > Самое идеальное — держать БД в облаках, но это для старта слишком дорого.

                                                Думаю, что для небольшого стартапа нестрашно приостановить работу сервиса на пару минут где-нибудь ночью, чтобы протестировать переход в облако.

                                                Есть ещё компромиссный вариант: залочить базу от записи так, чтобы сервис только отдавал страницы на чтение. А с добавлением данных юзеры подождут несколько минут. Но тут уже всё зависит от конкретного сервиса — надо, чтобы отправленные пользователем из браузера данные не потерялись.
                                                  0
                                                  > Я пишу невидимыми буквами? :-)
                                                  Да, видимо я с просоня не заметил ))
                                                    0
                                                    В 12:38? С понедельником :-)

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