Як ми мігрували з заліза на AWS: проблеми та рішення

Мене звати Ілля, я CTO компанії Wikr Group. Ми займаємося створенням і розвитком контент-проектів в усьому світі. Щомісяця наші ресурси відвідують більше 100 млн унікальних користувачів.

Спочатку всі наші проекти були створені на WordPress, а сервери проекту хостилися на залозі. Із зростанням географії сервісів по всьому світу ми були змушені купувати сервера в Бразилії, Штатах, Німеччині — у всіх точках присутності. Це було незручно з точки зору адміністрування: виникали труднощі з сетапами, додаванням нових инстансов. Коли потрібно було масштабуватися, ми витрачали по кілька днів на очікування, поки новий сервер доставлять у стійку. І після — поки отримаємо відповідь від служби підтримки. Зважаючи на все це, нам хотілося бути гнучкими, швидко деплоиться і управляти всім з одного місця.

До того ж наш продукт — це контент, а робота з контентом передбачає велику кількість статики, в нашому випадку картинок. Щомісяця зі всіх наших ресурсів ми віддаємо близько 100 Тб статики. Обслуговувати з залізних дисків такі обсяги даних стало незручно.

Так було вирішено переїхати в хмару. Це надійно, зручно і дозволяє гарантувати цілісність даних. Вибрали Amazon Web Services.

Чому AWS?

Amazon — лідер, саме він диктує правила клауда в світі. З AWS конкурують Google Cloud, Microsoft Azure, Digital Ocean і т. д. Але так склалося історично, що на той момент ми вже користувалися деякими сервісами Amazon — приміром, Route 53 DNS Service для балансинсировки запитів. Нам було простіше розширюватися, інтегрувати та узгоджувати інші сервіси вже звідти.

До того ж, у Amazon є дуже багато дата-центрів по всьому світу, які пов'язані між собою. Як я писав вище, наші сервери теж розміщувалися в різних країнах Європи і Америки, і тому ми мали намір переїхати на ту ж структуру — тільки тепер з'єднані в одну мережу набагато більш швидкими каналами.

Перехід на S3 і EFS

S3 — це сховище об'єктів, один з сервісів в AWS. Першим ділом ми інтегрували цей сервіс в наші внутрішні (не контентні) сайти: близько 12 аналітичних та інших додатків, написаних на PHP 7 і Symfony 3. Переписали код, щоб роздавати внутрішню статику безпосередньо з S3, однак тематичні сайти все одно продовжували працювати на залозі. Частина проблем залишилася: нам все ще доводилося піднімати WordPress у всіх регіонах, де ми запускалися.

Наступним етапом міграції був перехід на мережеву файлову систему EFS.

На цьому етапі ми зіткнулися з проблемою, яка обійшлася нам у добу простою. Amazon EFS використовує кредитну систему для визначення того, коли файлові системи можуть вичерпати виділені для них ресурси. Є таке поняття, як пропускна здатність: ми можемо прогнати через мережеву файлову систему певну кількість трафіку з певною швидкістю. Якщо ці кредити вичерпуються, то пропускна здатність і швидкість стає дорівнює 0. Саме це з нами і сталося: в один прекрасний день віддача файлів припинилася.

Написали в саппорт, і нам у відповідь скинули статтю, де розказано, як всі розраховується, запропонували нам самостійно розрахувати необхідні розміри трафіку. Виявилося, що чим більше об'єм, тим більше кредитів надається. Таким чином, для коректної роботи довелося «роздути» EFS файлами-заглушками з 4 Гб (це був тільки код, так як всі картинки в S3) до 30 Гб.

Тепер ми вже заздалегідь розраховуємо, яка кількість трафіку нам буде забезпечено. Коли необхідно, попередньо збільшуємо розмір файлової системи, щоб отримати більший кредит.

Специфіка роботи RDS

У нас є кілька регіонів. Майстер-база знаходиться тільки в одному з цих регіонів, а слейвы — в кожному. Для того щоб підключитися до майстра, нам потрібно дозволити підключення з інших зон. У рамках одного регіону це можна реалізувати, вказавши source сек'юріті-групи инстансов, яким потрібен доступ до майстра. Але з инстансами з іншого регіону так зробити не вийде. Тому необхідно прописувати їх зовнішні IP як дозволені.

В результаті доводиться рахуватися з тим, що цей фактор заважає динамічно крос-регионно скейлить инстансы, яким необхідний доступ до майстер-базі.

Єдина адмінка

Ми працюємо на 7 різних локаціях по всьому світу, і, відповідно, у нас 7 редакційних команд. Дуже багато хлопців звідти працює віддалено — це локальні редактори, перекладачі, творці контенту, фахівці з постпродакшену. Вони всі працюють з контентом через адмінку.

Тому виникла задача на рівні AWS логічно розділяти, як буде працювати роутинг в адміністративній і фронтовий частинах наших сайтів.

Знайшли таке рішення: зробили одну майстер-базу в Європі. Записувати нові дані ми можемо тільки на майстер, а зчитуємо з регіональних слейвов. Щоб все записувати в одне місце, ми зробили між регіонами ipsec-тунель — VPN, який пропускає трафік через шифрований тунель у Європу, в локацію адмінки. Таким чином, наприклад, коли контент-редактори з Бразилії редагують матеріали, інформація йде по ланцюжку з Південної Америки в Європу.

Наша поточна архітектура

Грошові питання

Мінус міграції з заліза в хмару може бути тільки один — це дорого. З нашими масштабами ці витрати виправдані. Але якщо йдеться про невеликому стартапі, то, можливо, буде простіше купити VPS.

Робота в хмарі вчить працювати з ресурсами, все ретельно прораховувати і позбавляє від необхідності брати сервера «на виріст». Ми беремо лише ті сервери, які підходять саме під наші завдання. Наприклад, якщо потрібно 3 двоядерних инстанса — стільки й візьмемо. Так що не доводиться платити більше і втрачати на просте.

Заощадити можливо і на оптимізації хостингу. AWS пропонує звернути увагу на так звані спот-инстансы — инстансы, які продаються на їх біржі за принципом аукціону. Так можна зловити найнижчі ціни. Однак треба розуміти, що пізніше їх ціна може підвищитися, і вони «схлопнутся». Тому на них не можна побудувати основну робочу групу, але цілком можна крутити ті завдання, для яких даунтайм не критичний. Наприклад, один з рівнів кеша.

Інший спосіб заощадити — використовувати резерв инстансов. Ми поки що їм не користувалися, так як у наших проектів йде активне зростання, і нам поки що складно точно спрогнозувати масштаби.

При цьому потрібно розуміти, що Amazon — це не завжди панацея. Приміром, у AWS дорогий CDN. Ми використовуємо сервіс компанії CloudFlare — це обходиться в десятки разів дешевше. Якщо комбінувати послуги різних постачальників, можна домогтися більшої ефективності — і в плані роботи системи, і в плані витрати коштів.

Підсумки і висновки

Ми почали міграцію навесні, і вона триває досі. Найскладніше — перенесення «живого» трафіку з 70-100 тис. користувачів онлайн. На порядку денному — робота над автоскейлингом. Це дозволить працювати з незапланованим трафіком, який наша існуюча архітектура може не витримати. Автоскейлинг дозволить додавати додаткові инстансы на пікових навантаженнях, а потім їх відключати.

Головні рекомендації — ретельно рахувати трафік і розглядати комбінації сервісів, які дозволять заощадити. І ще не допускати безладу в именованиях, групах, тегах, документації — це стосується не тільки хмари. Порядок — запорука успіху :)

З літератури можу порадити книгу «AWS Certified Solutions Architect Official Study Guide» — там доступно розказано про принципи роботи з Amazon. Є також однойменні відеоуроки.

Якщо ви тільки починаєте працювати з AWS, обов'язково поспілкуйтеся з тими людьми, хто вже має такий досвід. Ми завжди готові підказати і дати пораду: пишіть в коментарях або в особисті повідомлення.

Опубліковано: 08/11/17 @ 11:10
Розділ Різне

SEO Блог