Як жити в хмарі без адмінів : хмарно з проясненнями

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
Як відстежити ефективність рекламної кампанії?