날로 먹는

Scalable 이야기!

charsyam@naver.com

발표자 소개! 나! 이런 사람이야~

• 이름 : 강대명

• 성별: 남!

• 직업: 아키텍트를 꿈꾸는 프로그래머

• 직장: NHN( 6개월된 잉여 서버 개발자 )

• 특기: 스터디 발표 날로 먹기!

Topic: 이야기 거리

Scalable

Scale UP Vs

Scale OUT

Scale UP

초당 1000 TPS

초당 3000 TPS

3배 처리 가능한 서버를 투입

Scale OUT

초당 1000 TPS

초당 2000 TPS

초당 3000 TPS

What is Better?

Depends on

Depends on

구입 가격

Depends on

구입 가격

관리/유지비

rchitecture

Distribution Transparency

Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다.

Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다.

Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다.

Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다.

Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다

Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다.

Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.

Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다.

Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다.

Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다.

Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다.

Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다

Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다.

Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.

Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다.

Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다.

Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다.

Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다.

Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다

Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다.

Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.

Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다.

Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다.

Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다.

Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다.

Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다

Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다.

Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.

Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다.

Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다.

Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다.

Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다.

Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다

Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다.

Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.

Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다.

Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다.

Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다.

Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다.

Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다

Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다.

Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.

Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다.

Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다.

Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다.

Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다.

Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다

Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다.

Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.

Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다.

Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다.

Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다.

Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다.

Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다

Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다.

Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.

ifficult!!!

Use

Framework

3 Things +1

3 Things Gearman Memcached

MySQL Scale Out

GEARMAN

Queue Service

Job Server +

Multi platform Multi Language

Gearman Flow

Gearman Cluster

GEARMAN

MANAGER

Gearman Cluster

한대가 오류가 나더라도 다른 서버로 접근 단, addserver 로 추가해줘야 한다.

Gearman Dynamic

Gearman A,B 서비스

Client A 요청

Worker A 등록

작업처리 결과 전송

Gearman Dynamic 2

Gearman A,B 서비스

Client A 요청

A 대기

Worker A 등록

작업처리 결과 전송

Gearman Map/Reduce Client

Gearman Job Server

Map/Reduce Worker

Client Client Client

Gearman Job Server

Worker Worker Worker

Who Use Gearman!

Digg: 45+ Server, 400K Jobs/day Yahoo: 120+ Server, 12M jobs/day

Apply Cache Server

Perfomance UP

Client

Server

Cache Layer

Client Client

DBMS

Write

Update

MEMCACHED

NoSQL Key-Value Store

Atomic Operation

Who use Memcached? • Facebook and Google and Many Companies

• Facebook – 현재 가입자 수 6억명

– 활성 사용자 7,000만

– 사용자 증가 비율 4일에 100만명

– Web 서버 10,000 대, Web Request 초당 2000만번

– Memcached 서버 805대 -> 15TB, HitRate: 95%

– Mysq server 1,800 대 Master/Slave(각각, 900대)

• Mem: 25TB, SQL Query 초당 50만번

SERVER

Client

CACHE

CACHE 이용의 2가지 모델: 1

Client

CACHE 이용의 2가지 모델: 2

SERVER

CACHE

No, Free Lunch No, Silver Bullet

1G MEM vs 4G MEM

Appling Scale Out On

Memcached Server

Distributed Memcached Server

Proxy : Key Management

Memcached Server

Memcached Server

Memcached Server

Client

NorthScale Project

MySQL Scale Out

Default Architecture

Client

Master

Slave

REPLICATION/FailOver

One Write Master

+ Multi Read Slave

Client

Master

Slave

ONLY WRITE

Slave Slave

REPLICATION

Only READ

Partitioning

Why? Partitioning

Client

PART 1

Web Server

DBMS

PART 2

Web Server

DBMS

Scalable Partitioning

추가로 고민하면 좋은거?

Elastic!!!

Thank You!

권장 도서