Analytics Query Service (AQS) is the software behind the `/metrics` family of endpoints in RESTBase. Essentially it's It is a read-only HTTP proxy to results served from Cassandra and Druid backends. It's. It is currently based on a very old versionfork of RESTBase, the codebase was initially forked from RESTBase codebase andand has received little updates over the years.
As a part of the goal to sunset RESTBase, AQS has to be migrated from RESTBase codebase ~~to service-template-node~~ to be in line with the rest of the services and exposed in API Gateway via envoneeds to be migrated to a bespoke service exposed via the API Gateway.
Plan:### Overview
1. ~~(Optional) Add support in service-template-node for talking to Cassandra. Since we are planning to move storage from RESTBase down to individual services, we might benefit from some shared library support. This step however is optional - perhaps we could just use Cassandra driver directly without additional abstractions.Implement a new, To be investigated.~~stand-alone AQS service
2. ~~Finish support for Cassandra schema distribution, leftover from sessionstore project. Currently in RESTBase the schema is stored in code and can be created upon software startup. This pattern has been proven to be unsuitable for production, so the schema is actually created manually. In Kask, we've moved away from this pattern, and the schema is created only manually. Automation for schema/options distribution has never been finished for Kask,1. but now if we are to start migrating more service off RESTBase, we need better ways for schema distribution T220246~~Deploy AQS 2.0 on k8s
3. Rewrite AQS service ~~using service-template-node. Because AQS codebase is quite simple, this should not be too problematic. Some of the RESTBase built-in features, for example request parameter validation, will have to be reimplemented since there's no magic support for it in service-template1. Upgrade to node10 only inExpose the `/metrics` hierarchy from the new service using the meantime.~~API Gateway
4. Deploy AQS 2.0 on k8s. ~~Since AQS will be based on service-template-node,1. existing patterns for k8s deployments of node services can be reused.Switch RESTBase to proxying requests from the old AQS service, Cassandra connection setup could be borrowed from either of the Kask deployments.~~to the new k8s-based one
5. Expose /metrics hierarchy in API Gateway. Deprecate /api/rest_v1/metrics hierarchy. Switch RESTBase to proxying requests from old AQS cluster to the new,1. k8s AQS cluster.Deprecate the http://{project}/api/rest_v1/metrics resources
61. Eventually phase out the RESTBase `/metrics` hierarchy.
Solving this will make us progress on multiple fronts: T198901 T210704 T262315
----
(NOTE) EDIT: The normative (non-RESTBase) bits of the AQS code are pretty trivial (and reuse isn't quite copy-paste) so let's leave open the decision of implementation language.
NOTE: This will be picked up by Platform Engineering, with support from Analytics.
----
**See also:**
https://wikitech.wikimedia.org/wiki/Analytics/Systems/AQS
https://github.com/wikimedia/analytics-aqs
https://github.com/wikimedia/restbase
https://wikimedia.org/api/rest_v1/