Update 2: Sorting 1 PB with MapReduce. PB 는 peanut-butter-and-jelly 을 잘못쓴 것이 아닙니다. PB는 1000 TeraByte 또는 백만 기가바이트입니다. 4000대의 컴퓨터 있는 1 PB 정렬하는데 6시간 2분 걸리고 결과는 4만 8천개의 디스크로 복제됩니다.. (10조개의 100 byte 레코드)
Update: Greg Linden 은 MapReduce: simplified data processing on large clusters 라는 새로운 Goolge 문서를 발표했습니다. 몇 가지 흥미로운 통계 : 10만개의 MapReduce 작업이 매일 실행됩니다; 매일 20PB 데이터가 처리됩니다; 십만개 이상의 MapReduce 프로그램이 실행됩니다; 장비들은 기가비트 이더넷과 4-8B 메모리를 가는 듀얼 프로세스입니다.
Google은 확장성의 최고입니다. 모두가 Google을 크고, 세련되고, 빠른 검색으로 알고 있지만, 검색에서는 그렇게 뛰어나지 않습니다. 확장 가능한 응용프로그램을 구축하는 Google의 플랫폼 접근법은 Google이 놀랄 만큼 높은 경쟁에서 인터넷 규모의 응용프로그램을 출시할 수 있게 해줍니다. Google의 목적은 항상 Google 제품을 지원하는 더 높은 성능과 확장가능한 인프라를 구축하는 것입니다. 어떻게 했을까요??
Information Sources
Video: Building Large Systems at Google
Google Lab: The Google File System
Google Lab: MapReduce: Simplified Data Processing on Large Clusters
Google Lab: BigTable.
Video: BigTable: A Distributed Structured Storage System.
Google Lab: The Chubby Lock Service for Loosely-Coupled Distributed Systems.
How Google Works by David Carr in Baseline Magazine.
Google Lab: Interpreting the Data: Parallel Analysis with Sawzall.
Dare Obasonjo's Notes on the scalability conference.
Platform
Linux
언어의 다양성(A large diversity of languages) : Python, Java, C++
내부를 살펴볼까요?
통계
2006년도 기준으로 약 45만대 저가 서버 추산
2005년, Google은 약 8십억개 웹페이지를 색인. 현재는 누가 알까요?
현재 Google 에는 200개가 넘은GFS 클러스를 가지고 있습니다. 클러스터는 천에서 5천대의 장비를 가질 수 있습니다. 만대의 장비 풀은 5PB 가 넘는 스토리지에 동작하는 GFS로투터 데이터를 불러옵니다. 읽기/쓰기 합계 처리량은 클러스터 간에 40기가/초보다 높습니다.
현재 Google에서는 6000개가 넘는 MapReduce 응용프로그램이 있으며, 매달 수백개의 새로운 응용프로그램이 작성됩니다.
BigTable은 수십억개의 URL, 수백 TB의 위성 사진, 수억명 사용자의 설정을 저장하기 위해 확장됩니다.
The Stack
Google 은 3개의 레이어 스택으로 인프라를 시각화합니다.:
제품 : 검색, 광고, 이메일, 지도, 비디오, 채팅, 블로그
분산 시스템 인프라 : GFS, MapReduce, BigTable.
컴퓨팅 플랫폼 : 다른 데이터센터에 있는 장비 묶음
회사사람들이 낮은 비용으로 배치할 수 있게 용이함을 확신시킵니다.
응용프로그램 단위로 가격 대비 성능데이터를 살펴봅니다. 로그 데이터를 잃지 않기 위해 하드웨어에 돈을 더 투자하지만, 다른 종류의 데이터에는 투자하지 않습니다. Google은 데이터를 잃지 않는다고 말합니다.
GFS를 통한 안정적인 저장 메커니즘 (Google File System)
안정적인 확장가능한 저장은 모든 응용프로그램의 핵심 요소입니다. GFS는 Google의 핵심 저장 플랫폼입니다.
Google File System - 많은 데이터를 보내는 커다란 분산 로그 구조 파일 시스템( large distributed log structured file system )입니다.
선반 소프트웨어 대신에 왜 구축을 했을까요? 모든 것을 제어하고 싶고 다른 사람들과 Google을 구별해주는 플랫폼이기 때문입니다. Google의 요구사항입니다 :
- 데이터센터간의 높은 신뢰성
- 수천개의 네트워크 노드에서 확장성
- 매우 높은 읽기/쓰기 대역폭 요구사항
- 크기에서 기가바이트 정도의 큰 데이터 블록의 지원 .
- 병목을 감소시키기위해 노들간의 동작의 효율적인 분산
시스템은 마스터와 chunk 서버로 구성됩니다.
- 마스터 서버는 다양한 데이터 파일의 메타데이터를 보관합니다. 데이터는 64MB 조각으로 파일 시스템에 저장합니다. 클라이언트는 마스터 서버에게 파일의 메타데이터 동작을 수행하과 디스크에 있는 필요한 파일을 가지는 chunk 서버의 위치를 물어봅니다.
- Chunk 서버는 디스크에 실제 데이터를 저장합니다. 모든 chunk는 서버 장애를 대비하여 여분을 생성하기 위해 세 개의 다른 chunk 서버에 복제됩니다. 마스터 서버를 통해 지정되면, 클라이언트 응용프로그램은 chunk 서버로부터 직접 파일을 가져옵니다.
서비스를 시작한 새로운 응용프로그램은 기존의 GFS 클러스터를 사용하거나 자신을 위한 클러스터를 만들 수 있습니다. 데이터센터를 가로질러 프로세스를 제공하는 하는 것을 이해하는 것은 흥미롭습니다.
핵심은 직원들이 그들의 응용프로그램을 위한 선택을 확신할 수 있는 충분한 인프라입니다. GFS는 개별 응용프로그램의 요구에 맞출 수 있습니다.
MAPREDUCE를 사용하여 데이터로 무엇인가를 하라
훌륭한 저장 시스템을 가지고 있다면, 그 많은 데이터로 무엇인가를 해야겠지요. 1000대의 장비에 저장된 수TB 데이터가 있다고 생각해봅시다. 데이터베이스는 이 정도 수준을 확장하거나 비용대비 효율적인 확장을 할 수 없습니다. 그래서 MapReduce가 도입됩니다.
MapReduce는 프로그래밍 모델이고 거대한 데이터 집합을 처리하고 만들어내는 연합된 구현입니다. 사용자는 중간 키/값 쌍 집합을 생성하는 키/값 쌍을 처리하는 map 함수와, 그리고 동일한 중간 키 값으로 연관된 모든 중간 값을 모으는 reduce 함수를 지정합니다. 많은 실 세계 작업이 이 모델로 표현됩니다. 이 함수 스타일로 작성된 프로그램은 자동적으로 병렬화되고 장비들의 거대한 클러스터에서 수행됩니다. run-time system은 입력데이터의 세부적인 파티셔닝, 장비 집합들간의 프로그램 실행 시간조정, 장비 장애 처리, 요구되는 장비간의 통신등을 주의해야 합니다. 이는 병렬과 분산 시스템에 경험이 없는 프로그래머가 거대한 분산 시스템의 자원을 쉽게 활용하게 해 줍니다.
MapReduce 를 왜 사용하나요?
- 많은 장비들간에 작업을 분할하는 멋진 방법입니다.
- 장비 장애를 처리합니다.
- 검색과 광고처럼 다른 응용프로그램 종류에서도 동작합니다. 거의 모든 응용프로그램이 map reduce 종류 동작을 가지고 있습니다. 여러분은 유용한 데이터를 미리 처리하고, 단어 개수를 찾을 수 있고, TB 데이터를 정렬할 수 있습니다.
- 계산은 자동으로 IO 소스에 가깝게 이동할 수 있습니다.
MapReduce 시스템은 세 종류의 다른 서버를 가지고 있습니다.
- 마스터 서버는 map, reduce 서버로 사용자의 작업을 할당합니다. 작업의 상태를 추적합니다.
- map 서버는 사용자 입력을 받아들이고 이를 map 동작을 수행합니다. 결과는 중간 파일로 기록합니다
- reduce 서버는 map 서버가 만든 중간 파일을 받아서 reduce 동작을 수행합니다.
F예로, 모든 웹 페이지에 있는 단어를 수를 계산하길 바랍니다. GFS에 저장된 모든 페이지를 MapReduce로 전달합니다. 1000 대의 장비에서 동시에 일어나고 모든 조정, 작업 스케쥴링, 장애 처리, 데이터 전송은 자동으로 이뤄집니다.
- 단계는 다음 처럼 보입니다. The steps look like: GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS.
- Shuffling 키 종류를 집계합니다.
- reductions(축소)는 모든 키/값 쌍을 합계하고 마지막 답을 만듭니다.
Google의 색인 파이프라인은 20여 개의 다른 맵 축소를 가지고 있습니다. 파이프라인은 레코드와 합계 키를 가지고 데이터를 봅니다. 두번째 map-reduce에 도착하면, 결과를 취하고 다른 일들을 합니다. 계속 반복합니다.
프로그램은 매우 작습니다. 코드로는 20-50 라인정도로 작습니다e.
문제 중 하나는 낙오자입니다. 낙오자는 다른 것을 따라잡지 못하고 느려지는 계산입니다. 낙오자는 느린 Io(나쁜 컨트롤러) 때문이거나 임시적인 CPU 사용량 급등 때문에 발생합니다. 해법은 같은 계산을 여러 개 수행하고 하나가 완료되면 나머지를 모두 죽이는 것입니다.
map과 reduce 간의 데이터 전송은 압축을 사용합니다. 서버에 CPU 제한을 두지 않아 대역폭과 I/O를 절약하기 위해서 데이터 압축과 해제에 사용하는 것이 사리에 맞다는 생각입니다.
BITTABLE 에 구조화된 데이터를 저장하기 (Storing Structured Data in BigTable)
BigTable 은 TB 수준의 메모리와 PB 수준의 저장공간을 포함하는 큰 규모의 장애를 극복하는 자기 관리 시스템입니다. BigTable 은 초당 수백만개의 읽기/쓰기를 처리할 수 있습니다.
BigTable 은 GFS 최상위 단에 구축된 분산 해쉬 메커니즘입니다. BigTable 은 관계형 데이터베이스가 아닙니다. BigTable 은 조인이나 SQL 타입의 질의를 지원하지 않습니다.
BigTable 은 키로 구조화된 데이터를 접근하는 검색 메커니즘을 제공합니다. GFS는 불분명한 데이터를 저장하고 많은 응용프로그램 요구는 구조를 가지는 데이터를 가지는 것입니다.
상용 데이터베이스는 간단하게 이 정도의 확장을 지원하지 않으며, 1000대의 장비에 걸쳐 동작하지 않습니다.
저수준 저장시스템을 제어하여 Google은 더 많은 시스템 제어와 시스템을 향상시키는 영향력을 얻었습니다. 예로, Google이 데이터센터를 가로지는 동작을 쉽게 만든다면, 만들 수 있습니다.
시스템이 동작중일 때 장비를 추가하거나 제거할 수 있으며, 시스템은 그대로 동작합니다.
모든 데이터 아이템은 저수준 키나 컬럼키, 타임스탬프로 접근할 수 있는 셀에 저장됩니다.
모든 로우는 하나 이상의 tablets 에 저장됩니다. Tablets은 SSTable이라 부르는 데이터 포멧인 연속된 64KB 블록입니다.
BigTable 은 3개의 다른 서버를 가집니다:
- 서버는 tablets을 tablet 서버에 할당합니다. 마스터 서버는 tablet이 어디에 있는지 추적하고 필요에 따라 작업을 재분배합니다.
- tablet 서버는 tablet을 위한 읽기/쓰기 요청을 처리합니다. Tablet 서버는 tablet이 (보통 100-200MB) 크기 제한을 넘으면 tablet을 분할합니다. Tablet 서버에 장애가 발생하면, 100개의 tablet 서버가 새로운 tablet을 가져가고 시스템은 복구됩니다.
- Lock 서버는 분산 락 서비스를 수행합니다. 쓰기를 위해 tablet을 여는 동작은, 마스터 중재, 접근 제어 검사는 상호 배제를 필요로 합니다.
지역화 그룹은 더 나은 참조의 지역화를 위해 관려된 데이터들을 물리적으로 저장하는데 사용됩니다.
tablet은 가능한만큼 RAM에 캐쉬됩니다.
Hardware
아주 많은 장비를 사용할 때 어떻게 비용을 절약하고 전원을 효율적으로 사용하게 구축하겠습니까?
극도로 저렴한 하드웨어를 사용하고 하드웨어의 죽음을 처리하는 소프트웨어를 상단에 구축하세요.
실패하기 쉬운 인프라보다는 높은 신뢰성을 가진 컴포넌트로 구축한 1000대의 컴퓨터 능력은 비용대비 33배나 증가시켜줍니다. 업무에 이 전략을 통해 신뢰 할 수 없는 정점에 신뢰성을 구축해야 합니다.
Linux, in-house rack design, PC class mother boards, low end storage.
성능을 기준으로 와트당 가격은 좋아지지 않고 있습니다. 거대한 전원과 냉각 문제가 있습니다.
코로케이션을 섞어서 사용하고 그들만의 데이터센터를 이용합니다.
다양한 것들(Misc)
QA를 기다리지 말고 재빨리 변경사항을 적용하세요.
라이브러리는 프로그램을 구축하는 지배적인 방법입니다.
몇몇 응용프로그램은 크롤링 처럼 서비스로 제공됩니다.
인프라가 응용프로그램의 버전을 처리하기 때문에 google은 응용프로그램이 깨지는 공포없이 출시할 수 있습니다.
구글의 미래 방향 (Future Directions for Google)
지리 분산 클러스터 지원(Support geo-distributed clusters).
모든 데이터를 위해 단일한 글로벌 네임스페이스를 만들기. 현재 데이터는 클러스터에 따라 다르게 사용됩니다.
더 많이 더 좋게 데이터와 계산의 자동화된 이전 .
네트워크 파티셔닝에 따라 넓은 지역 복제로 연결될 때 발생하는 일치성 이슈를 해결 (클러스터가 관리나 정전 때문에 오프라인이되어도 서비스를 유지하는 것 같은).
배운 교훈
인프라는 경쟁우위입니다(Infrastructure can be a competitive advantage). ). Google에서는 틀림없습니다. Google은 새로운 인터넷 서비스를 빠르고, 저렴하게, 소수의 경쟁자들이 할 수 있는 것처럼 확장가능하게 출시합니다. 많은 회사들은 완전하게 다른 접근법을 가지고 있습니다. 많은 회사들은 인프라를 비용으로 다룹니다. 각 그룹은 완전하게 다른 기술을 사용하고 거의 계획하지 않으며 시스템 구축법에 대한 공통점이 없습니다. Google은 스스로를 소프트웨어를 구축하기 위한 매우 신선한 방법을 사용하는, 시스템 엔지니어링 회사로 생각합니다.
여러 데이터 센터로 확장은 아직 해결하지 못한 문제입니다(Spanning multiple data centers is still an unsolved problem). 대부분 웹사이트들은 하나 또는 2개이 데이터 센터에 있습니다. 데이터 센터간을 가로질러 완벽하게 웹사이트를 분산하는 방법은 무엇일까요? 우리는 까다롭다고 말할 수 밖에 없습니다..
여러분 스스로 모아서 이런 인프라를 재구축할 시간이 없다면 Hadoop을 눈여겨 보세요(Take a look at Hadoop) Hadoop은 여기서 설명한 많은 동일한 생각을 구현한 오픈소스 구현입니다.
플랫폼 접근법의 진정한 장점은(An under appreciated advantage) 초보 개발자들이 플랫폼의 최상단에 튼튼한 응용프로그램을 빠르고 믿을 수 있게 만들 수 있다는 것입니다. 모든 프로젝트들이 동일한 분산 인프라를 만들 필요하가 있다면 누가 어떻게 하는지 알아야 하는 사람들이 상대적으로 드물기 때문에 여러분은 어려움에 봉착합니다.
시너지는 항상 허풍만은 아닙니다(Synergy isn't always crap).시스템의 모든 부분이 함께 동작하도록 하면 하나의 향상은 모든 것에 도움이 됩니다. 파일시스템을 향상시키면 모든 사람은 즉시 분명하게 이득을 봅니다. 모든 프로젝트가 다른 파일 시스템을 사용하면 전체 스택에서 지속적으로 증가하는 개선이 없습니다.
시스템이 다운되지 않게 동작하는 자기관리 시스템을 구축하세요(Build self-managing systems that work without having to take the system down). 이렇게 하면 서버들간의 자원을 쉽게 재배치하고, 동적으로 가용성을 더할 수 있고, 장비를 offline 시키고, 우아하게 업그데이드를 처리할 수 있습니다.
다윈 인프라를 만드세요(Create a Darwinian infrastructure). 병렬로 시간을 소모하는 동작을 수행하고 승자를 취하세요.
학술적인 것을 잊지 마세요(Don't ignore the Academy). A학계는 제품환경으로 옮겨지지 않은 좋은 아이디어를 많이 가지고 있습니다. Google이 이룩한 대부분은 기술이전의 것이었지만 대규모 배치 이전은 아니었습니다.
압축을 고려하세요(Consider compression). 주위에 많은 CPU를 가지고 있고 IO에 제한이 있을 때 압축은 좋은 옵션입니다.