[대규모 서비스 with Redis] - 1. 대규모 서비스의 특성

페이스북은 2012년기준 하루에 500TB 쌓이고 있음

bit.ly는 하루에 하루에 6천만 ~ 1억 500만의 클릭이 일어남.

 

🤔 우리가 만든 서비스도 이런 트래픽을 문제없이 견딜수가 있을까?

 

대규모 서비스의 특성

1. 확장성
   • 서버의 capacity, 갯수를 늘리고 줄이는게 쉬워야 한다.
   • 네이버, 카카오의 경우 하루에 수백개의 서버를 띄우거나 교체한다.
2. 장애회복성
   • 서버에 장애가 났을때 사람이 신경써서 서버를 빼고, 교체하고 이러면 안됨. 자동으로 서버를 빼고 사람은 그걸 보고 이렇게 해야함
3. 자동화
   • 즉 배포부터 장애처리까지 자동화가 되어있어야 한다.
   • 우리가 예상 가능한 부분 인프라를 배포한다던지, 이런것이 버튼클릭이나 스크립트 한번에 처리가 되어야 한다.
4. 모니터링
   • 가장중요함. 서비스 상태가 항상 모니터링 되어야 한다.

 

확장성

트래픽이 늘어나면 어떤 서버를 확장해야 할까?

• 웹서버 → 쉽게 추가 가능
• DB서버 → 이건 쉽게 추가하기 어려움

반대로 서버를 줄여야 한다면?

• 트래픽이 잘 안발생 하는 서버 같은 경우 나 잘 안쓰는 서버는 갯수를 3개에서 2개로 줄이고 이런것
• 서버의 추가나 제거는 어떻게 보면 똑같은 상황인데 제거가 더 어려움

 

장애 회복성

• 서비스 중인 API서버중에서 한두대가 장애나면 서비스는 계속 지속될수 있을까 고민해야한다.
• 서비스 데이터를 저장하는 DB서버가 장애넘ㄴ 서비스는 지속될수 있을끼?
• failover, replication 같은게 자동화 되어있어야 한다.

⇒ 장애 회복성을 위해서는 SPOF가 없어야 한다.

⇒ 싱글포인트오브펠류어 ⇒ 하나가 장애나면 전체 서비스가 장애나는 경우

⇒ 만약 DB가 에러나면??

⇒ 만약 인증서버가 에러나면??

⇒ 이런 DB나 인증같이 중요한 서버 말고도, API 로직에서 에러를 낸다면? ⇒ 로직적인 부분에서도 SPOF가 발생 할 수 도 있다.

 

 

API 서버나 DB서버를 한대씩만 띄우면 SPOF가 무조건 발생한다.

한대의 물리서버는 무조건 SPOF가 존재.

 

이외에도 Swicth, Route 등의 서버외에 하드웨어 부분에서도 SPOF가 발생 할 수 있다. 전용선이 끊기는 경우, 포크레인이 전봇대 건들여서

 

• Network 의 Bandwidth 한계가 정해져 있는데 이럴 경우 패킷드랍이 발생한다.⇒ 네트워크 capacity에 대해 알아야 한다.
• ⇒ retransmition이 계속 발생

⇒ 스위치 들도 이중화가 되어야 한다.

⇒ 스위치 여러개가 서버 몇개씩을 담당 하기도 함.

 

자동화

사람이 서버를 직접 올리고 내리고 이런 작업은 무조건 자동화가 되어야 한다.

콘솔에 들어가서 서버를 생성하고 로드벨런서 생성하고 이런 부분을 테라폼 같은 도구를 사용한다면 누구나 같은 형태로 만드는게 가능하다.

대기업에서는 인프라 팀의 도움이 꼭 필요하다.

그 뒤에 서비스의 설치는 개발팀이 한다던지 한다.

일부 기업에서는 이런부분을 API를 통해 준비하기 위해 Private-Cloud 를 사용한다.

OS의 기본적인 네트웩 설정 이외에 모든 설정은 스크립트 하나로 처리 되어야한다. → infra as a code (chef, puppet, ansible로 가능)

Cloud 서비스라면?

⇒ 인프라 구성까지도 자동화가 가능하다.

⇒ 이때 Terraform(← 제일 유명), Pulumi 사용

⇒ 이미지를 생성해서 Terraform으로 띄움

 

 

즉, 대규모 서비스에서는 SPOF를 최대한 제거하고 각 부분을 손쉽게 확장 할 수 있게 해야한다!