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


Archive»


 
 

아마존의 EC2 서비스는 VM 기반의 컴퓨팅 자원을 제공하는 서비스이다.

클릭 몇 번으로 저기 바다 넘어있는 나라에 내 서버를 만들 수 있으며, 내가 사용한 만큼만 비용을 지불하면 된다.
아마존 EC2에서 제공하는 VM은 성능과 특성에 따라 여러가지 타입을 가지고 있다.

일반적인 인스턴스 
  • 1세대 인스턴스(m1) : m1.* 이름으로 시작하며 아마존에서 일반적으로 제공하는 가상화된 VM 인스턴스 이다.
  • 2세대 인스턴스(m3) : 2012년에 발표한 인스턴스로 m3.* 로 시작하며, 기존에 비해서 50% 이상의 높은 CPU 성능을 가지고 있다.
특수목적 인스턴스 

  • 고용량 메모리 인스턴스(m2) : m2.* 이름으로 시작하며 17,34,68 GB등 많은 용량의 메모리를 가지고 있는 인스턴스이다. (가상코어 역시 그만큼 많이 가지고 있다) 데이타베이스나 메모리 캐쉬 서버등 메모리 사용량이 높은 서비스에 이용할 수 있다. 
  • 고성능 CPU 인스턴스(c1) : c1.* 이름으로 시작하며, 같은 메모리나 디스크를 갖는 m1 시리즈에 비해서 상대적으로  CPU 만 더 많이 가지고 있다.
  • 클러스터링 인스턴스(cc1) : cc1.* 로 시작하며, 아마존 인스턴스 중에서 가장 높은 스펙을 가지고 있다. 많은 CPU와 많은 메모리 그리고 10G 기반의 IO 성능을 가지고 있다. 특히 클러스터링 인스턴스는 placement group이라는 옵션을 지원하는데, 아마존의 VM은 내부에서 생성될때, 어느 위치(Rack)에 생성될지 알 수 가 없다. 그래서 인스턴스간의 네트워크 latency가 예측 불가능 한데, 클러스터링 인스턴스를 placement group으로 묶으면, 인스턴스간의 네트워크 latency를 최소화하고 인스턴스간 10GB 네트웍을 사용한다. 클러스터링된 서비스들은 대부분 인스턴스간의 통신을 하고 그 속도에 많은 영향을 받기 때문에, 클러스터링 된 서비스에 매우 유리하다. Cassandra,MongoDB등과 같이 내부적으로 클러스터링이 되는 NoSQL등에도 사용할 수 있다.
  • 클러스터 GPU 인스턴스(cg) : cg* 로 시작하는 인스턴스로, VM에 GPU (그래픽카드에 들어가는 CPU)가 대거로 포함되어 있다. 우리가 사용하는 그래픽 카드에는 GPU라는 프로세스가 들어 있는데, 이 GPU들은 실수 연산 (floating point)과 같은 수치 연산에 매우 최적화되어 있다. 그래서 수치 해석이나 대규모 병렬처리등에 매우 유리한데, 이러한 GPU들은 CPU와는 다르게 큰 코어를 수개~수십개를 가지고 있는 것이 아니라 수백개의 GPU 코어를 가지고 있기 때문에, 수치 연산에 있어서는 탁월한 성능을 발휘할 수 있다.
  • High IO 인스턴스(hi) : hi*로 시작하며 높은 성능의 네트워크와 디스크 IO성능을 보장한다. 특히 디스크 성능이 탁월하게 높은데 그럴 수 밖에 없는 것이 SSD를 사용한다
EBS(디스크) 성능 옵션

그 외에, 위의 VM을 선택한 후에, VM에 따라 다음과 같은 몇 가지 추가 옵션을 제공한다.
EBS는 나중에 설명하겠지만, iSCSI기반의 SAN 스토리지다. PC로 쉽게 생각하면 외장 하드 정도로 이해하면 된다. (물론 그보다는 훨씬 빠르지만). EC2에서 문제가 되었던게 이 EBS 디스크를 VM에 붙였을때, EBS 디스크에 대한 IO 성능 느리고, 그 성능이 일정하지 않았던 문제를 가지고 있었다. 이를 보와하기 위해서 나온 것이 다음과 같은 두 가지 옵션이다.

Provisioned IOPS (PIOPS)
EBS 디스크 용량에 따라서 IOPS를 보장한다.  보장 가능한 IOPS는 EBS용량에 비례하여 증가한다. GB를 기준으로 N GB사용시, 명시적으로 지정 가능한 최대 IOPS는 N*10 IOPS가 된다. (40GB면 400IOPS, 100GB면 1000IOPS) 현재 최대 1,000 IOPS까지 지원된다.
정확하게는 EC2 VM의 옵션이 아니라 EBS의 옵션으로, Provisioned IOPS를 선택하면, IO 성능을 보장할 수 있는 EBS 디스크 영역에 EBS Volume이 생성된다.

EBS Optimized Instance
EBS Optimized Instance는 EBS와 EC2 인스턴스간에 내부적으로 전용 네트워크를 사용하여 대역폭을 안정적으로 유지해준다. 500Mbps~1000Mbps 사이에 대역폭을 설정할 수 있다.

추가적인 기능
아마존 EC2의 VM 서비스는 몇 가지 추가적인 기능을 가지고 있다.

VM Import/Export
Virtualization 기반의 서비스인 만큼 다른 동작중인 VM에 대한 Snapshot을 뜰 수 있고, 이 Snapshot 파일을 Export할 수 있다. 반대로 Local PC나 자사의 데이타 센터에서 사용하는 VM Image를 Import할 수 도 있다. 현재 지원하는 포맷은 VMDK(VMWare 포맷),VHD(Microsoft), RAW 포맷등을 지원한다.

Amazon Marketplace
Amazon Market Place는 EC2 VM을 생성할때, 미리 소프트웨어가 다 깔려져 있는 VM 이미지를 구매할 수 있는 Market place이다.  예를 들어 VM 생성시 RedHat Enterprise Linux 이미지를 선택하면, RedHat Linux가 깔려 있는 VM이 생성된다. OS 뿐만 아니라 SAP와 같은 패키지 소프트웨어에서 부터 LAMP (Linux + Apache +MySQL + PHP)와 같은 여러 소프트웨어 솔루션의 조합까지 다양한 형태의 이미지들을 구매할 수 있다.



물론 이러한 이미지들은 공짜가 아니다 EC2 시간당 사용 요금에 함께 합쳐서 소프트웨어 라이센스비가 청구된다. 
제품에 따라서는 아마존을 통해서 기술 지원을 받을 수 있는 제품들도 있다. 예를 들어 RedHat Linux의 경우 가격은 일반 Linux VM에 비해서 두배 가량 비싸지만, 아마존을 통해서 기술 지원을 받을 수 있다.

Elastic IP
EC2 VM의 특징중의 하나가, VM이 생성되고 그리고 Restart될 때마다 그 IP 주소가 동적으로 매번 바뀌다는 것이다. 이렇게 IP가 바뀌면 서버간의 통신이나 외부 서비스시에 고정 IP가 없으면 서비스가 어렵기 때문에, 아마존에서는 인터넷 고정 IP 자체를 EIP 라는 이름으로 판매한다. EIP를 구매하면, 인터넷 Public IP가 하나 부여되고, 이를 EC2 인스턴스에 부여하면 고정 IP를 사용할 수 있다.

특성
이외에도 EC2 서비스는 몇 가지 특성을 가지고 있다.

IP 주소 변경
앞의 EIP에서도 설명하였듯이, EC2 인스턴스는 EIP를 배정하지 않는 이상 리스타트 때마다 IP가 변경된다. 고정 IP를 사용하는 방법은 EIP와 VPC (Virtual Private Cloud)를 사용하여 Private IP를 배정하는 방법이 있다. (나중에 설명)

IO 성능
EC2 서비스, 아니 모든 클라우드 서비스에서 가장 신경써야 하는 부분이 IO다. 기본적으로 LOCAL 서버 만큼의 성능이 나오지 않는다. 네트워크 구간 성능, EBS 디스크와 연결된 네트워크 성능 모두 일반 LOCAL 서버에 비해서 낮다.(물론 IO 옵션을 적용하고, 큰 인스턴스를 사용하면 높아진다.) 이 IO 성능은 인스턴스 크기에 비례하고, IO 옵션 (PIOPS, EBS Optimized Instance)에 따라서 높일 수 있다. LOCAL 환경에서 개발한 시스템들이 AWS EC2에 올리면 많은 성능 차이가 나는 이유중의 하나가 이 IO 성능 때문이다. 인스턴스별 IO 성능은  http://aws.amazon.com/ko/ec2/ 를 나와 있다. 주의할점은 EC2의 네트워크는 다른 EC2인스턴스와 공유해서 사용되기 때문에, 그 성능이 일정하지 않다. 큰 인스턴스를 사용하면, 전체적으로 성능은 올라가지만 그 성능에 대한 편차가 크기 때문에 서비스전에 반드시 측정 및 테스트 후에 사용해야 한다.

SLA
SLA는 Service Level Agreement의 약자로, 서비스의 안정성을 백분율로 나타낸 것인데, 100%이면 1년에 장애가 없는 것. 99.95%면 1년에 365일 * 0.05% 만큼 장애가 날 수 있다는 것이다. 그런데 아마존 EC2 서비스의 SLA는 바로 99.95% 이다. 1년에 4.38 시간이 장애가 나도 아마존 책임이 아니라는 이야기. 그래서 AWS에서 설계를 할때는 항상 데이타 센터 자체가 장애가 나거나 region이 장애가 나는 것을 염두 해두고 Zone간 또는 Region 간 Fail over (장애 대응) 시나리오를 고려해서 설계해야 한다.

시간 단위 과금
EC2 사용시 주의해야할 점은 시간 단위의 과금이다. 딱 시간 개념으로만 과금을 한다. 분이나 초의 개념이 없다. 무슨말이냐 하면, 1시간을 사용하던, 1시간00분1초~1시간59분59초는 무조건 2시간으로 과금이 된다. 그래서 EC2 인스턴스의 UP time (기동시간)을 자동화 하거나 스케쥴링 할경우에는 시간을 넘지 않도록 해야 불필요한 시간 과금이 발생하지 않는다.

CPU 단위 ECU
아마존은 EC2 인스턴스의 컴퓨팅 능력 즉, CPU의 단위를 ECU라는 단위로 표현한다.
ECU는 하나의 표현 단위일 뿐이지 1 ECU = 1 vCore나, 1CPU를 뜻 하는 것이 아니다.
아마존 홈페이지의 내용을 인용하면, 1 ECU는 
"
ECU(EC2 컴퓨팅 유닛) 1개는 1.0~1.2GHz 2007 Opteron 또는 2007 Xeon 프로세서와 동일한 CPU 용량을 제공합니다. 이는 원본 설명서에 언급되어 있는 초기 2006 1.7 GHz Xeon 프로세서와도 동일한 수준입니다" 라고 나와 있다. 5~6년전 CPU 성능이다.


인스턴스 과금 방식에 따른 분류
EC2는 계약 방식에 따라 다른 가격 체계를 가지고 있다.
  • Free : 개발이나 테스트를 할 수 있게 일부 인스턴스를 무료로 제공한다. micro 인스턴스의 경우 750시간 무료, 그 이후에는 과금이 되니 주의 바람 (참고 http://aws.amazon.com/ko/ec2/pricing/ )
  • On-Demand Instance : 우리가 일반적으로 사용하는 과금 방식으로, 사용한 시간 만큼 비용을 지불하는 형태이다.
  • Reserved Instance : 일정 기간 인스턴스 사용을 약속하고, 그에 대한 Discount를 받는 방식
  • Spot Instance : 입찰 방식의 사용방법.  사용자가 입찰 가격을 제시해놓으면, 아마존에서 남는 인스턴스들에 대해서 Spot 가격을 책정하는데, 이 가격이 입찰가격 내로 들어오면 인스턴스가 기동되는 방식. 입찰 가격이 넘어가면 자동으로 Spot Instance는 다시 종료 된다. 인스턴스의 가동 시간을 예측할 수 없기 때문에, OLTP식의 일반적인 업무에는 적절하지 않고, Batch 나 분석 업무 같이 대규모의 컴퓨팅 자원을 분산해서 처리 하지만, 항상 인스턴스가 떠 있을 필요가 없는 업무에 적절하다.
아마존을 사용하고, 어느정도 EC2의 볼륨이 확정되면 Reserved Instance를 사용하는 것이 좋다. On-Demand는 가격이 비싸다.
그리고 Map & Reduce와 같은 OLTP용 서비스가 아닌 Batch나 계산 업무는 Spot Instance를 사용하는 것이 좋다.


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

댓글을 달아 주세요

  1. 주디아줌마 2012.12.03 11:20 신고  댓글주소  수정/삭제  댓글쓰기

    잘 보겠습니다^^

  2. Xmodulo 2012.12.22 12:37  댓글주소  수정/삭제  댓글쓰기

    친절한 설명 감사합니다. EC2를 함 써볼까 생각중이었습니다.

AWS (Amazon Web Service) 사용시 주의 사항


1. IP가 매번 바뀐다.

aws의 ec2 instance는 restart시 마다 ip가 매번 바뀐다. ip를 바꾸지 않으려면 EIP (Elastic IP)를 사용해야 하는데, 비용이 크다. 그래서 이런 경우에는 aws에 자체 dns 서버를 세팅하고, instance 가 start up 될때 마다, 고유 서버의 dns 이름을 새로 binding된 ip와 맵핑해서 dns서버에 등록하도록 스크립트를 짜 놓으면 유용하다.


2. io bandwidth를 믿지 마라

aws의 가장 큰 어려운 점이, 네트워크 대역폭이다. 아무래도 공유 서비스이다 보니 네트워크 대역폭이 매우 느리다. 즉 내부 서버간 예를 들어 application server - dbms 또는 application server간에 네트워크 대역폭이 느리고 또는 일정하지 않기 때문에 대 부분의 병목이 여기서 발생한다.

이를 해결하기 위한 방법은 큰 ec2 instance를 사용하면 높은 대역폭을 사용할 수 있으며,

Provisioned IOPS를 지원하는 ec2 instance의 경우에는 일정 수준의 IOPS를 보장해준다. (물론 돈을 내야 한다.)

또는 고 성능의 IOPS를 보장하는 인스턴스를 사용하는 것도 방법이 된다.

다른 방법으로는 Placement group이라는 옵션을 사용할 수 있다. 이는 clustering이 필요한 솔루션 (Nosql이나 cache 솔루션)을 사용할때 이 placement group을 이용하면, 해당 서버들을 가능하면 물리적으로 가까운 곳에 위치 시켜서, network 지연을 최소화 한다.

참고 http://bcho.tistory.com/630


3. 미리 resource를 확보해라.

EIP는 5개, EC instance는 20개가 처음 계정을 만들었을때 디폴트 값이다. 테스트 환경을 사용하거나 몬가 하다보면 eip나 ec2 instance가 모자르게 되는데, 미리 미리 확장에 대비해서 확보해놓는 것도 중요하다. 신규 신청시 시간이 걸리기 때문에 미리 신청해놔야 하며, 상품에 따라서 미리 확보해놓으면 과금이 될 수 있다. 아래는 디폴트로 확보되는 자원의 수이다.

EIP – 5
EC2 instance – 20
EBS Volumes – 5,000 volumes or an aggregate size of 20 TiB (max volume size is 1TB)
PIOPS - 10,000 Provisioned IOPS or an aggregate size of 20 TiB (whichever is smaller) S3 Buckets – 100 
Route53 - 100 Hosted Zones and 10,000 Resource Record Sets per Hosted Zone 
ELB - 10 concurrent load balancers 
RDS – 20 RDS MySQL instances (each instance has hard limit max 1024GB) and up to 5 Read Replica instances can be created from a Master. 
VPC – 5 VPCs, 20 subnets each, 50 Security Groups each, 50 rules per Security Group and 5 Security Groups per instance. 10 Network ACLS per VPC, 20 rules per ACL. 10 Route Tables per VPC and 20 entries per route table


4. 가급적이면 VPC를 사용하자.

VPC는 Virtual Private Cloud의 약자로 10.x.x.x 와 같은 내부 ip 대역을 사용할 수 있게 해준다. 이는 논리적으로 다른 서비스(다른 사용자의)와 분리하게 해줄뿐더러, ip를 고정으로 사용할 수 있게 해주시 때문에 위의 1번 문제를 회피할 수 있도록 해준다.


5. 과금에 관련해서.

안쓸때는 꺼놔라. 다 과금 된다.

1시간5분을 사용하더라도 2시간으로 과금된다. 서버의 startup과 down은 시간 단위로 하자.


6. RDS

최대 용량이 1TB이다. 장점은 AZ(Zone)간의 HA를 기본적으로 지원한다.

replica는 db당 최대 5개 까지만 지원한다.


7. multicast

AWS는 multicast를 지원하지 않는다. 상당수의 클러스터링 솔루션이 muticast를 사용하는 경우가 많다.(Oracle RAC) 이경우에는 AWS에서 클러스터를 사용할 수 없다.


8. ELB는 고정 IP가 아니다.

ELB는 HA와 확장성을 지원하기 위해서 DNS Round Robine 방식으로 연결된다. 즉 고정 IP를 사용할 수 없다. 시스템에 대한 접근 IP(방화벽등을 위해서)가 필요할 경우 ELB 앞단에 HA Proxy등 별도의 Proxy를 둬야 한다.


9. AWS에는 IDS가 없다.

기본적으로 탑재된 침입 탐지등의 ids/ips 솔루션이 없기 때문에, 보안이 중요한 경우 이를 사전 고려 해서 ec2 위에서 기동 될 수 있는 ids/ips 솔루션을 탑재하는 것이 좋다.


10. 장기적인 이용에는 on-demand instance를 이용하지 마라.

on-demand instance는 그때 그때 사용하기는 좋지만 과금 모델이 가장 비싸다. 어느정도 기간을 가지고 이용할 예정이면 reserved instance나 spot instance를 이용하는 것이 저렴하다.






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

댓글을 달아 주세요

  1. 강문수 2013.06.15 15:39  댓글주소  수정/삭제  댓글쓰기

    좋은 글 잘보고 가요.
    감사합니다. ^^

NoSQL 데이타 모델링 #1

Facebook Server Side Architecture Group
http://www.facebook.com/groups/serverside
조대협

빅데이타,클라우드,NoSQL은 요즘 기술적인 화두중에 하나이다. 그중에서도 NoSQL은 많은 사람이 관심을 갖고 있음에도 불구하고, 기존의 RDBMS 데이타 모델링 관점에서 접근을 하기 때문에, 많은 문제를 유발한다. NoSQL은 데이타 베이스이기도 하지만 RDBMS와는 전혀 다른 성격을 가지고 있고, 접근 방식도 틀리다.

특히 테이블 구조를 정의 하는 데이타 모델에 따라서 NoSQL의 성능은 하늘과 땅차이만큼 차이가 난다. 이 글에서는 NoSQL의 데이타 모델링 기법에 대해서 소개하고자 한다.
※ 깨지는 그림은 클릭해서 봐주세요.

NoSQL 데이타 모델

데이타 모델링에 앞서서 NoSQL이 어떤 구조로 데이타를 저장하는지를 먼저 이해할 필요가 있다. NoSQL의 데이타 모델링 패턴은 아래와 같이 크게 3가지 패턴정도로 구분된다.

1.     Key/Value Store

가장 기본적인 패턴으로, 대부분의 NoSQL은 다른 데이타 모델을 지원하더라도, 기본적으로 Key/Value의 개념을 지원한다. Key/Value Store, Unique Key에 하나의 Value를 가지고 있는 형태를 이야기 한다. Put(Key,Value), Value := get(Key) 형태의 API로 접근한다.


Value String이나 Integer와 같은 Primitive 타입이 될 수 도 있지만, 이정도로는 우리가 일반적으로 사용하는 테이블 형태의 데이타를 저장할 수 없기 때문에, 조금 더 확장된 개념을 사용하는데, Column Family라는 개념을 사용한다. Key 안에 (Column,Value) 조합으로 된 여러개의 필드를 갖는데, 이를 Column Family라고 한다.


예를 들어, 사용자 프로필을 저장하는 시나리오가 있을 때, 사용자의 이름을 KEY로 한다면, 성별,주소,나이들은 각각의 Column이 될 수 있다. Key 필드는 RDBMS에서 Primary Key, Column 필드들은 RDBMS의 일반 데이타 필드로 이해하면 된다. 프로그램 언어와 비교해서 생각한다면, Key/Value Store Map 데이타 구조와 유사하다.
Oracle Coherence
Redis와 같은 NoSQL이 이 데이타 모델을 기본 모델로 사용한다.

2.     Ordered Key/Value Store

Key/Value Store의 확장된 형태로 Key/Value Store와 데이타 저장 방식은 동일하나, 데이타가 내부적으로 Key를 순서로 Sorting되서 저장된다.



Sorting이 별거 아닌것 같지만, NoSQL 관점에서는 대단히 중요한 기능을 제공하게 된다. 뒤에 데이타 모델링 기법에서도 다루겠지만, NoSQL RDBMS Order By와 같은 기능을 제공하지 않기 때문에 결과값을 업데이트 날짜등으로 소팅해서 보여주는 것은 이 Ordered Key/Value Store가 절대적으로 유리하다.

대표적인 제품으로는 Apache Hbase, Cassandra 등이 있다.

3.     Document Key/Value Store

Key/Value Store의 확장된 형태로, 기본적으로는  Key/Value Store이다. Key에 해당하는 Value 필드에 데이타를 저장하는 구조는 같으나, 저장되는 Value의 데이타 타입이 Document 라는 타입을 사용하는데, Document 타입은 MS-WORD와 같은 문서를 이야기 하는것이 아니라, XML,JSON,YAML과 같이 구조화된 데이타 타입으로, 복잡한 계층 구조를 표현할 수 있다.



아울러, Document Store 기반의 NoSQL은 제품에 따라 다르기는 하지만 대부분 추가적인 기능 (Sorting,Join,Grouping)등의 기능을 제공한다.

대표적인 제품으로는 MongoDB,CouchDB,Riak 등이 있다.


그리고 여기서는 구체적으로 다루지 않지만 Graph Tree구조와 같은 데이타 구조를 저장하기 위해서 최적화된 Neo4J등의 NoSQL이 있다. 만약에 테이블 구조의 데이타가 아니라 Graph 구조의 데이타를 저장하고자 한다면 Neo4J를 한번 체크해보기 바란다.


RDBMS NoSQL의 차이

NoSQL DBMS라고 생각해서 RDBMS와 같은, 또는 떨어지지만 유사한 기능을 제공할것이라고 생각하면 큰 오산이다. NoSQL은 데이타를 저장한다. 그리고 Key에 대한 Put/Get만 지원한다. RDBMS로 치자면

Put : Insert into TABLE VALUES(KEY,value1,value2,…,valuen)

Get : Select * from TABLE where KEY=”key”

만 딱 지원한다. 물론 제품에 따라서 기능에 대한 지원 범위는 다르기는 하지만, 공통적으로 고민해야 하는 기능은

Ÿ   Sorting (SQL Order By)

Ÿ   Join (RDBMS에서 두개의 Table Foreign Key를 이용하여 join)

Ÿ   Grouping (SQL문의 group by)

Ÿ   Range Query (where key>”start” and key<”end” 와 같이 일정 범위내의 내용을 쿼리해오는 기능)

Ÿ   Index (RDBMS Index를 지정하여 select query 성능을 높이는 기능)

이다. RDBMS에서는 너무나도 익숙하게 사용했던 기능들이기 때문에, 막상 이 기능들을 빼고 데이타를 다루고자 하면 매우불편하다. 여기서는 이러한 기능들을 “NoSQL 데이타 모델링 패턴소개를 통해서 NoSQL에서 어떻게 구현할 수 있는지 알아볼 것 이다.

NoSQL 데이타 모델링 시작하기

NoSQL 데이타 모델링이란, NoSQL에 저장할 데이타들의 구조, 즉 테이블 설계를 하는 것을 정의한다. NoSQL DBMS이기는 하지만, 우리가 지금까지 익숙하게 사용해왔던, RDBMS와는 그 특성이 매우 다르기 때문에 접근 방법을 바꿔야 한다.

NoSQL RDBMS의 데이타 모델링 차이

NoSQL을 사용해서 데이타 모델링을 하려면 근본적인 사상 2가지를 바꿔야 한다.

1)     개체 모델 지향에서 쿼리 결과 지향 모델링

RDBMS의 모델링 기법은, 저장하고자하는 도메인 모델을 먼저 분석한 후에, 개체간의 관계(relationship)를 식별하고, 테이블을 추출해내고, 테이블을 이용하여 쿼리를 구현하여 결과를 뽑아내는 방식이다.

NoSQL의 경우에는 이 접근 방법을 역순으로 진행해야 한다.

RDBMS가 도메인 모델 à [테이블 à 쿼리] 순서로 진행을 했다면, NoSQL은 도메인 모델 à [쿼리 결과 à 테이블] 순서로 테이블을 디자인해야 한다. RDBMS의 경우 여러가지 최적화된 기능으로 테이블을 가지고 자유롭게 쿼리 결과를 뽑아낼 수 있지만, NoSQL의 경우 복잡한 쿼리 기능이 없기 때문에, 반대로 도메인 모델에서 어떤 쿼리 결과가 필요한지를 정의한후에, 이 쿼리 결과를 얻기 위한 데이타 저장 모델을 역순으로 디자인해야 한다.

2)     정규화(Normalization)에서 비정규화(Denormalization)

RDBMS 모델링에서는 데이타의 일관성과 도메인 모델과의 일치성을 위해서 데이타 모델을 정규화한다. 그중에서도 같은 데이타가 두개 이상의 테이블에 중복되게 저장하는 것을 제거 하는데, NoSQL은 반대의 접근 방법이 필요하다. 쿼리의 효율성을 위해서 데이타를 정규화하지 않고, 의도적으로 중복된 데이타를 저장하는 등의 비정규화된 데이타 모델 설계 방식으로 접근해야 한다.

NoSQL 데이타 모델링 절차

그러면, RDBMS NoSQL의 두가지 결정적인 차이를 인식하고, NoSQL 기반의 데이타 모델링 절차를 살펴보자.

1.     도메인 모델 파악

먼저 저장하고자하는 도메인을 파악한다. 어떤 데이타 개체가 있는지 개체간의 관계는 어떻게 되는지등을 분석하고 ERD를 그려서 도식화 한다. RDBMS의 모델링 접근 방법이고, NoSQL에서는 이렇게 하지 않고 바로 애플리케이션 관점으로 접근하는 경우도 많은데, 도메인 모델 분석 없이 필자의 경우에는 이런 방식에는 반대이다. NoSQL도 데이타베이스이고 저장할 데이타에 대한 명확한 이해 없이는 제대로된 데이타 모델이 나올 수 없다.

다음은 간단한 블로그 시스템의 데이타 도메인 모델이다. 이 블로그 시스템은

Ÿ   사용자 ID 기반으로 블로그의 분류(Category)를 가지고 있고,

Ÿ   분류별로 글을 작성할 수 있으며,

Ÿ   글에 파일을 첨부할 수 있고,

Ÿ   댓글을 달 수 있는 블로그이다.

Ÿ   이번 예제에서는 검색이나 페이징 기능은 제외한다. (단순화 하기 위해서)



2.     쿼리 결과 디자인 (데이타 출력형태 디자인)

다음으로 가장 중요한 과정인 쿼리 결과 디자인이다. “도메인 모델을 기반으로 애플리케이션에 의해서 쿼리 되는 결과값을 먼저 정해야 한다.

앞서 예를 든 블로깅 시스템을 다시 살펴보자



     화면 좌측 상단에는 블로그 사용자의 포스팅 분류명들을 목록 식으로 출력한다.

     포스팅 출력 화면에는 상단에, 포스팅의 분류명과 제목을 출력하고 다음에는 포스팅 날짜, 본문 내용을 출력한다.

     다음에는 첨부파일들을 출력하는데, 첨부파일 업로드 날짜와 파일명을 차례대로 출력하고, 파일에 대한 링크를 출력한다.

     마지막으로 댓글을 출력하는데, 댓글에는 작성일과, 작성자 이름과 댓글 내용을 출력하고, 작성자 이름에는 이메일을 링크한다.

이 출력 형식을 기반으로, 어떤 쿼리가 필요한지를 정의해보자

     전체 분류 출력

select categoryID,name from Category where userID=”사용자ID”

     포스팅의 분류,제목,날짜,본문 출력

select po.postID,po.Contents,po.date,ca.name
from Category ca,Post po
where userID=”
사용자ID”
order by date desc

     첨부 파일 출력

select fileID,filename,date,fileLocation
from Attachment
where userID=”
사용자ID” and postID=”현재 포스팅 ID”
order by date desc

     댓글 출력
select userID,email,Contents,date
from Comment
where userID=”
사용자ID” and postID=”현재 포스팅 ID”
order by date desc

대략적으로 4개의 쿼리가 필요하다. (물론 RDBMS 실제 구현에서는 좀더 최적화 할 수 있겠지만, 이해를 돕기 위해서 단순 구현하였다.) 그러면, 어떤 형태의 데이타 테이블들이 출력되는가?



위와 같이 애플리케이션의 출력형태에 따른 데이타를 정리할 수 있다. 사실 이것이 가장 중요하다. 앞에서도 설명했듯이, NoSQL의 데이타 모델링은 도메인 모델을 중심으로 하는 것이 아니라, 이 애플리케이션의 데이타 출력 내용을 기반으로 하기 때문이다.

3.     패턴을 이용한 데이타 모델링

애플리케이션 데이타 출력 내용을 디자인 했으면, 이제 이 내용을 가지고 NoSQL에 정의될 데이타 모델링을 들어간다. NoSQL Sorting,Grouping,Join 등의 RDBMS 기능을 제공하지 않기 때문에 이를 배제하고 Put/Get으로만 데이타를 가지고 올 수 있는 형태로 데이타 모델 즉 NoSQL내의 테이블을 재 정의 해야 한다.

이 데이타 모델링을 돕기위해서 다음 챕터에서는 NoSQL 데이타 모델링 기법을 다시 설명한다. 이 때 가장 중요한것은 Demoralization이다. 데이타를 가급적 중복으로 저장하여, 한번에 데이타를 읽어오는 횟수를 줄이도록 한다. ( IO자체가 엄청난 부담이기 때문에)

위의 블로깅 시스템 데이타를 일반적인 NoSQL 스타일로 바꾸면 다음과 같다.



특히 Key 부분을 주목해 볼 필요가 있는데, Join을 없애기 위해서, 아예 userID postID“:”로 구분되는 deliminator로 하여 Key에 포함시켜 버렸다. 이는 Join을 없애는 것 이외에 다른 이유가 또 있는데, Ordered Key/Value Store의 경우에는 Key를 기반으로 소팅을 하기 때문에 첫번째, 포스트 ID Sequential하게 증가 시켜 나가면, 같은 사용자의 글의 경우에는 Sorting 이 가능하다. 두번째, Grouping인데, 포스팅을 출력하는 사용자에 대해서 posting을 쭈욱 출력해 나가면, 순차적으로 Post가 출력이 되다가, 해당 사용자의 포스팅 데이타가 끝이나면, Key의 맨앞 userID가 다른 사용자id로 바뀌기 때문에 where문장이 없이도, 특정 사용자의 포스팅을 순차적으로 출력할 수 있다. 뒤에서 설명한 데이타 모델링 패턴에서 Enumerable Key Composite Key Index 패턴을 참고하기 바란다.


4.     최적화를 위한 필요한 기능들을 리스팅

자아 이제 약간은 NoSQL스럽게 디자인이 되었다. 이제는 NoSQL의 특성을 반영하여, 조금 더 디테일한 디자인을 할 수 있다. 다시 애플리케이션 및 데이타의 특성을 다시 한번 들여다 보자

첨부 파일 (Attachment) 파일의 경우에는 포스팅이 작성되었을 때 레코드가 추가되며, 변경이 거의 없다. 그리고 첨부파일의 수는 그리 많지 않기 때문에, 하나의 필드에 모두 몰아서 저장할 수 있다. 이렇게 하나의 필드에 여러개의 데이타를 저장할 경우에는 Document Store를 고려해 볼 수 있다.

그리고 앞에서도 언급했지만 블로그 포스트,첨부파일,댓글은 소팅이 되어야 하기 때문에, Ordered Key 형태가 필요하다.

현재 데이타 모델은 포스팅이 포스트된 순서대로만 출력하는 형태인데, 분류 개념이 있기 때문에, 분류에 따라서 포스팅을 출력하려면 분류 필드가 별도 필드로 들어가야 하고, 이 필드에 따라 where문으로 select할 수 있는 기능이 있어야 한다. 마치 RDBMS Index같은 개념이 필요한데, 이러한 기능을 NoSQL에서는 Secondary Index라고 한다.



이런 옵션등을 적용해보면 Posting 테이블은 위와 같이 변경해볼 수 있다.

여기서 고려해야 할점 하나를 짚고 넘어가자..!!

NoSQL 제품들은 KV, Ordered KV, Document Store등 데이타 모델로는 3가지 분류로 분리가 되긴 하지만, 세세한 내부 아키텍쳐나 기능들은 매우 다르다아주 자세하게는 아니더라도, 어떤 NoSQL 제품군이 있고, 대략적인 기능이 어떻게 되는지를 알아야, 이 정도 수준의 설계를 할 수 있다. 물론 이 단계까지 설계되더라도 아직까지 완벽하지 않다.

솔루션들이 스펙상에 “OOO 기능이 있다.” 하더라도, 그 기능이 제대로 돌아가는 건 아니다. Secondary Index의 경우 Cassandra Riak에서 지원은 하지만 실제 부하를 줘 가면서 테스트를 해보면 성능이 잘 안나오는 경우가 많고, 내부 구조상으로도 고성능을 내기가 어려운 구조이다. 그래서 이런 부가 기능들은 직접 내부 구조를 분석하고, 테스트를 해봐야 사용 가능 여부를 판단할 수 있다.

예전의 RDBMS, 워낙 레퍼런스도 많고, 벤더 지원도 있기 때문에, 써야할, 쓰지 말아야할 기능이 명확하지만 NoSQL의 경우는 제품도 많을 뿐더라, 기술도 신기술이기 때문에 서적조차 드물다. 직접 분석하고 테스트해보는 방법 밖에 없다.


5.     후보 NoSQL을 선정 및 테스트

앞에서 언급한 바와 같이, 모델링한 데이타 구조를 효과적으로 실행할 수 있는 NoSQL을 찾아야 한다. 이는, NoSQL에 대한 구조 및 특성 분석 후에, 실제로 부하 테스트, 안정성, 확장성 테스트를 거친 후에, 가장 적절한 솔루션을 선택해야 한다.

경우에 따라서는 하나의 NoSQL이 아니라, 여러개의 NoSQL을 복합해서 사용할 경우도 있다. 트위터나,페이스북같은 대규모 서비스들은 하나의 NoSQL만을 사용하지 않고 데이타의 성격과 업무의 목적에 맞는 다수의 NoSQL을 선정하여 사용한다.


6.     데이타 모델을 선정된 NoSQL에 최적화 및 하드웨어 디자인

마지막으로 선정된 NoSQL을 기반으로 다시 데이타 모델을 최적화 하고, 이에 맞는 애플리케이션 인터페이스 설계와 하드웨어에 대한 디자인을 진행해야 한다.


지금까지 간단하게나마 NoSQL의 데이타 모델링 절차에 대해서 알아보았다. 다시 한번 강조하지만 NoSQL의 데이타 모델링 방식은 RDBMS가 데이타 자체의 관계를 중요시 하고, 데이타에서부터 출발한다면, NoSQL은 애플리케이션이 출력하고자 하는 데이타 출력 내용에 따라서 데이터 모델링이 완성된다. RDBMS와 역순으로 진행되어야 하고, 데이타 중심이 아니라, 애플리케이션 중심으로 모델링을 진행해야 한다.

그리고 NoSQL은 신 기술 분야이면서 오픈 소스 진영이 주를 이르고 있기 때문에, 기술 지원을 받기가 매우 어렵다. 물론 외국에는 NoSQL에 대해서 유상으로 기술 지원을 해주는 업체들이 있기는 한데, (Cassandra의 경우 DataStax가 기술 지원을 하고, Riak Basho, MongoDB 10gen 등이 기술 지원을 한다.). 국내 실정상 외국엔지니어를 불러다가 기술 지원을 받기도 힘들뿐더러, 기술 지원 회사의 규모가 작기 때문에 숙력된 엔지니어를 필요할때 마다 부르기도 어렵다.

그리고, Amazon등에서 검색해보면 알겠지만, NoSQL에 대한 서적도 그리 많지 않은 편이기 때문에 공부하기도 어렵다. 해외에서 이러한 NoSQL류를 쓰는 업체들은 스스로 내부 개발자들을 역량을 키워서 공부하고, 테스트해서 내재화된 기술을 기반으로 NoSQL을 운용하기 때문에, 단순하게 솔루션 도입 관점에서만 볼 것이 아니라, 기술 내재화 관점에서도 NoSQL 도입을 고려해야 한다.


다음글에서는 NoSQL의 데이타 모델링을 하기 위한 일반적은 데이타 모델링 패턴에 대해서 소개하기로 한다.

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

댓글을 달아 주세요

  1. 김병진 2012.08.27 11:11  댓글주소  수정/삭제  댓글쓰기

    역시 조대협이십니다. 감사합니다. 초보자인 저도 읽을 수 있을 정도로 잘 설명해 주셨네요. 감사합니다. 앞서 간 아이티의 선구자들을 인터넷으로 뵙습니다.

  2. 최성현 2012.09.18 21:24  댓글주소  수정/삭제  댓글쓰기

    너무나 좋은 글 감사합니다.
    이렇게 잘 정리된, 한글로 된 noSQL 설명을 볼 수 있으리라곤 생각도 못했습니다.

    감사합니다(_ _)

  3. stud 2012.09.24 11:39  댓글주소  수정/삭제  댓글쓰기

    감사합니다 덕분에 개념이 좀 잡히는 듯합니다.

  4. 김승태 2012.10.17 11:37  댓글주소  수정/삭제  댓글쓰기

    글 서두에
    '특히 테이블 구조를 정의 하는 데이타 모델에 따라서 NoSQL의 성능은 하늘과 땅차이만큼 차이가 난다.'
    라고 하셨는데 정확히 어떨경우 차이가 나는지와 왜 차이가 나는지 잘 모르겠습니다. 설명해주시면 아주 감사하겠습니다.

  5. 김경화 2012.11.06 01:57  댓글주소  수정/삭제  댓글쓰기

    mongodb 모델링 관련해서 자료를 찾아보다가
    정말 감탄하고 갑니다.
    좋은 자료 감사드립니다.

  6. 윤석준 2013.02.18 18:17  댓글주소  수정/삭제  댓글쓰기

    NoSQL에 대해서 한글로 이렇게 잘 정리된 글은 처음 봅니다. 트랙백이 안되서 출처를 위에 남기고 좀 퍼가겠습니다. ^_^

  7. 홍성현 2015.01.12 15:19  댓글주소  수정/삭제  댓글쓰기

    저도 교안을 만드는 경우도 있지만.. 이렇게 깔끔하게 정리하기가 생각보다 정말 힘듭니다.^^ 잘 보고 갑니다. 좋은 자료 감사합니다.

  8. 이상엽 2015.05.25 14:53  댓글주소  수정/삭제  댓글쓰기

    좋은글을 이제야 접하게됬네요.
    NoSQL가지고 실무를 할때 많은 도움이 될 것 같습니다. 고맙습니다.

  9. 먹튀 검증 2018.08.06 16:52  댓글주소  수정/삭제  댓글쓰기

    관리자의 승인을 기다리고 있는 댓글입니다

  10. Candykick 2019.10.14 14:49  댓글주소  수정/삭제  댓글쓰기

    관리자의 승인을 기다리고 있는 댓글입니다

  11. ㅠㅠ 2019.11.07 13:45  댓글주소  수정/삭제  댓글쓰기

    굿굿





클라우드 컴퓨팅, Hadoop, NoSQL 새로운 기술이고 구글이나 FaceBook과 같은 B2C의 선두 업체들이 주로 사용하는 기술이다.


그런데, 왜 우리도 이 기술에 열광하는가?

재미는 있고, 쓸모는 있는 기술이다. 그런데 필요가 있나? 한번 더 생각해볼 필요가 있다.


첫번째 Hadoop

Hadoop의 경우 대용량 데이타를 배치성으로 처리하기 위한 분산 처리 프레임웍이다.

여러가지 사용 용도가 있을 수 있겠지만, 주로 대용량 데이타를 분석하기 위해서 사용된다.

이런 형태의 데이타 분석은 이미 OLAP이나 BI형태로 솔루션들이 제공되고 있고, 기업에서는 이미 구축되어 있다. 구글이나 페이스북과 같은  대규모 서비스를 한다면 모를까? 5000만 인구의 대한민국에서는 그만한 데이타 분석이 필요할까 과연 의문이다.

물론 비정형 데이타 분석에는 충분히 활용할만하다. 이런 시나리오를 바탕으로 오라클,Microsoft,IBM등은 Hadoop과 융합한 솔루션을 출시하는데, 데이타를 수집 및 정재 변환하고, 이 데이타를 Hadoop 클러스터에 넣는 시나리오이다.

국내에서도 한정된 시나리오에는 사용될만은 하지만, 이게 과연 이렇게 열광할만한 솔루션인가는 사실 반문이 든다. 차라리 memcached나 redis 같은 솔루션들이 훨씬 더 도움이 될거 같다.


두번째 NoSQL

NoSQL은 대용량 데이타 저장, 성능 등에 목적을 가지고 있는 특수목적 데이타 베이스로

각 NoSQL 솔루션에 따라서 그 사용 용도가 모두 틀리다.

오픈소스 RDBMS의 대명사인 MySQL 의 경우에도 10억개 정도의 레코드를 처리할 수 있으며, Query Off Loading이나 Sharding등을 통해서 확장성과 성능을 모두 보장할 수 있다. 페이스북도 몇년전까지만 해도 실제로 MySQL과 memcached의 조합으로 운영을 해왔다.


사실 요즘 유행하는 대부분의 기술들은 기업(Enterprise)성의 기술들이 아니다. IT의 주도권이 Oracle,IBM,Microsoft등의 대형 벤더에서 Google,FaceBook,Twitter로 넘어오면서 이들이 사용하는 기술들이 주목 받게 되었다. 그러나 이들이 만들어낸 기술 (NoSQL, Map & Reduce 기반의 분산 처리)는 철저하게 이들의 서비스 시나리오에 최적화 되어 있다.

 그런데 이것을 가져다가 적용하려하니, 엔터프라이즈에서는 안맞는 부분이 생기고, 국내 B2C에서도 활용 시나리오가 모호해진다.


첫번째로, 국내 시장 상황에서는 이정도의 빅데이타가 없고

두번째로, 이러한 기업들은 자체적으로 해당 기술에 대한 엔지니어를 보유하고 끊임 없이 공부하고 업그레이드 해 나간다. 특히 국내 SI기업에서는 인력 기반 장사 시장에서 어려운 이야기고 테스트랩이라도 하나 세팅하려고 하고 연구팀을 꾸리면 1~2년이면 SI 시장으로 나가야 한다.


기술 자체가 의미가 없는 것은 아니다. 그러나!! 왜 생긴 기술이고 내 업무에 적용할만한지를 판단해봐야 할것이며, 기존에 다른 솔루션들을 사용하고 있었을 경우, 이런 신기술로 변환했을 경우 장단점을 꼼꼼하게 따져 봐야 한다. 더 이상 기술 유행에 휩쓸리지 말고 기술 자체를 이해하는 노력이 필요하다.


그리고 이런 기술을 쓰려면 반드시 개발자나 기술자들이 중요한 것을 인식하고 충분한 기술 습득의 시간과 환경을 제공함으로써 내재화를 진행해야 한다. 예전처럼 외주 개발자를 밀어붙이고, 솔루션 벤더 불러다가 욕을 한다고 해결될게 아니다. 욕을 하고 싶으면 그 오픈소스를 만들고 있는 개발자들에게 월급을 주시던가... 

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

댓글을 달아 주세요

  1. 박진혁 2012.08.16 09:13  댓글주소  수정/삭제  댓글쓰기

    포스팅 잘보고 있습니다. 좋은 하루 보내시길 바래요^^

  2. 정호영 2012.09.10 16:39  댓글주소  수정/삭제  댓글쓰기

    포스팅 잘 보고 갑니다. 감사합니다.

  3. 게스트 2012.09.11 13:33  댓글주소  수정/삭제  댓글쓰기

    잘 보고 갑니다. 기술 자체에 대한 단순한 나열이 아닌 개인적인 평가를 담아내고 있어 늘 많이 느끼고 갑니다.
    감사합니다.

  4. 국어 전문가 2015.07.29 14:31  댓글주소  수정/삭제  댓글쓰기

    틀리다->다르다 로 고쳐주세요 ^^

어제 발표된 Microsoft Azure의 IaaS 서비스와 Amazon의 AWS 서비스 사이에 가격 비교를 해봤다.

아래 내용은 네트워크 비용이나 Blob Storage 등 부가 서비스를 제외하고 EC2 서비스 만을 비교한 것이다.

 

 

요약 - Linux VM의 경우 동일, Windows VM의 경우 MS가 저렴

Linux VM의 경우 동등 인스턴스 크기에서는 Amazon과 Azure 양쪽 가격이 같다. Azure가 레퍼런스해서 만든 느낌이 가득하다. 

 

Azure 장점 

- Windows Server VM의 경우 Amazon 대비 저렴. Amazon은 Windows VM에 대해서 별도의 가격 정책을 책정하나, Azure의 경우 Linux와 Windows를 모두 동일하게 가져감

 

Azure 단점

- 인스턴스 종류가  XS,S,M,L,XL 로 4개로 한정, 이에 반면 Amazon은 용도에 맞게 High-Memory Instance, High CPU Instance, Cluster Compute Instance, Cluster GPU Instance등을 다양하게 제공

 

결론

Instance의 실제 성능이나 IO 성능등은 테스트해서 비교해봐야겠으나, 일단 가격 정책상으로는 서로 경쟁할만한 위치에 왔다고 보여짐.

 

참고 자료

AWS 가격 - http://www.ec2instances.info/

Azure 가격 - http://www.windowsazure.com/ko-kr/pricing/calculator/?scenario=virtual-machines

 

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

댓글을 달아 주세요

Hadoop Architecture Overview

요즘 클라우드와 빅데이타 그리고 분산 컴퓨팅이 유행하면서 가장 많은 언급 되는 솔루션중하나가 Hadoop이다. Hadoop 이 무엇이길래 이렇게 여기저기서 언급될까? 본 글에서는 Hadoop에 대한 소개와 함께, Hadoop의 내부 동작 아키텍쳐에 대해서 간략하게 소개 한다.

What is Hadoop?

Hadoop의 공식 소개를 홈페이지에서 찾아보면 다음과 같다.

The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using a simple programming model. ’

정의를 요약하면, Hadoop은 여러 컴퓨터로 구성된 클러스터를 이용하여 큰 사이즈의 데이타를 처리하기 위한 분산 처리 프레임웍이다.

구조를 보면 엔진 형태로 되어 있는 미들웨어와 소프트웨어 개발 프레임웍의 형태를 띄고 있고, 대용량 데이타를 분산처리를 통해서 처리할 수 있는 솔루션으로, OLTP성의 트렌젝션 처리 (웹과 같이 즉시 응답이 필요한 시스템)보다는 OLAP성의 처리 (데이타를 모아서 처리 후 일정 시간 이후에 응답을 주는 형태)를 위해 디자인된 시스템으로 수분~수일이 소요되는  대규모 데이타 처리에 적합한 프레임웍이다.

Hadoop을 기반으로 한 여러가지 솔루션이 있으나 본 글에서는 Hadoop 자체에 대해서만 설명하도록 하겠다.

Map & Reduce의 기본

Hadoop의 분산 처리 방식은 기본적으로 “Map & Reduce”라는 아키텍쳐를 이용한다. Map & Reduce는 하나의 큰 데이타를 여러개의 조각으로 나눠서 처리 하는 단계 (Map), 처리 결과를 모아서 하나로 합쳐서 결과를 내는 단계 (Reduce)로 나뉘어 진다.

 

 

<그림 Map & Reduce의 기본 개념 >

예를 들어 한국에 사는 모든 사람의 수입의 합을 더한다고 하자. 우리한테는 한국에 있는 모든 사람의 수입이 적혀 있는 텍스트 파일이 하나 있다. 이 파일을 이용해서 각각 사람의 수입을 순차적으로 더해서할 수 도 있지만, 전체 파일을 10조각, 100조각으로 나눠서 각 조각의 수입합을 계산한후, 그 결과를 하나로 더하면, 조각을 나눈만큼의 계산을 병렬로 처리할 수 있기 때문에 조금 더 빠른 결과를 가질 수 있다. 이렇게 하나의 파일을 여러 조각으로 나눠서 계산 하는 것을 Map, 그리고 합치는 과정을 Reduce라고 한다.

이러한 Map & Reduce를 하기 위해서는 Input 데이타를 저장하고, 이 데이타를 조각으로 나눠서 저장하고, 조각에서 처리된 임시 결과를 저장 그리고 합쳐서 저장할 각각의 저장 공간이 필요하다. 이 공간은 전체 분산 처리 시스템에 걸쳐서 접근이 가능해야 하고, 대용량의 데이타를 저장할 수 있어야 하는데, Hadoop에서는 이 공간으로 분산 파일 시스템 (Distributed File System)을 사용하며, 이를 HDFS (Hadoop Distributed File System)이라고 한다. 그리고 위에서 설명한 것 처럼 MR을 위해서 데이타를 처리하는 부분을 Map & Reduce 모듈이라고 한다.

사용 시나리오

Hadoop Map & Reduce는 대용량 데이타에 대한 분석에 대해서 최적화 되어 있다.

즉 웹 시스템이나 OLTP (Online Transaction Processing)과 같은 1~5초내에 응답이 오는 형태의 Request/Response 방식의 Synchronous 형식의 시나리오에는 적합하지 않고, Input을 넣은 다음 수분 후에 결과를 받아서 보는 비동기 (Asynchronous) Deferred 형태의 시스템에 적절하다.

 수학적 계산을 위한 연산 처리, 대규모 저장 및 분석, BI (Business Intelligence)와 같은 데이타 분석과 같은 후처리(지연처리) 중심의 분석 시나리오에 적합하다.

Hadoop 구성

앞에서 설명한 것과 같이 Hadoop은 크게 분산 데이타 처리를 하기 위한 Map & Reduce 모듈(이하 MR) MR Input/Output 데이타를 저장하는 파일시스템인 HDFS (Hadoop Distributed File System)으로 구성되어 있다.

HDFS (Hadoop Distributed File System)

HDFS는 분산 데이타 처리를 위해서 데이타를 저장하기 위한 파일 시스템으로, 다음과 같은 특징을 가지고 있다.

  • 대용량의 파일 (페타 바이트)을 저장할 수 있다.

  • 많은 수의 파일을 저장할 수 있다.

  •  Streaming Data Access

  •  Commodity Hardware

  • Multiple writers, arbitrary file modifications

HDFS의 구성 컴포넌트는 크게 두가지로 나뉘어 진다. (Namenodes, Datanodes).

Namenodes

Namenodes는 일종의 Master node로 파일에 대한 메타 데이타를 저장하는 노드로, 디렉토리 구조, 파일에 대한 각종 메타 데이타, 그리고 물리적 파일이 저장되어 있는 위치등을 저장한다.

Datanodes

Datanodes는 실제 파일을 저장하고 읽어온다. 하나의 파일을 블록이라는 단위로 나눠서 저장하는 역할을 수행한다. 그리고 Namenodes와 주기적으로 통신하여 저장하고 있는 블록에 대한 정보를 Namenodes에 저장하도록 한다.

Namenodes에는 모든 블록에 대한 메타정보가 들어와 있기 때문에, Namenodes가 장애가 나면 전체 HDFS 이 장애가 나는 SFP ( Single Failure Point )가 된다. Namenodes에 대한 이중화가 필요하다. Namenodes에 대한 이중화 방안에 대해서는 추후에 설명하도록 한다. Namenodes SFP로 작용하는 것은 Hadoop 운영상에 아주 중요한 운영 포인트로 존재한다. 근래에는 HDFS의 약점을 보완하기 위해서 GlusterFS Hadoop을 지원하면서, 파일 시스템으로 HDFS를 사용하는 대신 GlusterFS로 대처할 수 있다.

블럭 (Block)

블럭은 HDFS에서 Read Write를 하는 최소 단위이다. 하나의 파일을 여러개의 블럭으로 나눠서 저장된다. Hadoop의 블럭 사이즈는 일반적인 파일 시스템의 블럭사이즈 ( Kilobytes – 일반적으로 파일시스템에서는 512 KB )에 비해서 큰 블럭사이즈를 사용한다. Hadoop에서는 디폴트로 64MB를 사용하고, 보통 128MB를 사용한다.

클 블럭사이즈를 사용하는 이유는, MR 처리에 있어서 Map Task가 하나의 파일 사이즈 단위로 처리하기 때문에, 작은 파일 억세스 보다는 Map Task 단위로 처리할 수 있는 단위가 필요하다. (이것이 블럭) 이를 위해서 큰 사이즈 단위로 파일 처리를 할 수 있는 블럭을 지정하는 것이다.

또한 블럭 크기를 크게 함으로써, 해당 파일에 대한 Seeking Time을 줄일 수 있고, 블럭 사이즈를 적게 하면 Master Node에서 저장 및 처리해야 하는 데이타의 양이 많아지기 때문에 Master Node에 많은 부하가 걸리기 때문에 큰 블럭 사이즈를 사용한다. 이런 이유로 반대로 블럭 사이즈가 작거나 사이즈가 작은 데이타 처리의 경우 Hadoop에서는 충분한 분산 처리 성능을 기대하기 어렵다.

HDFS는 대규모 분산 처리에 필요한 대용량 input 데이타를 저장하고 output 데이타를 저장할 대용량 파일 시스템을 지원한다. HDFS 시절 이전에는 고가의 SAN (Storage Area Network)장비나 NFS 장비를 사용했어야 했는데, Hadoop은 일반 x86 서버에 Disk를 붙인 형태의 저가의 서버 여러개를 연결하여 대규모 분산 파일 시스템을 구축할 수 있게 해줌으로써, 값비싼 파일 시스템 장비 없이 분산 처리를 가능하게 해주는 것이다

Read/Write Operation

1) Read Operation

Client에서 Read를 수행하면, 먼저 Client SDK Namenode에 해당 파일의 데이타 블럭들이 어디에 있는지 블록의 위치를 먼저 물어온 다음에, 순차적으로 해당 데이타 블록이 저장되어 있는 datanodes로 부터 데이타를 블록을 읽어온다.

 

<그림. HDFS Read Operation >

이 과정에서 Namenode라는 놈이 아주 기특한 일을 하는데, 기본적으로 HDFS는 하나의 파일 블록을 저장할때 하나의 datanode에 저장하는 것이 아니라 N개의 datanode에 복제해서 저장한다. (장애 대응을 위하여). Namenode가 블록의 위치를 리턴할때, Hadoop Client로 부터 가까운 곳에 있는 datanode (같은 서버, 같은 Rack, 같은 데이타 센터 순서로..)를 우선으로 리턴하여 효율적인 Read Operation을 할 수 있도록 한다.

2) Write Operation

 

<그림. HDFS Write Operation>

파일 블록 저장은 약간 더 복잡한 과정을 거치는데

파일을 Write를 요청하면,

     먼저 Namenode에서 File Write에 대한 권한 체크등을 수행한다.

     Namenode에서 파일이 Writing Block의 위치한 Datanode를 리턴한다. (1)
파일을 쓰다가 해당 블록이 다 차면, Namenode에 다음 Block이 저장되는 Datanode의 위치를 물어본다.

     Client Stream을 통하여 해당 Datanode Block에 파일을 Write한다. (2)

     Write된 파일을 복제 Datanodes (※ 여기서는 복제노드와 원본 노드를 포함하여 총 3개의 노드가 있다고 가정하자)로 복제(복사)한다. (3,4)

     복제되는 Datanodes들 쌍을 pipeline이라고 하는데, 내부 정책에 따라서 서로 복제할 Datanodes들을 미리 정해놓고 이를 통해서 복제한다. (pipeline Datanode의 물리적 위치 – Rack, 데이타 센터 등을 고려해서 자동으로 결정된다.)

     복제가 모두 끝나면 ACK를 보낸다. (5,6,7)

     파일 Writing을 완료한다.

 

이번 글에서는 간단하게 Hadoop에 대한 개념 소개와 Hadoop의 하부 파일 시스템인 HDFS에 대해서 알아보았다. 다음 글에서는 Hadoop의 Map & Reduce Framework에 대해서 살펴보기로 한다.

 

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

댓글을 달아 주세요

  1. 지나가는이 2012.06.09 22:26  댓글주소  수정/삭제  댓글쓰기

    글 잘읽었습니다. 대단한 것은 아니지만 위에 설명하신 Map&Reduce가 구글에서 만든 MapReduce 아닌가요? Map&Reduce도 틀린것은 아니지만 모델링 고유명을 사용하는 것이 혼동을 줄일 듯 해서;;

  2. Brian 2013.07.30 11:14  댓글주소  수정/삭제  댓글쓰기

    감사합니다. 쉬운 설명으로 개념 잡는데 도움이 되었습니다. 다음 글이 기대됩니다. ^^

  3. 아이스크린 2014.12.02 17:14  댓글주소  수정/삭제  댓글쓰기

    하둡 동작원리애 대해서 잘 보았습니다 쉽게 정리를 해주셔서 감사합니다.

 

내일 오전 5시에(한국시간) Azure 새버전이 발표됩니다.

아마존 서비스에 반격을 하기 위해서, 그리고 이제 개발자나 시장의 상황을 어느정도 인지한 듯한 모양을 보입니다.

기존의 윈도우와 .NET만 지원하던 환경에서

Linux 지원과 Java,Python등의 다른 개발 플랫폼 까지 지원하게 된것이 가장 큰 특징이라고 볼 수 있습니다.

글로벌하게 제대로된 IaaS가 AWS 밖에 없었다면 강력한 경쟁 체재가 생기게 된것입니다.

(이럴줄 알았으면 MS에 계속 있을 걸 그랬습니다.)

 

일단 주목할만한 특징들을 살펴보면

1. IaaS 제공 - Windows Server 뿐만 아니라, CentOS,Ubuntu,Suse Linux 제공

o   Windows Server

§  Windows Server 2008 R2

§  Windows Server 2008 R2 with SQL Server 2012 Eval

§  Windows Server 2012 RC

o   Linux

§  OpenSUSE 12.1

§  CentOS-6.2

§  Ubuntu 12.04

§  SUSE Linux Enterprise Server 11 SP2

2. Azure 서비스에 대해 Python과 Java 지원

Azure의 Queue 서비스, BlobStorage 등등의 기반 서비스들을 접근할 수 있는 Java와 Python SDK를 지원합니다.

 

위의 두가지만으로도 AWS와 어느정도 동등한 수준의 서비스를 제공할 수 있을 것으로 보입니다. 물론 세세한 서비스 기능들은 차이가 있겠지만요

 

3. 새로운 서비스 기능 추가

1) Memcached와 같은 프로토콜을 사용하는 캐쉬 서비스가 추가 되었습니다.

2) Media Service라는 것이 추가 되었는데, 정확한 실체는 분석해봐야 알겠지만, Multimedia Contents에 대한 Streaming CDN이 포함되는 것으로 알고 있습니다. Streaming CDN이란 기존의 CDN이 정적 컨텐츠만 캐슁하여 서비스하는데 반해, 동영상이나 음악을 Streaming해주는 서버를 Edge 서버에 위치 시키고 서비스 해주는 기능을 제공한다.

 기존의 CDN이나 이 Streaming CDN은 Akamai가 주로 제공하는데 상당히 고가이고, AWS의 CDN서비스는 Akamai등에 비해서 Edge Node의 수가 부족하여 충분한 성능 발휘가 어렵고 멀티미디어 컨텐츠를 지원하지 않는 단점이 있었다.

 Microsoft의 경우, 인터넷 회선 보유양이 전세계 3위정도로 상당한 네트워크를 가지고 있기 때문에, 높은 수준의 CDN 서비스를 클라우드 환경에서 제공할 것으로 기대된다.

3) 흥미로운 기능중에 하나가 MongoDB 지원성에 대한 언급이 있는데

"Microsoft also announced the availability of the Eclipse plugin for Java, MongoDB integration, Memcached using non-.NET languages, and code configuration for hosting Solr/Lucene. Developers can find out more in the new Windows Azure Developer Center, which includes additional information, tutorials, samples and application templates to quickly get started and create differentiated cloud scenarios."

실제로 MongoDB를 Azure 안쪽에서 서비스로 위치 시킨것인지 단순하게 SDK만 지원하는지는 열어봐야 겠지만 오픈 소스 NoSQL에 대한 지원을 시작한 점은 고무적이다.

 

결론

이번 업그레이드에서 Linux지원과 Java지원은 방향성은 제대로 잡았다.

그러나 이게 그냥 형식적인 구색갖추기인지, 아니면 본격적인 개방형 클라우드 기술 적용인지는 3~4개월은 지나봐야 알겠지만, 고객입장에서는 AWS이외에 글로벌 서비스 능력을 가진 새로운 IaaS가 생긴것만으로도 선택의 폭은 넓어졌다고 본다.

 

참고 자료

http://www.microsoft.com/en-us/news/download/presskits/cloud/docs/MeetWindowsAzureFS.docx

Azure 런칭 행사 웹사이트 : http://www.meetwindowsazure.com/

 

 

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

댓글을 달아 주세요

원문 : http://www.isi.edu/~gideon/publications/JuveG-DataSharing.pdf

 

아마존에서 과학관련 HPC 분산 컴퓨팅 시에, 공유 스토리지 (NFS, Shared Storage)에 대한 성능 비교 및 Cost 비교를 해 놓은 문서 입니다. EBS나 Local Disk와 같은 스토리지가 아니라 공유 스토리지에만 한정합니다.

 

Amazon S3, Gluster, NFS, PVFS를 중심으로 비교했는데,

결론 적으로 GlusterFS(NUFA Configuration)이 성능도 높은편에 속하고 Cost도 저렴합니다.

 

그림 1. Cost 비교 

 

 

그림 2. 성능 비교 

 

저도 Gluster를 AWS에서 사용했는데, 무엇보다 AWS에 Gluster를 Deployment하기 위한 Best Practice 문서등이 잘 되어 있습니다.

 

참고하세요.

 

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

댓글을 달아 주세요

클라우드 컴퓨팅이 IaaS,PaaS,SaaS와 같은 서비스 제공자 입장
Private,Public 클라우드와 같은 사용 대상에 대한 입장에 대한 정의가 이제는 다 이루어졌고, 구축 및 서비스가 성숙해가는 단계에서 근래에 시트릭스에서 3P 라는 클라우드 컨셉을 발표했다.

기존 클라우드가

  • 기업 내부에서 사용하는 Private
  • 기업이 외부 자원을 사용하는 Public 이었다면
  • 여기에 하나 더해서 + Personal Cloud의 개념을 추가하여 발표하였다.


새로운 클라우드 컴퓨팅 개념이라기 보다는 기존에 있었던 형태의 서비스를 조금 관점을 바꿔서 체계화 시킨 것에 불과하지만, 이 체계화 자체가 의미를 갖는다.
Personal Cloud는 기업이 아니라 각각의 개인에게 클라우드 서비스를 제공한다는 개념이다. 즉 클라우드 컴퓨팅이 컴퓨팅 리소스를 서비스로 제공하는 개념인 만큼 개인에게 컴퓨팅 파워를 제공한다는 개념인데, 가장 보편적인 서비스가 Personal Storage Cloud이다. 인터넷을 통해서 스토리지 공간을 개인에게 제공하는 서비스로,
국내에는 네이버 NDrive, 다음 클라우드, KT uCloud, 해외에는 Microsoft SkyDrive, SugarSync, DropBox, Box.net 등이 대표적인 서비스로 꼽힌다.
이 서비스의 특징들은 개인에게 

  1. 스토리지 공간 제공
  2. 파일 동기화 서비스 제공 (슈가싱크, Microsoft의 LiveMesh)

하는 특징을 가지고 있다.
이 서비스들도 서비스 제공업자의 형태에 따라서 여러가지로 나뉘어 질 수 있는데,

1. 순수 스토리지 공간만 제공하는 스토리지 서비스 사업자
이는 슈가 싱크나 DropBox처럼 순수하게 개인에게 스토리지 서비스(+싱크 서비스)를 제공하는 모델

2. 스토리지 공간을 제공하면서 자사의 다른 서비스와 융합 시키는 형태
대규모 벤더가 이에 해당하는데, Microsoft의 SkyDrive는 인터넷 저장 공간으로도 사용을 하지만, Microsoft의 Office와 연동이 되서 문서를 클라우드에 저장하여 다른 디바이스에서도 그 문서를 공유할 수 있도록 해준다.
즉 개인 스토리지 공간을 단순하게 개인에게 파일 저장공간으로만 제공하는 것이 아니라, 자사가 가지고 있는 서비스나 애플리케이션과 융합하여 시너지를 불러내는 형태이다.

3. 스토리지 공간을 타사의 다른 서비스와 융합 시키는 형태
스토리지 공간을 자사의 애플리케이션이 아니라 타사의 애플리케이션과 연동하도록 지원해주는 형태로, Box.NET의 경우 Zoho나 SalesForce.COM과 같은 다른 클라우드 서비스와 연동을 통해서 자사의 스토리지 사용량을 올리는 형태이다.

특이한 iCloud
그 중에서 조금 재미있는 비지니스 모델을 보면 애플의 iCloud 모델을 볼 수 있는데, 애플의 iCloud 모델중에 일반 사용자에게 잘 노출 되지 않는 서비스가 "Document 공유" 라는 서비스 이다. 이 Document 공간은 개인이 사용하는 개별의 애플리케이션이 사용할 수 있는 스토리지 공간으로 예를 들어 메모 애플리케이션이 이 스토리지 공간에 메모를 저장하여 다른 디바이스에서도 접근하여 자신의 디바이스에서는 어디서든지 같은 컨텐츠를 접근할 수 있도록 하는 형태이다.
 기존의 에버노트등이 이미 클라우드를 이용하여 멀티 디바이스간의 컨텐츠 공유를 지원하는데, 이게 모가 새롭냐? 라고 생각할 수 있겠지만 기본적인 비지니스 모델이나 목적 자체가 다르다.
 다른 스토리지 모델이 스토리지 판매를 통해서 수익을 창출하거나 자사의 서비스의 가치를 높이는데 목적을 두는데 반해, iCloud의 Document 서비스는 개발자 생태계를 지원하여 품질 높은 App을 만들 수 있게 해주는데 그 목적을 두고 있다고 판단할 수 있다. 
 이유는 기존에도 에버노트와 같이 다른 클라우드 예를 들어 Azure나 Amazon 클라우드를 이용하여 스토리지를 사용할 수 있었지만, 스토리지 사용에 필요한 비용을 애플리케이션 개발업체가 부담해야 하는 비지니스 모델이었다. 한번 앱을 판매해서 수익을 창출하는 입장에서 매달 들어가는 스토리지 사용비는 당연히 부담이 될 수 밖에 없고 그로 인해서 대규모 서비스나 인기있는 서비스가 아니라면 선뜻 이런 클라우드 스토리지를 사용하기 어려웠다.
 애플이 여기서 사용한 재미있는 트릭은 iCloud는 개인에게 5GB의 스토리지를 무료로 제공한다. 이 스토리지 비용은 단말에 포함이 되어 있는 금액이고 5G 이상을 사용할때는 개인이 사용에 대한 금액을 지불한다. 눈치가 빠른 사람은 이미 이해했겠지만

애플리케이션이 클라우드 저장소를 사용할 때 비용을 개발자가 지불하지 않고 개인에게 전가시킨 모델이다


는 것이다.
클라우드에 대한 사용비용을 절묘하게 사용자에게 전가 시킨 비지니스 모델로, 개발자의 경제적인 부담을 덜어주고
여기에 +해서 iPhone SDK에 이 클라우드 접근 기능을 단순화 하여 탑재해 놓음으로써 관리에 대한 기술적인 진입 장벽을 없앰과 더불어 개발자가 클라우드를 관리해야 하는 수고를 덜어준 것이다.

사실 다른 PIMS와 같은 서비스는 OutLook이나 Google mail, calendar가 있기 때문에 그다지 매력적이지 않다. Photo Stream도 일종의 샘플앱 정도의 개념이고, iCloud의 궁극적인 의미는

 개발자에게 클라우드를 무료로 줘서 애플리케이션 생태계를 윤택하게 함으로써 iOS의 생태계를 발전 시키고 이를 통해서 단말의 매출을 증대화 시키는데 있다.


3P 모델을 설명하다가 목표를 벗어나서 iCloud에 대해서 짚고 넘어갔는데, iCloud에 대한 분석 내용은 나중에 별도로 자세하게 포스팅 하겠다.

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

댓글을 달아 주세요


대충 2시간 정도 MongoDB를 훝어보니

구조
- mongod는 실제 데이타 베이스 핸들링 프로세스로 mysqld와 유사
- 앞단에 mongos 라는 프로세스를 띄워서 클러스터 구성을 하면, mongos가 로드 밸런서 역할을 함

클러스터링을 할경우
- Sharding을 사용하여 데이타를 분산 저장해야 함
- 이 경우 같은 shard내에 mongod를 3 copy로 replication하여 데이타 유실을 방지를 권고한다.
- 고급 문서 대부분 내용이 Shard 구성과 Index 구성이다. 이게 키 포인트인듯
※ 이 과정은 Redundant한 하드웨어 구성으로 인하여 하드웨어 코스트를 올릴 수 있다.

성능 부분에서는
- mongodb는 memory 기반의 index를 사용하여 cassandra나 hbase 에 비하면 높은 read performance를 보장한다.
- 단 메모리가 충분해야 한다는 이야기고 반대로 이야기 하면 비싸고 확장성에 제약이 있다는 이야기다.

용량 부분에서
- 사례 문서를 보니까는 1 node에 3TB 저장 가능한 문서가 있었고
- 궁극적으로 1000 node를 클러스터로 묶을 수 있다고 했다. 즉 peta byte급의 데이타 저장이 가능하다는 것이다. (실제로 가능할지는 모르겠다.)
- 여기에 아울러 12billion record (120억 레코드)
데이타 상으로만 보면 꽤 큰 데이타 저장이 가능한데, 대부분 문서는 중소형에서만 mongodb를 권장하고 있다.

저장 레코드
- GridFS 기반으로 파일을 저장할 수 있다.
- 대용량 파일은 Chunk 단위로 나눠서 저장이 가능하다. (자동으로 나눠줌)

기술지원
- 10gen에서 컨설팅과 Support 서비스 가능
- foursquare 레퍼런스가 있음. (나름 레퍼런스가 있다.)

결론
- 중소형에서만 사용하는 것이 권장됨
- 아키텍쳐 디자인에서는 Sharding과 Index 구성이 관건
- 하드웨어 아키텍쳐 구조에서는 메모리를 충분히 배치할것
- 그리고 결코 싸지 않다. (3 Copy)

구조도 간단하고, Key/Value Store 방식의 NoSQL에 비해서 Query 기능이나 Index와 같이 RDBMS와 같은 고급 기능도 제공한다. 아주 대용량의 시나리오가 없는 한국에서 그래서 다른 까다로운 NoSQL DB에 비해서 인기가 있는 것인지도..

요즘 분산 시스템은
- Proxy, Sharding, Ring Architecture, 3 Copy, Commodity hardware. 이 3개가 대세인듯. 다 똑같아.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

Nginx

클라우드 컴퓨팅 & NoSQL/NginX | 2011.10.31 23:45 | Posted by 조대협
큐브리드 블로그에 재미있는 글들이 많네요

http://blog.cubrid.org/dev-platform/what-is-nginx/

초고속 네트워크 핸들링 프레임웍 처럼 보이는데, TCP로 최적화된 모듈을 만들기 좋겠습니다.
자바 기반의 Netty (Mina)가 생각나네요.

지금 프로젝트 만드는 부분에 고민좀 해봐야겠습니다.

이건 머... 자체적으로  R&D 팀이라도 하나 두고 있어야지... 에효~~

'클라우드 컴퓨팅 & NoSQL > NginX' 카테고리의 다른 글

nginx module development guide (모듈 개발 가이드)  (0) 2011.11.09
Nginx  (0) 2011.10.31
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요


요즘 대용량 데이타 처리 때문에, NoSQL을 머릿속에만 올려놓고, 근래에나 되서 이래서는 안되겠다 해서 직접 자료를 찾아보고 있습니다.

NoSQL은 Cassandra, HBase, Mongo, Riak등을 후보군으로 뒀는데,

Cassandra는 FaceBook에서 Donation해서 만든 분산 DB로 개인적으로는 가장 신뢰가 가기는 했지만, 국내의 많은 블로그 포스팅등을 읽어보면, 안정성이나 사용성이 떨어진다는 것이다. 즉 제품은 좋은데 야생마처럼 잘 쓰지 못하면 모쓰는 제품이라는 이야기. 일단 후보로 남겨놓고 패스.

HBase는 Hadoop File System (HDFS)를 기반으로 설계되었는데, 검색해보니 생각보다 많이 사용이 안되는 것 같아서 패스
Riak도 신생이라서 패스

결국은 Mongo와 Cassandra에서 고민하게 되었는데,
신생 MongoDB가 얼마전부터 사람들 입에 많이 입에 오르내리고 있다. 검색을 해봐도 많이 나오고
이는 즉 사용이 쉽다는 것을 의미하고 또한 10gen이라는 회사에서 제품에 대한 Ownership을 지고 서포트와 컨설팅 그리고 라이센스를 제공하고 있다. 둘다 오픈소스(?)이긴 하지만 자기네들만이 사용하기 위해 만든 Cassandra와는 태생 자체가 다르다는 사실

요즘 분산 아키텍쳐를 보면 대부분 비슷한것이 앞단에 Load Balancing을 해주는 Proxy 를 두고, 뒤에 데이타 처리를 하는 Processing Node를 두는 것이 일반적인데, SWIFT도 글코, MogileFS도 글코, 분산 처리 환경인 Gearman이나 Hadoop도 결국은 비슷하다. 아니나 다를까, MongoDB도 유사한 구조를 갖는다.

일단 기능적인 특징을 보면

Indexing이 가능하다.
이말은 즉 빠른 Search가 가능하다는 이야기인데, 문서를 찾아보니, Index는 메모리에 저장되기 때문에, 메모리 크기에 영향을 많이 받는다. 즉 Deployment설계할때, 하드웨어의 Memory 사이즈가 중요한 Factor 라는 것

GridFS 기반의 Blob 데이타 저장 지원
GridFS라는 분산 파일 시스템을 사용하여 Binary 데이타 저장이 가능하다. 일반적인 아키텍쳐에서 meta 정보를 DBMS에, binary를 File System에 나눠서 저장할때, 이로 인해서 발생되는 데이타 일관성에 불일치를 방지할 수 있다는 점에서는 혁신적인데.. 문제는...
국내의 어느 블로거가 테스트한 데이타 http://symplog.tistory.com/entry/MongoDB-MongoDB-GridFS-%EB%B6%80%ED%95%98%ED%85%8C%EC%8A%A4%ED%8A%B8 를 보면, 파일 업로드 다운로드 성능이 그리 뛰어나지 않은 듯 하다.
큰 파일을 저장할때, 파일을 Chunk 단위로 나눠서 다운로드, 업로드 하는데 이는 메모리 사용면에서 효율성을 제공한다. (한꺼번에 다 읽거나 쓸때 한꺼번에 Flush를 하면 파일을 메모리에 가지고 있는 동안, 파일 사이즈가 크면 Out Of Memory를 유발할 수 있기 때문에..) 1.7 버전 이하에서는 4M, 1.7 이상에서는 16M의 Chunk Size를 제공하는 것 같은데.
문제는 Opendedup에서도 테스트해봤지만, 이 Chunk 단위로 파일을 나누는 작업이 보통 일이 아니라는, 일단 태생 자체가 작은 Blob 데이타를 저장하기 위함이지 대용량 파일을 저장하기 위함은 아닌 것 같은데,
http://blog.wordnik.com/12-months-with-mongodb 블로그를 보면 12billion (약 120억개)의 레코드를 저장하고, 여기에 음악 파일을 저장하는 것을 보면 가능하다고도 볼 수 있다. 보통 음악 파일이 4M 안팍인것을 감안하면 괜찮은 시나리오인 듯 하나 500GB가 넘어가는 비디오 파일을 저장할때는 어느정도 성능을 감당할 수 있을지는 미지수 이다.
만약에 안정적으로 GridFS가 대용량 파일을 저장할 수 있는 구조를 제공한다면 사람들이 SWIFT,MogileFS,GlusterFS를 사용하지 않고 모두 MongoDB를 사용해야 하지 않을까?
이 부분은 나름 테스트가 필요한 부분으로 남겨놓고 넘어간다.

Querying
아울러 RDBMS 와 같은 Query를 제공한다. (물론 RDBMS보다 한참 못 미치기는 하지만)
Key/Value Store만 지원하는 다른 NoSQL에 비하면 매력 적인 기능

Replication
http://www.mongodb.org/display/DOCS/Master+Slave
Master-Slave Replication도 지원하네, Query Off Loading 구현도 가능하겠다.

Sharding
그외에 자체적으로 데이타 Sharding 아키텍쳐를 지원한다. 요즘 이게 유행인지 MySQL 최신 버전도 자체적으로 Sharding을 지원한다. Sharding을 사용하면 1000개의 Shard까지는 거뜬히 지원할 수 있는 것 처럼 나오는데, 이건 테스트 하기는 어려울테고, 성능 데이타를 레퍼런스 하는 수 밖에

일단 완성도나 기능들이 높아 보이는 것 같은데..
깔아서 테스트해보고, 10gen 에서 컨설팅 불러서 직접 들여다 봐야 몬가 나오지 않을까?
=== 첨언 ===
구조를 살펴보니, 앞에서 언급했던 것처럼 SWIFT나 MogileFS와 상당히 유사하다
앞단에 Load Balancing 역할을 해주는 mongos 라는 프로세스들이 뜨고
뒷단에 실제 데이타를 저장하는 mongod라는 프로세스들이 뜨는데, 여기서 재미있는 것은 데이타 Replication을 하는데, 각 Shard당 3개의 인스턴스를 제공하도록 구성을 권장한다. Swift등에서 흔히 이야기 하는 3 Copy다. 데이타 안정성등을 위하는 건데. (딱 봐도, 하드웨어 비용이 장난 아니겠다.)

더불어서 MogoDB는 Cassandra나 HBase에 비해서 나은 성능을 갖는데 앞에서 설명한 바와 같이 Memory를 이용한 Indexing등으로, 반대로 이야기 하면 Memory가 충분히 있어야 한다는 이야기고, 비싸다는 이야기다.

큐브리드 블로그에 보면 재미있는 내용이 있는데 http://blog.cubrid.org/dev-platform/nosql-benchmarking/

Cassandra and HBase is for processing full-scale large amounts of data, while MongoDB can be used quickly, schema-free when using a certain amount of data.

MongoDB adopts a documented-oriented format, so it is more similar to RDBMS than a key-value or column oriented format.

MongoDB operates on a memory base and places high performance above data scalability. If reading and writing is conducted within the usable memory, then high-performance is possible. However, performance is not guaranteed if operations exceed the given memory. Therefore, MongoDB should be used as a medium or small-sized storage system.

한마디로, 성능은 좋지만 빅데이타는 Cassandra나 HBase를 쓰고 중소형에만 MongoDB를 쓰라는 것이다.
RDBMS에 유사하고 강력한 Feature, 사용의 편리성의 입장에서 MongoDB가 국내외에서 많은 사용층을 가지고 있는 것이 대강 이해는 된다. 한편으로는 MongoDB의 한계를 벗어날만한 데이타를 아직까지 사용해본 적이 없다는 반증도 될것이다. 10~20억 데이타는 내가 아는한에서는 RDBMS에서도 크게 문제가 없다. 문제는 10~20억을 넘는 100억, 1000억개의 데이타 핸들링에도 MongoDB가 버텨 줄것이냐인데.. 데이타 한건당 대략 10K만 잡아도 용량이 1Peta 이다. 3TB 노드를 300개 정도 연결해야 한다는 것인데... MongoDB에서 보통 1000개의 Instance를 이야기를 하니 이론상으로는 가능할것 같기는 한데
첫번째는 어렵지 않을까? 하는 생각이고, (그만한 레퍼런스가 있냐?) 두번째는 만약에 된다고 하더라도 돈이 엄청 들어갈것 같은 느낌이다. Swift도 MogileFS도 저가라고는 말하지만 소프트웨어가 저가인거지 3Copy로 하드웨어 구성을 벤더 제품으로 하면 마찬가지라는... (Commodity 하드웨어라면 몰라도..)
  이래 저래 자료를 찾아볼 필요가 있다.



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

댓글을 달아 주세요

  1. 지나가다 2012.01.20 16:51  댓글주소  수정/삭제  댓글쓰기

    "Commodity 하드웨어라면 몰라도..."라기 보다 오히려 Commodity 를 주로 염두에 두기 때문에 부상하는 것이라고 생각합니다. 여러 NoSQL들이 그점을 공유하고 있지 않나요? 하이엔드 유닉스나 메인프렝임 한대(?)와 whitebox 열대를 비교해도 후자가 쌀 수도 있습니다. 스토리지도 마찬가지죠.
    Query는 제가 볼 때는 약간의 편의 제공을 위해 DBMS 흉내를 내주는 정도지 그에 비교되거나 할 의도로 있는 것은 아니죠. 오히려 mapReduce가 더욱 확장될 것처럼 보이는데요.
    GridFS에 비디오파일을... 흠. (테이블에 external file에 대한 포인터만을 가지고 있지 있도록 하는 것이 아니고 테이블 스페이스에 끼워넣는다고 하면...) SQL이든 NoSQL이든 어느 DB에서 만족할만한 성능을 보여줄 수 있는 것인지, 확신이 안서는 시나리오라고 여겨지는데요. 비현실적인 구성으로 보이는군요.


클라우드 Security에 대한 글 하나
http://blogs.msdn.com/b/education/archive/2011/08/03/how-do-you-approach-cloud-security.aspx
네이트 사건도 있고, 점점 중요해지는 보안, 그러나 비용과 시간 때문에 맨날 경시 되는 보안

루머-Apple's rumored 'Replay' service a ways off
http://news.cnet.com/8301-31001_3-20089094-261/apples-rumored-replay-service-a-ways-off/
애플이 동영상 컨텐츠에 대한 클라우드 서비스를 시작하려한다는 루머입니다.
그 큰 데이타 센터 지어놓고, iCloud에서 Sync 만 제공하기에는 부족하고 몬가 꾸미고 있다고 생각했는데, 이게 아닐까 싶네요.
요즘 애플을 보면 서비스 혁신으로 격차를 벌리는 것을 넘어서 이제 스피드로 차이를 벌리는 것 같습니다.
더 이상 Catch up & Counter Plan은 안먹히는 것 같습니다. 애플과 상대하려면 "선빵"이 필요할듯...

VCE 블록은 돈먹는 하마
http://www.zdnet.co.kr/news/news_view.asp?artice_id=20110809002316&type=xml
VMWare가 V-Block으로 마케팅은 많이 했는데, 정작 팔지는 못했나 봅니다.
하기사 국내 영업도 보면 VCE 영업하는 것 보다는 VMWare 단독 영업 하는 케이스가 많은것 같더군요. (사견)

구글 NoSQL 레벨DB 공개
http://www.zdnet.co.kr/news/news_view.asp?artice_id=20110801100022
이미 다들 아시는 소식이겠지만 구글도 NoSQL DB를 오픈소스로 공개하였습니다.
차이점은 Cassandra나 Mongo DB 와 같은 서버 DB보다는 SqlLite나 버클리 DB등과 같이 임베디드 시장에 진출할 것이라는 관측이 있어서 흥미롭습니다.

벼락으로 유럽 아마존 클라우드 및 MS 클라우드 장애
http://www.crn.com/news/cloud/231300384/lightning-causes-amazon-microsoft-cloud-outages-in-europe.htm;jsessionid=4BinM6amUTGurWNYsFAyAg**.ecappj03?cid=rssFeed
지난번 아마존 장애도 그렇고, 클라우드 배포시 Regional Clustering을 통한 고가용성 확보가 중요하다고 생각되는 대목이네요.

Microsoft Windows Phone 7에 SkyDrive에 저장된 음악에 대해서 Streaming 서비스 제공
http://www.maximumtech.com/windows-phone-7-mango-offers-music-streaming-skydrive-accounts
요즘 Personal Storage의 추세가 저장에서 부터 Streaming/Transcoding으로 변화하는것 같습니다.
N Drive의 Transcoding 서비스도 그렇고, Apple의 Replay 서비스 루머도 그렇고, 이게 다음 트렌드 인가 보네요.

Tips for Business Resilience in Cloud - IBM
http://cloudcomputingarchitect.com/2011/08/08/ibm-tips-for-business-resilience-in-the-cloud.aspx?ref=rss&utm_source=twitterfeed&utm_medium=twitter&utm_campaign=Feed%3A+CloudArchitectCloudArchitectureTheCloudNetwork+%28Cloud+Architect+%7C+Cloud+Architecture+%7C+THE+CLOUD+NETWORK%29
오늘 아마존과 MS 클라우드 장애를 보니, 클라우드 설계 및 배포시 Resilience의 중요성을 한껏 더 느낍니다. Resilience에 대한 좋은 글이 있어 하나 첨부합니다.

VMWare 가격 정책 변경
http://www.zdnet.co.kr/news/news_view.asp?artice_id=20110809083259
VMWare가 라이센스 정책을 Core수에서 Memory로 변경했습니다.
애매한데... 보통 클라우드에서는 Physical Core:Virtual Core의 수를 Density라는 이름으로 조정합니다. 1:2~1:8 정도가 되는데, 애플리케이션의 성격이나, 사용시간에 따라서 다릅니다. 즉 낮에 많이 사용되는 VM과 저녁에 많이 사용되는 VM을 넣으면 CPU수를 공유해서 VMWare의 Core 기반의 라이센스 정책을 쓰면 동일하지만, VRAM기반이라면 오전,오후에 떠있는 VM의 VRAM을 합한 금액을 라이센스 금액으로 지불해야 하기 때문에 비용이 늘어날것으로 생각됩니다. 즉 거의 VM당 과금하겠다는 정책같네요.
지켜봐야될 부분입니다.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes

RabitMQ가 Amazon SQS에 비해 40배 가량 빠름.
AMQ나 RabitMQ를 클라우드에서 서비스하기 위해서는
1. SQS나 Azure Queue Service와의 호환성 문제 --> jCloud등 사용
2. Multitanent 문제 --> Pending Message가 장애를 발생시켜서 다른 업무나 사용자에게 방해를 줄 수 있다.
3. Global Scale Deployment --> DR과 Data Center간 Synchroization

이거 재미는 있겠는데.... 난이도가 무지 높겠다.. ROI가 쉽지 않겠어

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

댓글을 달아 주세요

http://www.zeus.com/products/load-balancer
이걸로 되어 있음...
가격만 맞으면 써볼만 할거 같은데...

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

댓글을 달아 주세요

Virtual Machine Management : OpenStack Nova + Glance (Image & Snapshot management)
Configuration Manager : Chef + Crowbar
Monitoring : TBD (System Center Operation Manager + Bridgeway)
Orchestration : http://java-source.net/open-source/workflow-engines 이건 짜야 쓰겄다.
Portal : Silverlight or HTML 5 or AJAX

추가 검토할 솔루션
Puppet
Nagios : Monitoring 쪽에 검토 요망


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

댓글을 달아 주세요

  1. CharSyam 2011.05.18 11:23  댓글주소  수정/삭제  댓글쓰기

    Nova 가 아직 사용하기에는 좀 애매하지 않은가요? 성숙하지 않았다는 말이 많더라구요.



Configuration Management : Chef + Crowbar
Imagemgmt : Glance

'클라우드 컴퓨팅 & NoSQL > IaaS 클라우드' 카테고리의 다른 글

Rackspace Load balancer  (0) 2011.05.22
오프소스 기반 클라우드 솔루션 조합  (2) 2011.05.16
Dell's destination for OpenStack  (0) 2011.05.16
Cloud.com CloudStack Quick overview  (0) 2011.05.16
Openstack review note  (0) 2011.05.13
L2,L3,L4 스위치  (0) 2011.05.11
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

쑤욱~~ 또 솔루션 훝어봤습니다.
KT에서 CloudStack 도입으로 꽤나 국내에서는 유명한 플랫폼입니다.
일단 앞단의 Self Service Portal에서 부터 하단의 Hypervisor를 제외한 대부분을 지원하고 있음
AJAX 기반 UI가 강력함.

몇가지 특징을 보면
Pod(Rack),Zone의 논리적인 공간 개념을 가지고 있고
Global Admin (클라우드 관리자), Domain Admin (업체별 관리자), User 로 계층별 사용자 개념을 가지고 있음.

사실 저 두가지가 상당히 중요한 부분인데, 개념 정리를 상당히 잘해놨고
NAT,Firewall,Load Balancer, Router등을 이미 SW로 잘 구현해놨고, 외부 FW와 LB를 연결할 수 있는 기능이 있음

아.. 근데 자료는 자세히 못 찾았는데, CloudStack은 Hypervisor에 Clustering feature를 사용하기 때문에, Clustering 될 수 있는 하드웨어 개수 제약으로 인해서 많은 제약이 있음.. 이것이 약점!!

Node간 MPLS 지원도 가능


==
아래는 주저리 주저리 노트

API를 3 단계로 나눠서 구별하고 있음

Global Admin
Domain Admin
User

User Types
admin - full API access. This is typically a service administrator or code that executes with complete trust in

the service operator's environment.

domain-admin - full API access within a domain. This is the most privileged user that a given customer has. This

may be a reseller for the service provider.

read-only-admin - API access limited to viewing most entities. No access is given to create or update those

entities. This may be useful for monitoring programs in the service operator's environment.

user - API access for all the resources associated with their account. There may be many users in a domain, many

domains in a deployment, and many users in a deployment. This is typically the end user.


Firewall,NAT,Load Balancer,Router들을 다 통재 가능함
위의 것들은 내장형이고, Ext LB와 Ext Firwwall을 추가할 수 있음

VM 그룹 개념이 있음. 내 디자인의 Service Role과 같은 개념

오호라~~ account나 domain에 대한 resource limitation을 관리할 수 있는 개념이 있음

Pod,Zone 개념도 가지고 있음


Global Admin. Access to all features of the cloud, including both virtual and physical resource management. You can access the 2.2. API via the link : http://download.cloud.com/releases/2.2.0/api/TOC_Global_Admin.html

Domain Admin. Access to only the virtual resources of the clouds that belong to the administrator’s domain. You can access the 2.2 API via the link : http://download.cloud.com/releases/2.2.0/api/TOC_Domain_Admin.html

User. Access to only the features that allow management of the user’s virtual instances, storage, and network. You can access the 2.2 API via the link : http://download.cloud.com/releases/2.2.0/api/TOC_User.html


Customization 가능한 모듈

UserAuthenticators. Allows you to integrate custom authentication schemes that the Management Server can use to validate user credentials.
 HostAllocators. Allows you to create custom rules to determine which physical host to allocate the guest virtual machines on.
 PodAllocators. Allows you to create custom rules to determine which pod to allow the guest virtual machines on.
 ConsoleProxyAllocators. Allows you to create custom rules to determine which routing nodes to allow the console proxy on.
 Investigators. Allows you to create custom rules to determine when a virtual machine is detected as down for HA purposes.

OpenStack에서 개선이 필요한 부분

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

댓글을 달아 주세요

오늘 대충 쭈욱 훝어봤는데...
결론은 Simple하네... 그리고 별거 읍네~~~
아래는 혼자 주저리 주러리 노트
기본 개념은 Hypervisor들 abstract해서 올려주고
EC2 호환성 가지도록 REST API 정의하고,(그래서 아마존 CLI가 다 먹는군..)
Provisioning 관련 프로세스 (Image관리, VLAN 태깅 등) 몇개 좀 해주고....
그게 다 인듯......
API 보니까는 100개도 오픈 안되어 있던데..
반대로 Simple해서 개발할때는 편할 수 도 있을 듯..
Reference Implementation으로 되어 있는 Portal은... 진짜... Tutorial 수준...
MS의 위대함을 또 한번 느꼈음... ㅋㅋ

Hyper-V support install  : http://wiki.openstack.org/HypervInstall?highlight=%28Hyper-V%29

Currently, Nova supports three kinds of networks, implemented in three “Network
Manager” types respectively: Flat Network Manager, Flat DHCP Network Manager, and
VLAN Network Manager. The three kinds of networks can co-exist in a cloud system.


일단 VM create 하는데, Affinity id는 있고

4.1.2.1. Server Affinity
As stated previously, the compute service has an anti-affinity property that attempts to
spread out VMs across hosts. There may be cases where affinity matters however. For
example, VMs may need to be placed near one another in order to effectively share
resources. The affinityId attribute represents the lowest level zone that allows clients to
specify placement of VMs. Note that VMs with the same affinityId may not necessarily
share the same hostId. That said, hosts with the same affinityId are guaranteed to be in
proximity of one another. To launch a server with affinity to an existing server, include the
affinityId of the existing server in the server create request.

Bare metal provisioning이 고민 되어야 겠네... 읍네~~

Template 가 좀 약하네.
특히 서버 Create할때..

==
5/18 추가 Live Migration 됨 - http://docs.openstack.org/cactus/openstack-compute/admin/content/live-migration-usage.html
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

요즘 오픈 소스 기반의 클라우드 솔루션을 보다 보니 트렌드가 많이 변했다고 느끼는데, 그중 하나가 Cross-Cloud-Management이다.

Microsoft의 경우 Concero라는 코드명으로 Private Cloud와 Azure 기반의 Public Cloud를 동시에 관리하는 기능을 제공하는데, 예를 들어 관리자가 Application을 만들고 Private Cloud로 Targetting하면 내부 클라우드에 배포 되고 Targetting을 미국 Azure로 하면 미국에 배포되는 모델이다.
즉 Private과 Public Cloud를 하나의 회사 클라우드로 통합 관리하는 모양이 되는데...
년초에 이 개념을 보고 차암 대단하다고 생각했는데..

이번에는 Right Scale이라는 솔루션을 봤는데. 이놈은 클라우드 위에서 Public Cloud간 또는 Public-Private Cloud간의 통합된 통제를 가능하게 한다.


RightScale은 Azure,Amazon,Rackspace등 주요 Public Cloud에 대한 중앙 관제를 제공하면서
Ecualyptus나 OpenStack으로 개발된 Private Cloud도 똑같이 중앙 관제가 가능하다. (Ecualyptus나 OpenStack은 Amazon EC2 호환이 되니까는 가능하다.) 즉 수평적,수직적인 클라우드 통합을 지원한다.

JClouds

아울러서 클라우드 개발 부분에서도 변화가 있는데, 재미있는 프레임웍중 하나가
jclouds.org
이다.
클라우드의 주요 기능등 예를 들어 S3,EBS 등을 Java API로 쌓아 놓은 것인데..
재미있는 점은 Amazon 뿐만 아니라 Azure,Ecualytus,Terramark 등 주요 클라우드 서비스들을 호출할 수 있도록 되어 있는데, Abstraction이 되어 있어서 비슷한 기능은 Provider만 바꾸면 되는 구조라는 것이다. 즉 Azure의 BlobStorage나 Amazone의 S3는 그 구조와 용도가 유사한데, JCloud에서는 이것을 하나의 인터페이스로 묶어서 클라우드 서비스 사업자 Depdency 없이 프로그래밍을 할 수 있도록 해준다.

참~~ 한국에서는 Azure나 Amazon 사용하지도 못하고, 그나마 KT가 이제 슬슬 클라우드 서비스 시작할려고 하는데, 벌써 바깥 세상은 한참 변하고 있네요.

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

댓글을 달아 주세요

  1. byeol 2011.04.20 23:00  댓글주소  수정/삭제  댓글쓰기

    spotcloud 개념도 좋더라구요..