30페타바이트 하드 드라이브로 프리트레이닝용 스토리지 클러스터 구축

 (si.inc)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 컴퓨터 사용 문제 해결을 위한 모델 프리트레이닝을 위해 9천만 시간 분량의 비디오 데이터 저장을 목표로 샌프란시스코 도심에 직접 스토리지 클러스터 구축을 진행
  • 온프레미스 방식을 선택하여 연간 $354k(5억원) 로 30PB 저장 인프라 운영 가능. AWS의 경우에 $12m(170억원)이므로 약 34배 비용을 절감
  • 대부분의 퍼블릭 클라우드와 달리 고가용성 및 무결성을 중시하지 않고, 훈련 데이터 특성상 데이터 손실 감내 전략을 적용
  • 간단한 Rust 및 Nginx 기반 소프트웨어로 운영하며, Ceph나 MinIO 같은 복잡한 시스템 대신 직접 제작한 200줄짜리 프로그램으로 관리 중
  • 프로젝트 진행 과정에서 물리적 배치와 네트워크 구성, 케이블 관리 등 여러 현실적 시행착오와 노하우를 경험함

서론 및 배경

  • 컴퓨터 사용을 위한 모델 프리트레이닝에는 대용량의 비디오 데이터가 필요함
  • 일반적인 텍스트 LLM(예: LLaMa-405B)은 약 60TB의 데이터로도 충분하지만, 비디오 기반 훈련엔 500배 더 많은 저장 공간이 요구됨
  • AWS 같은 퍼블릭 클라우드 활용 시 연간 1,200만 달러가 소요되지만, 콜로케이션 센터 임대 및 직접 구축으로 이를 약 35만 4천 달러로 대폭 절감할 수 있었음
  • 대용량 데이터를 자체적으로 보관함으로써 데이터 비용이 가장 큰 제약이던 문제를 해결함

왜 직접 구축했는가

  • 클라우드는 고신뢰성, 중복성, 데이터 무결성에 초점을 두지만, 프리트레이닝용 데이터는 5% 손실도 허용할 수 있을 정도로 크리티컬하지 않음
  • 이러한 특성 덕분에 일반 기업 대비 훨씬 느슨한 신뢰성 요구조건을 선택할 수 있었음 (13나인의 신뢰성 대신 2나인 적용)
  • 스토리지 가격이 실제 원가 대비 훨씬 높게 책정됨
  • 데이터가 가장 큰 비용 요소이며, 충분히 예측 가능한 범위 내에서 로컬 데이터센터 구축 비용이 유리하다고 판단함

비용 비교: 클라우드 vs 자체 구축

  • 월 recurring 비용: 인터넷 $7,500 + 전기 $10,000 = 총 $17,500
  • 일회성 비용: 하드 드라이브 $300,000, 샤시 $35,000, CPU 노드 $6,000, 설치비 $38,500, 노동력 $27,000, 네트워크 및 기타 설치비 $20,000 → 총 $426,500
  • 감가상각(3년) 포함 월 고정비 $29,500로 계산
  • AWS 월 $1,130,000, Cloudflare R2 월 $270,000, 직접구축 월 $29,500
    • AWS: TB당 약 38달러/월
    • Cloudflare: TB당 약 10달러/월
    • 자체 구축: TB당 1달러/월
  • 대규모 모델 학습에서는 Cloudflare마저 내부 시스템 심한 부하에 rate-limit 이슈 발생했으나 본인들 구축환경에서는 100Gbps 전용 회선으로 문제 해결함

구축 및 프로세스

  • 신속한 구축을 위해 Storage Stacking Saturday(S3) 계획, 주변 지인의 도움과 전문 컨트랙터 투입
  • 36시간 동안 2,400개의 하드 드라이브를 랙에 장착해 30PB 하드웨어 완성
  • 소프트웨어는 Rust(쓰기 담당, 200줄) + nginx(읽기 담당) + SQLite(메타데이터 추적)
    • Ceph, MinIO, Weka, Vast 등은 복잡도/비용 문제로 사용하지 않음(복잡성, 필요성 없음, 유지보수 부담 등)
    • 모든 드라이브 XFS로 포맷

프로젝트 피드백 및 교훈

잘한 점

  • 중복성/성능 트레이드오프를 적절히 적용해 100G 네트워크 거의 가득 채워 활용
  • 물리적으로 가까운 곳에 구축해 디버깅, 유지보수 용이성 확보
  • 벤더는 eBay에서 찾되 실제 구매는 개별 공급업체와 직거래, 워런티 필요성 강조
  • 100G 인터넷 회선 많은 장점, 네트워크 이슈도 자체 디버깅 용이
  • 고품질 케이블 관리가 추후 문제 해결에 큰 도움
  • 복잡한 오픈소스 저장 시스템 대신 단순화 원칙 적용, 유지보수 부담 최소화
  • 시간/노동 비용 예측도 정확했으며, 절감 효과 확실하게 확인

어려웠던 점 및 시행착오

  • 프론트로더 사용으로 2,400개의 HDD를 하나씩 직접 장착하는 번거로움
  • 스토리지 밀도 부족, 초기 설계에서 더 높은 밀도 채택시 노동 절감 가능성
  • 데이지체인은 속도 병목 유발, 각 샤시에 별도 HBA 연결이 이상적
  • 네트워크 부품은 브랜드 호환성 중요, 특히 광트랜시버
  • 네트워크 구성 실험/설정에 시간 소요, DHCP/NAT 대신 퍼포먼스와 편의성 중심으로 구성(firewall/secure link 최소 요건만 적용)
  • 물리적 접근성, 셋업 시 모니터/키보드 배선의 중요성 체감

시도해볼 만한 아이디어

  • KVM 및 IPMI 활용으로 원격 관리 효율화
  • 관리자 이더넷 네트워크 별도 구성 권장
  • 네트워크 오버프로비저닝(예: 400G 내부망도 고려할 만함)
  • 더 높은 밀도의 서버(90-drive Supermicro/20TB HDD 등)로
    랙 수 절감, 전력 절감, CPU 집적 효과 등 유리

어떻게 직접 구축할 수 있는가

스토리지 구성

  • 10대의 CPU 헤드 노드 (Intel RR2000 등, 각 서버당 듀얼 Intel Gold 6148/128GB ECC DDR4 RAM 권장)
    • CPU 부담 높은 기능(ZFS 등)은 더 성능 좋은 장비로 선택 가능
  • 100개 DS4246 샤시(각각 24개 HDD 장착)
  • 2,400개 3.5" HDD (가능하면 SAS 드라이브 추천, 속도 이점)
    • 다양한 용량(12TB, 14TB 등) 조합, 대용량일수록 배치/중고가치 유리
  • 물리적 장착을 위한 레일/브라켓류, 장비 배선 및 케이블
  • 네트워크 이슈 디버깅용 crash cart(모니터+키보드) 다수

네트워크 인프라

  • 100GbE 스위치(중고 Arista 등, QSFP28 포트)
  • 각 서버별 HBA(권장: Broadcom 9305-16E 등), HBA 포트/샤시 연결 방식
  • 네트워크 카드(Mellanox ConnectX-4 등, 반드시 이더넷 모드)
  • DAC/AOC 케이블—랙 간 거리 고려 시 DAC가 호환성 이점
  • CPU 헤드노드 구매 시 HBA/NIC 사전 장착된 공급업체 활용 추천
  • 시리얼 케이블, 관리 이더넷 별도 네트워크(backup 용 무선 어댑터 + mini 스위치 대안)

데이터센터 요구사항

  • 캐비닛당 3.5kW 사용전력, 42U 기준으로 4U×10 + 2U×1 구성을 가정
  • 3PB/캐비닛, 스위치용 여분 42U 캐비닛 1개 또는 섀시 1U 대체
  • 전용 100G 크로스커넥트(보통 QSFP28 LR4 광 한쌍), 폼팩터·브랜드 호환 사전 확인 필수
  • 사무실과 가까운 입지(코로케이션) 추천가 문제 발생시 신속한 물리적 대응 가능하여 디버깅·운영 생산성 최적

초기 설정 팁

  • 스위치 1차 로컬 콘솔 구성 후, 100GbE 업링크 포트 설정과 광 트랜시버 호환성을 먼저 검증
    • 필요 시 ISP 광을 NIC에 직결해 링크-업 확인 후 스위치로 이전
  • Ubuntu 설치 중 Netplan으로 노드 네트워킹 설정을 끝내는 편이 수월
  • 노드 인터넷 연결 후, 각 DS4246 1케이블 연결→포맷/마운트→상태 점검 순으로 진행해 배선·디스크 불량 조기 검출

성능·안정성 주의점과 보안

  • 학습 데이터 전용이라는 보안 전제 하에 공인 IP 직결 + 포트 방화벽 + nginx secure_link로 간소 운용
    • 고객 데이터 취급 시 동일 구성은 부적절, DHCP/NAT/세분화 방화벽 필수
  • 데이지체인은 관리·배선은 간편하나 대역폭 병목 유발, 가능하면 섀시당 전용 HBA 권장
  • 광 트랜시버는 브랜드 락인이 심함, FS.com 과 아마존 을 병행 소싱하되 스펙·브랜드 일치 확인 철저

결론 및 의미

  • $1/TB-월 수준의 초저가 자가 스토리지로 30PB 비디오 사전학습을 현실화, 클라우드 대비 10–38배 비용 절감 달성
  • 단순 아키텍처와 현장 접근성이 시간·리스크를 줄였고, 100G 전용 회선이 I/O 병목을 해소
  • 대규모 멀티모달·비디오 모델 시대의 핵심 경쟁력은 저비용 대용량 데이터 인프라이며, 본 접근은 소수 인원으로도 구현 가능한 실전 레퍼런스 제공

마무리 및 협력 안내

  • 본 글을 참고해 유사한 스토리지 클러스터를 구축한 경우 개선점 및 경험 공유를 바람
  • 대규모 컴퓨터 사용 모델 사전학습과, 일반화·인간 가치 연계된 인공지능 연구 인력 채용 중 (jobs@si.inc 연락처 안내)

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 처음 커리어를 시작할 때는 온프레미스가 당연한 환경이었음, 오래 가는 하드웨어는 결국 정성을 쏟게 되고 각 서버마다 상태가 누적됨, 시간이 지나서 하드웨어 성능이 부족해지면 내부 팀을 통해 새로운 하드웨어를 기존 리스트에서 골라야 하고 추가 비용 승인도 받아야 해서 번거로움이 있음, 하드웨어 교체 과정이나 펫같이 아껴온 장비를 철저히 분리해서 새 장비로 전환하는 과정에서 프로젝트가 지연되기도 함, 클라우드가 등장하면서 “이제는 무조건 클라우드 전환”이라는 생각을 갖게 됐음, 그런데 시간이 지나면 자신과 조직이 직접 하드웨어 관리하는 법을 잊게 되고, 결국 다시 그 기술을 되살리지 않으면 좋은 선택이었던 클라우드가 점점 덜 매력적인 선택이 됨, 그래서 이런 기술을 다시 기르게 해줘 고마움

    • 우리는 좀 독특한 상황임, 초기부터 하이퍼스케일 클라우드를 운영비로 감당할 수 없는 입장이어서 어쩔 수 없이 자체 기술을 키워왔음, 생각보다 그리 어렵지 않고 당분간은 이 방식으로 계속 할 예정임, 다만 언급한 상태 누적 문제는 좀 보이고 있음

    • 기억 속 온프레미스는 항상 비용이 더 저렴했음, 여러 물류 장애물이 사라지고 하나의 청구서로 편리해지는 점이 있었음, 클라우드 각광받을 때 조언은 항상 온프레미스를 쓰고, 갑작스럽게 트래픽 오르내릴 때만 클라우드를 써라는 거였음, 그런데 임시 확장 사용이 점점 상시 사용이 되고, 개발자들이 새로운 머신을 바로 띄우는 데에만 의존하게 됨, 이제는 모두가 클라우드를 기본 상태로 여기게 됐음, 그 과정에서 실제 비용을 제대로 감지할 기반을 잃었고 클라우드와 온프레미스 간의 비용 차이가 점점 더 벌어졌음

    • Docker는 서버를 펫이 아닌 존재로 만들어 주는 아주 훌륭한 도구임, 랙에 있는 서버가 그냥 또 하나의 K3나 K8 노드로 취급돼서 펫처럼 다루지 않게 됨, 이 점이 정말 좋음, VM도 비슷하게 얘기할 수 있겠지만 결국 VM 자체가 펫이 됨, 물론 이미지를 만들거나 스냅샷은 가능하지만 Docker에서 느껴지는 변화와는 다름

    • 한 번 더 이런 도전을 해볼까 하는 농담식 질문

  • .inc 두 글자 도메인을 아무렇지 않게 살 수 있을 정도로 돈이 많은 스타트업은 자금이 과도하게 많은 것임, 예전 스타트업에서 사무실에 얼마나 많은 Aeron 의자가 있는지 세는 것과 같은 현상임, 좋은 신호는 아님

    • 사용 안 된 .inc 두 글자 도메인이 연 $2300에 팔리고 있음, 개발자 한 명 인건비의 5%도 안 되는 금액임

    • .inc 도메인 이름에 실질적 가치가 있는지는 의문임

  • 재밌는 글임, 읽으면서 대리만족 얻음, 이런 경험을 더 재밌게 보려면 사진이 좀 더 많았으면 하는 바람임

    • 만약 작성자들이 댓글 달면 직접 Standard Intelligence PBC가 무슨 일을 하는지 궁금함, Public Benefit Corporation인지, 아니면 어떤 프로젝트 하고 있는지 물어보고 싶음

  • 기술적인 내용이 자세하게 써 있어서 좋았음, 궁금한 게 있는데, 콜로케이션 공간을 구하는 과정이 어땠는지 알고 싶음, 브로커를 썼는지, 가격 협상으로 처음 견적에서 실제로 낸 가격이 얼마나 달랐는지 궁금함

    • 샌프란시스코와 프리몬트 내 대부분의 콜로케이션 업체에 견적을 요청했음, 견적과 실제로 결제한 가격 차이는 없었음, 다만 조건과 일회성 비용은 협상함

  • 링크된 Discord 블로그 포스트도 흥미로움, 주로 진지한 내용이지만 이런 재밌는 부분도 있었음: 월드컵 골이 들어가면 그 데이터가 모니터링 그래프에 바로 반영되어 팀원들이 미팅 중 축구 경기를 본 걸 업무용 모니터링으로 둘러댈 수 있었음, 시스템 실 사용량이랄지, Discord가 “페타바이트 미만” 스토리지로 메시지를 저장한다는 근거로 인용됐음, 추측하건대 이 글의 노드 크기와 갯수로 계산하면 예전 클러스터가 708TB, 새로운 셋업이 648TB 정도로 나온다고 함, (성장 여력 포함)

  • 저장 자체는 매우 저렴함, 그런데 트레이닝과 네트워킹 셋업 부분이 이해가 안 됨, 다른 댓글에서 GPU가 한 군데에 있지 않다고 들었는데, 그러면 여러 사이트 간 100Gbps로만 학습 데이터를 주고 받아야 함, 이렇게 하면 프리트레이닝 과정에서 병목이 생기지 않을지 걱정임

    • 현재는 100기가 링크 한 줄만 갖고 있고, 일단 GPU 클러스터들도 데이터 송수신이 그 정도만 처리 가능함, 앞으로 확장하면서 대역폭과 저장공간도 늘릴 예정임, 참고로 콜로 내에 4090 여러 대가 있는데, 데이터 분할이나 임베딩 작업에는 엄청 유용했음

  • 사이즈가 이 정도 나오는 워크로드라면 AWS나 다른 클라우드에서도 프라이빗 견적을 충분히 받아볼 수 있음, S3의 경우 0.5PB만 돼도 별도 견적을 받을 수 있음, 전체 비용 자체가 따로 관리하는 것보다 더 싸다는 의미는 아니지만, CSP의 리테일 가격과 이베이에서 구한 장비 + 무료 노동(피자값 제외) 비교가 온전한 비교는 아님

    • AWS나 클라우드에서 egress 비용이 정말 핵심임, 그 부분은 협상 시도해도 전혀 양보해주지 않음, AI 트레이닝용으로는 아예 쓸 수 없는 수준임, 클라우드플레어 견적은 관리형 오브젝트 버킷 스토리지 중에서도 저렴한 편임, 자체 클러스터를 구축하면 관리형 서비스와의 차이가 작아지긴 했음, 자체 구축이 협상력을 주기도 하고, 그러나 관리형 버킷은 단순 프리트레이닝 저장용으로는 지나치게 오버스펙임, Glacier가 아카이브 용도로는 가성비 좋은데 ML 용도로는 딱 맞는 제품이 아직 없음

    • 구체적으로 어느 정도의 딜을 할 수 있다는 것인지 궁금함, 절반 이상 할인도 가능한지 궁금함

  • 드라이브 장착하는 작업을 함께해서 즐거웠음, 이렇게 많은 데이터를 실제로 다루는 작업이 가장 신나는 경험임 :P

  • 디스크 장애율에 대한 언급이 없음, 몇 달 지나고 나서 상태가 어떤지 궁금함

    • 예전에 올린 경험인데, 디스크 어레이 여러 개 올릴 때 대량의 드라이브 장애가 발생한 적 있음, 금요일 오후에 랙 세팅하고 주말 동안 손대지 않는 채 간단한 쉘 스크립트로 데이터 읽기/쓰기 테스트를 돌렸음, 월요일에 와보니 거의 절반에 가까운 디스크가 망가진 상태로 아무 로그도 남지 않음, 스트라이핑 과정에 문제 있었는지, 스트레스 테스트에서 터졌는지 알 길이 없음, 공장 불량 배치였고, 같은 회사 고객 여러 명이 불만을 제기함, 제조사에서 전량 교환해줬고, 프로덕션 투입만 늦춰졌음, 그 후에는 1년 동안 아무런 장애가 없었음

    • 최근 10년 전과 비교해 디스크 장애율이 매우 낮아졌음, 예전에는 한 주에 10개도 넘게 교체했지만, 지금은 드물게 일어나는 일임, Backblaze의 하드디스크 통계만 확인해도 충분하다고 생각함

    • 해당 클러스터는 엔터프라이즈 드라이브를 쓴다고 했는데, 비용을 아끼려다 보면 나중에 큰 손해가 날 수도 있음, 개인적으로 홈 서버용으로 중고 드라이브를 써보니 성능 편차가 너무 심해서 별로였음

    • 좋은 지적임

답변달기