대용량 서비스를 위한 아키텍처 with Redis #0

Chapter 0. 대규모 서비스의 특성

대규모 서비스란?

• 많은 사용자 트래픽
• 많은 사용자 데이터
• 사용자 트래픽/데이터의 빠른 증가 (서비스 증가)

서비스 이용량 증가에 따른 문제점

스타트 업에서 서비스의 인기가 좋아, 트래픽이 감당할 수 없을 정도로 늘어난다면?

그로인해 몇일 동안 서비스가 안된다면 어떤 일이 벌어질까?

우리가 만드는 서비스는 트래픽/데이터의 증가에도 묹제없이 서비스가 가능할까?

대규모 서비스가 가져야 할 특성

• 확장성 (Elastic)
  • 서비스의 가용용량을 늘이고 줄이는 것이 쉬워야 함
• 장애 회복성 (Resiliency)
  • 서비스에 장애가 일어났을 때 가능한 메뉴얼한 처리 없이 자동적으로 회복되어야 함
• 자동화 (Automation)
  • 배포부터 장애처리 등 대부분 자동화 되어서 버튼 클릭 한 두번 정도로 진행되어야 함
• 모니터링 (Monitoring)
  • 서비스 상태는 항상 모니터링 되어야 함

확장성 (Elastic)

트래픽이 늘어나서 서버를 추가해야 한다면?

• 추가가 되어야 하는 서버의 종류는?
  • Web Server
  • DB Server
• 이런 종류의 서버들이 쉽게 추가 가능할까?

트래픽이 줄어서 서버를 줄여야 한다면?

• 제거가 되어야 하는 서버의 종류는?
  • 잘 안쓰는 서버
• 이런 종류의 서버들이 쉽게 제거될 수 있을까?

장애 회복성 (Resiliency)

• FailOver
• Replication

서비스 중인 API서버 한, 두대가 장애가 나면 서비스는 계속 지속될 수 있을까?

서비스 데이터를 저장하는 DB서버가 장애가 나면 서비스는 계속 지속될 수 있을까?

장애 회복성을 위해서는 SPOF(Single Point of Failure)가 없어져야 함.

• 해당 지점에 장애가 발생하면 전체 서비스에 장애를 낼 수 있는 부분
  • DB 서버가 장애가 발생하고, 해당 서버를 대체할 서버가 없으면 서비스의 동작에 문제가 생김
  • 인증 서버에 장애가 발생하면 인증이 불가능하여 서비스 이용이 불가능
  • 한대의 물리 서버는 무조건 SPOF가 존재
    • SPOF를 제거 하려면 모든 부분에서 최소 이중화가 되어야 함

자동화 (Automation)

서비스 운영의 많은 부분이 자동화가 되어야 함

• 사람이 손으로 직접 건드리는 것은 도리어 새로운 장애의 씨앗이 됨 (Human Error)

IaC(Infrastructure as code)가 중요함