System Design

System Design⚑

Проблеми та рішення, з якими стикаємось при розвитку додатку⚑

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

• MVP - стадія прототипу
  • Достатньо сервера з додатками (фронтенд та бекенд в якості API), бази даних.
  • Для зберігання файлів, картинок потрібно користуватись стороннім сервісом Amazon S3 або аналогічним.
  • Можна масштабуватись тільки за рахунок вертикального масштабування - більше місця, більше оперативної пам'яті, кращий процесор.
  • Індекси на потрібні колонки.
• Бекапи - Backups
  • Щоб не втратити дані - потрібно робити бекапи. Або обрати зовнішнє рішення, яке буде це робити самостійно.
  • Потрібно перевірити процес відновлення з бекапів, оскільки вони можуть бути не робочі. Для цього періодично можна тестувати відновлення системи після інциденту.
• Доступність, Відказостійкість - Availability, Fault Tolerance - Load Balancer
  • Коли збільшується трафік, одного сервера може почати не вистачати. Тоді необхідно додати один або кілька інших, та налаштувати розподілення трафіку між ними.
  • Для розподілення трафіку потрібно скористатись Load balancer (Nginx). Найпростіший принцип розподілення - Round-Robin.
• Час відповіді - Performance - Cache, Database Replica, CDN
  • Якщо вузьким місцем стає база даних, потрібно налаштувати кешування найбільш часто запитуваних даних.
  • Якщо кешування недостатньо - потрібно налаштувати репліку, та перевести на неї read запити. Також потрібно налаштувати механізм master-slave, якщо одна з них вийде з ладу.
  • Якщо клієнти додатку розкидані географічно (користувачі із Сінгапуру незадоволені, що хост зі Штатів довго відповідає), можна скоротити час очікування відповіді, якщо перенести сервери ближче до кінцевих споживачів.
  • Також можна налаштувати кешування, CDN (Cloudflare).
• Аналітика - Analytics
  • Аналітичні запити зазвичай дістають велику кількість даних, мають кілька JOIN запитів, тож завжди повинні виконуватись на репліці. Оскільки ці великі запити вимагають великої кількості CPU, що може заблокувати основний додаток, а також вони забивають кеш, який база даних використовували для обслуговування додатку.
  • Якщо аналітичних даних багато, можливо потрібна денормалізація або NoSQL база даних.
• База даних - Database
  • Для оптимізації роботи бази даних, якщо вже є кешування та репліки, можна використати
    • Денормалізація
    • Партиціонування
    • Шардування
• Мікросервіси - Microservices
  • Впровадження мікросервісів ускладнює архітектуру додатку, сповільнює розробку. Для забезпечення транзакцій потрібно впроваджувати окремі концепції.
• Пікові навантаження
  • Якщо ми очікуємо маркетингову сесію, рекламу, свята - тобто піковий онлайн може бути 10х від звичайного, потрібно налаштувати політики автоскейлінгу.
  • Перед піком можна прогріти сервіси, тобто запустити додаткові сервіси так, щоб навантаження було близько 10% від максимуму. Це допоможе краще справитись з ростом навантаження.