Amazon Web Services는 대규모 AI 학습 클러스터 내 지연 시간과 대역폭 비용을 절감하기 위해 자체 개발된 고속 네트워킹 아키텍처를 조용히 추진하고 있다.

많은 데이터센터 네트워크는 설계가 미흡하지만, 아마존의 네트워크는 그렇지 않다. 지난달 나는 AWS 글로벌 네트워크 엔지니어링 부사장인 맷 레더와 네트워킹 랩에서 면담했다. 내가 케이지 너트가 쉽게 손을 베일 수 있다는 가벼운 농담을 하자, 그는 무표정하게 반응했다. 이 반응은 그 농담이 타당성이 없어서라기보다는, 그가 참조한 수동 조립 공정이 더 이상 AWS에 존재하지 않기 때문에 놀랍지 않았다. 랙은 사전 조립된 상태로 도착하며, 기술자들은 이제 시설 내에서 하드웨어를 나사로 고정할 필요가 없다. 이러한 상호작용은 클라우드 컴퓨팅을 뒷받침하는 고도로 자동화된 인프라의 이면을 엿볼 수 있는 기회를 제공했으며, 이는 업계 외부에서는 거의 완전히 이해되지 않는 현실이다.

내 동료 토마스 클버는 이전에 해당 시설을 견학하고 이에 대한 AWS의 연구 논문에 대한 상세한 분석을 게시했다. 요약하자면, 해당 기업은 의도적으로 거의 무작위 구성으로 배선된 평평한 단일 계층 네트워크를 활용한다. 이러한 아키텍처는 운영 비용이 훨씬 적게 드는 훨씬 더 탄력적인 네트워크를 생성하며, 독자들에게 기술적 기반을 빠르게 이해시키는 역할을 한다.

불충분한 주목을 받았고 내 예정되지 않은 AWS 시설 견학 요청을 촉발시킨 것은 고객에 대한 경제적 영향이었다. 그들의 새로운 네트워킹 접근 방식은 최대 40%의 에너지 효율성을 제공한다. 이는 AWS가 대규모로 배포하고 있는 대부분의 신규 데이터센터 구축의 표준이 되었지만, 내부 및 외부 모두에서 해당 기술은 여전히 거의 보이지 않는다.

결과적으로 발생하는 절감 효과와 비용 효율성은 상당하다. 그렇다면 이러한 자금은 어디에 할당되었는가? 17년 전 아마존 상무이사 제임스 해밀턴은 [PDF] 전통적인 네트워크 벤더들이 메인프레임 제조업체들과 유사한 이익 마진을 유지했다고 지적했는데, 그는 이를 "구멍가게 앞의 굶주린 돼지들"과 비교하여 생생하게 묘사했다. 비유는 내 것이었지만 관찰은 정확했다. 해밀턴의 핵심 불만은 간단명료했다: "그들이 내 길을 막고 있다." 그는 자신의 팀과 함께 범용 하드웨어를 사용하여 전체 네트워킹 스택을 처음부터 재구성함으로써 이 문제를 해결하기로 결정했다.

이러한 전략적 전환은 상당한 결과를 낳았다. 몇 년 전 이미 AWS의 네트워킹 비용은 전통적인 벤더에 의존하는 경우보다 현저히 낮았다. 이후 도입된 Resilient Network Graph 아키텍처는 비용을 더욱 대폭 절감시켰다. 이러한 복리 효율성을 고려할 때, 최근 몇 년간 축적된 Savings가 어디로 갔는지 묻지 않을 수 없다. 나는 AWS가 마진 개선을 고객에게 전달하기보다는 자체적으로 유지했는지 직접 물었다. 그들의 답변은 명확했다: "비용 관점에서? 효과적으로 그렇습니다."

이 답변은 비난처럼 보일 수 있지만, 더 넓은 산업 동향을 고려하는 것이 필수적이다. 많은 경쟁사와 달리 AWS는 기존 SKU(재고 관리 단위)의 가격을 인상하지 않았다. 물론 GPU 용량 블록의 비용은 분기별로 상승하고 있으며, 이는 스팟 인스턴스의 느린 변형과 유사하게 작동한다. 또한 AWS는 몇 년 전에 공개 IPv4 주소에 대해 요금을 부과하기 시작했다. 고객은 여전히 2020년에 사용 가능했던 동일한 64GB RAM 인스턴스를 오늘날 동일한 가격으로 배포할 수 있으며, 이 금액은 인플레이션을 반영하지조차 않는다. 게다가 Graviton4 기반 c8g.2xlarge에서 Graviton5 equivalents인 c9g.2xlarge로 마이그레이션하면 9%의 가격 인상이 발생하지만, 어떤 고객도 업그레이드를 강요받지 않는다. 상승하는 부품 비용을 고려할 때, AWS가 인상을 단 9%로 억제했다는 점은 놀랍다.

AWS 청구의 세분화 특성상 수백만 개의 SKU가 존재하지만, 각 SKU는 상당한 하위 복잡성을 숨기고 있다. EC2 인스턴스는 시간당(또는 초 단위)로 청구되지만, 그 단일 요금에는 CPU, 메모리, 백플레인, 전력 소비, 물리적 건물 보안, 신원 및 액세스 관리 프로토콜, 운영 인력 및 광범위한 네트워킹 인프라가 포함된다. 이 인프라의 한 가지 중요한 측면은 가용 영역(AZ) 간 데이터 전송에는 약 2센트/GB의 상당한 비용이 발생하지만(주요 지역 간), 단일 AZ 내의 데이터 이동은 무료라는 점이다.

단일 AZ가 종종 여러 데이터센터 시설에 걸쳐 있음을 고려하면 이는 특히 인상적이다. AZ가 확장되고 데이터 볼륨이 증가함에 따라 AWS는 이러한 증가하는 비용을 고객에게 이전하지 않고 자체적으로 흡수하고 있다. 반면, AWS에서 데이터를 추출하는 것은 여전히 훨씬 더 비싸다. AWS의 레거시 Snowball 장치는 클라우드와의 물리적 데이터_ship_을 허용했다. inbound 전송에는 고정 요금이 적용되었고, outbound 전송에는 GB당 요금이 추가되었으며, 이는 많은 사람이 번거롭게 여긴 arrangement였다. 지난 1년 동안 AWS는 Interconnect-multicloud를 도입하여 GB당 요금을 완전히 제거하고 시간당 포트 요금만 부과한다. 이 오퍼링에는 공급자당 500Mbps 포트 하나를 제공하는 무료 티어가 포함되어 있어, Google Cloud Platform, Oracle 및 eventually Microsoft Azure로 라우팅되는 트래픽에 대한 AWS 측 비용을 효과적으로 제거한다. 참고로, 해당 포트를 월간으로 퍼블릭 인터넷을 통해 포화시키려면 약 12,000달러가 소요된다.

이 이니셔티브는 AWS의 가격 책정 모델에서 전례 없는 변화를 나타낸다. 비록 이것이 내 논의의 주요 초점은 아니었지만, 나는 변경 사항에 대한 공식 성명을 요청했다: "고객들은 비용 예측이 어렵기 때문에 기반 속도 네트워크 요금을 좋아하지 않습니다. 따라서 우리는 새로운 네트워크 제품에 대한 고정 요금 가격 책정으로 이동하고 있습니다." 이 발전은 주의 깊게 주시할 가치가 있다. 일반적으로 클라우드 가격이 하락하는 시기가 아니라 상승하는 시기에 나타난다는 점에서 특히 주목할 만하다.

핵심 과제는 AWS가 보이지 않게 운영하려는 경향에 있다. 이는 적절한 질문을 제기한다: 왜 내가 이것을 설명하고 있는지, AWS 자체가 아닌 이유는 무엇인가? 해당 기업은 원함에도 불구하고 과거 자기 성과에 대한 커뮤니케이션의 부족함을 인정한다. 전통적으로 AWS는 이러한 혜택을 고객이 구체화하도록 의존해 왔으며, 그러한 옹호가 자연스럽게 플랫폼에 가치를 창출할 것이라고 가정했다. 기술적 실행을 고려해보자: 거의 무작위 네트워크에서 가장 큰 도전은 케이블링이 아니라 라우팅이다. BGP, OSPF 및 다양한 독점 시스템과 같은 표준 프로토콜은 최단 경로를 계산하지만, 임의의 두 지점 사이에 수천 개의 동등한 경로가 존재할 때 이 지표는 관련성을 잃는다. AWS는 제어 플레인을 관리하는 Scalable Intent-Driven Routing(SIDR, '사이다'라고 발음)이라는 커스텀 프로토콜로 이를 해결했다. Spraypoint라는 별도 시스템은 실제 데이터 전달 경로를 처리한다.

AWS는 re:Invent 2023에서 SIDR을 공개적으로 발표했고 2024년 "Monday Night Live" 키노트에서도 다시 다뤘다. 이후 그들은 SIDR에 대한 언급 없이 Resilient Network Graph(RNG) 아키텍처에 대한 논문을 발표했다. 내 지식 범위 내에서 외부 애널리스트 중 해당 프로토콜을 underlying 네트워크와 연결한 사람은 없다. 나는 이를 직접 확인해야 했으며, 나의 평가는 그대로 유지된다: 그것은 영업비밀이 아니다. AWS는 단순히 SIDR이 시스템 기능에 얼마나 중요한지를 강조하지 않았을 뿐이다. 불행히도 이 커뮤니케이션 격차는 AWS의 시장 인식에 손실을 주고 있다. 업계의 많은 사람들이 neocloud 제공업체와 Nvidia 레퍼런스 아키텍처가 더 우수한 네트워킹을 제공한다고 잘못 가정한다. 그렇지 않다. 최소한의 네트워킹 전문성으로 neocloud를 구축할 수 있으며, 여러 회사가 정확히 그렇게 시도했다.

나는 이를 firsthand로 안다; 나는 클라우드 제공업체에 이 복잡성을 위임할 수 있다는 것을 깨닫기 전까지 그 엔지니어들 중 한 명이었다. AWS는 네트워크의 정교함을 숨기는 데 너무 능숙해서, 우리가 그들의 환경에서 임의의 두 지점 사이에서 거의 풀 라인레이트 연결이 원활하게 작동한다는 사실이 얼마나 놀라운지 멈춰서 고려하지 않는다. 개인이나 소규모 조직이 구축한 데이터센터에서는 엔지니어들이 항상 병목 현상을 관리해야 하며, 예를 들어 랙 상단 스위치가 집계 트래픽을 제한하여 모든 노드가 동시에 풀 속도로 통신하지 못하게 한다. 나는 AWS 내에서 이러한 제한이 적용되는 실제 시나리오를 만난 적이 없다. 결과적으로 조직들이 자체 데이터센터를 구축하려고 할 때, 한 세대에 걸쳐 추상화된 도전에 대한 인식이 부족하여, 실제로 작업이 얼마나 어려운지에 대한 감각으로 접근한다.