Problem

JDK serialisation used by security plugin to serialize and deserialize various headers is slow.

Proposal

This is a proposal to change the implementation of Base64Helper::serializeObject and Base64Helper::deserializeObject to use a faster serialization protocol. I explored Fast Serialization, Protostuff, Kryo, Avro, and OpenSearch's Custom Serialization as alternatives to JDK serialization and ran a few benchmarks. Results are attached below.

Benchmarking Environment
Framework used - JMH, 1000 warm-up iterations, 30000 test iterations
EC2 InstanceType - c5.2xlarge
JDK - Corretto JDK 11
OS - Amazon Linux 2 x86_64

• Though FST is highly performant, simplest to use amongst all, it comes with its own shortcomings. FST no longer seems to be actively maintained with last commit made 2yrs ago and 102 open issues, history of breaking changes even with minor version upgrades.
• Protostuff too is highly performant, but will need explicit handling for certain classes such as InetSocketAddress by writing Delegates. Protostuff too doesn't seem to be actively maintained, last commit was 1yr ago.
• Kryo does not work out of the box. Kryo does not work with classes with no zero-arg constructors. We'll have to write serializers. Discovered that for complex objects for eg. java.util.Collections$SynchronizedMap we'll have to register separate serializers. There's a repo kryo-serializers that has many such serializers that we can use. Given we already have highly optimised custom serialization framework (StreamOutput, StreamInput) within OpenSearch, expending effort to integrate with another library seems unnecessary.
• Custom serialization using OpenSearch's BytesStreamOutput and BytesStreamInput classes is a promising approach. It too is highly performant. For the classes that are defined within security plugin such as User, SourceFieldsContext - Writeable interface can be implemented. For classes such as InetSocketAddress which we cannot change, we'll have to add Writers and Read methods to the StreamOutput and StreamInput classes to be able to use writeGenericObject and readGenericObject methods. This is inline with how OpenSearch deals with third party classes today. [source code]

To conclude, we propose to use custom serialization for headers in security plugin.

Solution

This change is to proposed to be introduced with OS 3.0 with no intention to backport this. We can break down the solution into following action items -

• Code change in OpenSearch's StreamInput, StreamOutput classes to add Writers and Read methods respectively for third party classes directly involved in serialization within security plugin. [will update the list below]
  • InetSocketAddress
• Re-implement Base4Helper::serialize and Base64Helper.deserialize methods to use custom serialization.
• Handle communication b/w old and new nodes during version upgrade
• Introduce safe class checks for the alternative (de)serialization implementation (this may no longer be needed as unsupported classes will fail to be serialized)
• End to end testing, especially the version upgrade scenario
• Run OSB tests to see how the various throughputs/latencies change (exploring different workloads where the impact would be much more pronounced, encountering high variance for the tests already performed)
• Finalise the OS version in which the change will be released (version code be used in the version upgrade handling logic to identify old nodes)

I've raised an initial draft PR for serialization using protostuff and working towards testing the version upgrade scenario (from OS2.5 to OS2.7). Currently, the change is assumed to be introduced as part of OS2.7 release for testing purpose. We may need to bump up this version.
Will raise another PR with custom serialization.

Next Steps

• Review the benchmarks and maybe explore any other potential alternatives.