Instance pool scale-out misses the SLA because of boot-time dependencies

The dominant delay is not the instance pool; it is the boot path. Every new instance downloads 3.8 GB from a public CDN through NAT and runs package updates, so scale-out is bounded by internet throughput and package repository latency, not by OCI provisioning. Bake the model and OS updates into the custom image, publish the image to Object Storage or an image catalog, and reduce cloud-init to small configuration fetched through a service gateway. That removes the public CDN dependency and makes boot deterministic. Use a faster boot volume profile than Lower Cost if boot I/O is a bottleneck, and set the instance-pool health-check grace period long enough for the remaining initialization so the load balancer does not kill instances mid-boot. Keep the health check path meaningful: it should return healthy only when the app can serve traffic, not merely when the port is open. For capacity, use a capacity reservation or pre-scale the pool before the sale; a max of 40 does not guarantee that 40 flexible instances can be launched in both ADs at peak. Also adjust the autoscaling policy to scale out in larger steps with a short cooldown, and use a schedule-based policy for the known flash-sale window.

Start by separating capacity from performance. OCI block volume performance is tied to the volume's VPU/GB setting and size, so a 500 GB Balanced volume has a fixed baseline that may be too low for large random scans with queued I/O. Compare Higher Performance and Ultra High Performance, and consider increasing volume size because more GB at the same tier raises the VPU ceiling. Check whether the volume is attached paravirtualized or over iSCSI; for high-throughput workloads, iSCSI with multipath can provide better queue depth and availability. Also check whether the reporting VM's shape has enough network and CPU to drive the volume, and whether the scan pattern is sequential or random. If the workload is throughput-bound, a volume group or multiple volumes in a RAID 0 layout may be more appropriate than a single larger volume; if it is latency-bound, focus on the higher tier and multipath first. Use OCI Block Volume auto-tune where available, but validate with the actual I/O size and queue depth rather than assuming the tier label solves the problem.

Do not simply increase the unhealthy threshold; that hides a failing app and keeps bad instances in rotation. Instead, set a health-check grace period that covers the expected boot and warm-up time, keep a short interval and low timeout for steady state, and make the health endpoint depend on a real readiness check such as database connectivity and model load. Use a separate liveness check if the app can recover. For autoscaling, do not rely only on CPU at 55%; add a custom metric such as request queue depth or p95 latency, and use a scale-out step of 4 with a cooldown that matches boot time. Add a schedule-based policy for the flash sale so capacity is warm before traffic arrives. Roll out the new image through a rolling instance-pool replacement with a maximum unavailable count, and watch load balancer healthy-host count, instance-pool lifecycle state, and scale-out duration. If instances still fail, inspect cloud-init logs and the health-check response body; churn is a symptom, and the fix must make new instances genuinely ready faster.