블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'Chubby'에 해당되는 글 1

  1. 2012.08.06 Google 기술 스택의 이해 (5)
 

Google의 기술을 이해한다.

근래에 들어서 유행하는 IT 기술은 구글이나 페이스북등의 B2C 서비스 업체를 중심으로 하여 파생된 기술이 그를 이룬다.
클라우드 컴퓨팅, NoSQL, 빅데이타등의 최신기술들 역시 구글이나 페이스북을 원류로 한다.
'이 글에서는 대표적인 B2C 기업인 구글의 서비스의 구조를 통하여 구글의 기술을 이해하고 현재 주류를 이루는 기술에 대한 배경을 이해함으로써 향후 유사 솔루션에 대한 적용 시나리오를 찾는데 도움을 주기 위해서 작성되었다.'

검색엔진의 일반적인 구조
구글은 기본적으로 검색 서비스를 바탕으로 유입자를 통한 광고 수입을 주요 비지니스 모델로 하고 있다.
이메일이나 개인 스토리지 서비스등 많은 서비스들을 가지고는 있지만, 아무래도 그 뿌리는 검색이다.
일반적인 검색 엔진의 구조는 다음과 같다. 
※ 아래 구조는 일반적인 기술을 바탕으로 추론한 내용으로, 실제 구글의 검색 엔진 구조와는 상의할 수 있다.



크게 3 부분으로 구성되는데, 주요 컴포넌트는 다음과 같다.
1. Crawler 
Crawler는 인터넷의 웹 페이지들을 샅샅이 뒤져서 모든 페이지 문서를 읽어와서 저장하는 역할을 한다.
2. Index Engine
Index Engine은 저장된 페이지를 분석하여 단어별로 색인(Index) 을 만드는 역할을 한다.
3. Search Engine
Search Engine은 사용자에 의해서 입력된 검색어를 가지고, Index를 검색하여 검색어가 들어있는 페이지를 찾아내서 그 결과를 리턴한다. 
이 컴포넌트의 유기적은 흐름을 보면 다음과 같다.




1) Crawler는 수집해야되는 URL 리스트를 가지고 여러개의 BOT을 기동하여, 각 페이지의 HTML 페이지를 읽어서 저장한다.
2) Index 서버는 저장된 페이지들을 읽어서 Index를 추출한다.
Index는 단어와 페이지 URL을 맵핑한 일종의 테이블이다.
저장시에는 실제 문서 URL을 저장하지 않고, 일종의 Hash 등을 이용하여 문서 ID를 추출하여 저장한다.
아래 저장 구조는 일종의 예로, 실제로 저장되는 구조는 이보다 훨씬 복잡하다.



3) 사용자에 의해 들어온 검색어는 위의 Index 테이블을 검색하여, 문서 ID 리스트를 추출하고 랭킹 알고리즘등을 적용하여 소팅된 형태로 사용자에게 출력된다.


필요 기술

위의 시나리오를 구현하기 위해서 어떤 기술들이 필요할까?

1) Crawler에서 필요한 기술
Crawling은 Crawling Bot들이 여러 웹사이트를 돌아다니면서 그 페이지를 저장한다.
수백만 사이트에서 페이지를 읽어와서 저장해야 하기 때문에, 다음과 같은 조건의 대규모 파일 시스템이 필요하다.
파일 시스템
- 많은 수의 파일을 저장할 수 있을 것
- Crawling Bot은 오직 읽은 페이지를 저장 즉 Write만 하기 때문에, write에 최적화 되어 있어야 한다.
- 저장된 파일에 대한 update는 발생하지 않는다.

2) Index에서 필요한 기술
파일 시스템
- 하나의 파일을 동시에 여러 Index가 처리할 수 있어야 한다. 파일을 여러개로 나눠서 처리 하기 때문에, Random Access가 지원되어야 한다. 이런 요구 사항에서 나온 파일 시스템이 Google의 파일 시스템인 GFS 이다. 

INDEX 기반의 저장 시스템
- 검색어를 KEY WORD로 하고, 문서를 저장하는 대규모 Key/Value Store가 필요하다. 
대용량 분산 Key/Value 스토어를 구현한 것이 Google BigTable로, 현재 대용량 NoSQL에서 Amazon Dynamo 계열과 함께 크게 양대 산맥을 이루는 기반 기술이다.

3) 분산 Locking, 공유 정보

이런 대규모 분산 시스템 처리에서 필요한 점 중 하나가, 분산되어 있는 리소스(파일)에 대한 억세스를 진행할때, 다른 프로세스가 해당 리소스를 동시에 억세스할 수 없도록 배타적(Exclusive)한 접근을 보장해야 한다.
일반적인 방법이 Locking을 이용하는 방법인데, 분산되어 있는 노드와 클라이언트가 억세스 되고 있는 리소스에 대한 Lock 정보를 공유할 수 있어야 하며, 빠른 속도를 보장해야 한다.

4) 분산 처리 기술

이 시스템의 구조가 주목 받는 점중의 하나는 대규모의 데이타를 저장한다는 점이외에도, 대규모 데이타에 대한 처리(연산)이 가능하다는 것인데, 대표적으로 사용되는 기술이 Map & Reduce  라는 기술이다.
Map & Reduce 기술의 개념은 간단하다
 " 큰 데이타를 여러개의 조각으로 나눠서 여러대의 컴퓨터가 각 조각을 처리하고, 처리된 결과를 모아서 하나의 단일 결과를 낸다."

※ Map & Reduce에 대한 자세한 개념은 - http://bcho.tistory.com/650 글을 참고

실제 구현화된 기술과 레퍼런스 구현

이러한 기술들을 실제로 구현화해 놓은 시스템의 스택 구조와 이 개념을 바탕으로 구현된 오픈 소스들을 살펴보면 다음과 같다.




종류Google오픈소스
분산파일 시스템Google File System (GFS)Apache Hadoop File System (HDFS)
Key/Value 저장Google Big TableApache HBase
분산 처리Google Map & ReduceApache Hadoop
분산 LockingGoogle ChubbyN/A

구글에서 해당 솔루션 구축에 대한 논문을 발표했고, 이 원리를 바탕으로 뛰어난 개발자들이 오프소스에 기여하여, Apache Hadoop 을 필두로 하여, Google 의 시스템 Stack과 유사한 오픈소스가 나왔고, 현재 빅데이타 분석 및 비동기 처리용으로 많이 사용되고 있다. 아쉽지만 아직까지 분산 Locking을 지원하기 위한 Chubby와 같은 솔루션에 대응 되는 솔루션은 없다. ZooKeeper등을 이용하여 분산 Lock 처리를 하거나 애플리케이션에서 이를 구현 및 제어하는 실정이다.

자세하지는 않지만, 
1) 이러한 기술들이 왜 필요하며
2) 어떤 이유에서 만들어 졌으며
3) 어떤 용도로 사용되고 있는지
에 대해서 간단하게 살펴보았다.

앞서 서문에서도 요약하였지만, 이 글의 목적은 구글 기술 자체를 깊이 있게 이해하는 것이 아니라, 너무나 유행이 되버린 분산 처리나, 빅데이타, Hadoop 기술들에 대한 맹신을 없애고, 기술에 대한 제대로된 이해를 바탕으로 적절한 곳에 적절한 기술을 활용하고자 하는데 있다.

참고
1. 분산 파일 저장 시스템 - Apache HDFS 에 대한 소개 : http://bcho.tistory.com/650
2. BigTable 기반의 Key Value Store 구조 - http://bcho.tistory.com/657 (Apache Cassandra의  Local Node당 데이타를 저장하는 구조는 Google의 BigTable과 원리가 같다)

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. taewook 2012.08.08 10:58  댓글주소  수정/삭제  댓글쓰기

    오픈소스 분산 Locking 에는 Zookeeper 가 사용됩니다.

    • 조대협 2012.08.08 17:33  댓글주소  수정/삭제

      ZoopKeeper는 코디네이터로는 괜찮은거 같은데...
      글로벌 Lock 관리는 일반적인 리소스는 몰라도, DB ROW단위와 같은 세밀한 Lock 관리는 좀 어렵지 않나요?
      분산 Lock을 ZooKeeper로 하는 시나리오를 보기는 했는데... 가능할련지 모르겠습니다.

  2. taewook 2012.08.13 15:13  댓글주소  수정/삭제  댓글쓰기

    DB Row 단위같은 세밀한 Lock 관리에 Zookeeper 가 적합하진 않습니다. 마찬가지로 Google Chubby도 DB Row 단위의 세밀한 Lock 관리에 적합하지 않지요.

    따라서 분산 Locking에 Google Chubby가 있다면, Zookeeper가 대응되거나,
    세말한 Lock 관리를 염두해 주셨다면 둘 다 분산 Locking에 포함되면 안된다고 생각합니다.

  3. 최일지 2015.04.09 16:52  댓글주소  수정/삭제  댓글쓰기

    잘 보고 갑니다!! 출처 밝히고 스크랩 해가겠습니다 ^^