1. 클라우드 컴퓨팅(Cloud Computing)이란?

클라우드 컴퓨팅에 대해서는 현재 매우 다양한 정의가 존재한다. 이 중 몇 가지를 정리하면 다음과 같다. 첫 번째 정으로 클라우드 컴퓨팅은 다양한 클라이언트 디바이스에서 필요할 때 언제든지 인터넷을 이용한 공유 풀에 있는 서버, 스토리지, 어플리케이션, 서비스 등과 같은 IT 리소스에 쉽게 접근할 수 있게하는 모델이다.

또 다른 정의로는 서로 다른 물리적 위치에 존재하는 컴퓨터들의 리소스를 가상화 기술로 통합해 제공하는 기술이라고도 생각할 수 있다. 개인적으로 클라우드 컴퓨팅의 개념을 이해는데 세일즈포스닷컴(www.salesforce.com)1이 만든 이 동영상2이 전반적인 이해를 돕는데 매우 유용하다. 아래 그림은 여러 대표적인 클라우드 서비스들의 사용 예를 보여주고 있다.

1.1. 클라우드 컴퓨팅의 장점3

사용자가 자신의 필요에 따라 무한정의 컴퓨팅 자원을 사용할 수 있다는 환상(Illusion)을 제공한다. 그러므로 사용자는 하드웨어와 소프트웨어 시스템을 제공하는 계획을 미리 세울 필요가 없다. 사용자는 작은 시스템으로부터 시작할 수 있고 시스템 자원에 대한 요구가 증가함에 따라 시스템 자원을 증가시키면 된다. 필요에 따라 짧은 시간을 단위로 (예를 들어 프로세서를 시간 당 또는 스토리지를 날짜 당) 사용하고 비용을 지불하면 되고 필요가 사라지면 자원을 더 사용하지 않을 수 있다.

1.2. 기존 클라우드 컴퓨팅 사례

1.2.1. 아마존

  • EC2(컴퓨팅 서비스)
  • Auto Scaling(자동으로 서버 생성 가능)
  • Elastic Load Balancing(소프트웨어 로드벨런싱 기능)
  • CloudWatch(모니터링 정보 제공)
  • Amazon Elastic Block Store(EBS, 빠르고 안정적인 스토리지)
  • Amazon Simple Storage Service(Amazon S3, 스토리지 서비스)
  • SimpleDB(데이터베이스 서비스)

1.2.2. 구글

  • GFS(구글파일시스템, 대용량 파일 처리 가능 시스템)
  • MapReduce(대용량 데이터의 분산 병렬 처리)
  • Bigtable4(관계형이 아닌 대용량을 위한 디비)
  • Sawzall(맵리듀스를 위한 스크립트)
  • Chubby(분산시스템간의 락 관리를 위한 작은 파일시스템)
  • Protocol Buffer

1.3. 클라우드 컴퓨팅의 분류

1.3.1. 서비스 제공에 의한 분류

  • SaaS(Software as a Service)
  • 소프트웨어를 설치하는 것이 아니라 서비스 형태로 제공한다는 의미
  • PaaS(Platform as as Service)
  • 구글 앱 엔진같은 서비스, 어플리케이션이 실행되는 환경을 제공
  • IaaS(Infrastructure as a Service)
  • 시스템의 구축이 필요한 자원을 제공, 아마존은 AWS서비스 중 EC2, S3, 등의 서비스

1.3.2. 서비스 배치에 의한 분류

  • 퍼블릭 클라우드(Public Cloud)
  • 특정 기업이나 사용자를 위한 서비스가 아닌 인터넷에 접속 가능한 모든 사용자를 위한 클라우드 서비스
  • 프라이빗 클라우드(Private Cloud)
  • 제한된 네트워크상에서 특정 기업이나 특정 사용자만을 대상으로 하는 클라우드 서비스
  • 하이브리드 클라우드(Hybrid Cloud)
  • 퍼블릭, 프라이빗을 병행하여 사용하는 방식. 보안이 중요한 부분은 프라이빗, 나머지는 퍼블릭으로 구성한다.

1.4. 클라우드 컴퓨팅 아키텍처

1.4.1. 진화과정5

  1. 웹 어플리케이션
  2. Facade 패턴6 적용(특정 모듈을 호출하는 Facade를 이용하여 분산)
  3. 여러 서버로 확장
  4. 서비스 풀 구성
  5. 데이터 분산 저장
  6. 캐시 계층 추가
  7. 외부 노출 서비스 선택
  8. 서비스 게이트웨이 구축
  9. 외부 게이트웨이 구축
  10. 서비스 버전 관리 기능 추가
  11. 클라우드 컴퓨팅 서비스 활용

2. 경량 어플리케이션 서버

전통적인 방법은 RPC를 이용하는 것이다. 하지만 이 방법은 IDL(Interface Definition Language)7로 변환하는 과정을 대부분 거치게 되는데 이 과정에서 많은 비용이 발생한다. 만약 이상적인 RPC 가 있다면 IDL로 변환하지 않고 사용할 수 있어야 할 것이다.

2.1. Thrift8

  • 페이스북의 어플리케이션 서버
  • 다양한 언어를 지원하는 RPC(Remote Procedure Call) 서버와 이 서비스를 호출하는 클라이언트 코드를 생성해주는 프레임워크
  • 언어별 소켓 서버에 대한 구현을 알 필요 없음
  • 사용자 정의 타입 사용 가능
  • 프로그래밍 언어 제약 없으므로 쉽게 개발 할 수 있다.

2.2. Avro9

  • 이기종 간 데이터 타입을 교환할 수 있는 체계 제공하는 프레임워크
  • 아파치 하둡의 서브 프로젝트에서 승격
  • 데이터 직렬화(Serialization)을 기본으로 RPC호출을 이기종간에 가능하게하게 함
  • Thrift 보다 사용 범위가 넓음.
  • Protocol Buffer, BERT, BSON10 가 유사 프로젝트
  • JSON 기반으로 편리함
  • Pig, Hive 등 하둡을 사용하는 다른 플랫폼에서 생성된 다양한 데이터를 상호교환하고 데이터 타입을 처리하고 위한 목적
  • 하둡 자체적으로 개발된 RPC가 Java 기반에서만 동작하기 때문에 한계 극복하기 위함

2.3. Jetty11

  • 톰켓과 같은 서블릿 컨테이너로 동작
  • 독립적인 프로세스로 실행되면서 jsp나 서블릿 클래스에서 정의된 기능 수행
  • 내장형 웹서버로도 사용 가능
  • jsp, 서블릿 컨테이너 역할도 같이 할 수 있는 프로그램 개발 가능

3. 분산 코디네이터### ### 3.1. 분산된 환경에서의 고려사항

3.1.1. 네임서비스 부하 분산(Round-robin DNS)12

  • 일반적인 방법은 여러 웹서버를 두고 L4 사용함
  • DNS를 이용한 부하 분산(Round-robin DNS)을 사용하기도 함
  • L4를 이용한 방법의 문제점
  • 어플리케이션 서버의 추가 제거가 발생할 경우 DNS의 수정 필요
  • L4는 하드웨어 인접 서버만 가능하다는 제약 조건 있음
  • 클라이언트의 DNS캐시로 인해 장애상황시 즉시 해결되지 않을 수도 있다.
  • 분산 락이나 동기화 문제

3.1.2. 공유되는 변수의 동기화 문제

  • 해결 방법
  • NFS(Network File System) 와 같은 파일시스템 마운트
  • SPOF(Single Point Of Failure) 문제 발생
  • 데이터베이스 이용방법
  • 락 요청이 많아지면 부하 발생
  • 장애가 발생하거나 데드락 문제 생길 수 있음

3.1.3. 장애 상황 판단 문제

  • 고가용성을 위해 이중화 구성
  • Active - Active
  • 동일 자원에 대한 동시 접근 동기화 등 문제 방생 가능
  • Active - Stanby
  • 동기화 문제는 해결, 고 비용
  • 네트워크 단절 문제로 Split Brain 문제 방생가능
  • Split Brain 이란 네트워크 단절로 서로의 상태를 확인할 수 없는 상황을 말함
  • JEUS의 이중화 구성 (Active-Stanby)13
  • Split Brain 개념14

3.1.4. 환경설정 값 관리

  • .properties 파일 설정 값에 저장하고 프로그램 시작 시 메모리 로드

  • 설정 값 변경시 모든 서버 배포해야 하는 문제

  • 데이터베이스에 저장하고 필요할 경우 조회하여 메모리 로드

  • 많은 조회로 인한 성능 저하
  • 디비 부하 집중 및 SPOF 문제

3.2. ZooKeeper15

  • 분산 코디네이터 서비스(Distributed Coordinator Service)를 제공하는 아파치 오픈소스
  • 분산 환경에서 락, 네이밍서비스, 클러스터 멤버십 등 쉽게 구현 가능
  • 사례
  • 네임 서비스, 환경 설정, 그룹 멤버십
  • Double Barriers
  • 우선순위 큐
  • 공유 락 제어
  • 두 단계 커밋
  • 리더 선출

4. Hadoop16 분산 파일 시스템

클라우드 컴퓨팅 서비스는 사용자의 모든 데이터가 클라우드 인프라 내부에 저장되기 때문에 기본적으로 대량의 데이터나 파일을 저장할 수 있는 저장소를 필요로한다. NAS(Network Attached Storage) 나 SAN(Storage Area Network)을 사용한다. SAN이 NAS보다 속도가 빠르고 안정적이여서 중요한 데이터 사용을 위해 더 많이 사용하지만 두가지 모두 가격이 비싸다는 단점이 있다. 하지만 분산파일 시스템은 싼 가격의 장비에서도 훌륭하게 동작한다.

4.1. 네트워크 공유 파일 시스템###

  • 전통적인 클라이언트 - 서버 파일시스템
  • 서버에서 접근 요청하고 마운트하는 과정이 필요
  • 파일시스템 상 전송 시 오버헤드 발생, 하지만 편리함
  • SUN에서 개발한 NFS(Network File System) 또는 MS에서 개발한 CIFS(Common Internet File System)등이 대표적

4.2. 클러스터 파일 시스템

  • 언제 어디서나 웹을 통해 서비스 받을 수 있는 클라우드 플랫폼 필요에 의해 탄생
  • 장애가 발생하더라도 안정적인 서비스 제공
  • 비대칭형(Asymmetric) 클러스터 파일시스템 지원
  • 성능과 가용성 면에서 적합
  • 파일 메타데이터를 관리하는 서버를 별도로 둠
  • 메타 데이터에 접근하는 경로와 데이터에 접근하는 경로 분리
  • 메타 데이터 서버에 부하가 집중될 수 있다는 SPOF 의 잠재적 문제
  • 클러스터 파일시스템
  • 구글 파일 시스템17에 대한 논문 기반
  • 야후에서 개발한 Hadoop 이 대표적

4.3. 구글 파일 시스템(GFS or GoogleFS)

  • 저가형 서버로 구성된 환경, 장애가 빈번하다고 가정
  • 파일은 대용량으로 가정, 대용량 환경에서 효과적으로 설계
  • 연속적으로 많은 데이터를 읽는 연산이거나 임의의 영역에서 적은 데이터를 읽는 연산 작업으로 구성
  • 쓰기 연산은 순차적으로 데이터 추가하는 연산, 파일에 대한 수정은 드물게 발생가정
  • 여러 클라이언트에서 동시에 동일한 파일에 데이터를 추가하는 환경에서 동기화 오버헤드 최소화
  • 낮은 응답지연 시간보다 높은 처리율
  • POSIX는 지원안함

4.4. 하둡 파일시스템### ### 4.4.1. 특징과 장단점

  • 선형적인 확장성 제공
  • 글로벌 네임스페이스 제공
  • 비용 절감
  • 전체 처리 용량 증가
  • 데이터 분석 처리에 활용
  • 응용 프로그램 기반의 파일 시스템
  • 불변 파일(Immutable File)만 저장
  • 네임스페이스 관리는 네임노드 메모리에 저장
  • 네임노드 이중화 문제

4.4.2. 대용량 데이터 분석 프레임워크 맵리듀스### ### 4.4.2.1. 소개 및 구조

  • 대용량 데이터를 병렬로 처리하기 위한 소프트웨어 프레임워크
  • 입력 파일은 라인단위로 맵 함수에 전달
  • 맵 함수의 출력 결과를 정렬/병합
  • 정렬/병합된 결과를 리듀스 함수에 전달
  • 맵 함수를 분산된 서버에서 수행
  • 분산 처리된 맵 결과를 리듀스가 수행될 서버로 전송

5. NoSQL

  • 그동안 관계형 디비가 주로 사용됨.
  • Not Only SQL, SQLess, Free Style Data Storage, Hybrid Data Storage 등의 의미
  • 관계형 디비는 대규모 데이터를 저장하기 위해 스케일 아웃(Scale-Out) 방식으로 확장하기 어려움
  • 대부분 고가
  • 새로운 인터넷 환경은 join 같은 작업 불필요
  • 조회만 가능하면 되는 경우 많음

  • 서비스 종류

  • 구글의 BigTable
  • 아마존의 다이나모(Dynamo) 등

5.1. CAP 이론

분산환경에서 데이터 관리 시스템을 구성할 경우 적용되는 이론, 이 세가지 조건을 모두 만족시키는 분산시스템을 구성할 수 없다.

  • 정합성(Consistency)
  • 가용성(Availability)
  • 단절내성(Partition Tolerance)

Visual Guide to NoSQL Systems18

5.2. NoSQL의 CAP은?

네트워크 단절시 어느 서버로 접속하더라도 같은 데이터를 읽을 수 있는 정합성 만족한다. 동일한 데이터가 여러 개의 슬래이브에 저장되기 때문에 특정 슬레이브가 장애 상황이 되더라도 읽기 연산 가능한 가용성 만족시킬 다수 있다. 네트워크 단절된 후 수정이 발생하면 데이터가 다를 수 있어 단절내성 만족하지 않는다.

5.3. NoSQL의 특징과 분류

  • 관계형 데이터 모델이 아닌 key-value 또는 key-value를 응용한 데이터 모델
  • 안정적이고 고가은 하드웨어가 아닌 다수의 값 싼 하드웨어 이용
  • 데이터는 분산된 노드에 파티션에 복제
  • 데이터의 정합성에 대한 요구사항보다는 단절내성에 대한 요구 중요
  • 2단계 커밋(2 phases commit) 수준의 트랜잭션보다는 Quorum 기반의 트랜잭션을 선호

5.4. NoSQL의 종류

  • Google’s BigData
  • 클라우데이터19
  • HBase20
  • Dynamo21
  • Cassandra22
  • MongoDB23
  • MySQL의 분산구성

5.5. NoSQL의 주의점

  • NoSQL은 범용적인 저장소가 아니다
  • 프로그램, 데이터 모델 경험이 부족하다. (최근 많이 나아졌다.)
  • 관리 도구가 부족하다.
  • 시스템 자원 사용을 모니터링 해야한다.
  • 커뮤니티에 적극적으로 참여하는것이 좋다.
  • 성능과 안정성 테스트는 실제 데이터를 이용하라.
  • 솔루션에서 제공하는 자료를 맹신해서는 안된다.

6. 로그 수집과 분석

6.1. 하둡 기반의 로그 저장 분석 솔루션

6.1.1. Chukwa24

  • 장점

  • 하둡 프로젝트의 서브 프로젝트로 로그 분석 솔루션
  • 로그를 생성하는 응용 프로그램을 수정하지 않고 로그 수집할 수 있음
  • 최종 로그 파일이 하둡 파일 시스템에 저장되기 때문에 로그파일 안정적 보관

  • 준 실시간(Near Real Time)과 실시간 수집을 지원

  • 단점

  • 하둡이 설치되어야 사용가능
  • 최종 로그파일이 SequenceFile25(Binary File)로 생성되기 때문에 별도 뷰어 필요

6.1.2. Scribe26

  • 페이스북의 로그 관리 솔루션
  • Thrift 에서 만든로그를 수신하는 서버와 접속하는 클라이언트 모듈만 제공
  • 하둡과 같은 저장소는 직접 구성해야 함
  • 척와가 기존 어플리케이션을 수정하지 않아도 되는 반면 스크리아브는 제공하는 API를 이용하여 기록하야함
  • tail을 이용해 스크라이브 서버로 전송하는 에이전트를 만들어도 됨
  • 성능향상을 위한 필수 요소

7. 메모리 캐시

  • 고려사항

  • 메모리를 얼마나 사용할 것인가?
  • 실제 데이터가 변경되었을 때 캐시에 저장된 데이터와 불일치 문제 해결방법

7.1. memcached27

  • 원격 분산 메모리 캐시 시스템
  • 데이터베이스 부하를 줄여 웹 어플리케이션의 성능을 높이기 위한 용도
  • http://www.membase.com 에서 memcached 를 유지보수하고 있음
  • 분산처리를 위한 기능 없음
  • key-value 쌍으로 기록
  • memcached 프로토콜을 이용하여 처리

7.2. membase28

  • 분산 memcached 서버

  • 다음의 경우 사용을 고려해 볼 수 있다.

  • memcached 서버 처럼 빠르면서 persistence 서비스를 제공받고 싶은 경우
  • memcached 서버에 장애 복구 기능을 추가해 좀 더 안전한 서비스를 제공받고 싶은 경우
  • 특정 서버의 memcached에 장애가 발생해 급히 해당 서버를 제거하고 재구성해야 하는 경우
  • 모든 memcached 서버에서 메모리가 부족해져 긴급히 메모리를 추가해야 하는 경우
  • 특정 서비스에서 많은 메모리를 사용해 사용량이 적은 서비스의 데이터가 캐시 아이템 교체 전략으로 제거되는 현상이 발생하는 경우
  • 특정 서비스의 캐시 데이터를 모두 삭제하고 싶은 경우
  • memcached 는 권한을 줄 수 없는데 하나의 클러스터로 여러 서비스가 같이 사용하고 싶은 경우
  • 복제 기능을 이용해 지워지지 않는 캐시 시스템을 구축하고 싶은 경우

8. Reference

  1. (2006). Salesforce.com 한국. Retrieved May 21, 2013, from http://www.salesforce.com/kr/. ↩

  2. (2009). 클라우드 컴퓨팅이란? (What is Cloud Computing … - YouTube. Retrieved May 21, 2013, from http://www.youtube.com/watch?v=Gm0gU1wrWuw. ↩

  3. 심영철 (2009). 클라우드 컴퓨팅의 기술 동향과 가상화 기반 관리 기술. KNOM Review, 12(1), 20-32. ↩

  4. Chang, F. (2006). Bigtable - Research at Google. Retrieved from http://research.google.com/archive/bigtable-osdi06.pdf. ↩

  5. (2010). 클라우드 컴퓨팅 구현 기술 – Daum 책. Retrieved May 21, 2013, from http://book.daum.net/detail/book.do?bookid=KOR9788960771703. ↩

  6. 퍼사드 패턴 - 위키백과, 우리 모두의 백과사전 - 위키백과 - Wikipedia. Retrieved May 22, 2013, from http://ko.wikipedia.org/wiki/%ED%8D%BC%EC%82%AC%EB%93%9C_%ED%8C%A8%ED%84%B4. ↩

  7. (2005). IDL (programming language) - Wikipedia, the free encyclopedia. Retrieved May 22, 2013, from http://en.wikipedia.org/wiki/IDL_(programming_language). ↩

  8. (2009). Apache Thrift. Retrieved May 22, 2013, from http://thrift.apache.org/. ↩

  9. (2010). Welcome to Apache Avro!. Retrieved May 22, 2013, from http://avro.apache.org/. ↩

  10. (2010). BSON - Binary JSON. Retrieved May 23, 2013, from http://bsonspec.org/. ↩

  11. (2009). Jetty - Servlet Engine and Http Server - Eclipse. Retrieved May 22, 2013, from http://www.eclipse.org/jetty/. ↩

  12. (2006). Round-robin DNS - Wikipedia, the free encyclopedia. Retrieved May 22, 2013, from http://en.wikipedia.org/wiki/Round-robin_DNS. ↩

  13. (2011). 의 “제3장 JEUS MQ 장애 극복” - TechNet. Retrieved May 23, 2013, from http://technet.tmax.co.kr/kr/edocs/jeus/60/mq/failover.html. ↩

  14. (2012). 서버 MCCS - IBM. Retrieved May 22, 2013, from http://www-903.ibm.com/edm/R1112/1208_ehc_thanks/3.pdf. ↩

  15. (2010). Apache ZooKeeper - Home. Retrieved May 22, 2013, from http://zookeeper.apache.org/. ↩

  16. (2007). Welcome to Apache™ Hadoop®!. Retrieved May 22, 2013, from http://hadoop.apache.org/. ↩

  17. Ghemawat, S. (2003). The Google File System. Retrieved from http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/de//archive/gfs-sosp2003.pdf. ↩

  18. (2010). Visual Guide to NoSQL Systems - Nathan Hurst’s Blog. Retrieved May 22, 2013, from http://blog.nahurst.com/visual-guide-to-nosql-systems. ↩

  19. (2010). cloudata. Retrieved May 22, 2013, from http://www.cloudata.org/. ↩

  20. (2010). HBase - Apache HBase™ Home. Retrieved May 22, 2013, from http://hbase.apache.org/. ↩

  21. (2012). Amazon DynamoDB - Amazon Web Services. Retrieved May 22, 2013, from http://aws.amazon.com/dynamodb/. ↩

  22. (2010). The Apache Cassandra Project. Retrieved May 22, 2013, from http://cassandra.apache.org/. ↩

  23. (2008). MongoDB. Retrieved May 22, 2013, from http://www.mongodb.org/. ↩

  24. (2010). Welcome to Apache Chukwa. Retrieved May 22, 2013, from http://incubator.apache.org/chukwa/. ↩

  25. (2012). SequenceFile (Apache Hadoop Main 2.0.4-alpha API). Retrieved May 22, 2013, from http://hadoop.apache.org/docs/current/api/org/apache/hadoop/io/SequenceFile.html. ↩

  26. (2010). facebook/scribe · GitHub. Retrieved May 22, 2013, from https://github.com/facebook/scribe. ↩

  27. (2006). memcached - a distributed memory object caching system. Retrieved May 22, 2013, from http://memcached.org/. ↩

  28. (2010). membase (Membase) · GitHub. Retrieved May 22, 2013, from https://github.com/membase. ↩