본문 바로가기
NCloud/Service

[NAVER DAN25] '네이버가 Ncloud Storage를 만든 이유' 세션 요약 정리

by okms1017 2025. 12. 1.
728x90

✍ Posted by Immersive Builder  Seong

 

 

안녕하세요. Seong 입니다. 

 

지난 11.06(목) ~ 11.07(금) 양일간 코엑스에서 네이버 DAN25 컨퍼런스가 개최되었습니다.

저는 키노트 세션은 온라인으로 시청했고, 오프라인 참가는 Day2에만 참석하였습니다. 

 

DAN25 컨퍼런스는 오프라인 사전 신청 모집이 시작되자마자 기술 트랙은 30초만에 마감될 정도로 인기가 상당했는데요. 기술 트랙으로 신청을 실패하는 바람에 크리에이티브 트랙으로 신청할 수 밖에 없었고, 다행히 현장에서는 모든 세션을 들을 수 있는 기회가 있었습니다. 

 

AI, 크리에이티브, 신규 서비스 및 기능 등 다양한 세션이 준비되어 있었는데요. 그 중에서 "기본기가 경쟁력이다: 네이버가 Ncloud Storage를 만든 이유"라는 세션에 참석하였습니다. 최근 Object Storage 관련 이슈를 경험한 만큼, 해당 주제를 보다 깊이 있게 이해하고 싶었습니다. 네이버클라우드에서 Object Storage 개발을 담당하고 있는 강영상님이 발표를 진행하였으며, 기존 Object Storage와 Archive Storage를 하나로 통합하는 Ncloud Storage 서비스를 만들게 된 배경과 향후 방향성을 들어볼 수 있었습니다. 

 

다음은 세션 내용을 요약 정리한 것입니다. 

 


◆  개요

  • 네이버 스토리지 기술의 변화 
  • 자체 스토리지를 개발하는 이유 
  • 왜 Object Storage인가? 
  • 기존 Object Storage의 한계 
  • S3 API를 선택한 이유 
  • Ncloud Storage를 어떻게 만들었는지 
  • 향후 계획  

 


네이버 스토리지 기술의 변화

Ncloud Storage를 만든 배경 - 네이버 스토리지 기술의 변화

 

  • OwFS(2008)
    • 네이버 블로그, 카페 등에서 사용
    • 데이터 유실을 방지하기 위해 3-Copy 구조를 적용하여 안정성 확보 
    • 단, 1GB 데이터 저장을 위해 3GB 저장소 공간이 필요하므로 그만큼 스토리지 비용 부담이 큼  
  • Papyrus(2015)
    • 스토리지 비용 절감을 위해 Erasure Coding 기법 적용
    • 약 1.5~1.7배 수준으로 비용 효율 개선 
  • Nubes(2018)
    • OwFS와 Papyrus가 전용 라이브러리 형태로 제공되던 것과 달리, REST API를 사용하여 접근성을 향상시킴
    • HTTP 기반으로 스토리지 접근이 가능해짐 
    • Tiering 기법을 적용하여 고속/저속 스토리지 간에 데이터 이동을 지원 
  • Lemon(2021)
    • OwFS, Papyrus 스토리지 엔진의 SW 아키텍처를 개선 
    • 성능 및 안정성 개선 
  • Bingo(2024)
    • HDD/SSD가 아닌 테이프(Tape) 저장 매체를 활용
    • 속도는 느리지만 가장 저렴하게 데이터를 저장 
  • Ncloud Storage(2025)
    • 폐쇄적 생태계를 탈피하기 위해 신규 스토리지 서비스 개발  

 


자체 스토리지를 개발하는 이유 

PB 단위의 대용량 데이터를 저장하는 서비스의 경우 저장 비용이 크게 발생합니다. 예를 들어 300PB를 3-Copy로 운영하면 저장 비용만 연간 1,000억 원이 발생하는데, 여기서 10%만 절감해도 약 100억 원을 절감할 수 있는 것이죠. 이러한 비용 구조 때문에 외부 어플라이언스 스토리지에 의존하기보다는 자체 스토리지 구축을 추진하고 있고 지속적인 기술 투자를 해오고 있습니다. 

 

비용뿐만 아니라 성능 측면에서도 자체 스토리지의 강점이 있습니다. 예를 들어 치지직 서비스에서 요구하는 수준의 성능은 외부 솔루션만으로 충족이 어려우나, 자체 스토리지를 보유하고 있다면 이를 충족할 수 있습니다. 

 

또한, 기능 확장성도 차별점입니다. 필요한 기능을 내부에서 직접 개발하여 적용할 수 있으며, 공공 및 금융권에서 요구되는 신규 규제나 보안 컴플라이언스도 빠르게 반영할 수 있습니다. 

 

마지막으로 자체 스토리지를 내부 서비스뿐만 아니라 외부 고객에게 제공함으로써 클라우드 사업화를 할 수 있다는 점도 중요한 이유 중 하나입니다. 

 


왜 Object Storage인가? 

근래 생성형 AI가 확산되면서 데이터 학습과 생성 규모가 폭발적으로 증가하였고 개별 파일 단위가 아닌 전체 데이터를 대상으로 한 배치 프로세스가 필요해졌습니다. 또한, 컴플라이언스 관점에서 권한 정책 및 보관 정책을 체계적으로 적용할 필요도 있었습니다.  

 

Block Storage와 NAS의 경우 기본적인 Read/Write 기능만을 제공할 뿐 이러한 요구 사항을 충족하기 어렵습니다. 따라서 대규모 배치 프로세스, 세부 정책 제어, 그리고 메타데이터 기반 관리가 가능한 Object Storage가 필수 선택지가 되었습니다. 

 


기존 Object Storage의 한계 

 

  • Object Storage와 Archive Storage는 서비스가 분리되어 있어 두 스토리지 간에 데이터 이동이 자유롭지 않음
  • 멀티존/리전 간 버킷 복제, 버킷 정책, 버전 관리 등 주요 기능 미지원 
  • QoS 제어 부족으로 특정 사용자가 대량의 연산을 수행할 시 다른 사용자에게 영향이 전파되어 장애가 발생할 수 있음
  • 특정 사용자에 대한 장애 격리(isolation)가 어려움 
  • 구조적으로 신규 기능 확장이 어려움 

 


S3 API를 선택한 이유 

2006년 AWS가 S3를 출시한 이후 S3 API는 사실상 업계 표준이 되었습니다. 인터넷만 연결되어 있으면 어디서든 동일한 방식으로 접근할 수 있으며, 사용자는 스토리지 장비가 어느 지역에 있든지 신경쓰지 않아도 됩니다. 단순하게 기능이 정상적으로 동작하고 성능만 보장된다면 무한한 확장성을 제공하는 것이죠. 

 

S3는 데이터를 여러 가용 존에 복제함으로써 높은 서비스 가용성과 낮은 데이터 유실 가능성을 보장합니다. 또한, 다양한 오픈소스와 생태계가 S3 API를 기본적으로 지원하므로 연동 및 호환성 측면에서도 유리합니다. 이러한 이유로 자연스럽게 S3 API를 선택하게 되었습니다. 

 


Ncloud Storage를 어떻게 만들었는지 

표준 S3 API는 100여 개 이상이며 공식 문서 또한 1900 페이지에 달합니다.

현재 Ncloud Storage에서는 주요 기능 약 20여 개를 우선 선정하여 단계적으로 구현하고 있습니다. 

 

Ncloud Storage를 구성하는 주요 컴포넌트 및 개념을 정리하면 다음과 같습니다. 

 

IAM

네이버클라우드는 자체 IAM 서비스를 통해 모든 사용자에 대한 키와 권한 정보를 중앙에서 관리합니다. S3 Gateway를 통해 사용자 요청이 들어오면 IAM 서비스가 해당 요청의 허용 여부를 검증하여 인증 절차를 수행합니다. 또한, IAM 연동을 통한 RBAC 기능을 지원하고 있습니다. 

 

HA & LB

Ncloud Storage는 고가용성과 부하 분산을 위해 nfront를 사용합니다. nfront는 사용자와 백엔드 서버 사이에서 문지기 역할을 수행하는 시스템입니다. nfront를 통해 들어온 요청은 n개의 S3 Gateway로 분산되어 처리됩니다. 

 

Region & Global Meta & Meta

리전은 여러 IDC를 그룹화한 개념입니다. Global Meta는 버킷별 리전 정보를 관리하는 저장소 시스템입니다. 버킷명은 리전과 무관하게 고유한 값을 가져야 하므로 이 Global Meta가 중복 생성 여부를 판단하고 제어하는 역할을 합니다. 그리고 Meta는 해당 리전에 생성된 버킷과 오브젝트 정보를 관리하는 저장소 시스템입니다. 한 리전의 Meta는 독립적으로 운영되므로 해당 리전에 장애가 발생하더라도 다른 리전에는 영향이 전파되지 않습니다. 

 

Consistency

버킷과 오브젝트의 생성·수정·삭제 연산은 항상 일관성을 유지해야 합니다. 하지만 연산 도중 API 호출 클라이언트나 S3 Gateway, GC 등의 내부 컴포넌트가 중단될 수 있기 때문에, 이를 대비해 Object Change Event라는 WAL(Write-Ahead Log) 방식을 적용합니다.

 

S3 Gateway에서 연산이 발생하면 해당 변경 내용을 Object Change Event에 먼저 기록하고, GC 모듈은 이 이벤트를 기반으로 실제 처리를 수행하여 강한 일관성(Strong Consistency)을 보장하고 있습니다. 

 

Storage Class

S3는 성능과 비용에 따라 Storage Class를 구분하고 있습니다.

 

  • Standard: 자주 접근하는 데이터 
  • Standard-IA: 자주 접근하지 않고 Standard에 비해 상대적으로 응답속도에 민감하지 않은 데이터 
  • Glacier IR: 거의 접근하지 않고 ms 단위의 접근이 필요한 데이터 
  • Glacier DA: 1년에 한 두 번 가량 접근하는 정도로 드물게 접근하는 데이터 

또한, Lemon이 디스크 기반의 스토리지 클래스를, Bingo가 테이프 기반의 스토리지 클래스를 처리하고 있습니다. 현재는 Standard와 Deep Archive 두 가지 스토리지 클래스를 제공하고 있으며, 향후 더 다양한 스토리지 클래스 옵션을 제공할 예정이라고 합니다. 

 

Erasure Coding(EC)

EC 4+2

Erasure Coding은 데이터를 여러 조각과 패리티로 분산 저장하여 일부가 손실되어도 복구할 수 있는 기법입니다. 예를 들어 EC 4+2 적용 시, 데이터는 4개의 데이터 블록과 2개의 패리티 블록으로 구성됩니다. 총 6개의 블록 중 4개만 존재하여도 원본 데이터를 복구할 수 있어 데이터 유실 가능성을 낮춰줍니다. 여기서 각 블록을 2개씩 서로 다른 IDC에 분산 배치하였다고 하면, 특정 IDC에 화재나 장애가 발생하더라도 나머지 블록을 통해 데이터를 유지할 수 있고 필요 시 다른 IDC로 복구도 가능합니다. 이를 통해 데이터 가용성과 안정성이 크게 향상됩니다. 만약 EC 7+5 적용 시에는 기존 3-Copy 대비 데이터 유실 가능성이 약 1800억분의 1 수준으로 낮아집니다. 

 

Information Lifecycle Management(ILM)

ILM은 다양한 스토리지 클래스 간에 데이터 이동을 담당하는 모듈입니다. ILM Rule과 Meta, Object Change Event를 기반으로 어떤 오브젝트가 언제 변경되었는지, 어떤 조건에서 이동해야 하는지 등을 판단하여 처리합니다. 

 

  • transition : 상위 스토리지 클래스 → 하위 스토리지 클래스로 오브젝트 이동 
  • restore : 하위 스토리지 클래스 → 상위 스토리지 클래스로 오브젝트 복사 

 

Quality of Service(QoS)

QoS 제어를 위해 토큰 버킷 방식을 사용합니다. 요청이 들어올 때마다 토큰을 하나씩 소모하며 토큰이 소진되면 요청을 차단하는 방식입니다. 이를 통해 일정 기간 동안 임계값을 초과하는 과도한 요청을 효과적으로 제한할 수 있습니다. 

 

또한, Weighted Fair Queue(WFQ)를 적용하여 대규모 연산 작업을 분산 처리하고 있습니다. 작업을 여러 큐로 나누어 스케줄링하는 구조로, 10억 개의 오브젝트 삭제나 100만 개의 transition 처리와 같은 대규모 배치 작업에서도 안정적인 QoS를 보장합니다. 

 

Metering

클라우드 사업 시에는 사용자에게 정확한 이용 요금을 청구해야 하므로 정확한 미터링이 필요합니다. 이를 위해 Object Change Event를 기반으로 스토리지의 Bucket Size와 Object Count를 지속적으로 갱신합니다. 또한, S3 Gateway는 모든 Access Log를 Ncloud Storage에 저장하며, Object Change Event에 기록되지 않는 Read 요청의 경우 이 Access Log를 함께 활용하여 API 호출 수와 트래픽 사용량을 계산합니다. 

 


향후 계획 

  • Object Storage & Archive Storage 대체 (deprecated 예정) 
  • Storage Class 스펙트럼 다변화 
  • 일본, 독일, 미국 리전 추가 지원 
  • 지속적인 추가 API 개발
  • 안정성 & 비용 구조 개선 

 


[출처]

1) https://dan.naver.com/25/sessions/727

 

기본기가 경쟁력이다 : 네이버가 Ncloud Storage를 만든 이유

발표자 : 강영상

dan.naver.com

2) https://tv.naver.com/v/89041675

 

네이버

[팀네이버 컨퍼런스 DAN25] 기본기가 경쟁력이다: 네이버가 Ncloud Storage를 만든 이유

tv.naver.com

728x90