Багатоклієнтська SaaS-архітектура з NestJS: практичний посібник для надійної експлуатації

Багатоклієнтність — це модель довіри, яка впливає на кожен шлях виконання в SaaS-продукті. Самого ідентифікатора клієнтської організації в одній таблиці бази даних недостатньо. Клієнтський контекст потрібно отримувати на довіреній межі й зберігати в запитах HTTP і GraphQL, з’єднаннях WebSocket, чергах, планових завданнях, кешах, файлах, пошуку, аналітиці, журналах, розрахунках, експорті, засобах підтримки, резервних копіях і процедурах відновлення. Варто пропустити лише один шлях — і система може відкрити дані іншого клієнта або застосувати хибне комерційне правило.

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

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

Обирайте модель багатоклієнтності відповідно до вимог ізоляції та експлуатації

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

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

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

Спільне, розподілене чи ізольоване зберігання даних

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

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

Перевіряйте ізоляцію як незмінну властивість системи. Створюйте записи з однаковими ідентифікаторами для різних клієнтів; перевіряйте читання, зміну, видалення, агрегування, пошук, поділ на сторінки, зв’язки, кеші, фонові завдання, експорт, журнали та адміністративні операції; окремо випробовуйте відмову в доступі й одночасне виконання. Для резервних копій проводьте реальне відновлення та звіряння даних на обіцяній межі. Індивідуальне розроблення на NestJS допоможе перетворити обрану модель на послідовні етапи впровадження й міграції з чіткими межами.

Створюйте клієнтський контекст на довіреній межі

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

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

На кожній межі контекст потрібно встановлювати заново. Повідомлення в черзі й планові завдання мають містити довірене або підписане посилання на клієнта та незмінні ідентифікатори господарської операції; обробники перевіряють їх і не успадковують неявний стан HTTP-запиту. З’єднання WebSocket повторно перевіряють членство після зміни сеансу чи ролей. Журнали, трасування, метрики, ключі кешу, шляхи до файлів, пошукові індекси та вихідні запити мають безпечно позначатися клієнтською організацією, не розкриваючи чутливих значень.

Розділяйте автентифікацію та перевірку прав у межах організації

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

Тримайте правила доступу поруч із предметними операціями. Захисні компоненти NestJS можуть відхилити неавтентифікований запит і встановити загальні вимоги для маршруту. Однак перевірка прав на конкретний ресурс часто потребує вже завантаженого стану, тому її місце — у службі правил доступу або обробнику команди. Початковим рішенням має бути відмова в доступі. Не розкидайте рядкові назви ролей по коду й не обмежуйте перевірки контролерами: фонові завдання, обробники GraphQL, внутрішні виклики або нові протоколи можуть їх оминути.

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

Зробіть ізоляцію даних стандартним шляхом

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

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

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

Передавайте відомості про клієнта до фонових завдань, тарифікації та налаштувань

Фонові завдання — це операції клієнта, що виконуються без HTTP-запиту. Передавайте до черги посилання на клієнтську організацію, незмінний ідентифікатор операції, відомості про виконавця або системну мету та дані повідомлення з явно зазначеною версією; під час отримання перевіряйте контекст; робіть наслідки повторного виконання безпечними; обмежуйте повторні спроби; відокремлюйте повідомлення, які не вдалося обробити; зберігайте зв’язок між етапами операції. Справедливе планування, обмеження паралельності для кожного клієнта, квоти та регулювання навантаження не дадуть імпорту чи звіту одного клієнта позбавити ресурсів усю платформу.

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

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

Масштабуйте роботу з клієнтами, а не лише оброблення запитів

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

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

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

Коли допоможуть зовнішні архітектори та додаткові інженерні ресурси

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

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

• Оберіть межу довіри: визначте клієнтську організацію, модель членства, регуляторну й договірну ізоляцію, індивідуальні налаштування, стійкість до надмірного навантаження одного клієнта, відновлення, видалення, регіон зберігання, розподіл найбільших клієнтів і відповідального за експлуатацію.
• Спроєктуйте належність даних: оберіть спільне, розподілене, ізольоване або змішане зберігання; узгодьте з цією межею ключі, обмеження, індекси, сховища, резервні копії, міграції та звіряння.
• Створіть довірений контекст: отримуйте ідентифікатор організації з перевіреного домену, токена, облікових даних або членства; створюйте незмінний контекст і повторно перевіряйте його в чергах, завданнях, з’єднаннях та інтеграціях.
• Перевіряйте право на ресурс і дію: на сервері перевіряйте членство, роль чи ознаки, доступні можливості, належність ресурсу, його поточний стан і привілеї підтримки; за відсутності явного дозволу відмовляйте в доступі та фіксуйте використання підвищених привілеїв.
• Перевіряйте ізоляцію наскрізно: охопіть однакові ідентифікатори, запити, зв’язки, кеші, файли, пошук, аналітику, журнали, фонові завдання, експорт, адміністрування, одночасне виконання, відновлення, видалення та локалізацію інциденту.
• Керуйте всією сукупністю екземплярів: контролюйте фонові завдання, права за тарифом, платіжні розрахунки, налаштування, квоти, версії схем, поетапні випуски, телеметрію, цільові показники сервісу, відновлення, потужність, вартість і переміщення між рівнями ізоляції.