В началото на Април 2020-та eBag се обърнаха към нас за съдействие в разрешаването на проблема, който спира развитието на компанията в този важен за нея момент. Благодарение на това че инфраструктурата на магазина е разположена в клауда на Делта.бг, ние имахме поглед върху текущите ресурси и имахме възможност бързо да направим изчерпателен анализ на ситуацията. Оказа се, че обикновено увеличение на ресурсите би закърпило проблема, но при допълнителен ръст на трафика, той би възникнал отново. Оптималното решение трябваше да включва комбинация от хоризонтално увеличение на сървърните ресурси, пълно автоматизиране на процеса по деплоймънт и промяна на алгоритъма за откриване на грешки и отпадания.
Вертикално или хоризонтално скалиране?
Вертикално увеличение (или скалиране, в по-общия вариант) обикновено означава добавяне на допълнителни хардуерни ресурси (CPU, RAM, storage) към същата машина. Хоризонтално увеличение означава добавяне на допълнителни обработващи единици към вече съществуващите и разпределяне на натоварването между тях.
Ако си представите лавка за закуски, обслужваща наплив от клиенти, вертикалното скалиране би представлявало увеличаване на броя на персонала в лавката с нарастването на броя клиенти. Хоризонталното скалиране би представлявало отваряне на паралелни лавки, копия на оригиналната, с нарастването на броя на клиентите. Когато сървърните ресурси не достигат, логичният въпрос е в коя посока да е увеличението. В случай че сървърът, с който разполагаме, е наша собственост, в повечето случаи имаме само един вариант – вертикално увеличение (дори хибридният вариант със собствен хипервайзор по същество е вертикално увеличение на ресурсите). Разполагайки инфраструктурата си в клауда, eBag имаха възможност да скалират хоризонтално, осигурявайки си по този начин следните несъмнени предимства на този подход:
- Неограничена възможност за ъпгрейд на хардуера,
- Тясно обвързване между разходите и приходите от дейността,
- По-голяма стабилност на системата,
- Отпадане необходимостта да се плаща постоянно за пиков капацитет.
Автоматизация на процеса по деплоймънт.
За да бъде реализирано гъвкавото хоризонтално скалиране на инфраструктурата според утвърдените съвременни практики, предложихме миграция към Ansible* като СМ (configuration management) решение. Предимствата на този подход пред шел скриптовете са много, но някои от по-съществените са параметризация, темплейти на конфигурационните файлове и пълна автоматизация на процеса по деплоймънт. Последното е ключовият момент в оптимизацията на работата на програмистите на компанията, защото им позволява, след като са тествали промените по магазина, да ги заредят на живия сайт само с натискането на един бутон – без прекъсване и без потребителите да забележат, че в момента се извършва някаква работа по него. А ако все пак нещо не сработи, както дори и на най-добрите програмисти се случва, автоматизираният процес по деплоймънт позволява възвръщане към предишна стабилна версия на сайта, за да може да се тества отново кодът за грешки**. Технологиите, в комбинацията, която предложихме, бяха напълно отворени решения, които могат да бъдат проверени от трета страна или да им бъде осигурена поддръжка от друга компания, без клиентът да бъде заключен към определена услуга или разработчик.
Прилагане на най-добрите практики за откриване на грешки и отпадания.
Дори с най-гъвкавата и устойчива инфраструктура, дори с напълно автоматизиран процес на деплоймънт, проблеми в системите са възможни и е необходимо да бъдат бързо открити и още по-бързо отстранени. Достъпването на всеки отделен сървър за проверка на логовете му бързо се превръща от изпитание в кошмар с нарастването на броя на сървърите, съобразно трафика. eBag знаеха, че централизиране на логовете би предотвратило такъв сценарий, но им бе необходимо конкретно решение. Предложихме ELK Stack*** - на всеки сървър трябваше да бъде инсталиран шипър за логове, който щеше да позволи централизирано търсене, съхранение и обработка на тази важна информация. Освен оптимизацията на работата, това щеше да освободи от съответните сървъри ресурси, които могат да бъдат използвани за поверената им задача. Отново предложеното решение бе open source, което спестяваше на клиента разходи за лицензи и такси.
Така разработеният проект за обновление на системата на магазина бе представен на eBag и, след одобрението на клиента, Делта.бг успя да го тества и внедри в рамките на три седмици. За целите на процеса бе изградена виртуална тестова среда, в която копие на обновения онлайн магазин бе подложено на симулации на пиков трафик. Резултатите се оказаха отлични и пристъпихме към обновлението. То бе извършено без прекъсвания на услугата, така че нито един клиент на магазина да не забележи.
