Building a High-Availability, Cost-Optimized Shopify Stack on OVH

Architectural Overview: OVH Managed Bare Metal for Shopify HA

Leveraging OVH’s managed bare metal infrastructure provides a compelling balance of performance, control, and cost-effectiveness for a high-availability (HA) Shopify stack. This approach bypasses the typical cloud overhead associated with virtualized environments while offering dedicated resources. Our strategy focuses on a multi-region, active-passive or active-active setup for critical components, ensuring resilience against single points of failure and regional outages. The core of this architecture involves robust load balancing, redundant database clusters, and stateless application servers.

Database Layer: Galera Cluster for MySQL on OVH Dedicated Servers

For transactional integrity and high availability, we deploy a Galera Cluster for MySQL. This synchronous multi-master replication solution ensures that writes are committed across all nodes simultaneously, minimizing data loss in failover scenarios. We’ll provision at least three dedicated OVH servers for the Galera nodes to maintain quorum. Each server should have sufficient RAM and fast SSD storage. Network latency between nodes is critical; therefore, placing them within the same OVH datacenter or a closely peered region is paramount.

Here’s a sample configuration snippet for a Galera node’s MySQL configuration file (my.cnf):

[mysqld]
user                    = mysql
pid-file                = /var/run/mysqld/mysqld.pid
socket                  = /var/run/mysqld/mysqld.sock
port                    = 3306
basedir                 = /usr
datadir                 = /var/lib/mysql
tmpdir                  = /tmp
lc-messages-dir         = /usr/share/mysql
skip-external-locking
bind-address            = 0.0.0.0

# Galera Provider Configuration
wsrep_provider          = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name      = "shopify_galera_cluster"
wsrep_cluster_address   = "gcomm://192.168.1.101,192.168.1.102,192.168.1.103" # IPs of other Galera nodes

# Galera Synchronization and State Transfer
wsrep_sst_method        = rsync
wsrep_sst_auth          = sstuser:your_sst_password

# Galera Node Specific Configuration (example for node 1)
wsrep_node_address      = "192.168.1.101"
wsrep_node_name         = "galera-node-1"

# InnoDB Configuration
innodb_autoinc_lock_mode = 2
innodb_flush_log_at_trx_commit = 0 # For performance, consider 2 in production with robust backups
innodb_buffer_pool_size = 8G # Adjust based on server RAM

# Other MySQL Settings
max_connections         = 500
query_cache_type        = 0
query_cache_size        = 0
log_bin                 = /var/log/mysql/mysql-bin.log
binlog_format           = ROW

Important Considerations:

• Replace 192.168.1.101, 192.168.1.102, and 192.168.1.103 with the actual private IP addresses of your Galera nodes.
• Ensure the wsrep_sst_auth credentials are set and used for the State Snapshot Transfer user.
• The innodb_flush_log_at_trx_commit = 0 setting significantly boosts write performance but increases the risk of data loss during a crash. For critical production environments, 2 is safer, or implement robust, frequent backups.
• Monitor cluster health using SHOW GLOBAL STATUS LIKE 'wsrep_%';. Key metrics include wsrep_cluster_size (should be 3 or more), wsrep_local_state_comment (should be ‘Synced’), and wsrep_incoming_addresses.

Application Layer: Stateless PHP-FPM on OVH Public Cloud Instances

The Shopify application logic, typically served by PHP, should be deployed on stateless servers. This allows for easy scaling and quick recovery. We’ll use OVH Public Cloud instances (e.g., General Purpose instances like GRA1-PA-3) for this layer, fronted by a highly available load balancer. Each instance will run Nginx as a web server and PHP-FPM for executing PHP code. The key is to ensure no session data or persistent state is stored locally on these instances. All state should be externalized to Redis or a similar caching/session store.

A typical Nginx configuration for serving a PHP application:

And a corresponding PHP-FPM pool configuration (e.g., /etc/php/7.4/fpm/pool.d/www.conf):



[www]
user = www-data
group = www-data
listen = /var/run/php/php7.4-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 10
pm.process_idle_timeout = 10s
pm.max_requests = 500

request_terminate_timeout = 60s
request_slowlog_timeout = 30s
slowlog = /var/log/php/php7.4-fpm.slow.log

catch_workers_output = yes
php_admin_value[error_log] = /var/log/php/php7.4-fpm.error.log
php_admin_flag[log_errors] = on



Scaling Strategy: Deploy multiple instances of these Nginx/PHP-FPM servers. Use an auto-scaling group managed by OVH's cloud orchestration tools or a third-party solution like Kubernetes if complexity warrants it. The goal is to have enough capacity to handle peak loads while scaling down during off-peak hours to optimize costs.



Load Balancing: HAProxy for Global and Local Traffic Management



A robust load balancing strategy is crucial for HA. We'll employ HAProxy for both global server load balancing (GSLB) and local load balancing. For GSLB, consider using OVH's managed load balancing service or a DNS-based solution with health checks to direct traffic to the active region. Within each region, HAProxy instances will distribute traffic to the Nginx/PHP-FPM application servers.



A sample HAProxy configuration for distributing traffic to application servers:



Caching and Session Management: Redis Cluster



To ensure statelessness and improve performance, a distributed Redis cluster is essential for caching frequently accessed data (e.g., product pages, inventory) and managing user sessions. Deploying Redis in a cluster mode provides high availability and scalability. OVH offers managed Redis services, or you can deploy your own cluster on dedicated servers.



Cost Optimization Strategies



The primary driver for using OVH managed bare metal and Public Cloud instances is cost optimization. Here's how to maximize savings:



Right-Sizing Instances: Continuously monitor resource utilization (CPU, RAM, Network I/O) of your bare metal servers and Public Cloud instances. Adjust instance types and configurations to match actual demand, avoiding over-provisioning.
Reserved Instances/Volume Discounts: For predictable workloads, explore OVH's options for long-term commitments on bare metal servers or Public Cloud instances, which often come with significant discounts.
Auto-Scaling: Implement aggressive auto-scaling for the stateless application layer. Scale down to the minimum required instances during off-peak hours.
CDN for Static Assets: Offload static assets (images, CSS, JS) to a Content Delivery Network (CDN). This reduces load on your application servers and bandwidth costs.
Database Read Replicas: For read-heavy workloads, consider setting up read replicas for your MySQL Galera cluster. Direct read traffic to replicas to offload the primary nodes.
Monitoring and Alerting: Implement comprehensive monitoring (e.g., Prometheus, Grafana) to identify underutilized resources and potential cost-saving opportunities. Set up alerts for performance degradation that might indicate inefficient resource usage.
Managed Services vs. Self-Hosted: Evaluate the cost-benefit of OVH's managed services (e.g., managed databases, load balancers) versus self-hosting. While self-hosting offers more control, managed services can reduce operational overhead and potentially total cost of ownership.



Disaster Recovery and Failover Procedures



A well-defined disaster recovery (DR) plan is essential. For an active-passive setup, this involves having a secondary region ready to take over.



Database Failover: In case of a Galera node failure, the cluster should automatically reconfigure. If an entire region fails, you'll need a strategy to promote a read replica or a standby Galera cluster in another region. This might involve manual intervention or automated scripts.
Application Server Failover: If using auto-scaling groups, the load balancer will automatically stop sending traffic to failed instances. New instances will be launched to replace them. For regional failover, DNS records or GSLB will need to be updated to point to the healthy region.
Data Backups: Implement a rigorous backup strategy for your MySQL database. Store backups off-site and test restoration procedures regularly.
Configuration Management: Use tools like Ansible, Chef, or Puppet to ensure consistent deployment and configuration across all servers, simplifying recovery and scaling.



Regularly test your failover and DR procedures. A documented, practiced plan is the only way to ensure business continuity during an outage.