[인프콘2022] 서버비 0원, 클라우드 큐 도입 - 조현영

1. 오늘의 픽업 서비스

• 오후 2시까지 주문하는 그날 자정까지 배송해주는 당일 배송 서비스 (새벽배송도 함)
• 주요 고객사 - 젝시믹스, 휠라, 삼성물산, 공구우먼, 발란, 알라딘 등
• 퀵 > 당일배송 > 택배

2. 오늘의픽업 기술 스택

현재 AWS but, 카카오가 GCP라서 옮기는 작업중;

서버는 크게 2가지 : 어드민서버, 앱서버

3. 오늘의픽업 프로세스

실제로는 어드민 서버가 더 많은 일을 한다~.

 

4. 문제 발생

(1) 2가지 불안감

1. 어드민 서버 터지는 경우

고객사에게 데이터를 엑셀로 받는 경우

-> json형태로 변환 후 DB에 넣을 객체를 생성한다 → 메모리 폭발

 

2. 앱 서버 터지는 경우

 

만약 10건 중 3건 완료한 상태인데 서버가 터지면

남은 7건 배송이 불가 또는 익일배송으로 처리가 늦어지게 된다

(2) 문제 정리

그 날의 문제는 그 날 해결해야 한다. 최대 1시간 내에

접수가 늦어지면 → 그 뒤 모든게 늦어진다.

라이더 형님들이 무서워서 → 배송이 안된다는 연락이 너무 무서웠다고 한다 ㅋㅎ

 

5. 해결방안 물색

1. 스케일 업
   1. 돈이 없다 ^^;
2. 스케일 아웃
   1. 작은 서버 1대를 2대로 늘리기 —→ 더 많이 늘려보기
   2. 오토스케일링
      1. CPU가 메모리 70% 이상이면 서버 대수 1개 씩 늘린다, 반대로 30% 미만이면 1대씩 줄임
      2. 알아서 조절되어 편리하다/ 트래픽 변화 대응 가능
      3. 하지만 함정이 있었다
         1. 트래픽이 한방에 몰리면 바로, CPU 메모리를 100%으로 만들어버린다
         2. 오토스케일링이 성립하려면, 새로운 서버가 뜰 때까지 기존 서버가 버텨줘야 한다.
         3. 100%인 경우 즉 트래픽한방에몰린경우,
         4. 1개가 터지면 다음 서버로 넘어가니까 또 못버텨서 터지고 또 넘어간 다음 서버가 터지고 ;;;;;
3. 클라우드 큐 -> AWS SQS
   큐란 ?

{
고객명: 김보현,
거래처: 김보현컴퍼니,
주소: 실리콘밸리,
전화번호: 010-1234-5678,
}

• 행동이 들어있는 게 아니라 데이터만 들어있음
  • 이 데이터를 어떻게 쓸지는 자유
  • 어드민 서버가 데이터를 받아서 씀
  • 큐당 데이터 12만건 제한 (응, 하나더 만들면 그만이야)

접수 단계

1. 거래처
2. 받은 엑셀 → S3
3. 엑셀 파싱 (엑셀→json) → Lambda
4. json 하나씩 등록 → SQS
5. 어드민 서버가 SQS에 있는 json을 가져온다

장점 :

어드민 서버가 감당가능한 접수건 2000건이리고 하면 , 그 이상 오는 경우는 감당이 불가했다

하지만 큐를 사용하면, 2000건 으로 잘라서 여러번 가져오면 된다

두번째 장점 :

현재 어드민서버부하가 터지면 거래처가 다시 접수데이터를 보내줘야 한다.

하지만 SQS 사용할 경우 처리실패시, 데드레터큐로 보낸다 + 실패건을 제외하고는 업로드 성공

**cloud task 인 경우**

SQS 대신 Task에 등록한다.

Task 의 장점 : 보내는 속도를 조절할 수 있다. 어드민 서버에 데이터를 보내는 속도를 조절해서 push

언제 쓰면 좋을까?

1. 특정 기능만 부하가 몰릴 경우
2. 특정 시간에만 부하가 몰릴 경우
3. 갑작스럽게 몰려, 오토스케일링 서버 100%되는 경우

Pub/Sub 써도 된다

pub/sub 이란?

다수(거래처들)로부터 메세지를 받아서 다수(어드민 여러서버)에게 전달

Pub/Sub란 무엇인가요? | Cloud Pub/Sub 문서 | Google Cloud

ex) 다수 서버에게 동시에 전달하면,

거래처 1건이 여러 서버에 전달이 될 수 있다.

한명만 받고 어느 정도 큐를 쌓아준다면 가능!

안 써도 되는 경우

1. 서버에 남는 코어가 있는 경우하지만, 큐 서버 부하 높으면 기존 서버 악영향 끼칠 수 있음
2. 코어를 활용해 큐 서버를 띄우면 됨
3. 서버를 한 대 더 띄울 수 있는 경우(나 자신을 믿지 말라)
   • 그 서버에 rabbitMQ, Kafka 등을 설치해 메시지 큐 서버로 활용하면 됨
   • 이서버가SPoF가될수있음에주의
4. 하지만, 직접 설계한 서버 즉 클라우드가 아닌 사람이 설계한 서버는 문제가 있을 수 있음

주의할 점

1. 서버 구조상의 문제중간에 큐라는게 추가되었기 때문에 느려진다.
2. 큐 서버가 고장날 수 있음 → 클라우드 큐 서비스는 매우 낮은 확률
3. → 접수 1건에 따라 바로 처리가 되었다면 이제는 남의 것까지 처리되는 것까지 기다려야할 수 있음
4. 서버 전반적으로 부하가 증가할 때, 스케일업/아웃 과 같이 할 것
5. 큐 단점
   하나씩 받아서 처리하므로 전체 개수가 몇 개인지 파악 어려움
   거래처의 접수가 다 끝난 것인지 알려주기 어렵다