Cognitive World
Atlas

Новий підхід до діагностики ментальних захворювань

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

Нашим клієнтом у цьому кейсі був стартап, побудований на базі Базельського університету. Вони прагнули сформувати новий підхід у діагностиці та профілактиці ментального здоров'я. Цей підхід полягав в об'єднанні психометрії та гейміфікації. Поки пацієнт грає в комп'ютерні ігри, система отримує і обробляє його дані, в результаті чого лікар отримує дані для якісної діагностики ментального здоров'я пацієнта. Зокрема, продукт був націлений на діагностику СДУГ та хвороби Альцгеймера.

Поставлена задача

Для рішення такої задачі продукт потребує об'єднання великої кількості експертиз та сучасних технологічних рішень. На момент початку співпраці ряд невирішених технічних задач суттєво уповільнював розробку продукту. Нам потрібно було допомогти вирішити ці проблеми.

Перші вхідні дані від клієнта були такими: “потрібно оптимізувати кілька застосунків на Scala, оцінити їх ефективність та обрати вірні інструментарії та техніки для масштабування цих застосунків”. Іншими словами, потрібно працювати з продуктом стартапу ранньої стадії з back-end на Scala, і кому вже потрібно масштабуватися. Вибір Scala, як основної мови програмування достатньо незвичний для ранніх MVP. Для продуктів стартапів екосистему Scala використовують досить рідко і тільки з вагомих причин. Крім того, ми були здивовані тим, що наш клієнт вже прийшов до проблеми масштабування. Зазвичай, на ранній стадії продукту інфраструктура невелика — на нашій практиці витрати цього напряму зазвичай становлять трохи більше 5% середньомісячних витрат.

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

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

Окремим важливим питанням була безпека продукту. Для стартапу індустрії healthcare, сутність якого полягає у зборі та аналізі даних людей життєво важливо захистити дані користувачів. На цьому ринку таких помилок не вибачають. За підсумками ми сформували з клієнтом спільне бачення цілей співпраці:

• 

  Мінімізація витрат на розробку продукту: розробка повторюваної розгортки.

• 

  Розробка сучасного CI/CD pipeline. Будування плану вертикального та горизонтального масштабування продукту.

• 

  Базовий моніторинг підсистем для контролю над навантаженням.

• 

  Security audit продукту і будування плану зменшення загроз продукту в області безпеки.

Отримавши доступ до репозитаріїв продукту та його розгортки, ми остаточно переконалися, що можемо бути результативними у цій співпраці. Конструкція продукту була ясна, вся код-база була на Gitlab, а в Gitlab CI ми добре розуміємось.

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

Вертикальне масштабування

Головна ціль — збільшення IOPS, потужності CPU та RAM, а також дискового простору на окремому сервері. Цей підхід продуктивний на ранніх стадіях розвитку продукту, коли він ще не потребує хмарної інфраструктури, а розгортка проводиться вручну з причин cost-ефективності.

Ми ознайомили клієнта з вигідним рішенням, тде збільшити серверні потужності можна можливостями платформи, такими як Hetzner Cloud.

Крім того, ми описали сценарій переїзду програм з одного сервера на інший.

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

Горизонтальне масштабування

Головна мета — розгортка множинних копій одного і того ж застосунку, працюючих однаково і одночасно. Це необхідно для підвищення відмовостійкості системи та підвищення її пропускної спроможності.

Випадок нашого клієнта полягав у тому, що деякі мікросервіси мали bottle-neck за CPU, а запити до БД займали відносно мало часу. У такому випадку було продуктивно розгорнути декілька таких застосунків для одночасної їх роботи.

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

Після того як клієнт вирішив проблеми непереносимості продукту, ми спільно визначили наступні пріоритетні задачі. Нам потрібно було вирішити проблеми швидкості і зручності програмування. Фактично, задача нашого клієнту полягала в тому, щоб в максимально стислі терміни подолати бар'єр входу в незнайомі технології та навчитися вирішувати свої завдання за їх допомогою. У такому випадку, найкращим способом пояснити технології — показати їх використання на робочих прикладах. Ми вирішили наступні задачі:

На цій стадії ми вже вирішили основну проблему клієнта — перенесення і масштабування застосунків стали ясними та зручними. Загроза витратити на це багато часу або грошей вже не виглядала суттєвою. Наступний набір задач включає в себе:

• 

  Централізовану систему логів на основі ELK. Це стало своєчасним, через те що кількість мікросервісів була вже суттєвою, а кількість даних важливою для відстеження також зросла. Приємний бонус — для перевірки невеликої гіпотези тепер можна було логувати дані в ELK для подальшого аналізу.

• 

  Автоматична розгортка застосунку за git push у гілку. Технічно продукт був вже готовим до такої задачі, і це суттєво скоротило час розробників.

• 

  Система моніторингу та сповіщень для технічних і продуктових метрик на базі Grafana та Prometheus.

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

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