Internet Scale Service Arichitecture

Post on 21-Jan-2018

1.616 views 0 download

Transcript of Internet Scale Service Arichitecture

Internet Scale Service강대명 (CHARSYAM@NAVER.COM)

WHO AM I?

Udemy Data Engineer

Kakao Story-Senior Backend Engineer

Naver Mail-Senior Backend Engineer

Internet Scale Service

Internet Scale Service

Massive Trafific

Huge Users/Data

Many IDC(or Regions)

Origin

James Hamilton - AWS Vice President

Paper

On Designing and Deploying Internet-Scale Services

https://www.usenix.org/legacy/event/lisa07/tech/full_papers/hamilton/hamilton_html/

Internet Scale Service

실제적으로는 하드웨어/소프트웨어인프라 전반에관한 이야기

Check List

https://gist.github.com/acolyer/95ef23802803cb8b4eb5

질문 #1!!!

우리의 서비스는 어떻게 구성되었나요?

질문 #2!!!

우리의 서비스는 Elastic 한가요?

Elastic

Scaling

Resiliency

SPOFSingle Point Of Failure

SPOF

API Server

DB Server

한대의 물리 서버

SPOF

API Server

DB Server

한대의 물리 서버

SPOF

API Server DB ServerClientClientClient

SPOF

API Server DB ServerClientClientClient

SPOF

API Server DB ServerClientClientClient

SPOF

ClientClientClientAPI

Server

API Server

API Server

MasterDB

SlaveDB

Name Service - DNS

ClientClientClientAPI

Server

API Server

API Server

MasterDB

SlaveDB

DNS Query Result

Domain IP

www.naver.com 125.209.222.142

202.179.177.21

www.google.com 203.233.96.58

203.233.96.57

203.233.96.56

DNS로만한다면서버가 죽었을땐?

(DNS TTL?)

Name Service - LB

ClientClientClientAPI

Server

API Server

API Server

LB

MasterDB

SlaveDB

StatelessShared Nothing

Stateless

Stateless 하지 않다면?

ClientClientClientAPI

Server

API Server

API Server

LB

MasterDB

SlaveDB

Stateless 하지 않으면?

부하가많아서 서버를 늘렸는데…

기존 사용자가 새 서버를 이용할 수 있을까?

부하가 없어서 서버를 줄였는데…

기존 사용자가 없는 서버를 찾는다면?

Sticky Session?

Stateless 의장단점

장점

추가/제거가쉽다

단점

결국 Stateful 한서비스에의존하게된다.(조삼모사)

크고 안정적인 Stateful 서비스가 필요하다.

관리를 여기에 집중한다.(DB/Cache)

API 서버 -> Stateless그럼 DB 단은?

Shared Nothing

일반적인 DB 서버의 부하

200 writes/s

800 reads/s Read > Write

읽기 분배 - Query OffWEB/AS

Master

Slave

ONLY WRITE

Slave Slave

Only READ

REPLICATION

읽기 분배 - Query Off

200 writes/s

800 reads/s

200 writes/s

400 reads/s

200 writes/s

400 reads/s

Read/1 Server Read/2 Server

Slave 장비를 추가하면계속 성능이 증가할까?

읽기 분산의한계

700 writes/s

50reads/s

700 writes/s

50reads/s

700 writes/s

50reads/s

700 writes/s

50reads/s

700 writes/s

50reads/s

Write Heavy Situation

DatabasePartitioning

Vertical Partitioning

Horizontal Partitioning

ShardingHorizontal Partitioning

특정 Key 를 어디에저장할 것인가?

특정 Key 를 저장하는 방법

특정 Key 를 찾는 방법

특정 Key를 찾는 방법

특정 유저의 데이터는 어디에 있을까?

특정 모텔 정보는 어디에 있을까?

Range

특정 범위대역으로 나누기

젤 쉬움

Server #1 Server #2 Server #3

User #1 ~ 100 User #101 ~ 200 User #201 ~ 300

Range

특정 서버가 놀거나 부하가 몰릴 가능성이 가장 큼

가입 이벤트, 1~2주후 유저 잔존률이 얼마나 될까?

Modular

서버 대수로 나누기

Server #1 Server #2

User #0 User #1

User #2 User #3

Modular

여기서 서버가한대가 추가되면 무슨 난리가…

데이터가 모두 섞여야 한다.

Server #1 Server #2

User #0 User #1

User #3 User #4

Server #2

User #2

User #5

Modular

두배로 늘리기

1에서는 3으로 절반이, 2에서는 4로 절반이 이동

Server #1 Server #2

User #0 User #1

Server #3 Server #4

User #2 User #3

User #4 User #5 User #6 User #7

Modular

이미 서버가한 16대쯤 있다면?

다음에 늘려야 할 서버 대수는

Indexed

특정 데이터의 위치를 가리키는 서버가 존재

Server #1 Server #2 Server #3

User #1

IndexUser #1 -> 3

User #100 -> 1

User #102 -> 1

User #100

User #102

Indexed

Index 서버에 부하가 몰아치면?

Index 서버가장애나면?

Complexed

위의 방식들을잘~~~알 조합해보자.

Complexed

Master

Index

User RANGE #1 -> 1

Slave Slave

Master

Slave Slave

Master

Slave Slave

ONLY WRITE

ONLY READ

User RANGE #10 -> 1

User RANGE #20 -> 3

KEY 설계를어떻게할 것인가?

키만 보고 어떤 서버에서찾아야할지

알 수 있지않을까?

Pinterest 의 ID

Twitter의 ID

Instagram 의 ID

MongoDB 의 ID

보통 Shard ID 가 들어감

시간 정보가 들어가면 ID 만으로 시간 정렬이 가능

뭔가 변화하지않을 특별한 정보가 있다면 ID에들어가 있으면 좋음.

Load Balancing

Client Side VS Server Side

Client Side

ClientClient예약Server

결제Server

결제Server

결제Server

예약 서버가 결제 서버를 호출한다고 하면?

1

2

3

Server Side

ClientClient예약Server

결제Server

결제Server

결제Server

예약 서버가 결제 서버를 호출한다고 하면?

ProxyLB

Coordinator

Zookeeper

Etcd

Consul

Eureka

Zookeeper Data Model

그냥디렉토리

Zookeeper 의 특징절대로 죽지않는다.(거짓말)

잘안죽는다.(몇대 죽어도 상관은 없다.)

그러나 다 죽을때도 종종 있음.

임시 노드의 경우, Health Check를 통해서 자동적으로 접속된 노드가 사라지면 데이터가 사라진다.(30초가 기본…)Cluster Membership

노드의 순서를 보장해준다.Leader Election

Leader ElectionNaming Service

Cluster Membership

Cluster MembershipCases

API Server 가 추가/변경 되었다.

Database Master 장비가 추가/변경되었다.

Cache 장비가 추가/변경 되었다.

우리의 대응은?목록을 추가하고, 배포해야 합니다.

목록만 추가하면 알아서 동작합니다.

장비만 추가하면 알아서 동작합니다.

ZookeeperEphemeral Node

서버와의 연결이 끊어지면노드 정보도 사라짐

해당 노드의 Child 정보만읽어와서 접속하면목록관리 가능

Name Service 도유사하게 구현 가능

Configuration

Feature Flag

새로 나간 기능을 어떻게 제어할 수 있을까요?

대응 방법

기능 설정 후 재배포?

클라이언트는?

그냥 설정을 동적으로 바꾸는 방법은?

Watch 기능을 이용!!!

Leader Election

여러 대의 서버 중에서한대만 그 일을하게 하고 싶을 때(or 분산 Lock)

Hell of Health Check

ClientClient예약Server

Health Check가 죽으면?

HealthCheck

Hell of Health Check

ClientClient예약Server

무한 Health Check

HealthCheck

HealthCheck2

HealthCheck3

HealthCheck N

그런데 여러 개를 띄우면…알람이 동시에 여러 개가…

Leader 만일해라.

ClientClient예약Server

Leader 만 동작한다.

HealthCheck

HealthCheck

HealthCheck

Leader Election

클라이언트들 간의 약속으로 정해둠.

Circuit Breaker

한화면을 구성하는데몇 개의 API가 필요할까요?

그 중에하나라도 실패하면?

필수적인 APIVS

필수적이지 않은 API

Circuit Breaker

필수적이지 않은 API가장애 중

매번 호출할때마다, 시간이 많이 걸림

장애 난 API 응답을 그냥 디폴트로 처리하면 안될까?

매번 찌르는 것도 손해…

Fast Fail Backand Background Check

Netflix Hystrix

Deployment

Blue-GreenDeployment

Netflix

Blue-Green

Blue-Green DeploymentBlue Set 과 Green Set이 존재.

현재 Blue Set으로 서비스 중이라면, 같은 양의 Green을준비해서 Green Set에 새로운 버전을 배포…

일부 트래픽을 Green Set에 투입해서 테스트…

정상적이면, Blue Set을 바라보는 설정을 모두 Green을바라보도록 수정

문제가 있다면, Blue Set으로 롤백

문제가 없다면, Blue Set 제거

Blue-Green 는 쉬운가?

같은 수의장비를 쉽게 준비할 수 있을까?

Cloud 라면 손쉬움(두 벌을 유지하는 시간이음.)

IDC 라면 어떻게?

예전에 모 B사의 W모 게임이 그렇게 했다고합니다.(거기는 부자니…)

Blue-Green 싸게 도입하기

점검 기간 두기

4대 보검중에하나, 정기정검(게임쪽)

무정지 서비스가 안됨

Rolling Update

한대씩 로드밸런서나 설정에서 제거 후 배포

백업이나 배포 자체가 느릴 수 밖에 없음.

Blue-Green 싸게 도입하기

리소스를 제한해서한 서버에서 두 개의 프로세스 실행

Port 10000, 20000 번으로배포.

Nginx 나 Proxy 단에서 설정 변경으로 새로운 서버로전환

리소스를 적절하게나누지 못하면 리소스 부족으로 서버장애발생가능

Blue-Green 야매 버전

ClientClientClientClientLB

Proxy

API : 10000

API : 20000

DB

Blue-Green 야매 버전

ClientClientClientClientLB

Proxy

API : 10000

API : 20000

DB

Blue-Green 야매 버전

ClientClientClientClientLB

Proxy

API : 10000

API : 20000

DB

Blue-Green 야매 버전

ClientClientClientClientLB

Proxy

API : 10000

API : 20000

DB

Location Latency?

서울 부산 IDC의 Latency

Seoul Busan

API Server DB ServerLatency3 ~ 7ms

같은 지역의 DB를 사용할 때는20~30ms 정도

API Server의 호출은최저 300ms

What Happen?

Location Latency #1

Seoul Busan

DB Server

Select * from postswhere id=123;

results

Select member from memberswhere id=poster.group;

results

API Server

Logic Server

Location Latency #2

Seoul Busan

API ServerDB Server

getMembersList()

results

Logic Server

그런데…

서비스가잘 돌아가는 건어떻게 알 수 있을까요?

모니터링/로그

결론

Internet Scale의 서비스를 만들기 위한 방법을 이해한다.

Kubernetes 나 Mesos 등등을 적용하면 직접 하는 것 보다 더손쉽게 가능하기도(이건 저도 잘 모름)

Rolling Update, 자동재시작 이런것들을 처리해주는…

모니터링/로그는 더더욱 중요합니다.

Thank you.