웹 서비스를 확장하기 위해 알아야 할 것

대규모 서비스의 특성

• Elastic : 트래픽이나 상황에 따라서 서버의 추가 / 제거가 쉬워야 합니다.

• Resiliency : 특정 장비의 장애 등은 자동으로 복구되어야 합니다.

• 서버가 복구되는 것은 아닙니다.

• 해당 장비의 장애로 인해 다른 쪽이 영향 받지 않아야 합니다.

• Scale Up : 초당 1000 TPS 처리가 가능했다가 초당 3000 TPS 처리를 감당해야 한다면 3배(3000 TPS) 처리가 가능한 서버 1대로 교체 투입합니다.

• Scale Out : 초당 1000 TPS 처리가 가능한 서버를 3대 투입합니다.

SPOF (Single Point Of Failure) 을 방지해야 합니다.

• 장애가 나면 서비스 전체를 마비시키는 병목 지점

• 

  
  

• 

  
  

어디를 확장해야 할까?

• API 서버에만 부하가 몰리는 작업은 어떤 것들이 있을까

• 파일 IO가 많은, 정적 파일 Serving

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

• 독립적인 작업이 가능하지만 CPU나 다른 작업이 많이 필요한 게임 서버

• 이미지의 영상 인식

• DB 서버의 경우

• 카톡방의 대화

• 페이스북의 글, 댓글, 친구 관계

• 유튜브 등에 올라가는 비디오나 댓글

• 생각보다 우리가 아는 대부분이 DB 서버에 부하를 준다.

State & Stateless

• 

  
  

• 

  
  

Stateless 한 서버의 경우

• 장점

• 추가 / 삭제가 간단하다.

• 사용하는 쪽에서 주소만 추가하거나 제거하는 걸로 가능

• Or LB에 추가하거나 제거하기만 하면 OK

• 단점

• 결국 데이터의 저장이 필요하므로 뒤에 책임을 떠넘기는 구조

• 개별 성능은 Stateful한 경우보다 떨어질 수 있음

그런데 왜 Stateless 인가

• Stateless한 서버에 신경을 쓰지 말고 중요한 DB(Storage) 쪽에 집중을 하는게 더 좋다라는 판단.

일반적인 DB 서버의 부하

• 

  
  

• 

  
  

이미지 출처 : 강대명님(CHARSYAM@naver.com) 발표 자료