- Elastic : 트래픽이나 상황에 따라서 서버의 추가 / 제거가 쉬워야 합니다.
- Resiliency : 특정 장비의 장애 등은 자동으로 복구되어야 합니다.
- 서버가 복구되는 것은 아닙니다.
- 해당 장비의 장애로 인해 다른 쪽이 영향 받지 않아야 합니다.
- Scale Up : 초당 1000 TPS 처리가 가능했다가 초당 3000 TPS 처리를 감당해야 한다면
3배(3000 TPS) 처리가 가능한 서버 1대로 교체 투입합니다. - Scale Out : 초당 1000 TPS 처리가 가능한 서버를 3대 투입합니다.
- 장애가 나면 서비스 전체를 마비시키는 병목 지점
-
API 서버에만 부하가 몰리는 작업은 어떤 것들이 있을까
- 파일 IO가 많은, 정적 파일 Serving
- 웹 스크래핑과 같은 DB 작업 자체보다는 다른 작업이 많은 녀석들
- 독립적인 작업이 가능하지만 CPU나 다른 작업이 많이 필요한 게임 서버
- 이미지의 영상 인식
-
DB 서버의 경우
- 카톡방의 대화
- 페이스북의 글, 댓글, 친구 관계
- 유튜브 등에 올라가는 비디오나 댓글
- 생각보다 우리가 아는 대부분이 DB 서버에 부하를 줍니다..
장점
- 추가 / 삭제가 간단합니다.
- 사용하는 쪽에서 주소만 추가하거나 제거하는 걸로 가능합니다.
- Or LB에 추가하거나 제거하기만 하면 OK
단점
- 결국 데이터의 저장이 필요하므로 뒤에 책임을 떠넘기는 구조입니다.
- 개별 성능은 Stateful한 경우보다 떨어질 수 있습니다.
- Stateless한 서버에 신경을 쓰지 말고 중요한 DB(Storage) 쪽에 집중을 하는게 더 좋다라는 판단이 있기 때문입니다.
