대용량 분산 시스템 디자인 패턴

1. 대용량 분산 시스템 아키텍쳐
#3.대용량 분산 아키텍쳐
조대협
http://bcho.tistory.com

2. 소프트웨어 개발 트랜드의 변화
• 대규모/긴기간 에서 소규모/단기간 (스타트업)
• 빠르고 잦은 릴리즈 (애자일)
• 고객의 VOC를 수용 (빅데이타,SNS)
• 개발과 운영을 통합 (DEVOPS)
• 열심히 일하는 것으로 감당 안됨 (자동화)
• 스페샬 리스트에서 제너럴 리스트 (수퍼엔지니어)
• 대용량 글로벌 스케일
• 오픈소스
• 구글링,STACKOVERFLOW,블로그,GITHUB

3. 소프트웨어 개발 트랜드의 변화
• 아키텍쳐의 변화
중앙 집중형 저장소
(RDBMS,NFS)
UX + 비지니스 로직
분산형 저장소
(NoSQL,Sharding)
REST API
비지니스 로직
자바스크립트
• HTML,Servlet/JSP
• EJB,Spring
• RDBMS
• HTML5,AngularJS
• REST,WebSocket
• Node.JS,IMDG
• NoSQL,Sharding
동기식,중앙 집중형,고가용성
클러스터링
비동기식, 분산형, Resilience
Shared Nothing

4. 일반적인 시스템 서비스 구조
• 모든 서비스 시스템은 일반적으로 다음과 같은 구조를 갖는다.
OSS BSS
• 컴포넌트
– Internal Business Logic : 일반적인 트렌젝션 처리 (서비스)
– External Interface : 대외 연계
– Reporting : 데이타 수집 및 분석/리포트 생성
– OSS (Operation Support System) : Tech Ops, Biz Ops
– BSS (Business Support System) : 리포트, PO 관리

5. 대용량 분산 시스템 아키텍쳐
• SOA 기반의 플랫폼 아키텍쳐 (Common)

6. 대용량 분산 시스템 아키텍쳐
• SOA 기반의 플랫폼 아키텍쳐 (Common)
: 재사용 가능한 API 컴포넌트 기반의 아키텍쳐
– Access Layer : Access Layer는 크게 두 가지 역할을 하는데, 외부로 부
터 들어오는 사용자 요청에 대해서 관문 역할을 하며, 외부 시스템과의
연동 역할을 한다.
– Business Layer : Business Layer는 들어온 사용자 요청에 대해서 비지니
스 로직을 처리하여 응답을 내보낸다.
– Persistent Layer : 마지막으로 Persistent Layer는 Business Logic에 의해
처리되는 또는 처리된 데이타를 저장하는 역할을 한다.

7. Access Layer
• 사용자 API에 대한 End Point
1. Reverse Proxy
– 부하 분산
– SSL Termination
– IP Blocking
– Logging

8. Access Layer
2. Service Bus (or API Gateway)
– API 에 대한 Backbone 역할
– Cross Cutting Concern (Logging, Authentication , Authorization)
– Mediation
• Routing
• Message Transforming
• Message format/Protocol converting
• MEP converting
• QoS management (메세지 Throttling)
• Orcherstration
Service Bus를 이용한, Sync to Async 변환

9. Access Layer
2. Service Bus (or API Gateway)
아래 내부와 외부 API 호출에 대한 접근 통제를 차별화 한 설계

10. Access Layer
2. Service Bus (or API Gateway)
• API Platform
• API Platform (APIgee)
• API Service (3Scale – API Market)
※ MaaS, BaaS

11. Access Layer
2. Service Bus (or API Gateway)
• API Mediation (APIgee)

12. Access Layer
2. Service Bus (or API Gateway)
• API Portal
- API Spec
- API Key 인증
- API Manual
- API Sand Box

13. Access Layer
3. IDM (Identity Management System)
– 사용자 계정 관리
– Access Control (Authentication, Authorization, Audit)
– Federation
– Lifecycle management & Provisioning
– Single Sign On
ProvisioningAuthentication & Authorization

14. Access Layer
3. Integration
– Integration Type
• API Integration
• Native Adapter – JCA, Mecator, TopLink ,WTC
• Data replication – ETL/CDC
– Consideration
• Logging (Audit)
• Retry
– Ignore
– Notification
– Retry
– Manual Handling

15. Business Layer
1. Transaction Processing (Sync)
– Simple request and response pattern.
– Stateless, Shared Nothing (공유 정보는 DataGrid로)
– Heavy Transaction & small # of concurrent user
• Multi threaded server
• Web Application Server
– Light Transaction & Huge # of concurrent user (C10K)
• Single thread server
• Vertex, node.js

16. Business Layer
1. Transaction Processing (Sync)
Multi thread server Single Thread Server
(Async)

17. Business Layer
1. Transaction Processing (Sync)
Multi thread server Single Thread Server
(Async)
http://strongloop.com/strongblog/node-js-is-faster-than-java/

18. Business Layer
1. Transaction Processing (Sync)
– 트렌젝션 처리
• Transaction manager (JTS, XA)
• 보상 (Compensation) 트렌젝션

19. Business Layer
2. Transaction Processing (Async)
• 메세지 큐 기반 (MQ, RabbitMQ,ActiveMQ, JMS,ZeroMQ)
• 응답을 기다리지 않고 바로 리턴
• 큐 뒤에, 다수의 Worker를 둬서, 대용량 처리에 유리

20. Business Layer
2. Transaction Processing (Async)
* Message Exchange Patterns
1) Fire & forget
2) Publish & Subscribe
3) Routing
4) Call Back
※ collation id

21. Business Layer
2. Transaction Processing (Async)
• 에러처리 (Error Hospital)
① Ignore
② Notify
③ Human interaction
④ Retry (Aging required)

22. Business Layer
3. Data Grid
• IMDG (In memory data grid)- HazelCast,Infinispan,Coherence
※ cf. redis (IMDB, 클러스터 안됨)
• 거대한 메모리 클러스터
• 공유 정보 (Sessiom,키 등)와 캐쉬 영역으로 사용됨
• 클러스터링 기반의 자가 HA 기능 필수

23. Business Layer
4. Working Space
• 작업용 파일을 올리는 일종이 temp directory
• 이미지 변환, 동영상 변환
• 자체 HA를 위한 Clustering 필수
• NFS, Gluster FS
Working Space + Async Transaction Processing 기반 구조

24. Persistent Layer
• RDBMS
• NoSQL
– Column DB
– Document DB
– Graph DB
• 파일 시스템
– 일반 파일 시스템
– Object Storage (S3,Blob Storage,OpenStack Swift)

25. Analytics Layer
• 데이타 분석 및 리포팅
– 단계
• 단순 리포팅
• 인사이트
• 예측
– 리포팅
• 리포트 생성 (엑셀)
• 대쉬 보드 (웹)
• Ad-Hoc 쿼리

26. Analytics Layer
• 전통적인 OLAP 방식의 분석 시스템
– ETL
– Dataware house
– Data Mart
– Reporting

27. Analytics Layer
• Map & Reduce (Hadoop) 기반의 분석 시스템
Map & Reduce + OLAP 형태의 분석 시스템

28. Analytics Layer
• 실시간 분석 시스템
– Realtime BI
– CEP (Centralized Event Processing)

29. OAM (Operation Admin Monitoring)
• CMDB (Application)
– RDBMS, ZooKeeper
• Configuration Management (Middleware & Infra)
– Chef,Puppet
• Deployment (Application)
– RPM,Fabric,Caspirano
• Monitoring (Application,Middleware,DBMS,Infra)
– Dash board : Nagio
– History : Cacti,Ganglia,Zzabix
– Application: Jennifer, Appdynamics
• Log gathering (Application,Middleware,DBMS,Infra)
– Log gathering : Flume,Fluentd
– Log gathering & Search : Logstash + Elastic Search + Kafka, graylog
– Error dash board : Sentry

30. 글로벌 배포 시스템
• 고려 사항
– Regulation : 법률(데이타의 위치와 이동,개인정보 보호), 세금
– 지역별 기술 차이
• 중국 : Amazon 없음, Google Push 안됨
• 동남아 : 네트웍이 많이 느림
– 네트웍 Latency
– 데이타 센터간 데이타 복제
• DB 복제 방식 : CDC/ETL
• API 복제 방식 : API를 중복 호출 (Service Bus 등을 이용)
– 다국어 지원

31. 글로벌 배포 시스템
• 위치 선정
– 법적 이슈 및 세금 (중국,미국,유럽)
– 네트워크 속도 (더블린, 미서부, 일본)
– 인력 수급
– 세제 혜택
– 가격
– Procurement (서버 구매)
※ 중국, 유럽 (더블린), 미서부 (캘리포니아)

32. 글로벌 배포 시스템
• 구성 방식
– Master center / Regional center
– Master / Master center
• 서비스 Look up : 주로 데이타 복제 가능 여부에 따라 디자인
– 가까운 곳 우선 (데이타 센터간 동기화가 잘 되어 있을 경우 – 주로 근거
리 또는 전용망)
– 특정 데이타 센터 지정 방식
※ Global Load Balancer 디자인이 관건

33. 글로벌 배포 시스템
• Request 라우팅
• 데이타 센터간 복제

34. 솔루션 스택
Layer Component Product
Access Layer
Reverse Proxy apache httpd, nginx, haproxy
Enterprise Service Bus (ESB Approach) mule, Oracle Service Bus
Enterprise Service Bus (API Platform
Approach)
Apigee, Layer 7,Mashery,3scale
Identity Management
Shiboleth, SimpleSAML PHP,
OpenAM, CA Site Minder
Integration Layer Apache Camel, Spring Integration
Business
Layer
Transaction processing(Sync)
apache tomcat, jetty ,apache mina ,apache netty ,redhat jboss
,oracle weblogic
Message Queue (Async) Rabbit MQ, Active MQ, Zero MQ
data grid Memcached,redis , oracle coherence ,Infinispan ,Hazlecast
Persistent
Layer
RDBMS mysql,maria db, postgres,MS SQL,Oracle
mysql replication Ganglia , tungsten ,oracle golden gate
file system (NFS) glusterfs
file system (object store) openstack swift,S3,BlobStorage
NoSQL
Hbase , Cassandra , mongodb,
Riak, Couch Base
Analysis Layer
log gathering Flume , flumed, Logstash, GrayLog,Sentry
analysis service splunk
ETL Pentaho
map & reduce Hadoop,pig,hive
cep esper
OAM
cmdb zookeeper
monitoring Jennifer , ganglia , nagios
configuration management Puppet , chef,ancible
Deployment Fabric,RPM

35. 클라우드 컴퓨팅
• 퍼브릭 클라우드
– IaaS,PaaS,SaaS
– 결코 싸지 않음
– 같은 서비스라도 지역별로 가격이 다름
– 생각보다 장애 많이 남 (99.95%)
– IO가 함정
– CPU Core가 2000년대 초 Xeon 수준 (요즘 CPU 수준이 아닌 가상화됨)
– 비쌈!!
– Infra Service, Fundamental Service
– IaaS : Amazon(갑), Azure, IBM Layer 7 (다크호스),Google Compute
engine
– PaaS : Heroku, Google App Engine,Azure, MongoLab, Cloudant,
CouchDB Cloud 서비스, MS Directory Service
– 저가 ? Digital Ocean

36. 몇가지 짚고 넘어갈 이야기
• 할 수 있는 것은 모두 Cache (CDN, DB 캐쉬, API 캐쉬)
• 인증, 보안. 개인정보 관리 특히 API 키
• 일단 빨리 시작해서, 사용자가 많아지면 아키텍쳐 개선
• 오버디자인 주의
• Technical debt – 빚은 항상 적절하게
• 아키텍쳐 디자인은 Trade off 게임이자 투자
• HighAvailibility.com
• Infoq.com

37. 분산 시스템 아키텍쳐 디자인 패턴
• 부하 분산
• 캐슁
– 분산 방식, 집중 방식
• 데이타 파티셔닝
• 쿼리 오프로딩
• 비동기 처리
• 데이타 복제
• 배포
• 로깅
– 글로벌 트렌젝션 ID