LY Corporation의 클라우드 인프라 전환: 두 거대 클라우드를 통합하는 차세대 플랫폼 Flava의 아키텍처

LY Corporation은 ex-LINE의 Verda와 ex-Yahoo의 YNW를 하나로 묶는 차세대 IaaS 플랫폼 Flava를 2025년 출시했다. 기존에는 11,000+ 대의 hypervisor와 27,000+ 대의 hypervisor, 130,000+ VM과 220,000+ VM, 4개와 **160+**개의 OpenStack cluster가 각각 따로 운영됐지만, Flava는 이를 500+ hypervisor, 9,000+ VM, 1+ OpenStack cluster, 5+ PB object storage 규모의 단일 체계로 다시 설계했다.

운영 원칙은 명확하다. 인프라가 모든 장애를 완벽히 막는 대신, 실패를 전제로 statelessness, application-driven availability, faster recovery를 지향한다. VM root disk는 임시 데이터로 보고, 영속 데이터는 외부 저장소로 분리하며, 장애 시에는 원인 규명보다 IaC로 환경을 빠르게 재구축하는 방식을 중시한다.

대규모 클라우드를 적은 인원으로 운영하기 위해 IaC와 관측 자동화도 강하게 밀어붙인다. OS 설정부터 패키지 설치, 네트워크 프로비저닝까지 코드로 관리하고 CI/CD로 배포하며, 가용성 존(AZ) 단위로 배치해 장애 범위를 제한한다. 관측은 Prometheus, Grafana, 내부 대시보드로 전체 상태를 보고, 이상 징후가 잡히면 kernel trace와 packet capture로 세부 원인을 파고드는 방식이다.

기술적으로는 OpenStack, Envoy, Linux kernel의 eBPF와 XDP, FRRouting (FRR), Ceph 같은 OSS를 중심에 두고, 필요한 기능은 upstream에 직접 기여한다. 실제로 OpenStack과 Ceph, FRRouting, Linux kernel에 대한 커밋과 패치를 계속 올리고 있으며, VPC용 SRv6와 BGP 기능도 직접 구현했다. 또 IaaS compute는 물론 VPC, DNS, Load Balancer까지 범용 x86 서버 위에 올리고, 고성능이 필요한 구간은 XDP, hardware offloading, tuning으로 wire-speed에 가깝게 끌어올린다.

OSS로 충분하지 않은 영역은 직접 만든다. 예를 들어 object storage Dragon은 HDD 효율과 운영성을 우선한 자체 시스템이고, SDN control plane, load balancer health check agent, service discovery 같은 운영 핵심도 Rust, Go, Python으로 내재화했다. 하드웨어 장애가 매일 발생하는 규모인 만큼, 장애 탐지부터 데이터센터 작업 요청, 교체 장비의 재편입까지 대부분 자동화했으며, 앞으로는 이 의사결정형 흐름에도 LLM을 적용하려 한다.

Flava의 핵심 변화는 세 가지다. 첫째, 제품별 전용 환경을 없애고 거의 모든 워크로드를 single resource pool로 흡수해 capacity planning 복잡도를 줄였다. 둘째, OpenStack 커스텀 패치를 최소화하고 upstream 정렬을 유지해 업그레이드와 보안 업데이트를 쉽게 했다. 셋째, VPC by default를 도입해 멀티테넌트 환경의 보안 기준을 끌어올렸고, 기존에 물리 분리와 전용 VLAN으로 수개월 걸리던 민감정보 환경을 논리적 격리와 연동 자동화로 수분 내 준비할 수 있게 했다.

비용 최적화도 사용자와 함께 수행한다. 개발 환경에는 리소스 수명을 설정하게 하고 만료된 "zombie" 리소스를 자동 삭제하며, object storage는 High Performance와 Scalable 같은 bucket class를 제공해 엔드포인트 변경 없이 성능과 비용을 바꿀 수 있게 한다. 다만 Flava는 아직 최소 기능만 출시된 단계라 기능 확장과 버그 수습이 급하고, 무엇보다 레거시 플랫폼에서의 마이그레이션 비용과 병행 운영 기간을 줄이는 것이 가장 큰 과제로 남아 있다.