<div id="readability-page-1" class="page"><article><div><p>안녕하세요. LY Corporation에서 프라이빗 클라우드 인프라를 담당하고 있는 이노우에입니다.</p>
<p>LY Corporation의 방대한 트래픽과 데이터를 지탱하는 것은 저희가 직접 개발해 운영하고 있는 대규모 프라이빗 클라우드입니다. 현재 저희는 구 LINE Corporation에서 사용하던 'Verda'와 구 Yahoo Japan Corporation에서 사용하던 'YNW(IaaS(infrastructure as a service))'라는 두 거대한 클라우드 기반을 차세대 클라우드 기반인 Flava로 통합해 나가는 과정에 있습니다.</p>
<table><thead><tr><th></th><th>Verda</th><th>YNW</th><th>Flava</th></tr></thead><tbody><tr><th>서비스 개시</th><td>2016</td><td>2013</td><td>2025</td></tr><tr><th>하이퍼바이저(물리 서버) 수</th><td>11,000 이상</td><td>27,000 이상</td><td>500 이상</td></tr><tr><th>VM(가상 머신) 수</th><td>130,000 이상</td><td>220,000 이상</td><td>9,000 이상</td></tr><tr><th>OpenStack 클러스터 수</th><td>4</td><td>160 이상</td><td>1 이상</td></tr><tr><th>오브젝트 스토리지 용량(PB)</th><td>200 이상</td><td>100 이상</td><td>5 이상</td></tr></tbody></table>
<p>이 방대한 리소스를 어떻게 효율적으로, 그리고 무중단으로 운영해 나가고 있는지 저희 클라우드의 근간을 이루는 설계 철학과 핵심 기술, 그리고 차세대 Flava가 지향하는 세계를 소개하겠습니다.</p>
<p>참고로 이번 글에서는 저희 클라우드의 기반이 되는 IaaS, 네트워크, 스토리지와 같은 레이어의 기술 스택에 초점을 맞출 예정입니다. KaaS(Kubernetes as a service), DBaaS(database as a service), PaaS(platform as a service) 등 상위 레이어에 대한 설명은 다음 기회로 미루겠습니다.</p>
<h2 id=""><strong>설계 철학과 운영</strong></h2>
<p>저희는 다음 철학에 기반해 클라우드를 설계 및 운영하고 있습니다.</p>
<h3 id="-1"><strong>장애를 전제로 한 설계 및 이용</strong></h3>
<p>서비스 개발 속도를 극대화하기 위해, 인프라 단독으로 과도한 가용성을 보장하는 데 집착하지 않고 장애는 언제든 발생할 수 있다는 것을 가정하고 설계합니다. 구체적으로 다음 세 가지를 설계의 핵심으로 삼고 있습니다.</p>
<ul><li>무상태성(statelessness) 추구: VM의 루트 디스크(임시 디스크)에 저장하는 데이터는 일시적인 것으로 정의합니다. 영속적인 데이터는 외부 스토리지로 분리해 인스턴스 장애 발생 시 서비스에 미치는 영향을 최소화합니다.</li><li>애플리케이션 주도의 가용성: 인프라 단독으로 완전한 가용성을 보장하는 것이 아니라 애플리케이션 측 구성과 조합해 신뢰를 확보하고 인프라 복잡성을 제거하고 있습니다.</li><li>신속한 복구: 장애 발생 시 최우선 순위는 현상 복구가 아니라 서비스 지속입니다. 원인 규명에 시간을 들이기보다는 IaC(infrastructure as code)를 사용해 환경을 즉시 재구축하는 운영을 권장하고 있습니다.</li></ul>
<p>이러한 설계 철학을 실현하려면 사용자 측의 이해와 협력이 필수입니다. 이에 따라 저희는 지속적으로 장애를 전제로 한 설계를 알리는 활동과 컨설팅을 진행하고 있습니다. 또한 KaaS나 PaaS 등 보다 추상화한 환경을 이용할 것을 권장하며 개발자가 의식하지 않아도 더욱 견고한 서비스를 만들 수 있는 문화를 정착시키고자 힘쓰고 있습니다.</p>
<h3 id="-2"><strong>운영 및 모니터링 고도화</strong></h3>
<p>대규모 클라우드를 소수 인원으로 안정적으로 운영하기 위해 철저히 자동화하고 관찰 가능성(observability)을 확립하는 데 주력하고 있습니다.</p>
<h4 id="iac"><strong>IaC를 통한 완전 자동화 및 통제</strong></h4>
<p>OS 설정부터 각종 패키지 설치는 물론 네트워크 투입까지, 모든 구성 관리를 코드화해 CI/CD 파이프라인을 통해 철저히 자동으로 적용하고 있습니다. 또한 배포는 AZ(availability zone) 단위로 실행해 혹시 장애가 발생한다고 해도 그 영향 범위를 국소화할 수 있는 안전 장치를 마련해 뒀습니다.</p>
<h4 id="-3"><strong>숲과 나무를 모두 볼 수 있는 관찰 가능성 확보</strong></h4>
<p>대규모 환경에서 현황을 정확하게 파악하기 위해 거시적 모니터링과 미시적 조사라는 각 레이어에 특화된 도구를 갖추고 있습니다. 엔지니어는 이를 활용해 상황에 따라 숲과 나무의 시점을 자유롭게 오가며 조사를 진행합니다.</p>
<ul><li>숲(거시적 관점): Prometheus/Grafana나 자체 제작 대시보드를 활용해 클라우드 전체의 건전성이나 트렌드를 상시 모니터링하며 이상 징후를 파악합니다.</li><li>나무(미시적 관점): 이상 감지 시 커널 레벨의 트레이스나 패킷 캡처 등의 심층 정보를 파고들어 원인을 특정합니다.</li></ul>
<p>이와 같은 도구들과 이를 능숙하게 다뤄 현상의 전체 모습부터 근본 원인까지 추적할 수 있는 팀원들의 기술력이야말로 안정적인 운영의 핵심입니다.</p>
<h2 id="-4"><strong>대규모 클라우드를 지탱하는 기술과 마인드</strong></h2>
<p>클라우드의 각 영역에서 저희는 ‘소프트웨어 정의(software defined)’를 기본으로 삼고, OSS(open-source software) 커뮤니티와 함께 성장하면서 부족한 것은 직접 만든다는 자세를 관철하고 있습니다.</p>
<h3 id="oss"><strong>OSS 활용과 기여</strong></h3>
<p>저희의 기반은 OpenStack과 Envoy, Linux kernel(eBPF/XDP), FRR, Ceph와 같은 OSS가 핵심입니다. 저희는 단순히 OSS를 이용하는 것에서 그치지 않고, 지속적으로 커뮤니티에 기여하고 있습니다.</p>
<p>예를 들어, OpenStack이나 Ceph에는 업스트림에 수정 패치(참고: <a href="https://specs.openstack.org/openstack/oslo-specs/specs/epoxy/http-driver.html" target="_blank">1</a>, <a href="https://review.opendev.org/c/openstack/nova/+/939658" target="_blank">2</a>, <a href="https://github.com/ceph/ceph/pull/60019" target="_blank">3</a>, <a href="https://github.com/ceph/ceph/pull/66042" target="_blank">4</a>)를 제공하고 있으며, 네트워크 영역에서는 Flava의 VPC(virtual private cloud)에 필요한 SRv6 BGP 관련 기능을 설계 및 구현해 FRRouting이나 Linux Kernel에 커밋해 왔습니다(참고: <a href="https://github.com/FRRouting/frr/pull/5865" target="_blank">1</a>, <a href="https://github.com/FRRouting/frr/pull/9649" target="_blank">2</a>, <a href="https://github.com/torvalds/linux/commit/62ebaeaedee7591c257543d040677a60e35c7aec" target="_blank">3</a>, <a href="https://github.com/torvalds/linux/commit/7a3f5b0de3647c854e34269c3332d7a1e902901a" target="_blank">4</a>).</p>
<p>또한 저희 워크로드에 필요한 기능이 있을 때에는 이를 자체 개발하는 데 그치지 않고 본래 OSS 자체에 기능을 구현하고 있습니다. 이를 통해 독자적으로 패치했을 때 발생할 장기적인 유지 보수 비용을 절감하는 동시에 전 세계 커뮤니티와 함께 기술 자체를 발전시킬 수 있다고 생각합니다.</p>
<h3 id="-5"><strong>범용 하드웨어의 성능을 한계까지 끌어내는 소프트웨어 정의 기술</strong></h3>
<p>성능이나 비용, 유연성 측면에서 고가의 전용 장비에 의존하는 것을 최소화하고 있습니다. IaaS의 컴퓨트 노드는 물론 VPC와 DNS, LB(load balancer)와 같은 네트워크 제품도 범용적인 x86 서버에서 작동시키고 있습니다. 그 위에서 높은 성능이 필요한 부분에는 XDP(eBPF)를 이용한 고속 데이터 플레인 구현이나 하드웨어 오프로드 활용, 튜닝 등을 최대한 활용해 범용 서버이면서도 와이어 스피드에 가까운 처리량과 매우 낮은 지연 시간을 실현할 수 있는 구성을 목표하고 있습니다.</p>
<h3 id="-6"><strong>격차를 메우는 풀 스크래치 개발</strong></h3>
<p>OSS만으로는 해결할 수 없는 사내 고유 과제는 풀 스크래치로 자체 개발하고 있습니다.</p>
<h4 id="-7"><strong>예시</strong></h4>
<ul><li>오브젝트 스토리지 Dragon(<a href="https://techblog.yahoo.co.jp/architecture/dragon-object-storage-architecture/" target="_blank">참고(일본어)</a>): HDD의 용량 효율과 운영성을 최우선으로 설계한 독자적인 오브젝트 스토리지 개발</li><li>네트워크 제어 및 주변 도구: SDN(software defined network) 컨트롤 플레인이나 로드밸런서의 헬스체크 에이전트, 서비스 디스커버리 등 운영의 핵심을 담당하는 컴포넌트를 Rust, Golang, Python 등으로 개발</li></ul>
<h3 id="-8"><strong>하드웨어 고장을 고려한 자율 운영</strong></h3>
<p>수만 대의 하이퍼바이저와 페타바이트급 스토리지를 보유한 환경에서는 반드시 매일 어딘가에서 하드웨어가 고장납니다. 이를 전부 사람이 대응하는 것은 불가능한데요. 따라서 저희는 고장 감지부터 데이터센터 현지 작업자에게 요청, 교체 후 클러스터로 재투입하는 작업까지 대부분을 자동화하고 있습니다.</p>
<p>아직 일부 작업이나 예외적인 고장 패턴 등 엔지니어가 손수 대응해야 하는 프로세스가 남아 있는데요. 앞으로는 이와 같은 업무에도 LLM을 활용해 더욱 높은 수준으로 자동화할 계획입니다.</p>

<p>저희는 과거 클라우드를 운영하며 쌓아온 지식과 노하우를 모아 2023년 하반기에 개발을 시작해서 2025년에 차세대 기반 Flava를 출시했습니다. Flava는 이미 VM이 1만 대 가까이 생성되는 등 이용이 확대되고 있습니다. Flava에서는 구 클라우드에서 문제로 지적됐던 많은 점들을 근본적으로 해결하기 위해 다양한 측면에서 개선하고 있습니다. 대규모 인프라를 처음부터 다시 만들 수 있는 흔치 않은 기회를 최대한 활용해 기존 제품의 연장선상에 놓인 수준의 개편이 아니라 근본적으로 아키텍처를 개선했습니다.</p>
<h3 id="flava-1"><strong>Flava에서 진행한 주요 개선 사항</strong></h3>
<h4 id="-9"><strong>전용 환경 폐지 및 단일 리소스 풀로 전환</strong></h4>
<p>구 클라우드에서는 특정 제품이나 서비스를 위한 전용 환경(클러스터, 리소스 풀 등)이 다수 존재해 용량 관리가 퍼즐처럼 복잡해졌을 뿐 아니라 리소스 활용 효율에도 문제가 있었습니다. Flava에서는 이러한 복잡성을 해소하기 위해 전용 환경을 폐지하고, 거의 모든 제품과 서비스를 하나의 거대한 리소스 풀로 흡수하는 방향으로 설계를 변경했습니다. 이를 통해 용량 계획 시 고려해야 할 변수가 크게 줄어들고, 리소스 효율 및 조달부터 제공까지의 민첩성(agility)이 극적으로 향상됩니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/79ddae00015c4a849e8b527b2cc4a9ac.svg?updatedAt=1768972464000" alt="단일 리소스 풀로 전환" width="601" height="550"></p>
<h4 id="-10"><strong>유지 보수 효율 및 편의를 유지하기 위해 업스트림 추종 아키텍처 채택</strong></h4>
<p>구 클라우드에서는 OpenStack을 독자적으로 너무 많이 커스터마이징한 결과 업그레이드가 어려워지는 문제가 있었습니다. 이에 Flava에서는 업스트림 OpenStack을 추종하는 아키텍처를 채택했습니다. 독자적인 패치를 최소한으로 억제하고, 필요한 기능 개선은 적극적으로 업스트림에 커밋해 본래 프로젝트에 반영되도록 하는 방침입니다. 이렇게 업그레이드 장벽을 제거함으로써 정기적인 업데이트 사이클을 실현하고, 보안 및 기능을 항상 최신으로 유지할 수 있도록 운영하고 있습니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/50fd9206dd52491587b20a9aef858cfd.svg?updatedAt=1768972477000" alt="OpenStack 추종 방식" width="1000" height="auto"></p>
<h4 id="vpc"><strong>VPC 기본화</strong></h4>
<p>Flava에서는 네트워크 보안 수준을 근본적으로 끌어올리기 위해 VPC(virtual private cloud) 사용을 기본값으로 설정했습니다. 이를 통해 멀티 테넌트 환경이면서도 서로의 통신이 간섭하지 않는 견고한 보안 모델을 표준으로 제공합니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/52928a30d01e4dbb96fb7d505712b85e.svg?updatedAt=1768972489000" alt="VPC 사용 아키텍처" width="401" height="403"></p>
<p>또한 VPC 도입은 개인 정보 등 기밀성이 높은 정보를 다루는 보안 환경 구축 방식도 크게 바꿨습니다. 기존에는 방화벽이나 전용 VLAN을 이용해 물리적으로 테넌트를 분리해야 했고, 환경 준비에 수개월이 소요되곤 했습니다. 반면 Flava에서는 VPC를 통한 논리적 분리와 그에 따른 제품군 연계로 기존과 동등한 수준의 안전을 확보할 수 있으며, 이로 인해 보안 환경을 단 몇 분 만에 제공할 수 있게 되었습니다.</p>
<p>전사 규모에서의 VPC 기본 설정은 구 클라우드에서는 시도하지 않았던 것으로 Flava가 최초로 도전하는 것입니다. 모든 트래픽을 처리하는 VPC의 기반에는 극히 높은 신뢰성과 성능이 요구됩니다. 저희는 구 클라우드를 운영하면서 쌓은 안정적 운영의 노하우를 활용하는 한편, VPC 데이터 플레인 쇄신(XDP화) 등 근본적인 성능을 개선하는 작업을 병행하며 추진하고 있습니다.</p>
<h4 id="-11"><strong>사용자와 함께 실현하는 비용 최적화</strong></h4>
<p>Flava는 사용자가 자율적으로 비용을 최적화할 수 있는 기능도 탑재했습니다. 개발 환경(클라우드 사용자 입장의 개발 환경)에서는 리소스의 유효 기간(lifetime)을 필수로 설정하도록 해 좀비 리소스 자동 삭제를 시행하고 있습니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/93978d2585be4983b352efb6e4828684.png?updatedAt=1768972499000" alt="리소스 유효 기간을 이용한 자동 삭제 흐름" width="1000" height="auto"></p>
<p>또한 오브젝트 스토리지에는 'High Performance'와 'Scalable(대용량·저비용)' 등 여러 유형의 버킷 클래스를 마련해 사용자가 엔드포인트를 변경하지 않고도 추후 클래스를 변경할 수 있도록 설계했습니다. 이를 통해 접근 빈도의 변화 등 업무 특성에 따라 비용과 성능을 동적으로 최적화할 수 있습니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/24d63d88f6ba4d31b853f2e0245aa7cf.svg?updatedAt=1768972513000" alt="오브젝트 스토리지 버킷 클래스" width="541" height="376"></p>
<h3 id="flava-2"><strong>Flava가 직면한 과제와 도전</strong></h3>
<p>아직 Flava는 최소한의 제품만 출시한 단계로 향후 기능을 확장하는 것이 시급한 과제입니다. 또한 개발 속도를 우선하다 보니 출시 후에 버그가 발견되거나 고려하지 못한 부분이 드러난 경우도 있는데요. 이러한 문제들을 신속하게 해결하면서 기반을 성숙시켜 나갈 예정입니다.</p>
<p>그리고 무엇보다 가장 큰 과제는 구 기반에서 마이그레이션하는 것입니다. 투명한 이전과 도구 제공 등을 통해 사용자의 부담을 줄이고 있지만 그럼에도 수동 대응이 필요한 부분은 있는데요. 신규 기반과 구 기반의 중복 투자 기간을 어떻게 단축하고 전체 비용을 최적화할 수 있을지가 이제 막 시작된 저희의 도전입니다.</p>
<h2 id="-12"><strong>스택의 진화를 뒷받침하는 팀과 문화</strong></h2>
<p>마지막으로 이 기술 스택을 계속해서 진화시켜 나가고 있는 팀을 소개하겠습니다. 저희 팀에는 커널 코드를 읽고 해석하는 저수준(low layer) 전문가부터, 모던 웹 프런트엔드로 관리 화면을 구축하는 엔지니어까지, 레이어를 넘나드는 다양한 배경의 팀원이 모여 있습니다.</p>
<p>저희의 공통점은 인프라를 블랙박스로 취급하지 않고 내부를 이해하고 주체적으로 제어하려는 자세입니다. 앞서 언급한 OSS에 깊이 참여하는 작업(업스트림에 패치 제공)도 소스 코드 레벨에서 작동 방식을 추적할 수 있는 팀원들의 기술력이 있어야만 가능한 일입니다. 저희는 또한 상용 제품을 도입할 때에도 단순한 사용자에 머물지 않고 벤더와 깊은 논의를 거치며 사양 개선을 요구하고 있습니다. 이처럼 스스로 제어할 수 있는 클라우드를 만들겠다는 자세야말로 LY Corporation의 프라이빗 클라우드를 지탱하는 원동력입니다.</p>
<h2 id="-13"><strong>마치며</strong></h2>
<p>이번 글에서는 독자적으로 진화해 온 구 LINE Corporation과 구 Yahoo Japan Corporation의 두 거대한 클라우드를 통합해 차세대 기반인 Flava로 혁신해 나가고 있는 저희의 노력을 소개했습니다. 저희 클라우드는 OpenStack과 같은 OSS를 최대한 활용하면서도 규모나 요구 사항에 맞지 않는 부분은 직접 만들어 바꾸는 접근 방식을 철저히 고수하고 있습니다. 장애 발생을 전제로 한 설계나, IaC를 이용한 철저한 자동화, 범용 하드웨어의 성능을 극한까지 끌어내는 기술, 이 모든 것은 LY Corporation의 방대한 트래픽을 안정적으로 지탱하기 위해 저희가 쌓아온 기술입니다.</p>
<p>이 글이 대규모 인프라 설계나 프라이빗 클라우드의 기술 스택에 관심 있는 분들께 참고 사례가 되기를 바라며 이만 마치겠습니다.</p>
<ul><li>관련 기사: <a href="https://techblog.lycorp.co.jp/ko/creating-the-cloud-of-the-future" target="_blank">미래의 클라우드를 창조하다</a></li></ul></div></article></div>

LINE ENGINEERING

안녕하세요. LY Corporation에서 프라이빗 클라우드 인프라를 담당하고 있는 이노우에입니다.LY Corporation의 방대한 트래픽과 데이터를 지탱하는 것은 저희가 직접 ...

LY Corporation의 클라우드 인프라 개편: 거대한 두 개의 클라우드를 통합한 차세대 플랫폼 Flava의 아키텍처 소개

댓글