Threads 개발 후, 인프라 팀은 출시 준비를 위해 단 이틀의 공지를 받았음. 대부분의 대규모 조직은 수십 개의 상호 의존적인 팀을 포함하는 프로젝트 계획을 작성하는 데만 이틀 이상 걸림. 그러나 Meta에서는 분산된 사이트에 전쟁실을 신속히 구축하여 인프라와 제품 팀을 실시간으로 문제를 해결하도록 함. 이 앱은 출시 후 5일 만에 1억 명의 사용자에 도달하며 역사상 가장 빠르게 성장한 앱이 되었음
빠르게 제품을 출시할 수 있는 능력을 유지하는 것이 인상적임. 관료주의가 증가하지 않도록 하고, 법무팀이나 다른 부서가 승인 게이트를 만들지 않도록 많은 노력이 필요함. 또는 전쟁실을 통해 신속하게 작업을 완료할 수 있는 능력이 필요함
FB에 있을 때, 인프라가 얼마나 강력한지 경험했음. 제품 엔지니어들이 며칠 만에 대규모 프로젝트를 구축함. 여러 팀의 기술 리더로 일했으며, 여기서 언급된 팀 중 일부는 HBase와 ZippyDB 팀임
ZippyDB가 처음으로 공개적으로 언급된 것이 멋짐. 개발자 효율성 향상이 언급된 것도 매우 멋짐. 매일 10,000개의 서비스가 푸시되거나 모든 커밋이 이루어짐
FB를 떠난 후, 비슷한 것을 찾을 수 없었음. 그래서 스타트업으로 내가 필요했던 인프라를 구축하고 있음. Batteries Included
이 댓글들에 많은 냉소와 부정적인 반응이 있어 아쉬움. 많은 사람들이 Meta를 싫어하지만, 실제 기사는 나에게 경이로움. 현대 디지털 세계를 지탱하는 인프라가 얼마나 광범위하고 복잡한지 몰랐음. 이 기사를 읽고 그 규모를 보는 것이 놀라움
회사가 여러 면에서 나쁠 수 있지만, 기사에 나오는 모든 것이 나에게는 놀라움
나는 여러분처럼 엔지니어가 아니어서 이 기사가 여러분에게는 오래된 뉴스일 수 있지만, 나는 "와우"라고 말하지 않을 수 없었음
과거의 SF 작가들에게 이 기사를 보여주면 그들도 경이로워할 것 같음
놀라움. 이 모든 놀랍고 인상적인 기술과 세계 최고의 엔지니어들이 단지 사람들의 눈에 더 많은 광고를 넣기 위해 사용됨. 한숨
PHP 웹 프론트엔드를 "서버리스" 또는 "서비스로서의 함수" 아키텍처로 설명하는 것이 흥미로움. 관점의 문제인 것 같음. 이는 많은 엔드포인트가 배포된 단일 코드베이스를 가진 서비스임. 엔드포인트 유지보수자의 관점에서는 "서버리스"일 수 있지만, 모든 추상화가 그렇듯이 누출이 있음
데이터센터 환경에서는 단순성과 고품질 의사결정 능력 때문에 중앙 집중식 컨트롤러를 선호함. 많은 경우, 중앙 집중식 제어 평면과 분산 데이터 평면을 결합한 하이브리드 접근 방식이 가장 최적임
이 접근 방식은 대규모 서버 수를 가진 조직의 소프트웨어 네트워킹(서비스 메쉬) 및 스토리지(데이터베이스 운영)에 가장 최적의 설계 중 하나로 보임. IP 네트워킹이 BGP에 주로 의존하지 않고 같은 모델을 따르는 것이 놀라움
로컬 캐싱을 사용하여 L7 라우터의 부하를 줄이고 데이터베이스 쿼리의 지연 시간을 개선할 것으로 예상됨. 클라이언트는 캐시를 무효화하고 합리적인 시간 초과 후 서비스 메쉬에 다시 조회할 수 있음
빠르게 개발된 서버리스 함수와 지속적인 배포가 결합되어, 누구나 전체 코드베이스에서 편집할 수 있는 것이 디스토피아적 악몽처럼 들림. 디버깅과 버그 찾기에 필요한 로깅의 양이 극단적임
서버리스 함수를 작성하는 데 Erlang을 사용하는 것은 BEAM이 제공할 수 있는 모든 큰 이점을 피하는 것 같음
제품 엔지니어들은 주로 PHP, Python, Erlang에서 상태 없는 서버리스 함수로 코드를 작성함. 이는 단순성, 생산성, 반복 속도에서 이점이 있음
개발자 생산성을 높이기 위해 Meta는 지속적인 배포를 보편적으로 채택하고, 더 많은 개발자가 전통적인 서비스 코드보다 서버리스 함수를 작성할 수 있도록 함
비 AI 컴퓨팅 작업에 대해, 단일 서버 유형만 제공하며, 하나의 CPU와 동일한 양의 DRAM(이전에는 64GB, 현재는 256GB)을 장착함. 이것이 업계 전반에 걸쳐 일반적인 것인지, Meta에만 일반적인 것인지 궁금함
이미지가 CDN109에 캐시되지 않았을 때, 사용자가 요청하면 CDN109는 요청을 인근 PoP로 전달함. PoP는 요청을 데이터센터 지역의 로드 밸런서로 전달하고, 로드 밸런서는 스토리지 시스템에서 이미지를 가져옴
1MB 이미지를 요청할 때, 느린 연결로 100ms 지연 시간으로 1MB 이미지를 제공하는 것이 여러 번의 왕복과 증가하는 지연 시간을 거치는 것보다 빠르지 않을까?
Meta의 시스템을 통해 요청한다고 가정하면, 결국 같은 데이터센터로 가고 FTL 기술이 없다고 가정할 때
하이퍼스케일러와의 명시적인 비교가 특히 흥미로움. 그들이 자체 퍼블릭 클라우드를 출시하기 위한 준비인지 궁금함. Meta의 누군가가 의견을 말해주길 바람
Hacker News 의견
Threads 개발 후, 인프라 팀은 출시 준비를 위해 단 이틀의 공지를 받았음. 대부분의 대규모 조직은 수십 개의 상호 의존적인 팀을 포함하는 프로젝트 계획을 작성하는 데만 이틀 이상 걸림. 그러나 Meta에서는 분산된 사이트에 전쟁실을 신속히 구축하여 인프라와 제품 팀을 실시간으로 문제를 해결하도록 함. 이 앱은 출시 후 5일 만에 1억 명의 사용자에 도달하며 역사상 가장 빠르게 성장한 앱이 되었음
빠르게 제품을 출시할 수 있는 능력을 유지하는 것이 인상적임. 관료주의가 증가하지 않도록 하고, 법무팀이나 다른 부서가 승인 게이트를 만들지 않도록 많은 노력이 필요함. 또는 전쟁실을 통해 신속하게 작업을 완료할 수 있는 능력이 필요함
FB에 있을 때, 인프라가 얼마나 강력한지 경험했음. 제품 엔지니어들이 며칠 만에 대규모 프로젝트를 구축함. 여러 팀의 기술 리더로 일했으며, 여기서 언급된 팀 중 일부는 HBase와 ZippyDB 팀임
ZippyDB가 처음으로 공개적으로 언급된 것이 멋짐. 개발자 효율성 향상이 언급된 것도 매우 멋짐. 매일 10,000개의 서비스가 푸시되거나 모든 커밋이 이루어짐
FB를 떠난 후, 비슷한 것을 찾을 수 없었음. 그래서 스타트업으로 내가 필요했던 인프라를 구축하고 있음. Batteries Included
이 댓글들에 많은 냉소와 부정적인 반응이 있어 아쉬움. 많은 사람들이 Meta를 싫어하지만, 실제 기사는 나에게 경이로움. 현대 디지털 세계를 지탱하는 인프라가 얼마나 광범위하고 복잡한지 몰랐음. 이 기사를 읽고 그 규모를 보는 것이 놀라움
회사가 여러 면에서 나쁠 수 있지만, 기사에 나오는 모든 것이 나에게는 놀라움
나는 여러분처럼 엔지니어가 아니어서 이 기사가 여러분에게는 오래된 뉴스일 수 있지만, 나는 "와우"라고 말하지 않을 수 없었음
과거의 SF 작가들에게 이 기사를 보여주면 그들도 경이로워할 것 같음
놀라움. 이 모든 놀랍고 인상적인 기술과 세계 최고의 엔지니어들이 단지 사람들의 눈에 더 많은 광고를 넣기 위해 사용됨. 한숨
PHP 웹 프론트엔드를 "서버리스" 또는 "서비스로서의 함수" 아키텍처로 설명하는 것이 흥미로움. 관점의 문제인 것 같음. 이는 많은 엔드포인트가 배포된 단일 코드베이스를 가진 서비스임. 엔드포인트 유지보수자의 관점에서는 "서버리스"일 수 있지만, 모든 추상화가 그렇듯이 누출이 있음
데이터센터 환경에서는 단순성과 고품질 의사결정 능력 때문에 중앙 집중식 컨트롤러를 선호함. 많은 경우, 중앙 집중식 제어 평면과 분산 데이터 평면을 결합한 하이브리드 접근 방식이 가장 최적임
이 접근 방식은 대규모 서버 수를 가진 조직의 소프트웨어 네트워킹(서비스 메쉬) 및 스토리지(데이터베이스 운영)에 가장 최적의 설계 중 하나로 보임. IP 네트워킹이 BGP에 주로 의존하지 않고 같은 모델을 따르는 것이 놀라움
로컬 캐싱을 사용하여 L7 라우터의 부하를 줄이고 데이터베이스 쿼리의 지연 시간을 개선할 것으로 예상됨. 클라이언트는 캐시를 무효화하고 합리적인 시간 초과 후 서비스 메쉬에 다시 조회할 수 있음
빠르게 개발된 서버리스 함수와 지속적인 배포가 결합되어, 누구나 전체 코드베이스에서 편집할 수 있는 것이 디스토피아적 악몽처럼 들림. 디버깅과 버그 찾기에 필요한 로깅의 양이 극단적임
서버리스 함수를 작성하는 데 Erlang을 사용하는 것은 BEAM이 제공할 수 있는 모든 큰 이점을 피하는 것 같음
제품 엔지니어들은 주로 PHP, Python, Erlang에서 상태 없는 서버리스 함수로 코드를 작성함. 이는 단순성, 생산성, 반복 속도에서 이점이 있음
개발자 생산성을 높이기 위해 Meta는 지속적인 배포를 보편적으로 채택하고, 더 많은 개발자가 전통적인 서비스 코드보다 서버리스 함수를 작성할 수 있도록 함
비 AI 컴퓨팅 작업에 대해, 단일 서버 유형만 제공하며, 하나의 CPU와 동일한 양의 DRAM(이전에는 64GB, 현재는 256GB)을 장착함. 이것이 업계 전반에 걸쳐 일반적인 것인지, Meta에만 일반적인 것인지 궁금함
이미지가 CDN109에 캐시되지 않았을 때, 사용자가 요청하면 CDN109는 요청을 인근 PoP로 전달함. PoP는 요청을 데이터센터 지역의 로드 밸런서로 전달하고, 로드 밸런서는 스토리지 시스템에서 이미지를 가져옴
1MB 이미지를 요청할 때, 느린 연결로 100ms 지연 시간으로 1MB 이미지를 제공하는 것이 여러 번의 왕복과 증가하는 지연 시간을 거치는 것보다 빠르지 않을까?
Meta의 시스템을 통해 요청한다고 가정하면, 결국 같은 데이터센터로 가고 FTL 기술이 없다고 가정할 때
하이퍼스케일러와의 명시적인 비교가 특히 흥미로움. 그들이 자체 퍼블릭 클라우드를 출시하기 위한 준비인지 궁금함. Meta의 누군가가 의견을 말해주길 바람