Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

feat: capacity to deploy sharded MongoDB #1321

Merged
merged 1 commit into from
Nov 14, 2024

Conversation

tschneider-aneo
Copy link
Contributor

@tschneider-aneo tschneider-aneo commented Sep 2, 2024

Motivation

Following aneoconsulting/ArmoniK.Infra#168 and aneoconsulting/ArmoniK.Core#760, this PR aims to enable the deployment of a sharded MongoDB as ArmoniK's database.

A more complete motivation is provided in AEP 004 (aneoconsulting/ArmoniK.Community#48). This PR is meant to treat a previsible bottleneck on ArmoniK's database by enabling a sharded architecture to it.

Description

This PR enables the possibility to deploy a sharded MongoDB in a configurable way. A new variable mongodb_sharding describing the configuration wanted is introduced. It allows to define the number of shards, labels, node selectors, resources and replicas for each MongoDB entities.

If this new variable is not null, a sharded MongoDB is deployed, else it is a classical one. Only one "version" is deployed at each deployment.

Testing

It has been tested manually in AWS and localhost. GCP deployment is still to be tested. Workflows testing a deployment of ArmoniK with a sharded MongoDB are currently being studied.

Impact

It is expected to enhance ArmoniK's strong scalability at the cost of simple database configuration. A sharded database is indeed more complex.

Warning

Theses developments were made using Bitnami's mongodb-sharded image and Helm chart. It is not guaranteed that they work without using these particular resources.

As Bitnami's images are not verified with Docker Scout, we advice to adapt Bitnami's mongodb-sharded image to make it compliant with your personnal or business security requirements.

As quick-deploy is an example of ArmoniK deployment meant to help understanding what ArmoniK needs to run correctly, we are not responsible for warrantying a full operationality in production environment, especially in a security-compliant point of view.

Additional Information

To better understand how MongoDB sharding works see MongoDB's documentation.

Checklist

  • My code adheres to the coding and style guidelines of the project.
  • I have performed a self-review of my code.
  • I have commented my code, particularly in hard-to-understand areas.
  • I have made corresponding changes to the documentation.
  • [] I have thoroughly tested my modifications and added tests when necessary.
  • [] Tests pass locally and in the CI.
  • I have assessed the performance impact of my modifications.

@tschneider-aneo tschneider-aneo force-pushed the ts/integrate-mongodb-sharding branch from fb06fc5 to e69c53c Compare September 27, 2024 15:16
@tschneider-aneo tschneider-aneo changed the title feat: capacity to deploy sharded MongoDB on localhost feat: capacity to deploy sharded MongoDB Sep 27, 2024
@tschneider-aneo tschneider-aneo marked this pull request as ready for review October 1, 2024 13:29
Comment on lines 200 to 201
min_size = 5
desired_size = 5
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could make it depend on whether we deploy the sharded mongodb or not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess so, I agree on the fact that we should design the "MongoDB nodes" to be kind of proportionnal with the resources needed for MongoDB. We'll talk about this

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could keep min_size and desired_size to 1 and rely on the cluster autoscaler to start more nodes when you have more shards and replicas.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems smart. Is there a similar mechanism for GCP deployment ?

infrastructure/quick-deploy/aws/parameters.tfvars Outdated Show resolved Hide resolved
infrastructure/quick-deploy/gcp/parameters.tfvars Outdated Show resolved Hide resolved
infrastructure/quick-deploy/localhost/storage.tf Outdated Show resolved Hide resolved
infrastructure/quick-deploy/localhost/storage.tf Outdated Show resolved Hide resolved
versions.tfvars.json Outdated Show resolved Hide resolved
versions.tfvars.json Outdated Show resolved Hide resolved
versions.tfvars.json Outdated Show resolved Hide resolved
@tschneider-aneo tschneider-aneo force-pushed the ts/integrate-mongodb-sharding branch from e00df89 to 9bf2e6c Compare November 14, 2024 09:48
@tschneider-aneo tschneider-aneo force-pushed the ts/integrate-mongodb-sharding branch from f13e115 to be0b089 Compare November 14, 2024 12:44
@lemaitre-aneo lemaitre-aneo merged commit 2a71d95 into main Nov 14, 2024
12 checks passed
@lemaitre-aneo lemaitre-aneo deleted the ts/integrate-mongodb-sharding branch November 14, 2024 15:34
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants