[GitHub] [trafficcontrol] rawlinp commented on a change in pull request #4708: Add Blueprint for Cache Config Snapshots

[GitBox <gi...@apache.org>]

rawlinp commented on a change in pull request #4708:
URL: https://github.com/apache/trafficcontrol/pull/4708#discussion_r430626600



##########
File path: blueprints/traffic-ops-cache-config-endpoint.md
##########
@@ -0,0 +1,155 @@
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+# Cache Config Snapshot
+
+## Problem Description
+
+Currently, ORT needs to request many large endpoints from Traffic Ops. These requests have a performance cost, and can cause issues for CDNs with many caches, running Traffic Ops or its PostgreSQL database on small hardware.
+
+The cache config generation doesn't need a lot of data, but there don't exist TO endpoints with only the data it does need, or a way to filter it.
+
+## Proposed Change
+
+Traffic Ops will add a “Cache Config Snapshot” feature.
+
+When the cache config is Snapshotted, all data will be serialized and stored, just like the CRConfig.
+
+Snapshot history will be stored. New snapshots will insert with a timestamp, retaining previous versions so they can easily be restored if necessary. Snapshots should be automatically pruned with a configurable number (which maybe be infinity or zero), and/or a configurable amount of time.
+
+The snapshot data will be cached in Traffic Ops' memory, with a configurable cache time (suggested default: 5s).
+
+If the cache is under that age, it will be served by Traffic Ops from memory with no database request.
+
+Initially, the Cache Config Snapshot will be created on Queue, so no interface change is necessary. In the future, Queue and Cache Config Snapshot could be easily separated, if desired.
+
+### Implementation
+
+Note endpoint names are provisional and may be changed to fit Traffic Ops API Requirements and OSS preferences.
+
+The data currently needed by the cache config generation which will be snapshotted can be seen here:
+
+https://godoc.org/github.com/apache/trafficcontrol/traffic_ops/ort/atstccfg/config#TOData
+
+### Traffic Portal Impact
+
+n/a
+
+### Traffic Ops Impact
+
+As above, TO should cache the snapshot in memory, and only fetch from the database if the cache has expired, and pre-check if the timestamp is unchanged (common) before initiating the full expensive snapshot retrieval.
+
+- The snapshot should use DeliveryService-Server IDs, not names, and omit the DSS last_modified, for both the database query and the response.
+    - DSS is 99% of the snapshot, using IDs and omitting the timestamp is a large size  reduction, saving network both DB->TO  and TO->client.
+    - The snapshot should use one-letter JSON names for DSS, i.e. `“d”: 42, “s”: 24`. This will further reduce the network to the client by about 50%, and improve TO scalability.
+    - The snapshot cache should store the serialized JSON bytes, so it doesn’t have to re-serialize for every request. JSON serializing in Go is a huge performance cost, and this will drastically improve scalability.
+
+Queueing Updates will automatically create the Snapshot
+    - This may be changed to a button on the Server in the future. But for now, automatically snapshotting on Queue avoids changing the User Interface.
+
+GET `/servers/{{name}}/cache-config-snapshot`
+    - Returns the cache config snapshot
+    - Per-server, because a lot of data is only needed by one server. For example, that server’s Parameters.
+    - TO should load the Snapshot, and then remove the unnecessary data before serializing it in the GET for one server.
+
+#### REST API Impact
+
+See Traffic Ops Impact
+
+#### Client Impact
+
+See Traffic Ops Impact - client functions for each endpoint.
+
+#### Data Model / Database Impact
+
+New table for Cache Config Snapshots.
+
+### ORT Impact
+
+ORT will be changed to request this endpoint if it exists, instead of the API endpoints.
+
+This should be a small change, and should only require changing the single request function. See https://github.com/apache/trafficcontrol/blob/b3e8605e9bdcaf097372c9c5dff337b72ff0bc66/traffic_ops/ort/atstccfg/cfgfile/cfgfile.go#L43
+
+ORT will need to continue to request the API endpoints for the prior Traffic Ops version, if the endpoint doesn't exist, for at least one major Traffic Control version.
+
+### Traffic Monitor Impact
+
+n/a
+
+### Traffic Router Impact
+
+n/a
+
+### Traffic Stats Impact
+
+n/a
+
+### Traffic Vault Impact
+
+n/a
+
+### Documentation Impact
+
+The new API endpoint will be documented. See Traffic Ops Impact.
+
+### Testing Impact
+
+The new API endpoint, and ATS config changes, will have TO API tests and unit tests. See Traffic Ops Impact.
+
+### Performance Impact
+
+No significant performance impact expected. Load impact on Traffic Ops should be reduced.
+
+### Security Impact
+
+n/a

Review comment:
       We may want to note here that secrets required by ORT (sslkeys, URI signing keys, etc) would now be stored in the cache-config-snapshot JSON blob in TODB, rather than existing only in Riak, so this new endpoint should require admin privileges.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org