Introduction
In software development, organizations can employ multiple strategies when deploying new software to production environments. Deployment approaches range from deploying everything at once (Basic Deployment, Multi-Service Deployment, or Recreate Deployment) to more incremental approaches like Blue/Green Deployments or Canary Deployments. Selecting the optimal deployment strategy depends on factors such as project complexity, availability requirements, infrastructure costs, and scalability needs.
One of AIM’s clients faced a significant challenge: users experienced extended periods of data unavailability in OpenSearch during deployments while historical data was being transformed and loaded through their ETL pipeline. This article describes how our team leveraged OpenSearch aliases to implement Blue/Green deployments within a single OpenSearch cluster, dramatically reducing downtime without requiring additional infrastructure.
Solution Overview: Blue/Green Deployments with OpenSearch Aliases
Blue/Green deployments provide a software release strategy utilizing two identical environments running in production. During a software release, the team updates the non-active environment with new code. After testing the updated environment, user traffic is redirected from the old version to the new one.
Unlike Blue/Green deployments (which typically switch traffic completely at once), Canary Deployments gradually shift traffic in incremental percentages, requiring additional infrastructure to control this gradual traffic routing.
Figure 1: Before Blue/Green Deployment
Figure 2: During Blue/Green Deployment
Figure 3: After Blue/Green Deployment
OpenSearch aliases enable similar functionality but within a single OpenSearch cluster. These aliases create virtual index names that can point to one or more indexes and allow seamless switching between them. By configuring applications to reference an alias instead of directly referencing an index, you can switch between indexes without application configuration changes or downtime.
Key Benefits of OpenSearch Aliases for Blue/Green Deployments
- Zero downtime for users – Data remains searchable throughout the deployment process
- No application configuration changes needed – Applications continue to reference the same alias
- Reduced risk – New index can be fully tested before switching traffic
- Same infrastructure – Achieves Blue/Green benefits without duplicating clusters
- Simplified rollbacks – Can quickly revert to previous index if issues arise
Implementation Example
Let’s walk through a specific implementation of this approach:
Figure 4: Sample OpenSearch cluster with 1 index
If you need to update this index, you would typically delete and recreate it with new fields or settings. During recreation and data reloading, users would experience unavailability or incomplete results.
Using OpenSearch aliases, you can instead create two indexes: “user-data-blue” and “user-data-green” with an alias “user-data” pointing to the active one. This allows seamless switching between the two indexes.
PUT user-data-blueFigure 5: Create OpenSearch Index called ‘user-data-blue’
POST _aliases
{
actions: [
{
“add”: {
“index”: “user-data-blue”,
“alias”: “user-data”
}
}
]
}Figure 6: Create OpenSearch Alias for new index called ‘user-data’
Figure 7: OpenSearch cluster with Index and Alias
PUT /user-data-green
{
mappings: {
eyeColor: {
“type”: “keyword”
},
heightInMeters: {
“type”: “integer”
}
}
}Figure 8: Create new user-data-green index with index settings
Figure 9: OpenSearch cluster with new user-data-green-index
POST _aliases
{
actions: [
{
“remove”: {
“index”: “user-data-blue”,
“alias”: “user-data”
}
},
{
“add”: {
“index”: “user-data-green”,
“alias”: “user-data”
}
}
]
}Figure 10: Update OpenSearch Alias to point at new index
Figure 11: OpenSearch cluster with alias flipped to user-data-green
Implementation Details
With these commands, we first create a “user-data-blue” index and an alias “user-data” pointing to it. This maintains compatibility with existing applications using that index name.
Next, we create a second “user-data-green” index with any required settings. We can populate this index while users continue accessing the blue index through the alias. For example, we could reindex data from blue to green to test new settings without affecting current workloads.
After testing confirms the green index is ready, we update the alias to point to green instead of blue. This switch is instant for users, who experience no downtime.
Challenges and Considerations
While this approach offers significant benefits, there are important considerations:
- Storage requirements – Maintaining two copies of your index requires additional storage
- Index naming conventions – Requires careful management of index naming
- Data synchronization – For rapidly changing data, you need a strategy to keep indexes in sync
- Testing requirements – New index should be thoroughly tested before switching the alias
Client Solution Implementation
Our team applied this approach to solve the client’s ETL pipeline challenges:
Figure 12: Original configuration of ETL pipeline before deployment
Originally, both the ETL pipeline and users directly communicated with the OpenSearch index. This worked well for small datasets but became problematic as data volumes grew and repopulation times increased.
Figure 13: Original configuration of ETL pipeline during deployment
During deployments, the Historical ETL would delete the index, recreate it with updated settings, and repopulate it with client data. As datasets grew larger, maintenance windows extended, frustrating users.
Figure 14: Original configuration of ETL pipeline after deployment
Figure 15: Updated configuration of ETL pipeline before deployment
Our solution introduced an OpenSearch alias between users and the index. The Continuous ETL pipeline now communicates directly with the active index.
Figure 16: Updated configuration of ETL pipeline during deployment
During deployments, we stop the Continuous ETL job and start the Historical ETL job, which recreates the inactive index with updated settings and loads necessary data. The alias continues pointing to the old index, allowing users to search data during the deployment.
Figure 17: Updated configuration of ETL pipeline after deployment
Once the new index is populated and tested, we point the alias to the new index and restart the Continuous ETL pipeline. Since it’s configured to target the active index, it seamlessly resumes operations with the new index.
Conclusion
As development teams seek to minimize production deployment impacts and reduce risks, Blue/Green deployments offer a valuable strategy. Using OpenSearch aliases enables teams to implement Blue/Green deployments within a single OpenSearch cluster, achieving similar benefits without duplicating infrastructure. This approach delivers immediate value by maintaining data availability throughout deployments while simplifying the overall deployment process.
Insights By
Ready to Optimize Your OpenSearch Deployments?
Is your organization struggling with data availability during OpenSearch deployments?
Contact our data engineering team today to discuss how we can help you achieve zero-downtime deployments with your existing OpenSearch infrastructure.
