scale-out application reference architecture...

Copyright © 2014 Samsung SDS Co., Ltd. All rights reserved | Confidential

2014. 07. 17

Software Architecture Lab

연구소 아키텍처 연구팀

정영일

클라우드와 오픈소스 기반

SCale-out Application

Reference Architecture

(SCARA)

[2014 한국소프트웨어아키텍트대회]

Agenda

I. SCARA 추진배경

II. SCARA 과제목적

III. Scale-out Application Architecture 사례

IV. SCARA 소개

V. SCARA 관련 사례

VI. SCARA 요소기술 적용사례

VII. SCARA 향후 계획

[별첨 #1] Scale-out을 위한 Sharding과 Query-Off Loading

[별첨 #2] Netty & Vert.x

[2014 한국 소프트웨어 아키텍트 대회]3

I. SCARA 추진배경

Web Scale IT among the Top 10 Strategic Technology Trends for 2014(Gartner)

• Mobile Device

Diversity & Management

• Mobile Apps&Applications

• The Internet of Everything

• Hybrid Cloud & IT as

Service Broker

Web Scale IT: Amazon, Google, Facebook 등과 같은 대형 클라우드 서비스 제공업체들이각종 역량을 구현하는 운영 방식으로, IT Value Chain을 개선시키고자 함

What’s In: Open Source,

Scale-out, DIY(Do It

Yourself), DevOps,

Sharing, Learning, New-

Age Vendors

What’s out: Proprietary,

Turn-key, ITIL, Complexity,

Scales-up, Old-School

Vendors

• Cloud/Client Architecture

• The Era of Personal Cloud

• Software Defined Anything

• Web Scale IT

• Smart Machines

• 3-D Printing

Web Scale IT: Need to Re-think the Entire IT Value Chain

※ Nexus: 아래 4가지 Trend가 하나로 수렴하여개인의 삶과 기업의 일하는 방식의 변화하는 개념


Large Cloud Service Technology

SCARA 추진 배경 I. SCARA 추진배경

Social Computing

OWASP Top10

IPV6

Hadoop

Cloud Computing

IoT/IoE

BYOD

In Memory Computing

HTML5

Big Data

Distributed Computing

SDDC

Mobile Web/App

All Flash

NoSQL

Multi-Tenancy

SoC

SDx

3D Printing

Mobile Security

Virtualization

The Latest Technology

Web Scale IT

Cloud Service

SaaS

PaaS+

IaaS+

ITaaS

Scale-out Architecture 추진배경

WOA

Feedback

DevOps

Open Source

+

분산 컴퓨팅 오픈소스

빅데이터 관련 오픈소스

+

서비스자동화 오픈소스

+ B2C 영역에 오픈소스 기반 대규모Scale-out 아키텍처 패턴을 B2B에 활용

Business 환경

x86

• 시스템 구축 및 운영에 대한 인건비 증가

및 IT 투자비용 절감 필요

• 서비스 사용자 수와 용량을 예측하기가 난

해함에 따른 On-Demand 서비스 요구증대

• Scale-up의 한계로 인한 시스템 재투자 비

용 증가

+

+

VA


SCARA 과제 목적 II. SCARA 과제 목적

L3/L4 SWITCH

COTS WEB Server

Clustering

COTS DB#1

… COTS DB#N

COTS WAS Server

Heavy Application

As-Is To-BeSteps to go

“관리자에 의한 Scale-up 및서버단위의 Scale-out”

“Enhance Scalability, Improve Server Utilization, Reduce Cost”

“저비용 소프트웨어를 이용한Auto Scale-out”

Auto Scale-out(동일 및 이기종 인프라 Pool,

모니터링)

B2B向 저비용분산 및 대용량 DB 구축

Software Load Balance(부하분산)

OSS(Open Source Software) 기반 저비용 분산처리 및 Auto Scaling 가능한 기술 구현

Dedicate Server

OSS Proxy(OSS : Open Source Software)

Shard

ing Shard #1

Shard #2…

Shard #N

OSS Light WAS

Light Application

OSS Light WEB

OSS Queue

OSS분산 Storage

NoSQLDB

OSSCache

Virtual Machine

Distributing Computing(분산처리)


Tumblr III. Scale-out Application Architecture 사례

서비스명 Tumblr

서비스 개요 소셜네트워크 서비스로 블로그 형태로 SNS 처럼 사용을 하는 마이크로 블로그 플랫폼

아키텍처

① 서비스 규모 (‘12.08 기준)

- 총 블로그 수: 6천 9백 4십만 개

- 게시물 수: 2백 9십 8억개

- 일 포스팅 수: 7천 1백 6십 만개

- 매일 1TB 데이터 하둡 클러스터 저장

- MySQL/HBase/Redis/Memcached에매일 수 TB 데이터 적재

- 포스트는 매일 50GB, 팔로어 리스트 업데이트 기준 하루 2.7TB 발생

② 아키텍처 구조- OS: Linux(CentOS) - 웹서버: Apache- 언어: PHP/Scala/Ruby - 소스 관리 : Git- RDB: MySQL(shard)- NoSQL: Redis, HBase- Load Balancing: Varnish, HA-Proxy, nginx- Cache: Memcached- RPC 프레임워크: Finagle (Twitter 공개)- Queue: Gearman, Kafka(Linkedin 공개), kestrel

- 배포/관리 도구: Jenkins, Capistrano, Puppet

특이사항- 웹서버 : 500대, DB : 200대(47개 pool, 30개 shard), memcached 서버: 30대, redis 서버: 22대- varnish 서버 : 15대, HAProxy : 25대 nginx : 8대, 큐서버(kestrel, gearman - Job 용) : 14대


Twitter III. Scale-out Application Architecture 사례

서비스명 Twitter

서비스 개요 무료 소셜 네트워킹 겸 마이크로 블로그 서비스, 160자 이내의 짧은 메세지들을 교환하는 SNS

아키텍처

① 하루 평균 2.5억건의 트윗을 저장하기 위한스토리지 플랫폼 구축.

② 트윗이 저장되는 DB를 T-Bird, Follower 및Following list 등 보조 인덱스가 저장되는DB를 T-Flock이라 하며, 동일하게 Gizzard 기반.

③ 공간 복잡도의 문제를 가지고 있으며 이를해결하기 위해 Gizzard(DB주소를 찾기 위한방법)와 MySQL 샤딩을 사용

④ Gizzard는 분산 DB관리 프레임워크이며Twitter에서 자체 개발, Scala 기반. 내부적으로 Mapping 테이블 및 Replication, 장애시 유연한 대처가 가능함.

⑤ 유일한 ID(UUID)를 생성하기 위해SnowFlake를 사용

⑥ DBMS는 MySQL의 innoDB 스토리지 엔진을 사용함.

특이사항• 오픈소스 플랫폼들과 apache mina, netty를 기반으로 한 Scala로 개발된 finagle, DB의 경우 MySQL 샤딩을

기본으로 Gizzard, Snowflake, FlockDB 사용


What is Scalability? IV. SCARA 소개

The measure of a system’s ability to increase or decrease in performance and cost in response to changes in application and system processing demands.

Examples)1) How well a hardware system performs when the number of users is increased2) How well a database withstands growing numbers of queries3) How well an operating system performs on different classes of hardware

■ Scalability Definition(Gartner)

- 대량의 처리를 할 수 있는 능력 또는 처리 용량의 증설이 요구될 때 대응할 수 있는 능력- 요구되는 Throughput이 증가할 때 대응할 수 있는 능력

■ Scalability 관련 품질속성

품질 속성 내 용

Latency 처리지연시간. 통상 Latency가 낮은 것을 Performance가 높다고 함

Throughput 단위 시간 내 처리 할 수 있는 업무량. 개별 처리의 Latency를 낮추거나 동시에

처리할 수 있는 개수를 늘리면 증가함

Availability 쉽고 빠르게 확장 가능하면서도 fail-over, coordinator 등의 제어 기능

Agility 비즈니스 변화에 탄력적 대응 (Cloud의 IaaS, PaaS, SaaS 등이 고려되어야 함)

단순한 확장성 뿐 만 아니라 Cost↓, Performance↑(Latency↓/Throughput↑), Availability↑, Agility↑ 는 것이 Quality Factor 임


Scalability의 유형 (Scale-out/up) IV. SCARA 소개

• Scale-out : 시스템 유닛 증가를 통한 수평적인 확장. 장비 대수를 늘림으로 성능향상

분산처리/병렬처리가 주 목적. 상대적으로 저렴하지만 분산처리 SW 및 아키텍처 필요

• Scale-up : 시스템 내 CPU, Memory, Disk 등 파워 및 용량 확장을 통한 수직적인 확장

즉, 장비 대수는 그대로 두고 부품만 추가하여 성능확장

구분 Scale-Out Scale-Up

확장방식시스템의 용량과 성능향상을 위해 Node 단위로확장하고 하나의 시스템처럼 운영

단일 시스템에 필요한 만큼 Resource 용량 증가

비용요소Node 추가 비용, 분산 컨트롤러 개발비용초기 개발시 Scale-out 아키텍처 반영

CPU, Memory, Disk 추가 비용

확장성높음, 컨트롤러나 네트워크 인프라가 지원하는 만큼계속 확장 가능

제한적, 하나의 장비에 추가할 수 있는 CPU나 Disk의수량이 한정됨

주요기술(App 관점)

Sharding, Query-off Loading, Queue, In Memory Cache, NoSQL, Object Storage, Distributed Storage

고성능 CPU, Memory 확장, SSD

주요 용도장/단점

분산처리 시스템/Global 웹 Application, 점진적 증가 가능, 보통 Scale-up 보다 저렴, 설계/구축/관리비용 증가

고성능 Legacy Application, 구축이 쉽고 관리 용이단계적 증가가 어렵고, 근본적인 해결이 안될 수 있음

기타특징

System

Resource

System

Resource

System

Resource

System

Resource

System

Resource


Scale-out의 유형 (Horizontal/Vertical) IV. SCARA 소개

• Horizontal Scale-out : 일반적인 Scale-out의 의미로써, 같은 역할의 장비수량을 증가시키는 기법

• Vertical Scale-out : 기능별 장비를 분할하는 기법으로써, 시스템 변경이 발생하기 때문에 일반적인 증

설의 의미가 아니라 Horizontal Scale-out을 효율적으로 가능할 수 있도록 기능별로 분할하는 기법

구분 Horizontal Scale-Out Vertical Scale-Out

확장방식같은 역할을 하는 장비의 수량 증가하여 Throughput을 늘리는 기법 또는 구조

기능 요소 별로 Resource의 필요량이나 종류가 다른것을 구분하여 효율적으로 Horizontal Scale-out이 가능하게 하는 기법 또는 구조

Check Point1) 보통 Coordinator가 필요하며, 이것이 성능저하나

장애원인이 될 수 있음

1) 기능요소에 따른 분할에 따라 통신 구간이 생길수 있으므로 Latency 증가와 함께 장애 가능성이존재함

2) 분화된 기능들끼리의 연동 방식이 부적절할 경우장비 추가의 효과가 없을 수 있음

적용 기술 Query-off Loading, In Memory Cache Clustering Sharding, Light Protocol/Framework

주요 사례L4 Switch, IBM SAN Volume Controller, Oracle RAC, Hadoop System(HDFS NameNode), GSLB

WEB/WAS/DB구조, Object Storage 분리(image 저장), 용도별 DB분리

Scalability

Scale-out

Scale-up

Horizontal Scale-out

Vertical Scale-out


SCARA 구성요소 IV. SCARA 소개

Management

Infra Structure

Data ServiceNetwork Front-End Middleware

Coordination Mornitoring Configuration/Deploy

OS Cloud Platform Storage/File System

DNS

CDN

Protocol

Proxy

Web Server

WAS

Queue

Search

RDBMS

NoSQL

Cache

Replication

Sharding

Synchronization

- Ultra DNS(*)

- Amazone Route53(*)

- CloudFront(*)

- Akamai(*)

- Thrift

- Protocol Buffer

- Avro

- SOAP / REST

- MongoDB- Cassandra- CouchDB(*)- HBase

- Apache Traffic Server- Nginx- HA-Proxy- Varnish / Squid

- Lucene, Solr, Elastic Search

- RabbitMQ / ActiveMQ- ZeroMQ / Gearman

- Tomcat / JBoss- Netty / Node.js / Jetty

- MySQL(*)- MariaDB- PostgreSQL(*)

- Redis- Memcached

- Apache

- Nginx- MySQL MHA(*) / DataBus- Galera Cluster

- Gizzard / Cubrid Shard- Spock Proxy / MySQL-Spider

- Oracle Golden Gate(*)- Databus

- ZooKeeper- Redis Sentinel

- Nagios / Ganglia- Zabbix

- Puppet / Chef- Jenkins / Grunt

- CentOS, Ubuntu, RHEL(*) - Cloud(*) / AWS(*)- CloudStack / OpenStack

- HDFS / GFS - Swift / S3(*)

UI

- HTML5

- AngularJS, Bootstrap

- Jquery, Underscore.js

- Android/ioS App

Application F/W

- Spring Framework- Node.js / Vert.x

Layer별 오픈소스 기반 Scale-out Application 아키텍처 구성요소는 다음과 같음 - 상용서비스(*)


To-Be Scale-out Application Architecture IV. SCARA 소개

예)미국 Cell #1

CloudFront

Akamai

UltraDNS

Route53

Proxy #1

Apache Traffic

HA-Proxy

Proxy #2

Apache Traffic

HA-Proxy

WAS #1

Netty

Vert.X

Spring F/W

Application

WEB #1

Nginx

AgularJS

JQuery

Web source

WEB #2

Nginx

AgularJS

JQuery

Web source

WAS #2

Netty

Vert.X

Spring F/W

Application

Search Egine#1

Elastic Search

Search Egine#2

Elastic Search

Queue #1

RabbitMQ

Queue #2

RabbitMQ

KVS #1

Redis

KVS #2

Redis

Sharding Platform

#1

Sharding Platform

#2

RDB Master

MySQL

NoSQL

Cassendra

HBase

RDB Slave

MySQL

MHA(Replicatio

n)

DataBus

Coordination(Zookeeper) Server Monitoring(Nagios)

Configuration (Puppet, Chef, Jenkins) OS(CentOS)

Cloud Service

Object Storage #1

Swift

Object Storage #1

Swift

예)한국 Cell #1

Proxy #1

Apache Traffic

HA-Proxy

Proxy #2

Apache Traffic

HA-Proxy

WAS #1

Netty

Vert.x

Spring F/W

Application

WEB #1

Nginx

AgularJS

JQuery

Web source

WEB #2

Nginx

AgularJS

JQuery

Web source

WAS #2

Netty

Vert.x

Spring F/W

Application

Search Engine #1

Elastic Search

Search Engine #2

Elastic Search

Queue #1

RabbitMQ

Queue #2

RabbitMQ

KVS #1

Redis

KVS #2

Redis

Sharding Middleware

RDB Slave

MySQL

NoSQL

Cassandra

HBase

RDB Master

MySQL

MHA(Replication)

DataBus(Synchronization)

Coordination(Zookeeper) Server Monitoring(Nagios)

Configuration (Puppet, Chef, Jenkins) OS(CentOS)

Cloud Service / Cloud Management

Object Storage

Swift #1

Object Storage

Swift #2

Scaleout

Scaleout

Scaleout

Scaleout

Scaleout

Scaleout

Scaleout

Scaleout

Scaleout

Cloud와 Open Source를 활용한 Global Cell 기반의 Scale-out Application Architecture 구현 및 검증

DataBus(Synchronization)

http://www.prlog.org/12249600-buy-online-desktop-computer.jpg

http://www.prlog.org/12249600-buy-online-desktop-computer.jpg

http://event.asus.com/2010/Computex/Press/images/galley/ASUS_Eee_Pad_EP101TC_10_inch.jpg

http://event.asus.com/2010/Computex/Press/images/galley/ASUS_Eee_Pad_EP101TC_10_inch.jpg

http://contentdeliverynetworkcdn.files.wordpress.com/2012/02/cdn.jpg

http://contentdeliverynetworkcdn.files.wordpress.com/2012/02/cdn.jpg


SCARA – SNS 서비스 사례 V. SCARA 관련 사례

구 분 설 명

서비스 소개

사용자 전체 사용자(10000명), 동시사용자(2000명)

성능요구사항 Think Time(10초), 평균 응답시간(3초).

목표 처리량 약 154 TPS

• TPS = 부하사용자 / (Think time + 평균 응답시간)약 154 TPS = 2,000 / (10 + 3)

• TPS: 화면단위처리량

자원 사용량 70%미만• 목표 처리량이 발생하고 있는 시점에서 자원 사용량이 70% 미만으로 사

용되어야 함

VISUAL 및 분석 기능을 갖춘 SaaS 방식 SNS

VisualSNS

GroupProject

문서관리SocialSearch

키워드분석

Wiki 보안 관리OpenAPI

AdminNote

사용자 기능 (7개 모듈) 관리자 기능 (3개모듈)

Visual SNS


SCARA – SNS 서비스 사례 V. SCARA 관련 사례

Management

Infra Structure




DNS

CDN

Protocol

Proxy

Web Server

WAS

Queue

Search

RDBMS

NoSQL

Cache

Replication

Sharding

Synchronization

- Ultra DNS

- Amazone Route53

- CloudFront

- Akamai

- Thrift

- Protocol Buffer

- Avro

- SOAP / REST

- MongoDB- Cassandra- CouchDB- HBase




- Tomcat / Node.js- Netty, Jetty

- MySQL- MariaDB- PostgreSQL

- Redis- Memcached

- Apache

- Nginx- MySQL MHA / DataBus- Galera Cluster

- Gizzard / Cubrid Shard- Custormizing Development

- Oracle Golden Gate- Databus




- CentOS, Ubuntu, RHEL(*) - Cloud / AWS- CloudStack / OpenStack

- HDFS / GFS - Swift / S3

UI

- HTML5



- Android/ioS App

Application F/W


SCARA 관련 아키텍처와 오픈소스 조사 결과 아래와 같은 범위로 검증 범위 수립

적용 미적용- 검증 대상

- 미적용 대상


SCARA – Enterprise SNS 서비스 사례 V. SCARA 관련사례

구분목표

처리량

테스트 결과

처리량TPS

동시사용자

자원 사용률

WEB1 WEB2 WAS1 WAS2EtherPad1

MetaMaster

MetaSlave

SharedMaster

SharedSlave

1차 테스트154TPS

53.7 TPS 537명 2% 1% 92% 93% - 17% 80% 58% 65%

2차 테스트 266.3 TPS 2,663명 18% 15% 59% 45% 35% 48% 45% 65% 71%

테스트 결과 요약

처리량 TPS 추이

Active User

최대 처리량266.3 TPS

목표처리량154 TPS

테스트 결과 수용 가능한 예상 동시사용자는 2,663명 임. (2,663명 = 266.3TPS X 10 초 Think Time)


AS-IS 요소기술 적용사례 VI. SCARA 요소기술 적용사례

Management

Infra Structure




DNS

CDN

Protocol

Proxy

Web Server

WAS

Queue

Search

RDBMS

NoSQL

Cache

Replication

Sharding

Synchronization

- Ultra DNS

- Amazone Route53

- CloudFront

- Akamai

- Thrift

- Protocol Buffer

- Avro

- SOAP / REST

- MongoDB- Cassandra- CouchDB- HBase




- Tomcat / Node.js- Netty, Jetty

- MySQL- MariaDB- PostgreSQL

- Redis- Memcached

- Apache

- Nginx- MySQL MHA / DataBus- Galera Cluster

- Gizzard / Cubrid Shard- Spock Proxy/MySQL-Spider

- Oracle Golden Gate- Databus




- CentOS, Ubuntu, RHEL(*) - Cloud / AWS- CloudStack / OpenStack

- HDFS / GFS - Swift / S3

UI

- HTML5



- Android/ioS App

Application F/W


Service side mid-term Transaction 처리 모듈, 그룹웨어, SNS 시스템에 요소기술 적용을 진행 중이며향후 통합 구성 후 비기능 테스트 실시 예정

현재 진행중인 요소기술


1) Server side Biz Transaction처리 VI. SCARA 요소기술 적용사례

NoSQL, In Memory Cache, Queue가 구성요소

WASWAS

Browser

Sync Agent

NotifyE-mail

MDM

SNS

RESTful

Channel Layer

Http(s)

Mobile App

Async Biz Transaction(예,변환 등)

Business LayerPersistence

Layer

<< Notify >> Daemon

LDAP

Batch

Asynchronous

queue

In Memory Cache

<< use >>

WebWebRDBMSRDBMS

NoSQLDB

NoSQLDB

Object StorageObject

Storage

QueueQueue

On-premise / Cloud

Stateless

Legacy

SSO

.

.

.

JDBC

Asyncqueue

Http(s)

JDBC

MVC


1) Server side Biz Transaction처리 VI. SCARA 요소기술 적용사례

PC, Mobile, OpenAPI 인증 성능을 향상시키기 위해 In Memory Cache(Redis)를 적용, WAS의 세션 클러스터링 대체하여 사용자 Session의 HA를 위해 Tomcat-Redis Sentinel 적용

Biz 시스템

플랫폼

REDIS

Business Logic임시 스토르지

DecryptedMessage

EncryptedMessage

Key Management

Seed

Indexsize

1. 암호화 Key 생성

Key = GetEncryptKey(Index, size)

Key암호

알고리즘

2. Message 암호화

3. Message 저장

4. MessageMeta 반영

Message UUID, Index

암호화 Key 생성

RDB

Account

Device

Policy

Message Meta

Storage

EncryptedMessage

UUID URLIndex

UUID URLIndex

UUID URLIndex

UUID URLIndex

……..

Message 저장 성공 시저장소의 URL 리턴

Message UUID, 암호화 Key Index, URL 반영

UUID, Key Index, URL


2) Push Service VI. SCARA 요소기술 적용사례

웹 Push 기능을 클라이언트(Socket.io, Long Polling)을 사용하고, 서버 사이드에 HA Proxy와 경량Framework(Vert.x)와 경량 WAS(Netty)를 이용하여 전환할 예정

WEB #1

RHEL 6.3 (Santiago)

Cronolog 1.6.2

Push Server)

Apache 2.4

CL-기업형, 사내-004

•IP: 112.106.147.183•CPU: Intel Xeon X5670 • 2.93GHz 4 Core•Memory: 8GB•DISK: 100GB

Munin Agent(Server Monitoring)

Web Source

Copy URL

Source

WEB #2

RHEL 6.3 (Santiago)

Cronolog 1.6.2

Push Server

Apache 2.4

CL-기업형, 사내-013

•IP: 112.106.147.184•CPU: Intel Xeon X5670 • 2.93GHz 4 Core•Memory: 8GB•DISK: 50GB

Munin Agent(Server Monitoring)

Web Source

Copy URL

Source

웹 Zone

Tomcat 7.0.37(Copy URL

Application)

Tomcat 7.0.37(Copy URL Application)

JVM (1.7 Version)

Netty

Vert.x

Hazelcast

java js rb py …..

ServerClient

Browser

WebSocket

HA

PROXy


3) Web Document 공유 서비스 VI. SCARA 요소기술 적용사례

■ GlusterFS Dirty db 테스트 구성 각 인스턴스 별로 별도 dirtyDB 사용 – GFS에서 dirtyDB 파일 서버별 복제

dirtyDB

node.js

ueberDBI/F

benchmark.js

dirtyDB

node.js

ueberDBI/F

benchmark.js

dirtyDB

node.js

ueberDBI/F

benchmark.js

dirtyDB

node.js

ueberDBI/F

benchmark.js

Test Server 1

dirtyDB

node.js

ueberDBI/F

benchmark.js

dirtyDB

node.js

ueberDBI/F

benchmark.js

dirtyDB

node.js

ueberDBI/F

benchmark.js

dirtyDB

node.js

ueberDBI/F

benchmark.js

Test Server 2

dirtyDB dirtyDB dirtyDB dirtyDB dirtyDB dirtyDB dirtyDB dirtyDB

Gluster FS

replication


SCARA RoadMap VII. SCARA 향후 계획

• Cloud와 Open Source 기반의 아키텍처로 구축비용 절감• 시스템 확장에 대한 투자비용, 운영비용 절감

IT 투자비용감소

• 서비스 사용자 수 증감에 따른 탄력적 대응으로 고객만족 및 Uptime 증가Time-to-Market

• Architecture Reference & Pattern Asset을 활용한 개발기간 단축상품화기간 단축

차세대데이터 센터

SaaS

PaaS

+

IaaS

+SCARA

(SCale-out Application Reference Architecture)

++

dPaaS 연구

Multi-TenancyScalability 연구

Scale-out App. Reference Architecture 및 Pattern 연구

+

Scalability Performance Availability

SCARA 관련 아키텍처 연구 결과는 향후 PaaS, SaaS 영역으로 확산


SCARA RoadMap - 1) PaaS Service VII. SCARA 향후 계획

Application

Data

Runtime

Middleware

O/S

Virtualization

Servers

Storage

Networking

TraditionalSoftware

You Manage

Application

Data

Runtime

Middleware

O/S

Virtualization

Servers

Storage

Networking

SCARA based dPaaS

Cloud Infra

SCARA+

dPaaS

SCARAArch.

Pattern

dPaaS 서비스와 SCARA의 PaaS 구성요소를 Add-on하여 차별화된 PaaS 서비스 제공


SCARA RoadMap - 1) PaaS Service VII. SCARA 향후 계획

Service OpenShift Cloud Foundry dPaaS + SCARA

Definition어플리케이션을 개발, 배포 및 관리를할 수 있도록 개발 환경을 생성해 주는 클라우드 PaaS 솔루션

Vmware에서 개발한 오픈소스 클라우드 컴퓨팅 PaaS 솔루션

소프트웨어 개발 및 관리를 위한 표준도구를 제공하고, Cloud Infra를 활용하여 개발에 필요한 환경을 자동으로구성해주는 플랫폼 서비스

Vender RedHat VMWare -

RDBMS MySQL, PostgreSQL MySQL, PostgreSQL MySQL, Oracle

NoSQL MongoDB MongoDB Cassandra, MongoDB, HBase

Sharding N/A N/A Sharding Platform

Proxy N/A N/A HA-Proxy, Nginx

Web Server Apache N/A Apache, Nginx

WAS JBoss N/A JBoss, Tomcat, WebLogic, Netty

In MemoryCache

N/A Redis Redis, MemCached

Queue ActiveMQ RabbitMQ RabbitMQ, ActiveMQ

Storage/FileSystem

N/A N/A Swift, GlusterFS

App F/W N/ASpring Framework, Play Framework

Node.jsSpring Framework, Node.js, Vert.x

Language PHP, Python, Java, Ruby Java, Ruby Java, javascript, python

dPaaS 서비스와 SCARA의 PaaS 구성요소를 Add-on하여 차별화된 PaaS 서비스 제공


SCARA RoadMap - 2) SaaS Service VI. SCARA 향후 계획

SaaS가 풀어야 할 과제는 Scalability, Customization, Multi-Tenancy Efficiency 3가지 이며, SaaS 성숙도는 다중 테넌트 지원 용이성(multitenant efficiency), 다중 테넌트를 고려한 설정(configurability), 그리고 확장 용이성(scalability)으로 평가 할 수 있으며, SaaS 향 Scalability에 대한 연구가 필요

Level 명칭 내용 구성

Level 1Ad

Hoc/Custom

• 각 고객별로 별도의 애플리케이션 인스턴스를 제공하고커스터마이징하므로 관리가 복잡 (ASP와 유사)

• 각 고객별로 수정하게 되므로 운영 비용 증가폭이 상대적으로 높음

Level 2 Configurable

• 각 고객별로 동일한 애플리케이션 인스턴스를 별도 제공• 서비스 내의 설정으로 인스턴스별 커스터마이징이 가능• 공급자 는 대량의 애플리케이션 인스턴스들을 지원하기

위해서 충분한 하드웨어와 저장공간을 제공해야 함

Level 3Configurable, Multi-Tenant-

Efficient

• 모든 고객을 하나의 인스턴스로 지원하고 메타데이터를통해 커스터마이징을 제공

• 멀티테넌시를 고려한 인스턴스 설계/개발이 필요• 레벨 2에 비해서 공급자는 효율적인 자원관리 가능

Level 4

Scalable, Configurable, Multi-Tenant-Efficient

• 레벨 3의 구성과 부하분산 시스템(load-balanced farm)에서 모든 고객을 지원하는 가장 성숙한 모델

• 고객의 데이터의 isolation과 고객별 프로세스 isolation 등과 같은 대규모 Enterprise level의 성숙도 제공 가능


SCARA RoadMap - 3) Sharding Platform VI. SCARA 향후 계획

Sharding 유형은 크게 Application과 Middleware Sharding이 있고 Middleware Sharding 유형에는DBMS 종속형과 Customizing 개발 유형이 있으며 Customizing 개발에 대한 연구 진행 예정

유형 DBMS 종속형 Customizing 개발

개념DBMS 종속적이며 Proxy 형태로 Sharding 분기 처리

In-house 형태로 개발

사례

• MySQL 지원- Gizzard- Spock Proxy- MySQL-Spider

• MySQL/Cubrid/Oracle- Cubrid Shard

• SNS- Customizing Sharding

개발

장점

• DBMS의 자체 기능 지원Ex) 분산트랜잭션,

Replication 등• 개발공수가 적음

• DBMS 독립적• 프로젝트 환경에 따라

변경 가능• Multi-DB 환경 가능

단점

• DBMS 종속되어 다른 DB와 호환성 불가

• 플랫폼 확장 어려움

• 다양한 환경 검증 필요• 개발공수 필요• DBMS 특정기능의 사용

이 어려움

Sharding 유형 Middleware Sharding 유형



1. Scale-out을 위한 데이터베이스 기법의 개요

가. Scale-out 데이터베이스의 부각배경

- Cloud와 Big Data, IoT 등의 최신 기술의 발전으로 비즈니스 Needs에 쉽고 빠르게 탄력적으로 대응할

수 있는 IT 기술의 필요성 증대

- 솔루션 및 IT 서비스 상품의 Time-to-Market 및 불확실한 서비스의 미래에 대응할 수 있는 아키텍처

필요

나. Scale-out 관점에서 NoSQL과 RDBMS



1. Scale-out을 위한 데이터베이스 기법의 개요

다. RDBMS 관점에서의 Scale-out 핵심 기술 Query-Off Loading

구 분 개 념

Sharding

- 관계형 데이터베이스에서 대량의 데이터를 처리하기 위해서 데이터를 파티셔닝하는기술- 샤딩은 DBMS 레벨에서 데이터를 나누는 것이 아니고 데이터베이스 자체를 분할하는방식이며, 어플리케이션 레벨에서 구현해야 함

Query-Off Loading

- Read Transaction이 많은 경우 하나의 마스터 데이터베이스(Master DB)에Create/Update/Delete를 일으키고, 여러 개의 슬레이브 데이터베이스(Slave DB)에 데이터를 복사해 여러 개의 슬레이브 데이터베이스에서 읽기 관련 트랜잭션을 분산처리하여 대규모 처리를 가능하게 하는 기술



2. Scale-out을 위한 Sharding과 Query-Off Loading 기술

가. Sharding의 개념도

- 분리된 데이터베이스 인스턴스에 데이터를 분할하는 구조



2. Scale-out을 위한 Sharding과 Query-Off Loading 기술

나. Query-Off Loading 기술

- Master DB에는 쓰기(Update)만을 허용하고, Master DB의 내용을 중간의 Staging DB라는 곳으로복사한다. 이 Staging DB는 복제된 내용은 N개의 Slave DB로 복제

- Master Staging Slave DB로의 복제시 CDC (Change Data Capture) 기술을 이용- CDC 제품으로는 Oracle의 Golden Gate, Quest의 Share Flex가 있고, 오픈소스 제품으로는 Galera



3. Scale-out을 위한 Sharding과 Partitioning 차이점

가. 구성관점의 차이점




나. 기술관점의 차이점

구 분 Partitioning Sharding

개념도

물리적위치

- 같은 DBMS - 다른 DBMS

기법 - horizontal partitioning- horizontal partitioning- vertical partitioning

영향도 - Query에 영향 - Application Architecture에 영향

Scale-out측면

- DB 샤딩 + DB Partitioning 기술을 병행

http://1.bp.blogspot.com/-MalKoZTUdhM/UeaEhAFYsSI/AAAAAAAAABI/pItKp7lI9-w/s1600/Partitioning.png

http://1.bp.blogspot.com/-MalKoZTUdhM/UeaEhAFYsSI/AAAAAAAAABI/pItKp7lI9-w/s1600/Partitioning.png

http://3.bp.blogspot.com/-KE5asHoqwn4/UeaEsIp0OoI/AAAAAAAAABU/ppvNdrdG8SM/s1600/Sharding.png

http://3.bp.blogspot.com/-KE5asHoqwn4/UeaEsIp0OoI/AAAAAAAAABU/ppvNdrdG8SM/s1600/Sharding.png


구분 Gizzard Spock Proxy Cubrid Shard

Sharding rule 저장- DBMS Table(내부의 메타테이블에 저장)

- DBMS Table -설정파일

Shard key 생성 방법 - Modulo - Modulo/사용자 작성 코드

Shard key 찾는방법 - SQL 파싱 - HINT이용, 쿼리와 별도

장점

- 자체적으로 분산관리, 장애 복구기능- Twitter의 메인 DB솔루션(검증된 성능 및 기능)

-SQL변경 필요 없음-미들웨어이므로 아키텍처변경에도 유연함.

-CUBRID, MySQL, Oracle 다양한 DBMS 지원-미들웨어이므로 아키텍처의변경에도 유연함.

단점

- 완제품이 아닌 반제품 형태- DB스키마 변경시, gizzard의 내용도 수정 필요

- SQL 파싱 부담, 성능상의문제 발생할 우려- MySQL만 지원

- HINT 삽입에 따른 SQL 변경 필요(공수)

* 이외 MySQL fabric, Hscale 등은 현재 오픈소스 프로젝트가 alpha단계이며, 사용사례가 많지 않아 제외하였음.


다. 오픈소스 기반의 Sharding Platform 비교




4. Sharding 문제점 및 고려사항

구 분 문제점 및 고려사항

데이터 재분배- Sharding된 DB의 물리적인 용량한계나 성능한계에 다르면shard의 수를 늘리는 scale-up 작업이 필요하다. 서비스 정지 없이scale-up 할수 있도록 설계방향을 잡아야 함

데이터 조인- Sharding-db 간에 조인이 불가능 하기에 처음부터 역정규화를어느정도 감수

샤드에 데이터를파티션하는 방법

- shard 해쉬함수를 잘 설계

샤드간의 트랜잭션 문제- Global Transaction을 사용하면 shard DB간의 트랜잭션도 가능하지만 성능저하의 문제

Global Unique Key- DBMS 에서 제공하는 auto-increment를 사용하면 key가 중복될수 있기 때문에, application 레벨에서 Key 생성을 담당

데이터는 작게 - Table의 단위를 가능한 작게 만들어야 함



Netty는 유지보수성을 감안한 고성능 프로토콜 서버와 클라이언트를 빠르게 개발하기

위한 비동기 이벤트 중심의 네트워크 어플리케이션 프레임워크

특징

- 이벤트 기반이며 비동기 방식

- 과부하 및 Dos 방어 매커니즘 포함

- 다양한 컨테이너 지원(JbossMc, OSGi, Guice, Spring)

주요기능

- 이벤트 기반이고 비동기 방식으로 인해 성능이 좋고

리소스를 적게 사용함

- IO를 추상화한 레이어로 API를 제공함으로써 코드의

변경 없이 NIO, OIO, AIO를 바꿔가면서 사용할 수 있고

이벤트 모델과 쓰레드 모델이 잘 정의되어 있어 원하는

대로 사용 가능

제약사항

- 분산형 시스템에서 성능이 좋지 않음



- Lightweight, High performance application platform- Designed for modern mobile, web, and enterprise application- 이벤트 기반 프로그래밍 모델을 제공하는 서버 프레임워크

특징

• Polyglot: Java, JavaScript, Python, Ruby, Groovy, Scala, …

• Simplicity: Writing non-blocking network enabled applications with ease

• Scalability: messaging, Using non-blocking IO to serve many connections

주요기능• Run Loop (Event Loop)

• Single Threaded model

• Non-blocking

• Async. 모델

적용사례

- Facebook 등

제약사항

- 국내 사례 부족으로 Know-how 필요



Vert.x Java EE

• Run Loop (Event Loop)


• Non-blocking

• Async. 모델

• JRE 7 이상

• Polyglot

• Multiple Core per Process

• Thread per Request

• Multi-threaded model

• Blocking

• Sync. 모델

• Container가 많은 기능 제공

Node.js

• Run Loop (Event Loop)


• Non-blocking

• Async. 모델

• C 기반

• JavaScript

• Single Core per Process

scale-out application reference architecture...

Documents