너무 수준 높은 질문이라 죄송합니다. 서버 로드 밸런싱의 기본은 이해하지만, 30,000대의 서버를 관리한다는 개념은 저에게 조금 낯설습니다. 10,000배로 확장된 2~3대의 서버를 밸런싱하는 것과 정말 같은 개념인가요?
이것이 memcached, sql/mysql, 검색 엔진 등과 어떤 관련이 있습니까?
이를 기반으로 데이터를 전달하는 '컨트롤러' 서버와 슬레이브 서버를 갖는 계층구조인가? 중복은 어떻게 처리되나요?
해당 문제에 관한 기사에 대한 정보나 지침을 제공해 주셔서 감사합니다.
편집하다답변 주셔서 감사합니다. 내 게시물은 닫혔지만 제목을 수정했습니다. 이러한 최고 수준의 데이터 솔루션과 관련된 문제 해결 프로세스가 매력적이라고 생각하고 현재 약간의 기본 로드가 필요한 API를 구축 중이므로 다시 열릴 것입니다. 균형, 따라서 질문입니다.
답변1
Google이 서버에서 사용하는 대부분의 소프트웨어 스택은 내부에서 개발되었습니다. 피할 수 없는 하드웨어 오류로 인한 영향을 줄이기 위해 소프트웨어는 내결함성을 갖도록 설계되었습니다.
원천:구글 플랫폼
기사를 읽은 후 Linux를 기반으로 자체 개발한 내부 소프트웨어 스택을 사용하여 최대 1000개 이상의 서버로 확장된 소수의 서버 간의 로드 균형을 조정하는 것과 동일한 개념이라고 추측합니다. 예를 들어GFS(구글 파일 시스템),빅테이블- GFS를 기반으로 구축된 구조화된 스토리지 시스템
이것링크에서는 네트워크 로드 균형을 조정하는 방법을 설명합니다.
그들은 사용한다로드 밸런싱 스위치부하를 분산시키기 위해. 웹 사이트에 대한 모든 요청은 시스템에 도착하고 이 시스템은 사용 가능한 서버 중 하나로 요청을 전달합니다. 스위치는 어느 서버가 가장 적게 로드되었는지 알아낼 수 있으므로 모든 서버가 동일한 양의 작업을 수행합니다.
Google의 네트워크 토폴로지다음과 같습니다:
클라이언트 컴퓨터가 Google에 연결을 시도하면 여러 DNS 서버가 라운드 로빈 정책을 통해 www.google.com을 여러 IP 주소로 확인합니다. 또한 이는 부하 분산의 첫 번째 수준 역할을 하며 클라이언트를 다른 Google 클러스터로 연결합니다. Google 클러스터에는 수천 개의 서버가 있으며 클라이언트가 서버에 연결되면 추가 부하 분산이 수행되어 부하가 가장 적은 웹 서버로 쿼리를 보냅니다.
답변2
여기서 가장 중요한 부분은 소프트웨어가 확장 가능하도록 설계되지 않은 경우 어떻게 확장할 수 있는가입니다. 예를 들어 현재 Facebook의 가장 큰 제한 사항 중 하나는 MySQL에 대한 의존도입니다. 그들은 점점 더 많은 시스템을 투입하여 문제를 피할 수 있었지만그들의 엔지니어는 이것을 "죽음보다 더 나쁜 운명"이라고 부릅니다.
일반적으로 요청의 부하를 분산할 수 있어야 하며 오픈 소스 등 많은 프로젝트가 설계됩니다. 그러나 이로 인해 로그 작성, 쓰기 지연, "최종 일관성" 아키텍처를 포함한 오버헤드가 발생합니다. 즉, 스케일링은 저렴하지 않습니다.
따라서 정적 콘텐츠를 제공하는 웹 서버와 같은 것들은 쉽게 병렬화될 수 있습니다. Memcached 및 기타 캐싱 시스템은 쉽게 로드 밸런싱됩니다. 하지만 단일 실패 지점을 어떻게 변경합니까? 단일의 대규모 관계형 데이터베이스는 어떻게 확장됩니까? 파일 저장소는 어떻습니까? 본질적으로 이것은 연구의 전체 분야입니다. 하나의 질문으로 답할 수 있는 것이 아닙니다.
답변3
동일한 개념은 동일해야 한다고 생각하며 중요한 점은 사용 가능한 리소스 간에 로드와 데이터를 어떻게 배포하고 데이터를 찾는 방법입니다.
한 가지 방법은 서버의 지리적 분포입니다. 각 사용자는 가장 가까운 서버로 연결됩니다.
레지스트리와 유사한 서비스를 사용하여 요청된 데이터를 조회할 수 있습니다.
DNS 서비스 구현을 생각해 보세요. 매우 거대한 분산 데이터베이스를 보유하고 있습니다. 루트 노드는 쿼리에 응답할 수 있는 담당 노드에 도달할 때까지 사용자를 다른 하위 수준 노드로 안내합니다.