Actual-time information streaming has turn into outstanding in at the moment’s world of instantaneous digital experiences. Fashionable software program as a service (SaaS) functions throughout all industries rely increasingly more on repeatedly generated information from completely different information sources similar to internet and cell functions, Web of Issues (IoT) gadgets, social media platforms, and ecommerce websites. Processing these information streams in actual time is vital to delivering responsive and personalised options, and maximizes the worth of information by processing it as near the occasion time as attainable.
AWS helps SaaS distributors by offering the constructing blocks wanted to implement a streaming software with Amazon Kinesis Knowledge Streams and Amazon Managed Streaming for Apache Kafka (Amazon MSK), and real-time processing functions with Amazon Managed Service for Apache Flink.
On this put up, we take a look at implementation patterns a SaaS vendor can undertake when utilizing a streaming platform as a way of integration between inside parts, the place streaming information shouldn’t be immediately uncovered to 3rd events. Specifically, we deal with Amazon MSK.
Streaming multi-tenancy patterns
When constructing streaming functions, it’s best to take the next dimensions under consideration:
- Knowledge partitioning – Occasion streaming and storage must be remoted on the acceptable stage, bodily or logical, based mostly on tenant possession
- Efficiency equity – The efficiency coupling of functions processing streaming information for various tenants should be managed and restricted
- Tenant isolation – A stable authorization technique must be put in place to ensure tenants can entry solely their information
Underpinning all interactions with a multi-tenant system is the idea of SaaS id. For extra data, discuss with SaaS Structure Fundamentals.
SaaS deployment fashions
Tenant isolation shouldn’t be non-compulsory for SaaS suppliers, and tenant isolation approaches will differ relying in your deployment mannequin. The mannequin is influenced by enterprise necessities, and the fashions will not be mutually unique. Commerce-offs should be weighed throughout particular person companies to realize a correct steadiness of isolation, complexity, and price. There isn’t a common answer, and a SaaS vendor must rigorously weigh their enterprise and buyer wants towards three isolation methods: silo, pool and bridge (or combos thereof).
Within the following sections, we discover these deployment fashions throughout information isolation, efficiency equity, and tenant isolation dimensions.
Silo mannequin
The silo mannequin represents the best stage of information segregation, but additionally the best working value. Having a devoted MSK cluster per tenant will increase the chance of overprovisioning and requires duplication of administration and monitoring tooling.
Having a devoted MSK cluster per tenant makes certain tenant information partitioning happens on the disk stage when utilizing an Amazon MSK Provisioned mannequin. Each Amazon MSK Provisioned and Serverless clusters assist server-side encryption at relaxation. Amazon MSK Provisioned additional permits you to use a buyer managed AWS Key Administration Service (AWS KMS) key (see Amazon MSK encryption).
In a silo mannequin, Kafka ACL and quotas shouldn’t be strictly required except your corporation necessities require them. Efficiency equity is assured as a result of solely a single tenant can be utilizing the sources of your entire MSK cluster and are devoted to functions producing and consuming occasions of a single tenant. This implies spikes of site visitors on a selected tenant can’t affect different tenants, and there’s no danger of cross-tenant information entry. As a downside, having a provisioned cluster per tenant requires a right-sizing train per tenant, with a better danger of overprovisioning than within the pool or bridge fashions.
You possibly can implement tenant isolation the MSK cluster stage with AWS Id and Entry Administration (IAM) insurance policies, creating per-cluster credentials, relying on the authentication scheme in use.
Pool mannequin
The pool mannequin is the only mannequin the place tenants share sources. A single MSK cluster is used for all tenants with information cut up into subjects based mostly on the occasion kind (for instance, all occasions associated to orders go to the subject orders), and all tenant’s occasions are despatched to the identical matter. The next diagram illustrates this structure.
This mannequin maximizes operational simplicity, however reduces the tenant isolation choices out there as a result of the SaaS supplier received’t have the ability to differentiate per-tenant operational parameters and all tasks of isolation are delegated to the functions producing and consuming information from Kafka. The pool mannequin additionally doesn’t present any mechanism of bodily information partitioning, nor efficiency equity. A SaaS supplier with these necessities ought to take into account both a bridge or silo mannequin. In the event you don’t have necessities to account for parameters similar to per-tenant encryption keys or tenant-specific information operations, a pool mannequin gives decreased complexity and could be a viable choice. Let’s dig deeper into the trade-offs.
A standard technique to implement shopper isolation is to establish the tenant inside every occasion utilizing a tenant ID. The choices out there with Kafka are passing the tenant ID both as occasion metadata (header) or a part of the payload itself as an express area. With this strategy, the tenant ID can be used as a standardized area throughout all functions inside each the message payload and the occasion header. This strategy can scale back the chance of semantic divergence when parts course of and ahead messages as a result of occasion headers are dealt with in a different way by completely different processing frameworks and may very well be stripped when forwarded. Conversely, the occasion physique is usually forwarded as a single object and no contained data is misplaced except the occasion is explicitly remodeled. Together with the tenant ID within the occasion header as nicely could simplify the implementation of companies permitting you to specify tenants that should be recovered or migrated with out requiring the supplier to deserialize the message payload to filter by tenant.
When specifying the tenant ID utilizing both a header or as a area within the occasion, shopper functions won’t be able to selectively subscribe to the occasions of a selected tenant. With Kafka, a shopper subscribes to a subject and receives all occasions despatched to that matter of all tenants. Solely after receiving an occasion will the buyer will have the ability to examine the tenant ID to filter the tenant of curiosity, making entry segregation just about unattainable. This implies delicate information should be encrypted to ensure a tenant can’t learn one other tenant’s information when viewing these occasions. In Kafka, server-side encryption can solely be set on the cluster stage, the place all tenants sharing a cluster will share the identical server-side encryption key.
In Kafka, information retention can solely be set on the subject. Within the pool mannequin, occasions belonging to all tenants are despatched to the identical matter, so tenant-specific operations like deleting all information for a tenant won’t be attainable. The immutable, append-only nature of Kafka solely permits a complete matter to be deleted, not selective occasions belonging to a selected tenant. If particular buyer information within the stream requires the proper to be forgotten, similar to for GDPR, a pool mannequin won’t work for that information and silo ought to be thought-about for that particular information stream.
Bridge mannequin
Within the bridge mannequin, a single Kafka cluster is used throughout all tenants, however occasions from completely different tenants are segregated into completely different subjects. With this mannequin, there’s a matter for every group of associated occasions per tenant. You possibly can simplify operations by adopting a subject naming conference similar to together with the tenant ID within the matter title. This can virtually create a namespace per tenant, and in addition permits completely different directors to handle completely different tenants, setting permissions with a prefix ACL, and avoiding naming clashes (for instance, occasions associated to orders for tenant 1 go to tenant1.orders and orders of tenant 2 go to tenant2.orders). The next diagram illustrates this structure.
With the bridge mannequin, server-side encryption utilizing a per-tenant key shouldn’t be attainable. Knowledge from completely different tenants is saved in the identical MSK cluster, and server-side encryption keys will be specified per cluster solely. For a similar motive, information segregation can solely be achieved at file stage, as a result of separate subjects are saved in separate information. Amazon MSK shops all subjects throughout the identical Amazon Elastic Block Retailer (Amazon EBS) quantity.
The bridge mannequin gives per-tenant customization, similar to retention coverage or max message dimension, as a result of Kafka permits you to set these parameters per matter. The bridge mannequin additionally simplifies segregating and decoupling occasion processing per tenant, permitting a stronger isolation between separate functions that course of information of separate tenants.
To summarize, the bridge mannequin gives the next capabilities:
- Tenant processing segregation – A shopper software can selectively subscribe to the subjects belonging to particular tenants and solely obtain occasions for these tenants. A SaaS supplier will have the ability to delete information for particular tenants, selectively deleting the subjects belonging to that tenant.
- Selective scaling of the processing – With Kafka, the utmost variety of parallel customers is decided by the variety of partitions of a subject, and the variety of partitions will be set per matter, and due to this fact per tenant.
- Efficiency equity – You possibly can implement efficiency equity utilizing Kafka quotas, supported by Amazon MSK, stopping the companies processing a very busy tenant to eat too many cluster sources, on the expense of different tenants. Seek advice from the next two-part collection for extra particulars on Kafka quotas in Amazon MSK, and an instance implementation for IAM authentication.
- Tenant isolation – You possibly can implement tenant isolation utilizing IAM entry management or Apache Kafka ACLs, relying on the authentication scheme that’s used with Amazon MSK. Each IAM and Kafka ACLs mean you can management entry per matter. You possibly can authorize an software to entry solely the subjects belonging to the tenant it’s alleged to course of.
Commerce-offs in a SaaS setting
Though every mannequin supplies completely different capabilities for information partitioning, efficiency equity, and tenant isolation, additionally they include completely different prices and complexities. Throughout planning, it’s vital to establish what trade-offs you’re keen to make for typical clients, and present a tier construction to your consumer subscriptions.
The next desk summarizes the supported capabilities of the three fashions in a streaming software.
| . | Pool | Bridge | Silo |
| Per-tenant encryption at relaxation | No | No | Sure |
| Can implement proper to be forgotten for single tenant | No | Sure | Sure |
| Per-tenant retention insurance policies | No | Sure | Sure |
| Per-tenant occasion dimension restrict | No | Sure | Sure |
| Per-tenant replayability | Sure (should implement with logic in customers) | Sure | Sure |
Anti-patterns
Within the bridge mannequin, we mentioned tenant segregation by matter. An alternate can be segregating by partition, the place all messages of a given kind are despatched to the identical matter (for instance, orders), however every tenant has a devoted partition. This strategy has many disadvantages and we strongly discourage it. In Kafka, partitions are the unit of horizontal scaling and balancing of brokers and customers. Assigning partitions per tenants can introduce unbalancing of the cluster, and operational and efficiency points that can be arduous to beat.
Some stage of information isolation, similar to per-tenant encryption keys, may very well be achieved utilizing client-side encryption, delegating any encryption or description to the producer and shopper functions. This strategy would mean you can use a separate encryption key per tenant. We don’t suggest this strategy as a result of it introduces a better stage of complexity in each the buyer and producer functions. It could additionally stop you from utilizing many of the commonplace programming libraries, Kafka tooling, and most Kafka ecosystem companies, like Kafka Join or MSK Join.
Conclusion
On this put up, we explored three patterns that SaaS distributors can use when architecting multi-tenant streaming functions with Amazon MSK: the pool, bridge, and silo fashions. Every mannequin presents completely different trade-offs between operational simplicity, tenant isolation stage, and price effectivity.
The silo mannequin dedicates full MSK clusters per tenant, providing an easy tenant isolation strategy however incurring a better upkeep and price per tenant. The pool mannequin gives elevated operational and cost-efficiencies by sharing all sources throughout tenants, however supplies restricted information partitioning, efficiency equity, and tenant isolation capabilities. Lastly, the bridge mannequin gives compromise between operational and cost-efficiencies whereas offering vary of choices to create sturdy tenant isolation and efficiency equity methods.
When architecting your multi-tenant streaming answer, rigorously consider your necessities round tenant isolation, information privateness, per-tenant customization, and efficiency ensures to find out the suitable mannequin. Mix fashions if wanted to search out the proper steadiness for your corporation. As you scale your software, reassess isolation wants and migrate throughout fashions accordingly.
As you’ve seen on this put up, there isn’t a one-size-fits-all sample for streaming information in a multi-tenant structure. Fastidiously weighing your streaming outcomes and buyer wants will assist decide the right trade-offs you can also make whereas ensuring your buyer information is safe and auditable. Proceed your studying journey on SkillBuilder with our SaaS curriculum, get hands-on with an AWS Serverless SaaS workshop or Amazon EKS SaaS workshop, or dive deep with Amazon MSK Labs.
In regards to the Authors
Emmanuele Levi is a Options Architect within the Enterprise Software program and SaaS staff, based mostly in London. Emanuele helps UK clients on their journey to refactor monolithic functions into trendy microservices SaaS architectures. Emanuele is principally considering event-driven patterns and designs, particularly when utilized to analytics and AI, the place he has experience within the fraud-detection trade.
Lorenzo Nicora is a Senior Streaming Resolution Architect serving to clients throughout EMEA. He has been constructing cloud-native, data-intensive programs for over 25 years, working throughout industries, in consultancies and product corporations. He has leveraged open-source applied sciences extensively and contributed to a number of tasks, together with Apache Flink.
Nicholas Tunney is a Senior Associate Options Architect for Worldwide Public Sector at AWS. He works with International SI companions to develop architectures on AWS for shoppers within the authorities, nonprofit healthcare, utility, and training sectors. He’s additionally a core member of the SaaS Technical Area Neighborhood the place he will get to satisfy shoppers from everywhere in the world who’re constructing SaaS on AWS.
