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


Archive»


 

'GFS'에 해당되는 글 2

  1. 2014.10.01 임시 파일 작업 공간 (Working storage)에 대한 노트 (1)
  2. 2012.08.06 Google 기술 스택의 이해 (5)
 

임시 파일 작업 공간


비동기 처리나 분산환경에서 추가적으로 필요한 컴포넌트 중의 하나는 임시 파일 작업 공간을 들 수 있다. 임시 파일 작업 공간은 직접 애플리케이션 서버에 네트워크 파일 시스템 (NFS)등으로 마운트 될 수 있는 파일 시스템인데, 작업을 위해서 임시적으로 파일을 저장하는 공간이다.

 아래 그림을 보자, 아래 그림은 업로드된 동영상에서 썸네일을 추출하고 변환을 통해서 아카이빙 스토리지에 저장하는 구조인데, 앞단의 업로드 서버에서 파일이 업로드 되면, 파일은 임시 파일 작업 공간에 저장되었다가, 파일 업로드가 완료되면 메시지 큐에 변환 요청이 들어가게 되고, 뒷단의 변환(Transform)서버에서는 순차적으로 메시지를 받아서, 변환에 필요한 업로드된 파일을 읽어다가 변환한 후 아카이빙 스토리지에 저장하는 방식이다. 아카이빙 스토리지는 저가의 파일 저장소로 아마존 클라우드 S3, 애저 클라우드의 Blob Storage 등으로 가격이 저렴하며 REST API HTTP 프로토콜로 접근이 가능하지만 파일 시스템에 직접 마운트 하는 것은 불가능하다.



만약에 이러한 아카이빙 스토리지만을 사용한다면, 업로드 컴포넌트는 로컬 디스크에 파일을 업로드한 후, 업로드가 끝나면 이 파일을 아카이빙 스토리지에 저장해야 하고, 변환 컴포넌트는 변변환 할 때, 이 아카이빙 스토리지에서 파일을 로컬 스토리지에 복사해놓고 작업을 시작해야 한다.

만약 이러한 비동기 절차가 길면 길 수 록 많은 파일 복사가 발생하게 된다. (로컬과 아카이빙 스토리지간). 아직까지 대부분의 SDK API들이 보통 로컬 파일 시스템을 기준으로 개발이 되어 있기 때문에, 직접 아카이빙 스토리지에서 파일을 읽어가면서 작업하는 것이 어렵기 때문에. 로컬 스토리지로의 파일 복사는 일반적인 절차가 되는데, 이러한 작업을 막으려면 중간에 임시 파일 작업 공간을 넣는 것이 방안이 된다. 네트워크 파일 시스템 (NFS)와 같은 파일 시스템을 둬서, 각 서버에 마운트 한후에, 직업 이 NFS로 파일을 업로드 하고, 파일 변환 작업등도 이 NFS에서 모두 끝낸 후에, 작업이 끝난 최종 파일만을 아카이빙 스토리지로 올리는 방법이 있다.

일반적인 NFS를 사용할 수 도 있지만, 대규모 분산환경에서는 이 NFS를 이용한 임시 파일 작업 공간 자체의 IO가 많이 발생할 수 있기 때문에 분산해서 처리할 필요가 있는데,이런 경우 분산 파일 스토리지를 사용하는 방법이 있다. GlusterFS의 경우는 클러스터링 기능을 통하여 분산 기능을 제공하여 IO 성능을 높일 뿐만 아니라 특정 노드가 장애가 났을 때도 파일 복제를 통한 장애 대응이(Fail Over)를 가능하게 한다.

다른 시나리오로는 분산 환경에서의 공유 파일 시스템으로 사용이 가능한데, 아래의 시나리오를 보자, 아래의 시나리오는 많은 로그를 수집하기 위한 로그 수집 시스템으로 앞단의 API 서버 (Log Server)들이 로그 업로드 호출을 처리하고, 그 로그들을 공유 파일 시스템에 쓰는 시나리오이다. 여기서의 제약 사항은 부하량에 따라서 Log Server 수 가 늘어나고 줄어드는 Auto Scale out기능을 사용한다는 것이다.

물론 아래와 같은 구조를 사용하지 않고, 뒷단에 바로 RDBMS NoSQL등을 써서 바로 Write 하는 방법도 있고, Flume과 같은 분산 로그 시스템을 쓸 수 도 있지만, 기존의 인프라나 구성을 바꾸지 않고 가장 쉽게 할 수 있는 방식은 API 서버가 로그를 파일에 쓰는 구조이다.

아래 그림과 같이 공유 파일 시스템을 쓰면 장점이, Log Server가 줄거나 늘어남에 상관 없이 로그 파일이 공통된 파일 시스템에 모인다는 장점이다.



Log Server에 로그 파일을 써서 주기적으로 중앙 로그 저장소로 긁어갈 수 도 있겠지만, 로그를 긁어가는 수집 시스템에서 현재 기동하고 있는 Log Server들의 목록들을 알아야 한다. Log Server Auto Scale out에 의해서 늘어나거나 줄어들 수 있고, 보통 클라우드에서 이러한 Auto Scaling된 인스턴스는 IP주소가 변경되는 경우가 많기 때문에, 중앙 로그 수집 시스템이 그 주소를 알기가 어렵다.

반대로 Log Server가 파일을 중앙 저장소로 주기적으로 밀어주는 방법도 있겠지만, 이 경우 전체 시스템 부하가 줄어들었을 때,서버의 수를 줄이는 Auto Scale In이 발생하였을 때, Log Server의 인스턴스가 로그를 중앙 저장소에 복사하기 전에 내려가 버린다면 로그파일 유실이 발생할 수 있다.

그래서 바로 임시 파일 작업 공간을 만들어서 직접 마운트해서 사용하게 되면, Log Server의 코드 역시 간단하게 일반 로컬 파일 시스템을 접근하는 듯한 구조를 사용하면 되기 때문에 구현이 매우 단순해 진다.

이러한 임시 파일 작업 공간은 성능이나 신뢰성에 따라서 그에 맞는 파일 시스템 구성과 애플리케이션 설계를 해야 한다.

예를 들어 GlusterFS의 경우 하나의 파일에 append하는 데는 성능이 좋은 편이지만 작은 파일을 여러 개 쓰는 데는 성능이 좋지 않기 때문에 위와 같은 로그 시나리오라면 로그를 하나의 파일에 계속 append 해서 쓰는 구조가 좋다. 또한 고 성능이 요구 될 때는 당연히 SSD를 고려하고 RAID 디스크 구성에 있어서도 Striping 구성등을 고려 해야 한다

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과 원리가 같다)