Масштабуючи до 100 мільйонів: архітектура, обумовлена рівнем сервісу

Це третя частина циклу «Масштабування Wix до 100 мільйонів користувачів». Вступ і другий пост.

Wix починався з одного сервера, який забезпечував весь функціонал: реєстрацію користувачів, редагування веб-сайтів, обслуговування опублікованих веб-сайтів і завантаження зображень. У свій час цей єдиний сервер був правильним рішенням, оскільки він дозволив нам швидко рости і застосовувати гнучкі методи розробки. Проте до 2008 року почалися періодично повторювані проблеми з розгортанням, які вели до незапланованих простоїв як в створенні нових сайтів, так і в обслуговуванні вже створених.

Розгортання нової версії нашої системи в деяких випадках вимагало зміни схеми MySQL. Оскільки Hibernate не прощає розбіжностей між очікуваною їм схемою і реальною схемою бази даних (БД), ми використовували загальну практику розгортання програмного забезпечення: планова двогодинна зупинка в період найменшого трафіку (опівночі в США на вихідних). За час цієї планової зупинки ми повинні були зупинити сервіс, вимкнути сервер, внести зміни у схему MySQL, розгорнути нову версію і перезапустити сервер.

Ця планова двогодинна зупинка часто перетворювалася в щось більш складне з-за проблем, які могли траплятися при розгортанні. У деяких випадках внесення змін в схему MySQL займало помітно більше часу, ніж планувалося (зміна великих таблиць, перебудова індексів, скасування обмежень на міграцію даних тощо). Іноді після зміни схеми і спроби перезавантажити сервер він не запускався з-за якихось непередбачених проблем з розгортанням, конфігурацією чи схемою, які не давали йому працювати. А в деяких випадках нова версія нашого програмного забезпечення виявлялася непрацездатною, тому для відновлення сервісу нам доводилося знову міняти схему MySQL (щоб привести її у відповідність з попередньою версією) і знову розгортати попередню версію системи.

Але найгірше траплялося, якщо через кілька днів після «успішного» розгортання ми виявляли в новій версії критичний, хоч і рідкісний, баг, приводив до пошкодження користувальницьких сайтів. У цьому випадку найкращим було відкотитися до попередньої версії (принаймні до моменту виправлення бага), а для цього потрібно знову міняти схему, що означало позапланову зупинку сервісу.
Важливо відзначити, що, оскільки ми використовували одне серверний додаток для обслуговування всіх систем Wix, зупинка піднімала весь сервіс, включаючи опубліковані сайти. Оскільки наша користувацька база зростала, все більше і більше сайтів виявлялися порушеними нашими плановими і позаплановими зупинками.

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

Усвідомивши це, ми розділили нашу систему на два сегменти: редакторський сегмент, який відповідає за побудову нових сайтів, і публічний сегмент, який відповідає за обслуговування сайтів. Це рішення дозволило нам забезпечити різні рівні сервісу, відповідні кожної з бізнес-функцій.

Технологічний стек, вибраний для вибудовування публічного сегмента, був навмисно простим. Ми більше не використовували Hibernate, ми відмовилися від будь-яких форм кеша, і ми почали використовувати Spring MVC 3.0. Важливим принципом проектування було зробити сегменти не пов'язаними один з одним в термінах програмного забезпечення, циклу релізів та зберігання даних, а також зробити програмний стек простим для розуміння і оптимізованим для обслуговування сайтів.

Явною ознакою такої незв'язаності був процес публікації (нащадки якого як і раніше присутні в ядрі Wix), який копіював дані з БД редакторського сегмента в БД публічного сегмента. У ході цього процесу, структури даних трансформувалися від уявлення, ефективного для редагування, уявлення, яке найкращим чином підходить для опублікованого сайту.



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

Чого ми навчилися
Ми вже розуміли, що цикл релізу пов'язаний з ризиком, але тепер усвідомили, що дві наші ключові бізнес-функції – будівництво та обслуговування сайтів – по-різному схильні до ризику. Ми зрозуміли, що нам потрібно забезпечити різні рівні сервісу для цих функцій і що саме навколо них ми повинні вишиковувати нашу систему. Що це за різні рівні сервісу? Ми розглядали такі аспекти: доступність, продуктивність, ризикованість змін та час відновлення після збою. Публічний сегмент, який зачіпає всіх користувачів та всі сайти Wix, повинен мати найвищий рівень сервісу за цим аспектам. Але в редакторському сегменті збій зачіпає тільки користувачів, безпосередньо зайнятих створенням сайту, тому наслідки для бізнесу менш значні. Тому ми дещо поступилися високим рівнем сервісу задля більшої гнучкості, що дозволило знизити зусилля, необхідні для розробки.

Головний архітектор програмного забезпечення конструктора сайтів Wix,
Йоав Абрахами
Оригінал статті: блог інженерів компанії Wix

Джерело: Хабрахабр
  • avatar
  • 0

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.