Railway의 자체 데이터센터 구축기

 (blog.railway.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Railway는 GCP 기반 컴퓨트가 가격·지원·기능 개발을 제약한다고 보고, 더 직접 통제할 수 있는 물리 인프라인 Railway Metal을 시작함
  • 2024년 1월 착수 후 첫 서버 연결까지 5개월, 사용자 워크로드 투입까지 추가 3개월이 걸렸고, 9개월 뒤 캘리포니아 첫 사이트가 가동됨
  • 공간 임대보다 더 큰 제약은 전력과 냉각이었으며, Railway는 Greenfield나 랙 단위 임대 대신 Cage Colocation을 선택함
  • 네트워크는 지역별 최소 2개 ISP, 전체 인터넷 라우팅 테이블, IP prefix별 경로 선택, 여러 zone 설계로 단일 데이터센터 장애에 대비함
  • 랙 배치, 케이블 문서, PDU, 역방향 airflow 스위치, Redfish API, PXE, FRR, SONiC까지 직접 다뤄야 하며, 자체 클라우드 구축은 Terraform 배포보다 집을 짓는 일에 가까움

GCP에서 Railway Metal로 옮긴 이유

  • Railway의 컴퓨트는 초기부터 Google Cloud Platform 위에 구축돼 있었음
  • GCP는 초기 성장에는 도움이 됐지만, 운영이 커지면서 고객에게 원하는 플랫폼을 제공하는 데 한계가 생김
  • 하이퍼스케일러 기반 운영은 Railway가 제공할 수 있는 가격, 서비스 수준, 기능 개발 범위를 직접 제한함
    • egress fee가 가격에 영향을 줌
    • 상위 인프라에서 문제가 생겨도 원인을 이해하는 경우가 드묾
    • 연간 수백만 달러를 지출해도 지원 수준은 100달러를 쓰는 것과 크게 다르지 않다고 평가함
  • Railway는 이에 대응해 2024년에 Railway Metal 프로젝트를 시작함
    • 9개월 뒤 캘리포니아 첫 사이트를 가동함
    • cage 안의 광섬유 케이블부터 ISP 계약까지 설계, 사양 정의, 설치를 직접 진행함
    • 추가로 3개 데이터센터 region을 켜는 중임

첫 공간 선택: 데이터센터 cage

  • Railway Metal 프로젝트는 2024년 1월 시작됐고, 첫 서버를 연결하기까지 5개월이 걸림
  • 사용자 워크로드를 하드웨어에 올려도 된다고 판단하기까지 추가로 3개월이 필요했음
  • 자체 인프라에는 서버를 둘 공간, 안정적인 전력, 충분한 냉각이 필요함
  • 선택지는 크게 세 가지였음
    • Greenfield buildout: 데이터센터를 구매하거나 임대함
    • Cage Colocation: 사업자 데이터센터 안에 메시 벽으로 둘러싸인 전용 공간을 확보함
    • Rack colocation: 코로케이션 데이터센터에서 개별 랙이나 랙 일부를 임대함
  • Railway는 네 벽, 보안 문, 나머지를 직접 설계할 수 있는 빈 공간을 얻기 위해 Cage Colocation을 선택함
  • 공간 자체 비용은 크지 않지만, 전력과 그에 따른 냉각 비용이 가장 큼
    • 지역에 따라 kW당 비용 차이가 큼
    • 미국 서부에서는 싱가포르보다 절반 이하로 낼 수도 있음
    • 전력은 실제 사용량과 무관하게 온디맨드 가용성을 보장하기 위해 월정액 commit으로 지불함

전력 설계와 PDU

  • Railway는 GCP에서 쓰던 용량에 맞추기 위해 목표 vCPU 수, RAM GB, NVMe TB를 먼저 정함
  • 이 수치를 바탕으로 서버와 CPU를 선택함
  • 핵심 변수는 특정 전력 소비 안에 원하는 컴퓨트 밀도를 넣는 전력 밀도였음
  • 전력 계산은 watt 합산만으로 끝나지 않으며, 특히 3상 전원에서는 더 복잡함
  • 데이터센터에서 전력은 가장 중요한 자원이고, 정전은 복구 시간이 매우 길 수 있음
  • 각 랙에는 완전히 독립적인 전력 feed 2개가 필요함
    • 평상시에는 두 feed가 부하를 나눔
    • 하나의 feed가 내려가도 견딜 수 있어야 함
  • 서버에 전력을 전달하려면 Power Distribution Unit이 필요함
    • 기본 PDU는 사실상 확장 멀티탭에 가까움
    • Railway가 배치하는 PDU는 개별 소켓 제어와 계측이 가능함
    • 각 PDU는 네트워크로 접근할 수 있고, 개별 소켓을 원격으로 계측·제어할 수 있음

네트워크: ISP, 라우팅, 지역별 경로

  • 클라우드 머신은 단독으로 존재하지 않으므로 네트워크가 핵심 역할을 함
  • Railway는 낮은 지연 시간을 위해 외부 세계와 견고하게 연결된 데이터센터 시설을 찾음
  • 선호 조건은 다음과 같음
    • Tier 1 ISP와 on-network 상태임
    • Internet Exchange에 포함됨
    • 가까운 다른 데이터센터로 연결할 수 있는 광섬유가 있음
  • Railway에 배포된 애플리케이션은 다양한 엔드포인트와 통신함
    • 시드니의 가정용 인터넷 사용자
    • 미국 AWS 서버에 호스팅된 API
  • 낮은 지연 시간과 낮은 대역폭 비용을 위해 Railway는 사용 사례별로 최적화된 여러 인터넷 제공자와 계약함
  • ISP는 목표 지역에서의 네트워크 성숙도를 기준으로 고름
    • 잘못된 ISP와 협력하면 특정 목표 시장까지 추가 네트워크 hop이 생겨 지연 시간이 늘어날 수 있음
    • 최악의 경우 복잡하게 꼬인 네트워크 경로가 생길 수 있음
    • 각 지역에서 지역 footprint를 기준으로 최소 2개의 별도 네트워크를 선택함
  • 연결 후 각 ISP에서 전체 인터넷 라우팅 테이블을 받고, 네트워크 스위치에서 이를 통합해 IP prefix별 최적 경로를 결정함
    • 호주 사용자가 싱가포르에 배포된 앱에 접근하면 Telstra로 패킷을 넘길 가능성이 높음
    • 같은 앱이 일본의 사용자나 서버로 패킷을 보내면 PCCW로 넘길 가능성이 높음
  • Peering 정보는 공개돼 있으며 bgp.tools에서 네트워크 상호 연결을 볼 수 있음
  • 이중화를 위해 각 region 안에 여러 zone을 구축하고, 사이트 간 상호 연결도 확장에 중요함
    • dark fiber나 wavelength service 같은 도구를 검토함
    • 앱은 데이터베이스가 같은 방에 있든 4블록 떨어진 이웃 건물에 있든 차이를 느끼지 않게 하는 방향임
    • 개별 데이터센터 장애에 대한 복원력을 높이기 위한 설계임

랙, 통로, 냉각, 케이블 경로

  • 데이터센터에서는 랙을 줄로 배치하고 랙 사이 통로를 공기 흐름에 사용함
  • Cold Aisle에는 시설에서 찬 공기가 들어오고, 서버는 이 공기를 빨아들인 뒤 뒤쪽 Hot Aisle로 배출함
  • 효율을 높이려면 Cold Aisle과 Hot Aisle 사이의 공기가 섞이지 않아야 함
  • 랙은 19인치 폭 장비를 쓰더라도 높이, 폭, 깊이를 장비와 케이블 요구에 맞게 선택할 수 있음
  • 대부분의 서버 장비는 유지보수를 위해 레일 위에서 앞으로 당겨낼 수 있으므로, cage 치수가 이를 허용해야 함
  • 케이블과 케이블 관리에도 공간이 필요해 랙을 얼마나 빽빽하게 채울지와 cage 안에 몇 개의 랙을 넣을지 사이에 절충이 생김
  • Railway의 경험에서는 실제 공간보다 전력과 냉각이 더 자주 제약이 됨
  • 신규 사이트에서는 케이블을 배기 경로에서 치워 airflow를 개선하기 위해 800mm 폭의 더 넓은 랙을 선택함
  • 랙 외에도 전력과 데이터를 전달하기 위한 상부 인프라와 트레이가 필요함
    • cage 가장자리에서 각 랙까지 광섬유를 라우팅함
    • 랙 사이 케이블도 라우팅함
    • 이런 항목은 데이터센터 운영자가 cage 견적에 포함하는 경우가 있음
  • Railway는 랙마다 switch-to-server 광섬유 케이블 밀도가 높기 때문에 포트가 랙 뒤쪽을 향하는 reverse airflow switch를 구매함
    • 네트워크 포트가 있는 쪽으로 배기하는 스위치임
    • 케이블 트레이를 맞춰 모든 케이블링이 랙 한쪽에서 이뤄지게 함
    • 랙 앞뒤로 케이블이 지그재그로 오가는 상황을 피함

설치 문서와 rack-and-stack

  • Railway는 처음 직접 케이블링을 시도했지만 결과가 고르지 않았고, 제대로 설치하기 위해 전문가를 투입함
  • 설치 전문가가 무엇을 어디에 설치해야 하는지 알 수 있도록 포괄적인 문서 패키지가 필요함
  • 일반적인 문서는 두 가지임
    • Cabling matrix: 각 케이블 양쪽 끝의 장비 위치, 포트, 케이블 사양, 광섬유 종류, 길이 등을 정의함
    • Rack elevation: 랙 안에서 각 장비의 위치와 방향을 시각적으로 나타냄
  • Railway의 각 설치 단계에는 60개 이상의 장비, 300개 이상의 개별 케이블, 수십 개의 세부 사항이 포함됨
  • 설치와 시운전의 기반이 되는 서면 사양과 스프레드시트는 수작업으로 만들어짐
  • 자재가 현장에 도착한 뒤 모든 설치를 끝내는 데는 약 6~14일이 걸림
  • 이후 Railway는 build specification 생성을 자동화하는 내부 도구를 만듦
  • 데이터센터 cage 구축은 일반적인 소프트웨어, DevOps, Terraform stack 배포와 거리가 멀고 집을 짓는 작업에 더 가까움
  • 데이터센터 시설, 계약업체, 벤더마다 같은 조직 안에서도 방식이 조금씩 달라 운영상 매우 세부적인 주의가 필요함

현장에서 겪은 예외와 물리적 문제

  • 한 사이트에서는 PDU가 거꾸로 설치돼 있었고, 전원이 바닥에서 들어와 계획상의 소켓 번호가 반대로 됨
  • Amsterdam 현장에서는 전용 demarcation point가 아니라 외부 광섬유 링크가 랙 안의 박스로 직접 들어오는 시설 방식이 있었음
  • 어떤 시설은 다른 사이트와 다르게 전력 소켓이 phase-to-neutral 방식으로 배선돼 있었고, 다른 곳은 phase-to-phase 방식이었음
  • 계약업체가 네트워크 장비가 reverse airflow인 것을 모르고 반대 방향으로 장착하려 해 데이터 케이블이 짧다고 판단한 사례가 있었음
  • 특정 케이블에서 link가 올라오지 않는 원인은 광섬유 polarity 오류였고, Railway는 그때 “rolling fibre cables”를 알게 됨
    • LC connector의 플러그를 빼서 서로 바꾸는 방식임
  • 한 벤더의 PDU 약 24개는 소켓 결함으로 전원 플러그가 제대로 물리지 않았고, 강한 물리적 힘을 가해도 해결되지 않았음

물리 설치 이후의 소프트웨어 작업

  • 하드웨어가 제자리에 들어간 뒤에는 작업이 더 익숙한 소프트웨어 영역으로 넘어감
  • 필요한 작업은 다음과 같음
    • BGP 설정
    • OS 설치
    • 모니터링 구성
    • 네트워크 장비 설정
    • 라우터 설정 작성
    • RIR, 즉 지역 인터넷 레지스트리 기록 업데이트
  • 서버와 PDU의 전용 컨트롤러에 접근하기 위해 Redfish APIs를 사용함
  • 서버를 네트워크로 부팅하기 위해 PXE를 사용함
  • Railway의 네트워크 설계는 FRR과 SONiC을 실행하는 whitebox network switch를 사용함
  • 이 설계로 Railway control plane과 깊게 통합된 L3-only 소프트웨어 주도 네트워크를 구축함
  • 최근 몇 달 동안 Railway는 새 소프트웨어 도구 Railyard와 MetalCP를 만듦
    • 새 cage 설계
    • 케이블 추적과 시각화
    • 서버 OS 설치
    • 서버를 인터넷에 연결하는 과정까지 버튼 클릭 경험을 가능하게 하는 도구임
  • 이후 글에서는 방 안의 서버 묶음을 기능하는 Railway zone으로 만드는 과정을 다룰 예정임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 내 경험과 이런 글들을 보면 Google은 고객이 있는 걸 싫어하는 것 같음
    누군가 “퍼블릭 클라우드는 해야 한다”고 결정해서 만들긴 했지만, 고객은 3미터 장대로 밀어내고 싶어 하는 느낌임
    AWS 계정 담당자는 필요하면 진흙탕에서도 같이 구를 사람이라고 100% 확신함. 위기 상황에서 부탁하면 바닥에서 같이 잘 사람임
    반면 Google Cloud 담당자들을 보면 슬퍼짐. 그들도 우리보다 Google 내부에서 덜 사랑받고 덜 지원받는 게 보이기 때문임. 자기 회사가 제대로 팔고 서비스하도록 설득하려는 사람을 보는 건 안타깝고, 실패하도록 세팅된 것 같음
    Microsoft 쪽 사람들은 방탄처럼 단단하고, 영업도 잘하고, 서비스도 잘 제공하고, 내 주머니에서 돈을 다 짜내면서도 그게 내게 좋은 일이라고 죽도록 믿게 만듦. 다만 클라우드는 아주 이상한… 무언가임
    Railway가 베어메탈로 간다는 건, 15년 정도 해본 입장에서 절대, 절대, 절대로 돌아가고 싶지 않음. 그만한 가치가 없음. 하지만 직접 겪어봐야 알 것 같고, 원래 그런 길임
    곧 Google이 도대체 왜 그렇게 고생하는지 알게 됨. 단, Borg나 인공 두뇌를 만드는 대신 사람들에게 서비스를 팔고 싶다는 마음이 정말 강하다면 Google보다 100배는 잘할 수 있음

    • AWS 계정 담당자가 낚시도 데려갔음. 연간 100만 달러 이상 지출하면 그 정도는 받는 듯함
      그래도 진흙탕에서 같이 구를 것 같진 않은데, 그게 좀 놀라움. 대체 얼마를 써야 진흙탕 동행 단계에 들어가는지 궁금함
    • “Microsoft는 아주 이상한 클라우드… 무언가를 갖고 있다”는 말에 대해, 조금 샛길로 빠질 위험을 감수하자면 이건 Azure의 큰 문제 중 하나인데 잘 논의되지 않음
      전체 클라우드 서비스가, 클라우드 컴퓨팅을 전혀 모르는 사람이 “베어메탈 서버 임대”만 알고 설계한 것처럼 느껴짐. 클라우드 컴퓨팅이긴 한데 클라우드 컴퓨팅의 개념 자체를 무너뜨리는 방식임
    • 아쉬운 건, Google의 “서버리스” 쪽, 예를 들면 Cloud Run을 써본 경험은 AWS 대응 서비스보다 확실히 좋았다는 점임
      GCP 명령줄 도구인 gcloud도 더 잘 설계된 느낌임
    • 지원이 너무 나쁘면 어떤 계정 담당자도 도움이 안 됨. 차라리 “모르겠다”고 인정했으면 나았고, 우리가 팔린 기능이 실제로는 존재하지도 않고 만들 계획도 없다고 인정했으면 훨씬 좋았을 것임
      그러면 몇 달의 선행 작업 시간을 아낄 수 있었음
      개인 경험으로는 Google Cloud 지원은 3명짜리 작은 팀이 아주 적은 비용을 쓰는 상황에서도 꽤 잘 대해줬고, 다른 회사에서는 Microsoft도 아주 잘 대해줬음. 다만 그때 지출 규모는 아마 데이터센터 전력망 감시로도 추적 가능했을 수준이었을 것임
      반면 AWS는 기능에 대해 거짓말했고, 결국 끝까지 답도 하지 않았음
      고위 경영진과 필수적인 수백만 달러 AWS 계약을 이야기하는 계정 담당자들은 그 경영진에게 어떻게 말해야 하는지 잘 아는 것 같음
      하지만 실제로 타인을 위한 제품을 개발하고 제공하는 단계에서는 우리만 먼지 속에 남겨졌음
      더 웃긴 건, 그 거짓말한 기능이 최종 사용자 경험을 아주 뛰어나게 만드는 데 핵심이라고 팔렸던 기능이었다는 점임
    • 개발자로서 최근 처음 AWS 지원 요청을 보냈는데, 자기 플랫폼에 대해 사실과 다른 내용이 들어간 쓸모없는 답을 받았음
      지원 티켓에 답장을 보냈지만 응답이 없었고, AWS 담당자 둘에게 이메일을 보냈지만 역시 답이 없었음

  • 옛날 Rackspace 시절이 떠오름. 정말 전쟁 같은 일들이 많았음
    EMC 사람들이 테스트용 스토리지 장비를 설치하러 왔다가 서로 발이 꼬여 코미디처럼 서버 랙 하나를 통째로 내려버렸음. 당연히 계약은 못 땄음
    어떤 트럭 운전자가 심장마비를 일으켰고, 사고 때문에 DFW 데이터센터가 오프라인이 됐음. 이런 상황을 막으려고 볼라드가 있었지만 아직 시멘트가 채워지기 전이었음
    한때는 길 건너 다른 건물까지 레이저로 대역폭을 쏘아 임시 연결했음
    어느 날은 서버가 말 그대로 불타기 시작해서 창문을 깨고 박스 팬을 사 왔음
    데이터센터 공학은 초기 시절보다 꽤 발전했음. 당시 Facebook과 함께 OpenCompute Project를 했는데, 그때 기준으로는 매우 앞서간 인프라 개념들이 있었음

    • 영국 시골의 개조한 소 외양간 데이터센터에서 일한 적이 있음. 위 경험과 맞닿는 강한 기억들이 있음
      핵심 마이크로웨이브 링크가 데이터 링크 계층 깊은 곳에서 간헐적 패킷 오류와 함께 계속 끊겼음. 조사해보니 길 건너 나무에 잎이 나고, 가지가 우리 건물 장비의 가시선 안으로 흔들려 들어오고 있었음. 사다리, 톱, 10분으로 연결을 복구했음
      데이터센터 밖으로 나가는 주 BGP 라우터가 계속 재부팅됐음. 이중화 장비는 없었음. 확인해보니 데이터센터 온도가 너무 높고 냉각이 너무 나빠서 흡기 팬 쪽 공기 온도가 60°C를 넘었음. 임시로 팬을 겨냥해 세웠음
      몇 주 뒤 다른 방의 에어컨도 뻗더니 Nortel DMS-100 위로 물을 뿜기 시작했음. 자체 스위치를 가진 다이얼업 ISP였음. 물에 전기가 흐를 수도 있다고 생각해서 닦는 걸 돕고 싶진 않았지만 어쩔 수 없었음
      그 뒤 작은 외딴섬에서도 일했는데, 인터넷 주 링크는 GS 위성을 통한 1MB/s 링크였고 핑은 500ms 이상이었음. 현지인들은 9600보드로 등급 매겨진 마이크로웨이브 전화망으로 다이얼업했는데, 어찌 된 일인지 56k 모뎀이 동작했음
      어느 날 Solaris 박스에 중요한 .so가 빠져 있다는 걸 알았는데, 로컬 백업도 설치 매체도 없었음. 영국 친구에게 전화해 FTP 서버에 사본을 올려달라고 부탁해서 그 박스를 다시 온라인으로 살렸음
      몇 년 뒤에는 Manchester의 Oxford Road, 당시 유럽에서 가장 붐비는 버스 노선 위로 레이저 링크를 설치해 사무실과 대학 캠퍼스를 연결하기도 했음. 재미있는 시절이었음
      전부 엄청 재미있었지만, 지금은 거의 소프트웨어만 하는 게 정말 다행임
    • “데이터센터 공학은 발전했다”고 하지만…
      서버가 말 그대로 불난 건 아니어도, 창문 열고 팬을 쓰는 일은 2024년 1월 Chicago의 Equinix CH1 데이터센터에서도 벌어졌음. Azure ExpressRoute가 내려갔음
      너무 추워져서 CRAC가 버티지 못한 것 같다고 들었음. 충분히 차갑게 유지하려고 모든 문과 창문을 열어뒀다는데 결국 실패했음. CRAC가 가면 서버도 같이 감
    • 오래전에 LINX용으로 INTX LON1에 설치하던 중 BlackDiamond 스위치가 발 위로 떨어져 몇 시간 동안 움직이지 못한 적이 있음
      그 스위치는 저주받은 게 분명했음. 그 주 후반 같은 장비에서 스패닝 트리 설정 오류가 나서 LINX가 몇 시간 동안 멈췄고, 영국 ISP 피어링의 절반이 일시적인 혼란에 빠졌음. 그 프로젝트에 관련된 다른 사람들도 2년 안에 모두 세상을 떠났음
    • 전봇대 위 변압기에 새가 내려앉아 퓨즈가 나간 적이 있음
      몇 년 뒤 시설을 둘러봤는데, 그 아래 바닥에 구워진 사체가 아직도 남아 있었음
    • “창문을 깨고 박스 팬을 샀다”면, 팬은 안으로 불었는지 밖으로 뺐는지 궁금함

  • 글에 나온 “연간 수백만 달러를 써도 100달러 쓰는 사람만큼의 지원밖에 못 받는다”는 대목은 아픔. Google에는 꽤 큰 문제임
    이 글이 특히 재밌었던 건 Blekko 인프라를 구축할 때 비슷한 모험을 했기 때문임
    Blekko처럼 랙 간 트래픽, 즉 인터넷과 오가는 트래픽보다 동서 트래픽이 많은 회사에서는, 물리적으로 함께 배치된 서비스가 다른 서버와 대역폭을 경쟁하지 않는 것이 필수였고 SoftLayer, 즉 IBM의 종속 클라우드에서 이런 특수 사례 비용을 내는 것보다 훨씬 경제적이었음
    차가운 통로를 감싸는 인클로저를 만들어주는 꽤 멋진 회사들도 있음. 기본적으로 바닥에서 나오는 모든 찬 공기가 서버 뒤쪽으로 들어가고 다른 곳으로 새지 않게 해줌. 측면에서 덜 차가운 공기가 서버로 말려 들어가는 것도 막아줌
    데이터센터의 HVAC CRAC 용량 계산도 흥미로움. 첫 코로케이션 시설에서는 우리 케이지 옆 바닥 면적으로 확장할 수 있는 우선거절권이 있었지만, 실제 확장 시점에는 시설의 냉각 용량이 더 남아 있지 않아 아무 의미가 없었음
    이런 과정을 해보고 나면 0xide 솔루션이 훨씬 더 잘 이해될 것임

  • 이렇게 해야 지배적인 회사를 만들 수 있음. 하이퍼스케일러에 갇히게 만드는 징징대는 통념을 무시한 건 잘한 일임
    인프라 회사라면 파는 베어메탈을 직접 소유해야 함. 그렇지 않으면 클라우드 중개상일 뿐이고, 송신 비용 0달러의 베어메탈 경쟁자에게 언제든 가격으로 밀릴 위험이 있음
    코로케이션과 피어링으로 송신 비용을 0달러로 만들 수 있기 때문에 Cloudflare가 무료 요금제를 제공할 수 있고, 새 진입자가 클라우드 서비스를 재판매해서는 Cloudflare와 경쟁할 수 없음
    사실 하이퍼스케일러에게 대역폭 바가지는 단순한 수익원이 아니라 해자임. AWS 위에서 다음 AWS를 만들 수 없게 하고, IaaS 위에 “PaaS”라는 완전히 새롭고 전략적으로 더 약한 시장 구간을 만들어냄

    • 맞음. 정확함. 우리도 클라우드 송신 비용을 고객에게 전가해야 했고, 그게 별로였음
      이걸로 그 비용을 절반으로 줄이고, 스토리지 비용도 낮추고, “좌석당” 가격 책정도 없앨 수 있음
      정말 기대됨

  • 꽤 괜찮은 글임. 떠오르는 한 가지는, 랙 관리용 내부 도구를 왜 직접 만들었느냐는 것임. NetBox가 이미 있음
    NetBox는 훌륭하고, 2000년대 중반에 50개 넘는 랙을 관리하던 때 이게 있었으면 좋았을 것임
    https://github.com/netbox-community/netbox

    • 직접 만들기로 결정하기 전에 상용과 오픈소스 제품을 많이 평가했음. 아직 어딘가에 NetBox 배포도 남아 있음
      하지만 우리가 만든 도구인 Railyard가 잘 맞는 이유는 우리 전체 소프트웨어, 하드웨어, 오케스트레이션 스택에 깊게 통합돼 있기 때문임
      오픈소스 도구의 문제는 너무 범용적이라는 데 있음. 문제를 해결하기보다 그 도구의 데이터 모델에 맞게 문제를 구부리게 됨
      결국 이 도구를 Railway 자체에 통합할 가능성이 큼. 온프레미스로 가고 싶다면 버튼 클릭으로 하드웨어 설계, 커미셔닝, 배포, 개발자 경험까지 제공하는 식임. Oxide가 하는 것과 비슷하지만 반대쪽에서 접근하는 셈임
    • 이슈 목록을 보면 이유가 보임
      https://github.com/netbox-community/netbox/issues?q=is%3Aiss...
      NetBox는 “네트워크 인프라의 진실 공급원(source of truth)”이 되려 함
      각 상황에 따라 중요한 것은 다르지만, NetBox가 어떤 항목은 다른 시스템이 진실일 수 없다고 고집하지 않고 중앙 저장소를 목표로 했다면 이야기가 달라졌을 수 있음
      복잡성과 통제를 중앙집중화하려는 시도는 작동하지 않는다는 걸 배웠음. Clinger-Cohen Act가 통과된 직후에도 거의 바로 알았고, 이제 ITIL과 TOGAF도 이를 명확히 다루고 있음. 앞으로 몇 년간 컨설턴트들이 이 지점을 많이 노릴 것 같음
      상태를 찾는 중앙의 일관된 방법은 필요함. 권위 있는 정보를 어디서 찾아야 하는지 의문을 없애기 위해서임
      하지만 확장하고 성장하거나 새 변화에 적응하려면 이런 중앙집중식 신 상자 같은 규범적 시스템은 피해야 함
    • NetBox는 테마를 얹은 Django 모델 1만 개에 가까움
      쓰는 보람이 큰 소프트웨어는 아님
    • NetBox를 좋아하고 꽤 오래 배포해서 썼지만, 성능은 형편없었고 세상을 NetBox가 원하는 방식에 맞춰야 했음
      흔한 “우리는 X가 필요하고 Y가 X를 한다”의 사례인데, Y가 Z, M, Q도 하고 설거지까지 한다는 사실과 그게 필요 없다는 점을 무시하는 것임
      때로는 필요한 것만 만드는 게 가장 쉬운 해결책임. 특히 필요한 게 데이터베이스 앞의 CRUD라면 더 그렇음
    • 이미 호스트와 네트워크 정보를 앱에 저장하고 있다면 앱 안에 만드는 게 그렇게 어렵지 않음
      실제로는 범위를 확장하는 것뿐임. NetBox는 거기서 시작해 시스템을 그 주변에 맞출 의향이 있다면 괜찮은 출발점임
      하지만 이미 시스템이 있거나 NetBox 논리에 맞지 않는 일을 해야 한다면, 그냥 기존 시스템을 확장하는 편이 나을 가능성이 큼
      이 경우 Railway는 랙, IP 주소, 물리 서버를 넘어 훨씬 많은 추가 정보를 신경 써야 함

  • 대형 기술 회사에서 장비 수리 자동화를 했었음. 수리는 과소평가되지만 다루기 더 어려운 일 중 하나라고 봄
    AWS에서 돌릴 때는 고장 난 하드웨어를 거의 신경 쓰지 않음. 대체로 알아서 수리되기 때문임
    직접 운영하면 그런 사치가 없음. 예비 부품, 수리할 기술자, 호스트에서 작업을 빼고 다시 넣는 절차, 테스트 스위트, 하드웨어 모니터링 도구, 그 밖의 1001가지가 필요함
    작은 규모에서는 일부를 대충 넘길 수 있지만 결국 물리게 됨. 이건 단지 서버 이야기일 뿐임
    네트워크 장비는 또 다른 재미있는 문제 묶음이 있고, 실패하면 랙 전체를 내려버릴 수 있음. 피크 부하 중 코로케이션 업체가 전원을 잃지 않을 거라고 얼마나 믿을 수 있나? 이런 상황에 대비해 재해 복구 훈련을 하길 바람
    이 팀에 행운을 빔. 재미있어 보임

  • 커리어 중 겪었던 몇 날들이 떠오름. 2003~2010년 사이 수만 대의 서버를 배포해야 하면서 데이터센터에 대해 꽤 흥미로운 것들을 배웠음
    케이블 관리와 표준화가 극도로 중요했음. 엉망인 관행으로는 버틸 수 없었음
    매주 수백 대의 서버를 배포하던 곳에서는, 서버가 주요 클러스터 중 하나와 다를 때 운영자가 고를 수 있는 메뉴가 있었음. 기본적으로 섀시는 2가지, 2U 대용량 디스크 서버나 1U 피자박스였음. 디스크는 9/36/146GB SCSI 중 선택할 수 있었음
    모두 같은 프로세서의 듀얼 프로세서였고, 랙 하단에는 2U 박스 10대 정도, 나머지는 1U 박스 20대 이상으로 채웠음
    기억이 맞다면 전력 가격을 아주 좋은 조건으로 받았는데, 케이지 안에서 시설 랙을 사용했기 때문이었을 것임. 그 랙을 쓰면 처음 30A 240V 회로 2개를 무료로 제공했던 것 같음
    10년 계약이었고 계량도 없어서 각 랙을 최대한 빽빽하게 채웠음. 한쪽에는 30A 두 개, 다른 쪽에는 20A 두 개를 넣었음
    우리가 내뿜은 열과 전력 소비를 생각하면 데이터센터가 거의 손익분기였을 것 같음. 아마 연결이나 피어링 비용으로 메웠을 수도 있음
    세부 사항은 기억이 잘 안 나서, 그 시절 거기서 일했던 친구에게 확인해봐야 함

  • 클라우드에 있는 게 맞는 곳도 있고 아닌 곳도 있음. 가장 좋은 예는 고대역폭 또는 디스크를 많이 쓰는 애플리케이션임
    Netflix를 보면 거의 모든 것이 클라우드에 있지만 실제 비디오 전송은 자체 하드웨어로 함. Netflix 규모에서도 이걸 남에게 비용 내고 했다면 경제적으로 가능했을지 의문임
    자주 본 숫자를 약간 바꿔보면, 20PB 송신에 GB당 0.02달러면 월 40만 달러임
    20PB는 대략 95백분위 기준 67Gbps에 해당함
    100Gbps 정액 회선은 월 5천 달러로도 찾기 어렵지 않음
    물론 이건 지나치게 단순화한 계산이고, 실제로는 훨씬 많은 요소가 들어감. 그래도 차이는 큼
    어떤 회사에는 연 468만 달러가 별일 아닐 수 있지만, 다른 회사에는 생존이 걸린 금액일 수 있음

  • 훨씬 더 자세한 내용이 있으면 좋겠음. WTF 섹션이 제일 좋았음
    장비에는 “이쪽을 적에게 향하게 하시오” 같은 표지나, 한 방향으로만 들어가게 하는 적절한 어포던스가 필요해 보임
    랙 수준에서 레이아웃을 표준화했나? 실수를 막기 위해 어떤 포카요케 절차를 넣었나?
    베어메탈에서 부팅까지의 스택은 어떻게 생겼나?
    서로 다른 클라우드 제공업체 두 곳에서 일했고 PXE 부팅 호스트로 내부 클라우드를 직접 만들었던 입장에서 이런 내용은 정말 흥미로움
    새 데이터센터를 시작할 때는 최대한 활용해서 생각나는 모든 실패 시나리오와, 무작위 장애 주입으로 생각하지 못한 시나리오까지 시험해보는 게 좋음

    • “훨씬 더 자세한 내용이 있으면 좋겠다”는 문장은 전력 회로 종류에 대한 세 문단을 줄이라는 요청을 받을 때를 위해 저장해두겠음
      랙 수준 레이아웃 표준화는 지금은 하고 있음. 두 번째 사이트 이후에야 깨달았음. 덕분에 검증이 훨씬 쉬워짐
      검증은 어렵고 지금까지는 수동으로 하고 있음. LLDP 데이터를 긁어오는 걸 해보고 싶지만 스위치 소프트웨어 스택에 버그가 있음
      계속 진화하는 과정임. 서로 다른 시공업체와 작업할수록 더 많은 예외 상황을 발견하고 반영하게 됨
      가장 큰 개선은 내부 DCIM을 만들어 랙 설계를 템플릿화하고, 현장 기술자에게 인터랙티브한 “케이블링 탐색기”를 내보내도록 한 것임. 포트 이름 등이 표시된 장비의 상세 주석 다이어그램도 포함됨. 글에 나온 랙 입면도 스크린샷은 그 도구의 일부임
      베어메탈에서 부팅까지는 https://github.com/danderson/netboot/tree/main/pixiecore 위에 해킹해 만든 것이 있음. Debian netboot와 preseed 파일을 제공함
      BMC의 Redfish API에 연결해 이 장치를 조종하는 커스텀 Temporal 워커도 있음. 그다음 커스텀 호스트 에이전트가 QEMU VM을 프로비저닝하고, 호스트에서 FRR을 사용해 할당된 IP를 BGP로 광고함
      새 데이터센터 실패 시나리오와 관련해서는 이미 차단기를 터뜨리며 테스트해봤고, 그 덕분에 상 밸런싱이 어긋난 걸 알아냈음. 다른 사이트에서는 열화상 카메라를 들고 들어갔음
      다음 주 AMS 사이트가 올라오는데, 목표는 완전히 채운 스위치 패브릭을 어디까지 밀어붙일 수 있는지 보는 것임

  • 좋은 글임. 100G 속도가 필요할 때 Google은 정말 심하게 가격을 물림. 거의 모욕적일 정도임
    예를 들어 이중화된 100G Dedicated Interconnect는 월 약 3만5천 달러이고, 여기에 VLAN attachment, 코로케이션 교차 연결 비용, 트랜짓 등은 포함되지 않음. 게다가 VLAN attachment는 50G가 최대임
    이 비용을 비교해보면, 같은 돈으로 Arista의 새 32포트 100G 스위치 2대를 살 수 있음
    북미에서는 100G WAN 회선, 즉 관리형 Wavelength를 월 5천 달러 미만으로 구할 수 있음. 로컬 메트로라면 다크 파이버를 더 싸게 구하고 원하는 속도로 돌릴 수도 있음

    • 거기에 DWDM 장비를 사면 다크 파이버를 쉽게 확장해서 아주 낮은 비용으로 여러 개의 100Gbps 연결을 제공할 수 있음
답변달기