Стварэнне прыкладання SaaS з некалькімі арэндамі: поўнае кіраўніцтва для распрацоўшчыкаў і заснавальнікаў

Рэвалюцыя некалькіх арандатараў: чаму гэта па змаўчанні для сучаснага SaaS

Стварэнне прыкладання SaaS раней азначала стварэнне асобных асобнікаў для кожнага кліента — мадэль, якая хутка становіцца няўстойлівай па меры маштабавання. Сёння шматарандатарская архітэктура стала залатым стандартам: больш за 85% новых платформаў SaaS выкарыстоўваюць гэты падыход. Мультыарэнда дазваляе аднаму асобніку прыкладання абслугоўваць некалькі кліентаў (арандатараў), захоўваючы пры гэтым іх дадзеныя ізалявана і ў бяспецы. Гэта не проста тэхнічнае рашэнне; гэта бізнес-імператыў, які непасрэдна ўплывае на вашы эксплуатацыйныя выдаткі, маштабаванасць і здольнасць хутка ітэраваць.

Падумайце пра матэматыку: падтрыманне асобнай інфраструктуры для кожнага кліента можа каштаваць вам 200 долараў у месяц на кожнага арандатара. Са 100 кліентамі гэта складае 20 000 долараў штомесяц толькі ў базавай інфраструктуры. Добра пабудаваная сістэма з некалькімі арэндамі, якая абслугоўвае тых жа 100 кліентаў, можа каштаваць менш за 2000 долараў, што дазваляе зэканоміць 90% толькі на інфраструктуры. Такая эфектыўнасць азначае канкурэнтаздольныя цэны, больш хуткае разгортванне функцый і, у канчатковым рахунку, лепшую эканомію адзінкі, што можа зрабіць ваш SaaS-бізнес або разбурыць яго.

Разуменне мультыарэнды: больш, чым проста агульная інфраструктура

Па сутнасці, мультыарэнда звязана з сумесным выкарыстаннем рэсурсаў, але яна рэалізуецца на розных узроўнях з рознай ступенню ізаляцыі. Самая асноўная форма падзяляе інфраструктуру, але падтрымлівае асобныя прыкладанні, у той час як пашыраныя рэалізацыі падзяляюць усё, ад баз даных да кода прыкладання. Салодкае месца для большасці кампаній SaaS заключаецца ў збалансаванай мультыарэндзе, дзе вы абагульваеце логіку прыкладанняў і інфраструктуру пры захаванні строгага падзелу даных.

Тры ўзроўні ўкаранення некалькіх арэндаў

Ізаляцыя на ўзроўні базы даных забяспечвае найвышэйшую бяспеку, але найменшую эфектыўнасць. Кожны арандатар атрымлівае ўласную базу дадзеных, што азначае адсутнасць рызыкі ўцечкі даных, але больш высокія аперацыйныя выдаткі. Гэты падыход добра працуе для карпаратыўных кліентаў са строгімі патрабаваннямі адпаведнасці, але становіцца грувасткім у маштабе.

Ізаляцыя на ўзроўні схемы забяспечвае баланс дзякуючы выкарыстанню агульнай інфраструктуры базы дадзеных, але асобных схем для кожнага арандатара. Гэта зніжае выдаткі пры захаванні моцнага падзелу даных. Аднак аперацыі з базамі дадзеных, такія як рэзервовае капіраванне і перанос, становяцца больш складанымі па меры росту колькасці арандатараў.

Ізаляцыя на ўзроўні радкоў (найбольш распаўсюджаны падыход) выкарыстоўвае адзіную схему базы дадзеных са слупком tenant_id у кожнай табліцы. Гэта дазваляе максімальна выкарыстоўваць рэсурсы і спрашчае працу, але патрабуе пільнай увагі, каб гарантаваць, што запыты ніколі выпадкова не вяртаюць даныя ад няправільнага арандатара.

Стварэнне вашай шматкватэрнай асновы

Вашы архітэктурныя рашэнні ў першыя 30 дзён будуць вызначаць вашу маштабаванасць на наступныя 3 гады. Аснова пачынаецца з таго, як вы вызначаеце і накіроўваеце арандатараў. Большасць сучасных прыкладанняў SaaS выкарыстоўваюць субдамены (tenant.yourapp.com) або маршрутызацыю на аснове шляху (yourapp.com/tenant/), каб накіроўваць запыты ў адпаведны кантэкст арандатара.

Аўтэнтыфікацыя і аўтарызацыя складаюць аснову бяспекі арандатараў. Укараніце надзейную сістэму, якая правярае ідэнтыфікацыю карыстальніка і сяброўства арандатара перад прадастаўленнем доступу да любых рэсурсаў. Вэб-токены JSON (JWT) з убудаваным кантэкстам арандатара сталі стандартам для аўтэнтыфікацыі без захавання стану ў сістэмах з некалькімі арэндамі.

<цытата> «Самае распаўсюджанае парушэнне бяспекі некалькіх арандатараў адбываецца не ад хакераў, а ад таго, што распрацоўшчыкі забываюцца ўключыць tenant_id у пункт WHERE. Убудуйце кантэкст арандатара непасрэдна ў ўзровень доступу да даных з першага дня».

Дызайн ўзроўню даных заслугоўвае асаблівай увагі. Для ізаляцыі на ўзроўні радка разгледзьце магчымасць выкарыстання інфраструктур базы дадзеных, якія аўтаматычна ахопліваюць запыты па tenant_id. Такія інструменты, як Django з django-tenant-schemas або Ruby on Rails з apartment gem, могуць забяспечыць ізаляцыю арандатара на ўзроўні ORM, зніжаючы рызыку чалавечай памылкі.

Крок за крокам: Стварэнне вашага MVP SaaS з некалькімі арэндамі

Крок 1: Вызначце сваю мадэль арандатара
Пачніце з вызначэння таго, што з'яўляецца арандатарам у вашай сістэме. Для B2B SaaS гэта звычайна арганізацыя з некалькімі карыстальнікамі. Стварыце табліцу арандатараў з важнымі дэталямі арганізацыі і параметрамі канфігурацыі.

Крок 2: Укараніце ідэнтыфікацыю арандатара
Стварыце прамежкавае праграмнае забеспячэнне, якое ідэнтыфікуе арандатара па кожным запыце — праз субдамен, карыстальніцкі дамен або ключ API. Захоўвайце гэты кантэкст арандатара ў загалоўках запытаў або ў лакальным сховішчы патоку для лёгкага доступу на працягу ўсяго жыццёвага цыкла запыту.

Крок 3: Абараніце доступ да даных
Змяніце ўсе табліцы базы дадзеных, каб уключыць слупок tenant_id. Стварыце класы базавай мадэлі, якія аўтаматычна фільтруюць запыты па ідэнтыфікатары бягучага арандатара. Праверце гэта шырока, каб пераканацца, што ніякія запыты не могуць абмінуць ахоп арандатара.

Крок 4: Стварыце адаптацыю арандатара
Стварыце бесперашкодны паток рэгістрацыі, які прапануе новых арандатараў. Гэта ўключае ў сябе стварэнне запісу арандатара, наладжванне канфігурацый па змаўчанні і правядзенне карыстальнікаў праз пачатковую наладу. Аўтаматызацыя тут прыносіць дывідэнды па меры маштабавання.

Крок 5: Укараніце адсочванне выкарыстання
З першага дня адсочвайце ключавыя паказчыкі для арандатара: актыўныя карыстальнікі, выклікі API, выкарыстанае сховішча і г.д. Гэтыя даныя будуць мець вырашальнае значэнне для выстаўлення рахункаў, падтрымкі і разумення таго, як розныя арандатары выкарыстоўваюць вашу праграму.

Стратэгіі ізаляцыі даных: выбар вашага падыходу

Ваша стратэгія ізаляцыі даных паўплывае на ўсё: ад прадукцыйнасці да адпаведнасці. Давайце падрабязна разгледзім тры асноўныя падыходы:

• Асобныя базы даных: максімальная ізаляцыя, самае простае рэзервовае капіраванне, але самы высокі кошт. Ідэальна падыходзіць для прадпрыемстваў са строгімі патрабаваннямі да суверэнітэту даных.
• Асобныя схемы: добры баланс ізаляцыі і эфектыўнасці. Даныя арандатара лагічна падзелены, але маюць агульныя рэсурсы базы дадзеных.
• Агульная схема з бяспекай на ўзроўні радкоў: найбольш эфектыўнае выкарыстанне рэсурсаў, але патрабуе ўважлівага ўкаранення. Сучасныя базы дадзеных, такія як PostgreSQL, прапануюць функцыі бяспекі на ўзроўні радкоў, якія могуць дапамагчы забяспечыць ізаляцыю.

Большасць стартапаў SaaS пачынаюць з падыходу агульнай схемы з-за яго эканамічнай эфектыўнасці і прастаты. Па меры росту і прыцягнення буйных карпаратыўных кліентаў вы можаце прапанаваць спецыялізаваныя варыянты баз дадзеных у якасці прэміум-ўзроўню, ператвараючы тэхнічныя абмежаванні ў магчымасць атрымання прыбытку.

Праблемы маштабавання і рашэнні

Мультыарандацкія сістэмы сутыкаюцца з унікальнымі праблемамі маштабавання. Праблема "шумнага суседа" - калі інтэнсіўнае выкарыстанне аднаго арандатара ўплывае на іншых - можа пагоршыць прадукцыйнасць для ўсіх карыстальнікаў. Укараняйце абмежаванне рэсурсаў і маніторынг для выяўлення і ліквідацыі праблем з прадукцыйнасцю, перш чым яны паўплываюць на ўсю вашу базу карыстальнікаў.

Прадукцыйнасць базы даных часта становіцца асноўным вузкім месцам. Разгледзьце наступныя стратэгіі:

1. Укараніць рэплікі чытання для размеркавання нагрузкі на запыт
2. Выкарыстоўвайце пул злучэнняў для эфектыўнага кіравання злучэннямі да базы дадзеных
3. Дадайце ўзроўні кэшавання (Redis, Memcached), каб паменшыць нагрузку на базу дадзеных
4. Разгледзьце стратэгіі шардынга, калі адзінкавыя асобнікі базы дадзеных не могуць справіцца з нагрузкай

Паколькі ваша колькасць арандатараў вырасце да тысяч, вам спатрэбіцца складаны маніторынг для адсочвання спраўнасці сістэмы для кожнага арандатара. Укараніць папярэджанне, якое спрацоўвае, калі пэўныя арандатары адчуваюць пагаршэнне прадукцыйнасці або незвычайныя мадэлі выкарыстання.

Бяспека: прыярытэт, які не падлягае абмеркаванню

У сістэмах з некалькімі арэндамі парушэнне бяспекі, якое закранае аднаго арандатара, можа падарваць давер ва ўсёй вашай кліенцкай базе. Акрамя асноўнай ізаляцыі арандатараў, якую мы абмяркоўвалі, разгледзьце наступныя важныя меры бяспекі:

Бяспека API: пераканайцеся, што ўсе канчатковыя кропкі API правяраюць кантэкст арандатара. Укараніць абмежаванне ставак для арандатара, каб прадухіліць злоўжыванні. Выкарыстоўвайце шлюзы API, якія могуць паслядоўна выконваць палітыку бяспекі ў вашых мікрасэрвісах.

Шыфраванне даных шыфруе канфідэнцыяльныя даныя ў стане спакою і перадачы. Разгледзьце магчымасць шыфравання на ўзроўні поля для асабліва канфідэнцыяльнай інфармацыі, напрыклад плацежных дэталяў або асабістых ідэнтыфікатараў.

Вядзенне журнала аўдыту: Вядзе поўныя журналы доступу і мадыфікацый даных з тэгамі кантэксту арандатара і карыстальніка. Гэта дапамагае не толькі ў расследаванні бяспекі, але і ў адпаведнасці з правіламі, такімі як GDPR і SOC 2.

Цэны і ўпакоўка для поспеху некалькіх арандатараў

Ваша архітэктура павінна дазваляць гібкія стратэгіі цэнаўтварэння. Падумайце аб укараненні сцяжкоў функцый на ўзроўні арандатара, што дазволіць вам лёгка ўключаць або адключаць функцыянальнасць на аснове ўзроўню падпіскі. Адсочвайце паказчыкі выкарыстання, якія адпавядаюць вашай мадэлі цэнаўтварэння — незалежна ад таго, ці гэта за карыстальніка, за выклік API або на аснове спажывання.

Самыя паспяховыя прадукты SaaS прапануюць дакладныя шляхі абнаўлення. Распрацуйце сістэму канфігурацыі арандатара, каб кліенты маглі лёгка перамяшчацца паміж узроўнямі без пераносу даных і прастою. Гэта можа ўключаць:

• Узроўні на аснове функцый (Basic, Pro, Enterprise)
• Цэнаўтварэнне на аснове выкарыстання з мяккімі абмежаваннямі
• Гібрыдныя мадэлі, якія спалучаюць цэны на аснове месцаў і выкарыстання

Разгортванне і DevOps.

Разгортванне абнаўленняў у асяроддзі з некалькімі арэндамі патрабуе ўважлівага планавання. Вы не можаце дазволіць сабе прастоі, якія закранаюць усіх кліентаў адначасова. Укараняйце сіне-зялёныя разгортванні або выпускі Canary, каб мінімізаваць рызыку. Выкарыстоўвайце сцяжкі функцый, каб паступова разгарнуць змены і хутка адкаціцца, калі ўзнікнуць праблемы.

Ваш канвеер CI/CD павінен уключаць тэсціраванне з улікам кліентаў. Стварыце наборы тэстаў, якія правяраюць функцыянальнасць розных канфігурацый арандатараў і аб'ёмаў даных. Падумайце над тым, каб падтрымліваць прамежкавае асяроддзе, якое адлюстроўвае разнастайнасць арандатараў вашай вытворчасці.

Будучыня шматкарыстальніцкай архітэктуры

Па меры таго, як SaaS працягвае развівацца, мы бачым новыя мадэлі, якія абапіраюцца на традыцыйную архітэктуру з некалькімі арэндамі. Бессерверныя вылічэнні прапануюць новыя магчымасці для ізаляцыі і маштабавання, прычым кожны арандатар можа працаваць у ізаляваных асяроддзях выканання. Гранічныя вылічэнні набліжаюць логіку прыкладання да карыстальнікаў, памяншаючы затрымку, але ўскладняючы маршрутызацыю арандатараў.

Самыя дальнабачныя платформы SaaS з самага пачатку ўбудоўваюць гнуткасць у сваю архітэктуру. Яны падтрымліваюць гібрыдныя мадэлі разгортвання, прапаноўваючы шматарэнду ў воблаку для большасці кліентаў, адначасова размяшчаючы лакальныя або спецыяльныя інстансы для прадпрыемстваў з асаблівымі патрабаваннямі. Такі падыход максімальна пашырае ваш адрасны рынак, захоўваючы пры гэтым перавагі эфектыўнасці мультыарэнды для большасці вашых кліентаў.

Стварэнне мультыарандацкага прыкладання SaaS з'яўляецца і тэхнічнай праблемай, і бізнес-стратэгіяй. Рашэнні, якія вы прымаеце на ранняй стадыі, будуць адбівацца на траекторыі росту вашай кампаніі. Засяродзіўшы ўвагу на трывалай архітэктуры, строгай бяспецы і маштабуемых шаблонах, вы не проста ствараеце праграмнае забеспячэнне — вы ствараеце аснову для ўстойлівага бізнесу SaaS, які можа канкураваць і перамагаць на сучасным перапоўненым рынку.

Часта задаюць пытанні

У чым розніца паміж аднаарэндацкім і мультыарандацкім SaaS?

Адзін-арандатар забяспечвае выдзеленую інфраструктуру для кожнага кліента, а мульты-арандатар абагульвае рэсурсы паміж кліентамі з ізаляцыяй даных. Мультыарандатар больш рэнтабельны і лягчэй падтрымліваць у маштабе.

Як забяспечыць бяспеку даных у шматарэндацкім дадатку?

Укараняйце строгую ізаляцыю арандатара на ўзроўні базы дадзеных, выкарыстоўвайце аўтэнтыфікацыю з улікам арандатара, шыфруйце канфідэнцыяльныя даныя і вядзіце поўныя журналы аўдыту. Заўсёды ўключайце фільтрацыю tenant_id у запыты да базы дадзеных.

Які дызайн базы дадзеных лепш за ўсё падыходзіць для мультыарандацкага SaaS?

Для большасці стартапаў агульная база дадзеных з ізаляцыяй на ўзроўні радка (слупок tenant_id) прапануе найлепшы баланс эфектыўнасці і прастаты. Па меры пашырэння вы можаце прапанаваць спецыяльныя базы даных у якасці прэміум-варыянту.

Як апрацоўваць спецыфічныя налады арандатара?

Выкарыстоўвайце сцягі функцый і табліцы канфігурацыі на ўзроўні арандатара. Падтрымлівайце асноўную кодавую базу, дазваляючы спецыфічную функцыянальнасць арандатара праз наладжвальныя модулі і налады.

Якія самыя вялікія праблемы пры маштабаванні шматарэндацкай праграмы?

Асноўныя праблемы - прадухіленне праблем з прадукцыйнасцю "шумных суседзяў", кіраванне маштабаванасцю базы дадзеных і падтрыманне бяспекі па меры росту колькасці арандатараў. Укараніце абмежаванне рэсурсаў, кэшаванне і маніторынг, каб вырашыць гэтыя праблемы.