LY Corporation's Cloud Infrastructure Transition: The Architecture of Flava, a Next-Generation Platform Unifying Two Massive Clouds

LY Corporation launched Flava, a next-generation IaaS platform unifying ex-LINE's Verda and ex-Yahoo's YNW, in 2025. Previously, 11,000+ hypervisors and 27,000+ hypervisors, 130,000+ VMs and 220,000+ VMs, and 4 and 160+ OpenStack clusters were each operated separately, but Flava redesigned this into a single system at the scale of 500+ hypervisors, 9,000+ VMs, 1+ OpenStack cluster, and 5+ PB object storage.

The operating principle is clear. Rather than having the infrastructure perfectly prevent every failure, it assumes failure will happen and aims for statelessness, application-driven availability, and faster recovery. VM root disks are treated as ephemeral data, persistent data is separated into external storage, and in the event of failure, rebuilding the environment quickly via IaC is prioritized over root-cause investigation.

To operate a large-scale cloud with a small team, IaC and observability automation are also heavily pushed. Everything from OS configuration to package installation and network provisioning is managed as code and deployed via CI/CD, and placement is done at the availability zone (AZ) level to limit the blast radius of failures. For observability, overall status is monitored via Prometheus, Grafana, and internal dashboards, and when anomalies are detected, kernel trace and packet capture are used to dig into the detailed root cause.

Technically, the platform centers on OSS such as OpenStack, Envoy, the Linux kernel's eBPF and XDP, FRRouting (FRR), and Ceph, and contributes needed features directly upstream. In practice, they continuously submit commits and patches to OpenStack, Ceph, FRRouting, and the Linux kernel, and have directly implemented SRv6 and BGP features for VPC. They also run not just IaaS compute but VPC, DNS, and Load Balancer on top of general-purpose x86 servers, pushing segments that require high performance close to wire-speed through XDP, hardware offloading, and tuning.

Where OSS isn't sufficient, they build it themselves. For example, the object storage system Dragon is a proprietary system prioritizing HDD efficiency and operability, and core operational components such as the SDN control plane, load balancer health check agent, and service discovery have also been internalized in Rust, Go, and Python. Given that hardware failures occur daily at this scale, most of the process—from failure detection to data center work requests to the reintegration of replaced equipment—has been automated, and they plan to apply LLMs to this decision-making flow going forward as well.

Flava's core changes are three-fold. First, it eliminated dedicated environments per product and absorbed nearly all workloads into a single resource pool, reducing capacity planning complexity. Second, it minimized custom OpenStack patches and maintained upstream alignment to ease upgrades and security updates. Third, it introduced VPC by default, raising the security bar in a multi-tenant environment—what used to take months to set up sensitive-data environments via physical separation and dedicated VLANs can now be prepared within minutes through logical isolation and automated integration.

Cost optimization is also carried out together with users. Development environments require resources to have a set lifespan, with expired "zombie" resources automatically deleted, and object storage offers bucket classes such as High Performance and Scalable, allowing performance and cost to be changed without altering endpoints. That said, Flava is still at the minimum-viable-feature stage, so expanding functionality and fixing bugs remain urgent, and above all, reducing migration costs from the legacy platform and shortening the period of parallel operation remains the biggest challenge.