From f126b8829e1b47d2ede0a7dd95cd86c32888a41f Mon Sep 17 00:00:00 2001 From: Axel Uhl Date: Wed, 10 Aug 2022 18:58:33 +0200 Subject: [PATCH] bug5627: added AwsShard interface --- .../com/sap/sse/landscape/aws/AwsShard.java | 28 +++++++++++++++++++ .../sap/sse/landscape/application/Shard.java | 20 +++++++++---- 2 files changed, 43 insertions(+), 5 deletions(-) create mode 100644 java/com.sap.sse.landscape.aws/src/com/sap/sse/landscape/aws/AwsShard.java diff --git a/java/com.sap.sse.landscape.aws/src/com/sap/sse/landscape/aws/AwsShard.java b/java/com.sap.sse.landscape.aws/src/com/sap/sse/landscape/aws/AwsShard.java new file mode 100644 index 00000000000..fb36ce10f15 --- /dev/null +++ b/java/com.sap.sse.landscape.aws/src/com/sap/sse/landscape/aws/AwsShard.java @@ -0,0 +1,28 @@ +package com.sap.sse.landscape.aws; + +import com.sap.sse.landscape.application.Shard; + +/** + * A shard is represented by a target group that has its own auto-scaling group and which handles a number of sharding + * keys. + *

+ * + * Technically, the shard's name is represented as a tag value on the {@link #getTargetGroup() target group}, hence the + * restrictions for AWS tag values apply. + *

+ * + * Routing to shards happens at the {@link #getTargetGroup() target group's} {@link TargetGroup#getLoadBalancer() load + * balancer}, or more precisely, through the load balancer's HTTPS listener's rule set. Each shard requires a number of rule pairs + * of which one rule forwardsrequests based on an HTTP header field requiring the request to be handled by a replica, + * and the other one based on the request using the GET request method. Another rule pair is required per three sharding keys + * to be handled, due to the restriction on the number of conditions a rule may have. + * + * @author Axel Uhl (d043530) + * + * @param + */ +public interface AwsShard extends Shard { + TargetGroup getTargetGroup(); + + AwsAutoScalingGroup getAutoScalingGroup(); +} diff --git a/java/com.sap.sse.landscape/src/com/sap/sse/landscape/application/Shard.java b/java/com.sap.sse.landscape/src/com/sap/sse/landscape/application/Shard.java index f35fe0f261e..19a89f57580 100755 --- a/java/com.sap.sse.landscape/src/com/sap/sse/landscape/application/Shard.java +++ b/java/com.sap.sse.landscape/src/com/sap/sse/landscape/application/Shard.java @@ -1,17 +1,27 @@ package com.sap.sse.landscape.application; +import com.sap.sse.common.Named; + /** * Part of a {@link Scope}. A {@link Shard} cannot be moved in isolation and can hence not move across {@link Scope}s. * Sharding can be used to optionally split {@link ApplicationProcess}es in groups, each of which being responsible * primarily only for a subset of the {@link Shard}s available in the {@link ApplicationReplicaSet}. While we assume * that all {@link ApplicationProcess}es in an {@link ApplicationReplicaSet} can handle requests for all - * {@link Shard}s managed by the replica set, it may be beneficial performance-wise to have individual processes - * focus only on a subset of {@link Shard}s. This may, e.g., result in better cache utilization and hence less CPU - * consumption on the hosts running those processes. + * {@link Shard}s managed by the replica set, it may be beneficial performance-wise to have individual processes focus + * only on a subset of {@link Shard}s. This may, e.g., result in better cache utilization and hence less CPU consumption + * on the hosts running those processes. + *

+ * + * There may be restrictions for the {@link Named#getName() name} that a shard can have, for example it could be + * possible that shard names with quotes or bracked in them are not permitted; the name is expected to be human-readable + * and meaningful. * * @author Axel Uhl (D043530) * */ -public interface Shard { - ShardingKey getKey(); +public interface Shard extends Named { + /** + * @return the keys handled by this shard + */ + Iterable getKeys(); }