Architecture in 2013 comes from scratch, so is there any hope for the future? Business is primarily about money, but what if the balance between technical improvements and a beautiful look is not maintained.
"Emergency 2015" - the limit after which you need to make drastic changes in the technical component. Carte blanche from business and a rough idea of where to start the transformation.
Why did you choose to go through refactoring? Why did you decide to split the monolith into microservices in 2015, when the hype was just emerging, instead of SOA and monolith? How did you choose where to start? How AWS S3 defeated Ceph and helped save the nerves and funds of DevOps? What nodes of the system have provided us with the opportunity to grow 10-15 times in 5 years without spending much more money on vertical scaling? Stable 1.5 billion letters in 2020.
3. Чим являвся UniSender в 2013
● прибутковим бізнесом
● приблизно 100 млн листів в місяць
● дизайн в дусі нульових
● невелика розподілена команда
● великі амбіції
4. Технічні деталі
● haproxy + nginx
● php 5.6 * 8
● mysql 5.6 (2Tb sata/ssd, 256Gb Ram, 16core CPU) *2
● redis
● exim smtp server * 7 (ram disk для швидкості)
● nfs server 2Tb користувацьких даних
орієнтовна ціна за залізо 12k EUR
5. Проблеми ?
SPOF Коментар Проблеми
NFS 2Tb дрібних файлів падіння, rsync не встигає
Percona MySql master/slave (не кластер) падіння, 1 клієнт міг покласти сервіс
Exim RAM spool для швидкодії пікові навантаження
код відправки кампаній 1 функція на 50+ аргументів і
порядка 2000 строк
спагетті код, неможливо оперативно
гасити пожежі
код результатів доставки модуль на 2-3к строк логічно заплутаний код, забагато
обов'язків, неможливо оперативно
гасити пожежі
9. Було Стало Коментар
Exim Smtp PowerMta PMTA відбив кошти через рік
NFS Ceph -> AWS S3 AWS S3 на 10% виявився дорожчим
модуль відправки кампаній все той же модуль + UniCore (Java
сервіс)
забрали з PHP, написали частково на
Java
модуль збору статистики PMTA + Java сервіс + RabbitMq 100% Java сервіс, PHP не деплоїться
на SMTP тепер
10. Ceph * vs AWS S3 ? AWS S3 wins.
* Ceph Object Storage
● станом на 2017 Ceph інфо по особливостям шукали в мейл групах
11. Ceph * vs AWS S3 ? AWS S3 wins.
* Ceph Object Storage
● станом на 2017 Ceph інфо по особливостям шукали в мейл групах
● тестові заміри на маленьких даних не покажуть нічого
12. Ceph * vs AWS S3 ? AWS S3 wins.
* Ceph Object Storage
● станом на 2017 Ceph інфо по особливостям шукали в мейл групах
● тестові заміри на маленьких даних не покажуть нічого
● на реальних даних ~ 2-3Tb файлів, більше 35 млн об’єктів швидкість
читання 1 об’єкта складала 15-20 секунд, на кластері з 3 потужних нод
13. Ceph * vs AWS S3 ? AWS S3 wins.
* Ceph Object Storage
● станом на 2017 Ceph інфо по особливостям шукали в мейл групах
● тестові заміри на маленьких даних не покажуть нічого
● на реальних даних ~ 2-3Tb файлів, більше 35 млн об’єктів швидкість
читання 1 об’єкта складала 15-20 секунд, на кластері з 3 потужних нод
● кешування не допомагало, ніяке ніде
14. Ceph * vs AWS S3 ? AWS S3 wins.
* Ceph Object Storage
● станом на 2017 Ceph інфо по особливостям шукали в мейл групах
● тестові заміри на маленьких даних не покажуть нічого
● на реальних даних ~ 2-3Tb файлів, більше 35 млн об’єктів швидкість
читання 1 об’єкта складала 15-20 секунд, на кластері з 3 потужних нод
● кешування не допомагало, ніяке ніде
● minio.io тільки починав свій шлях
15. Ceph * vs AWS S3 ? AWS S3 wins.
* Ceph Object Storage
● станом на 2017 Ceph інфо по особливостям шукали в мейл групах
● тестові заміри на маленьких даних не покажуть нічого
● на реальних даних ~ 2-3Tb файлів, більше 35 млн об’єктів швидкість
читання 1 об’єкта складала 15-20 секунд, на кластері з 3 потужних нод
● кешування не допомагало, ніяке ніде
● minio.io тільки починав свій шлях
● втрачали дані
16. Ceph * vs AWS S3 ? AWS S3 wins.
* Ceph Object Storage
● станом на 2017 Ceph інфо по особливостям шукали в мейл групах
● тестові заміри на маленьких даних не покажуть нічого
● на реальних даних ~ 2-3Tb файлів, більше 35 млн об’єктів швидкість
читання 1 об’єкта складала 15-20 секунд, на кластері з 3 потужних нод
● кешування не допомагало, ніяке ніде
● minio.io тільки починав свій шлях
● втрачали дані
● внутрішнє апі для роботи з файлами стало сумісним із S3 API
17. Ceph * vs AWS S3 ? AWS S3 wins.
* Ceph Object Storage
● станом на 2017 Ceph інфо по особливостям шукали в мейл групах
● тестові заміри на маленьких даних не покажуть нічого
● на реальних даних ~ 2-3Tb файлів, більше 35 млн об’єктів швидкість
читання 1 об’єкта складала 15-20 секунд, на кластері з 3 потужних нод
● кешування не допомагало, ніяке ніде
● minio.io тільки починав свій шлях
● втрачали дані
● внутрішнє апі для роботи з файлами стало сумісним із S3 API
● отримали статистику використання
18. Колись Ops-и були дешевшими за програмістів
● автоматизувати все, що можливо: autofailover, backups, deploys (no kube
only docker), monitoring
● чим менше shared ресурсів тим краще
● тримати в голові масштабування по принципу кубиків
● тюнінг мережевих налаштувань на рівні ОС
● відмова від DNS resolving всередині сервісів
● асинхронно там де можливо
23. Чому ми не вибрали переписувати з 0 ?
● навантаження на фонд оплати праці
● потрібен архітектор in house
● ризик втратити функціональність
● підтримувати 2 системи одночасно
● PHP 7 і досвід з “мікро-сервісами”
24. Чому у нас вийшло ?
Контрольований процес
● свідомо виділяли місця, які потрібно було “вилікувати”
● призначили відповідального за процес
● відразу писали авто-тести на api
● додавали відсутні тести
● code-review + code style
● декілька раз свідомо зупинялися в розробці окремих сервісів
25. Рік Рефакторинг Розвиток продукта
2016 50% 50%
2017 60% 40%
2018 34% 66%
2019 62% 38%
2020 25% 75%
26. Як відновлювати неактивні адреси
Запит від бізнеса: “Зробіть, щоб клієнти не мучили сапорт запитаннями чому
мої контакти все ще недоступні?”.
Дано: база контактів всіх клієнтів живе на 1 сервері. Результати доставки по
контактам тут же. Поточна реалізація не встигає обробити і 10% від всієї бази
за сутки. Оновлювати статус контактам потрібно щодня. Статус оновлюється
в залежності від результату доставки. Контактів сотні мільйонів.
27. Що ще ?
● вибираємо найважливіші для бізнеса вузли системи і модифікуємо їх
● форсуємо перехід на свіжі версії ПЗ: PHP 7+, MySql 5.7, фреймворків
● API endpoint-и мікро-сервісів на ReactPHP
● стараємось думати "впасти може будь-що і будь-коли"
● якщо можна обходимся без JOIN
● денормалізація, оптимізація структури, стискання даних і розділення баз
даних
● привчаємо розробників мислити: “Що можна зробити, щоб при передачі
даних між вузлами не робити додаткові запити в БД/мікро-сервіси?”