20180325 읽어보기 : 신입사원을 위한 웹서비스 확장전략

• 신입사원을 위한 웹서비스 확장 전략

읽어보기.

[ 2018. 04. 14 ~ 2018 04. 21 ]

대규모 서비스 특성

• Elastic 
• Resiliency 

탄력적어야 한다. 

• 트래픽이나 상황에 따라서 서버의 추가 / 제거가 쉬워야 한다.
• 특정 장비의 장애 등은 자동으로 복구가 되어야 한다.
• 특정 장비의 장애로 인해 다른 쪽은 영향을 받지 않아야 한다.

두가지 경우를 확인할 수 있다.

Scale Up & Scale Out

Scale Up

초당 1000 TPS 를 초당 3000 TPS 로 바꾸기 위해서 3배 처리 가능한 서버를 투입한다. 서버의 Scale Up 을 시행한다. 

TPS (Transaction Per Second)

용어는 "Transaction Per Second" 의 약자로 초당 트랜잭션의 수이다. Oracle 에서 한 트랜잭션을 commit 과 rollback 의 수로 나타낸다면 초당 commit & rollback이 일어나는 횟수이다.

1. 하나의 요청이 10개의 쿼리를 실행시키며, 각 쿼리는 평균 실행시간이 50ms 라고 가정하자.
2. 10개의 쿼리를 실행시키면 500ms 가 걸린다. 결국 하나의 요청에 대한 응답까지 걸리는 시간은 500ms이다.

이 가정에서 커넥션 풀에 이용 가능한 idle 상태의 커넥션이 5개인 상황이라면 동시에 5개의 요청을 500ms동안 처리 가능한 것이다. 1초라 하면 10개의 요청의 처리가 가능하다. 따라서 성능 지수는 10TPS 가 된다.

참고 : http://egloos.zum.com/dkworld1234/v/2042040

Scale Out

초당 1000 TPS 의 성능을 가진 서버를 3개 투입한다.

SPOF (Single Point Of Failure)

여기서 장애가 나면 서비스 전체를 마비시키는 병목지점이 된다.

• 왼쪽 그림처럼 한 대의 물리서버가 망가지면 전체 서비스를 이용못하게 될 것이다.

• 오른쪽 그림처럼 서버를 따로 두었다고 하더라도 둘 중 하나의 서버가 망가지면 클라이언트는 서비스를 이용하지 못한다.

Name Service : DNS 방식을 이용한다. 하나의 도메인에 매핑되는 IP들을 여러개 두어서 관리하는 모습이 있다. 

Name Service : LB 방식도 존재한다. (Load Balancing)

무엇을 확장해야 하는가?

DB Server vs API Server

• API 서버에만 부하가 많은 작업들은 어떤 것이 있는가?

• 파일 IO가 많은, 정적 파일 서빙

• 웹 스크래핑과 같은 디비 작업 자체보다는 다른 작업이 많은 녀석

• 독립적인 작업이 가능한데, CPU나 다른 작업이 많이 필요한 것들 (게임서버)

• 이미지의 영상 인식과 전처리

• DB 서버에서만 부하가 많은 작업들은 어떤 것이 있는가?
• 카톡방의 대화
• 페이스북의 글, 댓글, 친구관계
• 유튜브에 올라가는 비디오나 댓글 등

state vs stateless

state 는 각각의 api 서버가 개별적인 스토리지를 가지고 있는 경우

stateless 는 각각의 api 서버가 하나의  스토리지를 참조하는 경우

• stateless 한 서버를 사용한 경우,
• 장점
  (1) 추가 / 삭제가 간단함
  (2) 사용하는 쪽에서 주소만 추가하거나 제거하는 걸로 가능
  (3) Or 로드밸런서에 추가하거나 제거하기만 하면 OK
• 단점
  (1) 결국 데이터의 저장이 필요하므로 뒤에(스토리지) 책임을 떠 넘기는 구조
  (2) 개별 성능은 state 한 경우보다 떨어진다.
• 왜 stateless 인가?
  (1) stateless 한 서버에 신경을 쓰지 말고,
  (2) 중요한 DB(storage) 쪽에 집중을 하는게 더 좋다라는 판단
  (3) 두 마리 토끼를 다 쫓지 말고 한 놈만(DB) 팬다

여기까지 읽기. 

그 이후의 내용은 다시 읽기