bcgov / ols-geocoder

Physical Address Geocoder
Apache License 2.0
10 stars 6 forks source link

Create a cloud-ready architecture for the online geocoder to support continuous availability #23

Closed mraross closed 1 year ago

mraross commented 5 years ago

The BC Address Geocoder's current system architecture is tied to Ministry infrastructure which includes both a fixed hardware platform and a private cloud platform running OpenShift. While the current architecture supports georedundancy and fixed horizontal scaling (multiple nodes), it doesn't support autoscaling.

We need a new, cloud-based, non-proprietary architecture that can do the following:

  1. Autodeploy a set of geocoder nodes/pods in a rolling manner to avoid API service interruption.

  2. Autoscale to handle peak loads gracefully and efficiently.

  3. Be deployed to both the gov't cloud platform and a public cloud that supports Kubernetes.

  4. Simplify geocoder pod deployment by replacing Apache Cassandra with per-pod, file-based storage of geocoder configuration data. The configmap capability of Kurbenetes may come in handy here.

  5. Be compatible with any new cloud platform that the Ministry is planning to roll out this year.

Autoscaling automates the deployment and release of compute nodes and storage to effectively shadow demand. This will require use of kubernetes to manage online geocoder deployment to private or public cloud infrastructure.

The need for autoscaling arose in November, 2019 when the online geocoder couldn't handle peak load during the BC Referendum on Proportional Representation. The geocoder became unavailable for twenty minutes while DataBC infrastructure staff manually deployed additional geocoder nodes.

The following tasks will be required:

  1. Design of a new architecture including all kubernetes and other scripts for build and deployment. [DataBC]

  2. Architecture review by geocoder developer

  3. Update online geocoder to support new architecture [geocoder developer]

  4. Deployment testing to ensure geocoder can be correctly deployed without API service interruption. [DataBC]

  5. Volume testing to ensure correct operation of autoscaling. [DataBC]

  6. Cloud cost analysis to determine impact of new architecture on operating costs. [DataBC]

cmhodgson commented 4 years ago

I don't think a significant departure from our existing kubernetes architecture is required for this. For this reason I would estimate 8 hours for (task 2) review, feedback, and discussion of the new architecture.

The development work for Task 3 is covered by #78.

alixcote commented 1 year ago

Older ticket. Closing.