Run the Structured Field Encryption Benchmark

This page reproduces the Structured Field Encryption Benchmark with the Aklivity fork of the OpenMessaging Benchmark (OMB) on AWS. The run sends the same record, encoded as JSON, Avro, and Protobuf, through Zilla Plus, which encrypts only the sensitive field and leaves the rest readable.

Provision the Environment

Clone and build the OMB fork:

git clone https://github.com/aklivity/openmessaging-benchmark.git
cd openmessaging-benchmark
mvn clean install -Dlicense.skip=true

Follow the prerequisites and Terraform steps in the deployment README with the 2cku setup. It provisions 3 Zilla Plus instances, 6 benchmark clients, 6 Kafka brokers, 3 controllers, and 1 Prometheus instance, all on m5.xlarge.

The deployment's templates/zilla.yaml runs one Zilla Plus listener per record format. Each client connects over TLS with SASL_SSL.

Format	Scenario	Port	Namespace in `templates/zilla.yaml`	Payload
JSON	`zpak-structured-field-encrypt`	`9096`	`apache-kafka-structured-field-encrypt`	`payload/payload-1Kb-event.json`
Avro	`zpak-structured-field-encrypt-avro`	`9097`	`apache-kafka-structured-field-encrypt-avro`	`payload/payload-1Kb-event.avro`
Protobuf	`zpak-structured-field-encrypt-protobuf`	`9098`	`apache-kafka-structured-field-encrypt-protobuf`	`payload/payload-1Kb-event.protobuf`

The Record

Every format carries the same record, with one field encrypted:

Field	Type	Encrypted
`id`	string, 36 chars	No
`status`	string, `ACTIVE`	No
`ssn`	string, `123-45-6789`	Yes
`notes`	string, 930 chars	No

JSON and Avro select the sensitive field by the x-kind annotation in the schema:

select:
  - type: structure
    fields:
      - tagged:
          - x-kind: pii-encrypt

Protobuf schemas have no annotations, so Protobuf selects the field by name. The policy then lives in the Zilla Plus configuration rather than the schema, and a renamed field is no longer encrypted:

select:
  - type: structure
    fields:
      - named:
          - ssn

The Protobuf catalog entry sets record: Event. Avro infers the record.
Avro and Protobuf set disclosure: action: redact. The default omits the field, which an Avro record allows only when the field is nullable.

Run the Workloads

From the OMB root directory, load your SSH key and generate the workloads:

eval $(ssh-agent)
ssh-add ~/.ssh/omb
./confluent-bin/create-blog-workloads.sh

Each format has its own workload, sized to its encoded record:

Workload	Record size	Format
`confluent-blog-workloads-2cku-1p-1c-1Kb-45topic-200part-24MBps.yaml`	1,024 B	JSON
`confluent-blog-workloads-2cku-1p-1c-1Kb-45topic-200part-24MBps-avro.yaml`	988 B	Avro
`confluent-blog-workloads-2cku-1p-1c-1Kb-45topic-200part-24MBps-protobuf.yaml`	992 B	Protobuf

Every workload uses 45 topics with 200 partitions each, 1 producer and 3 consumer groups per topic, and 24,576 msg/s, with a 30-minute warm-up and a 60-minute measurement. With 3 consumer groups, the consume rate settles at three times the publish rate.

Run each format in turn:

./confluent-bin/run-workloads.sh zpak-structured-field-encrypt workloads/confluent-blog-workloads-2cku-1p-1c-1Kb-45topic-200part-24MBps.yaml
./confluent-bin/run-workloads.sh zpak-structured-field-encrypt-avro workloads/confluent-blog-workloads-2cku-1p-1c-1Kb-45topic-200part-24MBps-avro.yaml
./confluent-bin/run-workloads.sh zpak-structured-field-encrypt-protobuf workloads/confluent-blog-workloads-2cku-1p-1c-1Kb-45topic-200part-24MBps-protobuf.yaml

Chart the Results

When a run completes, OMB writes output.txt to the results/ directory. Generate publish and end-to-end latency charts from it:

python3 ./bin/create_charts.py results/<your-result-folder>/output.txt

Tear Down

From the deployment directory, destroy the AWS resources:

cd driver-kafka/deploy/aklivity-deployment
terraform destroy