17P by xguru 2022-03-28 | favorite | 댓글 3개

HN에 올라온 질문과 답변들

  • Nix로 매월 페타 데이터를 처리하는 수천 CPU코어와 수백 종류의 데이터 파이프라인을 운영중
  • WhatsApp은 페북에 인수되기 전 베어메탈 서버에서 FreeBSD로 운영. BEAM 및 어플리케이션 코드를 rsync로 처리했음
  • Grooveshark는 소수의 물리 서버만으로 45M MAU를 처리. nginx + PHP + MySQL + 멤캐쉬 + Go로 작성된 실시간 메시징 서버
  • 2010년에 MySpace의 분석 시스템은 14개의 EC2 인스턴스로 동작했고, ESPN의 스트리밍 서비스도 수백만 동시 접속을 VM만으로 처리. 월 45M 방문자 웹사이트도 싱글 EC2인스턴스로
    → K8s + Docker는 알려진 것 보다 훨씬 무거움
  • Fly.io는 고객들에겐 컨테이너를 제공하지만, 자신들의 인프라에선 컨테이너를 많이 사용하지 않음(고객들 대상 API서버등을 제외하고)
  • Guardian은 수백대의 EC2 인스턴스를 공식 이미지로 만든 EC2 이미지를 설치해서 사용(도커가 De facto가 되기 전에 이미 구축). 도커로 옮기는 걸 고려했지만, 스택이 JVM기반이라 도커를 사용하는 것이 큰 이점이 없음.
  • 200여대의 서버를 베어메탈에서 Ansible로 관리중. PXE 부팅으로 이미지 관리. 커스텀 Arch 리눅스 이미지로 몇개의 스크립트를 사용하며, 20년째 이렇게 잘 쓰고 있음
  • 스택오버플로우는 2016년까지는 컨테이너를 사용하지 않았음
  • Freebsd Jails와 Rust로 작성된 경량 오케스트레이션 도구를 사용. 수백대의 64코어 라이젠 머신을 운영중이며, 아마존에서 운영하는 것에 비해 1/6 정도로 훨씬 저렴하며 성능은 훨씬 뛰어남

관리의 편의를 위해 도커는 쓰지만 Kubernetes는 대부분의 경우 오버스펙이죠. 여러 노드를 운영한다 쳐도 대부분은 도커 스웜 레벨에서 다 커버 가능하다고 봅니다.

최근에 HN에서 본 글입니다.
반대로 쿠버네틱스를 고성능으로 운영하는 팁이네요.
https://medium.com/pinterest-engineering/…

대규모가 기준에 따라 다르겠지만 HPC는 아무래도 베어메탈 기반으로 운영했었죠..
전 직장에서 Rack 42U사이즈 50개 분량을 HPC로 구성해서 운영했었으니까요.
운영의 문제였죠. 문제 발생했을 때 기존 HW, OS, Grid Engine, User Script 에서만 찾을걸
컨테이너에서까지 범위를 넓힐 이유가...