Як жити в хмарі без адмінів : хмарно з проясненнями
via Shutterstock .
Історія мого знайомства з « хмарами» почалася приблизно три роки тому. Моя компанія займається розробкою « коробкового » ПЗ , і єдиним сервісом , який вимагав адміністрування , був наш власний сайт.
Він розміщувався на виділеному сервері в одному з датацентрів . Сайт працював і не доставляв особливого клопоту рівно до тих пір , поки одного разу в сервері не " помер» RAID -контролер , поховавши разом з собою і файлову систему. Не таке вже й страшна подія , якби не низка вкрай неприємних збігів . По-перше , не виявилося працюючого резервного контролера. По-друге , сталося це 5 -го січня - в самий розпал новорічних канікул , коли все навколо знають слова «олів'є» і «шампанське» , але щиро дивуються , коли заводиш мову про « колокейшн » , « датацентр » , « сервер» і т.п.
Залишити сайт неробочим на кілька днів я не міг , тому продовжував шукати варіанти швидкого відновлення. Саме в цей момент прийшло в голову спробувати Amazon AWS ( Amazon Web Services ) - виключно як тимчасовий варіант .
Але немає нічого більш постійного , ніж тимчасове : наш сайт так і продовжує працювати в Амазон . За цей час ми з колегами накопичили величезну кількість досвіду роботи з хмарними провайдерами і з Амазонії зокрема. Далеко не завжди досвід цей був позитивним , але , тим не менше, всі нові сервіси компанії ми продовжуємо запускати виключно в « хмарі» . Чому це так , які висновки ми зробили за три роки - про це і постараємося розповісти .
Міф № 1 : «хмару» - це швидко
Майже напевно це не так. Одним з найбільш « вузьких» місць будь-якого «хмари » є дискова система . Диски в « хмарі» майже завжди повільні , і з цим доводиться або миритися , або якось боротися. Наприклад , організацією софтверного RAID , якщо хмарний провайдер дає можливість гнучко управляти конфігурацією дисків в системі.
Міф № 2: « хмара » - це надійно
Якщо хтось запропонує вам перенести ваш проект з звичайного сервера в хмару без будь-яких змін архітектури зі словами «там надійніше » - він покривить душею ... Перебільшуючи, « хмара » - це віртуальна машина , запущена все на тих же серверах , в тих же датацентрах , що обслуговуються тими ж людьми.
І їм притаманні ті ж проблеми , з якими стикаються звичайні сервери. Форс -мажори трапляються і в « хмарах». Одного разу блискавка влучила в трансформатор в датацентрі Амазону в Ірландії і вивела його з ладу - а разом з ним і сайт моєї компанії - на багато годин . « Хмарні » віртуальні диски виходять з ладу так само , як і звичайні «залізні ». Людський фактор - найстрашніший джерело бід і катаклізмів - нікуди не зникає з «хмари ». Наприклад, інженер , випадково викотився на бойові сервери неправильну конфігурацію , цілком може « грохнути » користувальницькі frontend'и - балансувальників (так, так теж було).
На моїй пам'яті Амазон неодноразово « якісно » «лежав » - окремими серверами , сервісами , а іноді й датацентрами - зачіпаючи чимало великих проектів : Foursquare , Instagram , Netflix , Pinterest ...
Міф № 3: « хмара » - це дешево
Якщо прямо порівнювати ціни віртуальної машини в « хмарі» та аналогічного по конфігурації «залізного» сервера , виртуалка практично завжди програє. Кажуть , що перевагою «хмари» , яке дає реальний виграш у ціні , є гнучкість і масштабованість . Що , мовляв , в будь-який момент часу ми платимо тільки за ті ресурси , які споживаємо , і при виникненні навантаження на сервіс просто додаємо потрібну кількість віртуальних машин.
Це дійсно так . Тільки на практиці виявляється , що дев'ять жінок не можуть за один місяць народити дитину , а 90 % веб -додатків не вміє «з коробки» масштабироваться горизонтально , тобто розподілятися на кілька серверів. А вертикальне масштабування (збільшення ресурсів CPU , RAM) існуючого сервера досить швидко впирається в « стеля» .
Здається , на цьому місці пора ставити крапку в розповіді про «хмари» ? Оцінивши всі ці недоліки , але не розібравшись в темі досконально , багато біжать від « хмар» як від вогню. І дарма.
Про що слід подумати , вибираючи «хмару» ?
Економія в « хмарі» базується не на низькій ціні , а на можливості дуже гнучко планувати свої витрати , а також на відсутності витрат на старті. Якщо ви запускаєте новий проект , який вимагатиме значних ресурсів у міру зростання , вам потрібно заздалегідь бути готовими до купівлі або оренді необхідної кількості серверів. У « хмарі» можна робити це поступово - і реально лише в міру необхідності.
І найголовніший ресурс , який економить «хмару» - це час. Додати , видалити сервери , переконфігурувати дискову систему , додати новий компонент в архітектуру можна з браузера з будь-якої точки світу в будь-який час . І не потрібно їздити в датацентр або чекати виконання своєї заявки інженерами датацентру , в якому ви орендуєте «залізні» сервери.
Що стосується надійності , то нерозумно розраховувати на те , що простий перенесення сайту в «хмару » дасть гарантії 100 % відмовостійкості . Якщо для сервісу критично важлива надійність (наприклад , для інтернет- магазину або для бізнес-додатки ) , необхідно самостійно оцінити всі можливі ризики і спрогнозувати , як можна їх уникнути або мінімізувати.
Що робити , якщо вийде з ладу диск? Як захиститися від аварії на рівні цілого датацентра ? Як швидко відстежити можливі помилки розробників ? Як не пропустити термін делегування домену ? Ризиків - маса .
« Хмари» - це не « чарівна пігулка » , не панацея , яка врятує вас від усіх бід. Більш того , бездумний перехід в «хмару » може лише додати проблем. Саме по собі « хмара " не надійніше традиційного хостингу і власного обладнання , однак ця технологія дає можливість організувати надійну інфраструктуру тим , для кого це дійсно важливо .
Опубліковано: 18/12/13 @ 08:59
Розділ Різне
Рекомендуємо:
Дайджест: лікнеп по опціонах , Обама закликає американців вчитися програмувати , інтерв'ю з творцем Doom
19 грудня, Одеса - Практикум з Haskell
16 грудня , Київ - Lua . Огляд мови та її можливостей
Дайджест цікавих вакансій № 115
Як відстежити ефективність рекламної кампанії?