Actual-time information streaming has develop into outstanding in as we speak’s world of instantaneous digital experiences. Fashionable software program as a service (SaaS) purposes throughout all industries rely an increasing number of on repeatedly generated information from completely different information sources corresponding to net and cell purposes, Web of Issues (IoT) units, 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 doable.
AWS helps SaaS distributors by offering the constructing blocks wanted to implement a streaming software with Amazon Kinesis Information Streams and Amazon Managed Streaming for Apache Kafka (Amazon MSK), and real-time processing purposes with Amazon Managed Service for Apache Flink.
On this publish, we have a look at implementation patterns a SaaS vendor can undertake when utilizing a streaming platform as a method of integration between inside elements, the place streaming information just isn’t straight uncovered to 3rd events. Specifically, we concentrate on Amazon MSK.
Streaming multi-tenancy patterns
When constructing streaming purposes, you need to take the next dimensions into consideration:
- Information partitioning – Occasion streaming and storage must be remoted on the applicable stage, bodily or logical, primarily based on tenant possession
- Efficiency equity – The efficiency coupling of purposes processing streaming information for various tenants should be managed and restricted
- Tenant isolation – A strong authorization technique must be put in place to verify tenants can entry solely their information
Underpinning all interactions with a multi-tenant system is the idea of SaaS identification. For extra info, consult with SaaS Structure Fundamentals.
SaaS deployment fashions
Tenant isolation just isn’t 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 should not mutually unique. Commerce-offs should be weighed throughout particular person companies to attain a correct steadiness of isolation, complexity, and value. There isn’t any common resolution, and a SaaS vendor must rigorously weigh their enterprise and buyer wants in opposition to 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 in addition the best operating price. Having a devoted MSK cluster per tenant will increase the danger 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 help 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 just isn’t strictly required except your enterprise necessities require them. Efficiency equity is assured as a result of solely a single tenant shall be utilizing the assets of all the MSK cluster and are devoted to purposes producing and consuming occasions of a single tenant. This implies spikes of visitors on a particular tenant can’t affect different tenants, and there’s no danger of cross-tenant information entry. As a disadvantage, 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 Identification and Entry Administration (IAM) insurance policies, creating per-cluster credentials, relying on the authentication scheme in use.
Pool mannequin
The pool mannequin is the best mannequin the place tenants share assets. A single MSK cluster is used for all tenants with information cut up into matters primarily based on the occasion sort (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 accessible as a result of the SaaS supplier gained’t have the ability to differentiate per-tenant operational parameters and all tasks of isolation are delegated to the purposes 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. When you don’t have necessities to account for parameters corresponding to per-tenant encryption keys or tenant-specific information operations, a pool mannequin provides lowered complexity and is usually a viable possibility. Let’s dig deeper into the trade-offs.
A standard technique to implement shopper isolation is to determine the tenant inside every occasion utilizing a tenant ID. The choices accessible 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 method, the tenant ID shall be used as a standardized area throughout all purposes inside each the message payload and the occasion header. This method can cut back the danger of semantic divergence when elements course of and ahead messages as a result of occasion headers are dealt with in another way by completely different processing frameworks and might be stripped when forwarded. Conversely, the occasion physique is usually forwarded as a single object and no contained info is misplaced except the occasion is explicitly remodeled. Together with the tenant ID within the occasion header as properly might simplify the implementation of companies permitting you to specify tenants that have to 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 purposes won’t be able to selectively subscribe to the occasions of a particular 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 patron will have the ability to examine the tenant ID to filter the tenant of curiosity, making entry segregation just about inconceivable. This implies delicate information should be encrypted to verify 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 doable. The immutable, append-only nature of Kafka solely permits a whole matter to be deleted, not selective occasions belonging to a particular tenant. If particular buyer information within the stream requires the correct to be forgotten, corresponding to for GDPR, a pool mannequin won’t work for that information and silo needs 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 matters. 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 corresponding to together with the tenant ID within the matter title. This can virtually create a namespace per tenant, and likewise 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 just isn’t doable. Information from completely different tenants is saved in the identical MSK cluster, and server-side encryption keys may be specified per cluster solely. For a similar cause, information segregation can solely be achieved at file stage, as a result of separate matters are saved in separate recordsdata. Amazon MSK shops all matters throughout the similar Amazon Elastic Block Retailer (Amazon EBS) quantity.
The bridge mannequin provides per-tenant customization, corresponding 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 purposes that course of information of separate tenants.
To summarize, the bridge mannequin provides the next capabilities:
- Tenant processing segregation – A shopper software can selectively subscribe to the matters 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 matters belonging to that tenant.
- Selective scaling of the processing – With Kafka, the utmost variety of parallel customers is set by the variety of partitions of a subject, and the variety of partitions may be set per matter, and subsequently 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 devour too many cluster assets, on the expense of different tenants. Seek advice from the next two-part sequence 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 matters belonging to the tenant it’s speculated to course of.
Commerce-offs in a SaaS setting
Though every mannequin supplies completely different capabilities for information partitioning, efficiency equity, and tenant isolation, in addition they include completely different prices and complexities. Throughout planning, it’s necessary to determine what trade-offs you’re keen to make for typical clients, and supply a tier construction to your shopper 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. Another could be segregating by partition, the place all messages of a given sort are despatched to the identical matter (for instance, orders), however every tenant has a devoted partition. This method 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 shall be exhausting to beat.
Some stage of information isolation, corresponding to per-tenant encryption keys, might be achieved utilizing client-side encryption, delegating any encryption or description to the producer and shopper purposes. This method would mean you can use a separate encryption key per tenant. We don’t advocate this method as a result of it introduces a better stage of complexity in each the patron and producer purposes. It might additionally stop you from utilizing many of the normal programming libraries, Kafka tooling, and most Kafka ecosystem companies, like Kafka Join or MSK Join.
Conclusion
On this publish, we explored three patterns that SaaS distributors can use when architecting multi-tenant streaming purposes with Amazon MSK: the pool, bridge, and silo fashions. Every mannequin presents completely different trade-offs between operational simplicity, tenant isolation stage, and value effectivity.
The silo mannequin dedicates full MSK clusters per tenant, providing an easy tenant isolation method however incurring a better upkeep and value per tenant. The pool mannequin provides elevated operational and cost-efficiencies by sharing all assets throughout tenants, however supplies restricted information partitioning, efficiency equity, and tenant isolation capabilities. Lastly, the bridge mannequin provides a great compromise between operational and cost-efficiencies whereas offering a great vary of choices to create sturdy tenant isolation and efficiency equity methods.
When architecting your multi-tenant streaming resolution, 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 seek out the correct steadiness for your enterprise. As you scale your software, reassess isolation wants and migrate throughout fashions accordingly.
As you’ve seen on this publish, there isn’t a one-size-fits-all sample for streaming information in a multi-tenant structure. Rigorously weighing your streaming outcomes and buyer wants will assist decide the proper trade-offs you may 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 group, primarily based in London. Emanuele helps UK clients on their journey to refactor monolithic purposes into trendy microservices SaaS architectures. Emanuele is especially enthusiastic about 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 Answer 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 initiatives, together with Apache Flink.
Nicholas Tunney is a Senior Accomplice 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 Discipline Group the place he will get to satisfy shoppers from everywhere in the world who’re constructing SaaS on AWS.
