> For the complete documentation index, see [llms.txt](https://incheol-jung.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://incheol-jung.gitbook.io/docs/q-and-a/seminar/2022-infcon/102-0.md).

# \[102호] 서버비 0원, 클라우드 큐 도입으로 해냈습니다!

{% hint style="info" %}
💡 By 조현영 카카오모빌리티

열심히 서버를 만들어 출시한 여러분, 기대 반 걱정 반으로 서버가 잘 돌아가는지 지켜보고 계실 겁니다. 조금씩 이용자가 늘다 보면 어느새 서버 수용량에 한계가 오기 시작하고, 여러분은 서버를 스케일업 할지 스케일아웃 할지 고민하실 텐데요. 주니어 서버 개발자들은 여기서 한 가지 선택지가 더 있다는 걸 잘 모르는 경우가 많습니다. 바로 간단한 큐 서버의 활용입니다.

오늘의픽업 CTO로 있으면서 서버 비용을 최소화하여 운영한 노하우를 공개합니다. 큐 서버 도입이 장점만 있는 것은 아니라 도입 시 주의할 점과 생각해야 할 점도 알려드립니다.
{% endhint %}

### Q. 큐를 도입한 이유는 무엇인가?

<figure><img src="/files/021xAL5rVFOUaOWGEH3d" alt=""><figcaption></figcaption></figure>

* 어드민 서버가 장애가 나면 접수를 못 받음
* 앱 서버가 터지면 배송완료 처리가 안됨
* 불안감이 있었다.. → 찜찜하지만 그냥 넘어갔다..
* 실제로 어드민 서버가 터졌다..
  * 엑셀 업로드 - 엑셀 메모리가 어마어마…
    * 임시방편 : 엑셀을 개발자들한테 전닳해서 데이터를 포워딩함(개발서버 활용)
  * 배송 중에 서버가 터지면 다음 배송 진행이 안됨..ㅜ
* 서비스 특성상 그날의 문제는 그날 해결했어야 했다..(에러가 안나게 하는게 제일 좋긴 하지만..ㅜ)
* 새벽에도 서버 터지고.. 주말에도 터지고..ㅜㅜㅜ
* 해결 방법..?
  1. 스케일 업 : 스몰 → 미듐 → 라지(트래픽 분포를 봤지만 시간별로 유동적임.. 아침,점심 시간에만 효과적이다..)
  2. 스케일 아웃 : 서버를 여러대 늘려간다..(그래도 서버가 터진다..ㅜ)
     1. 오토스케일링 원리 : CPU나 메모리가 70%이상이면 서버 대수 1개씩 늘림,, 반대로 30% 미만이면 1대씩 줄임(알아서 조절되니 편리, 트래픽 변화 대응 가능)
     2. 그러나 트래픽이 한번에 100%가 되면.. 이미 장애가 나버리고 연달아서 장애가 나게 됨..
* 장애를 겪으면서 발견한 점
  * 나는 나를 믿을 수가 없다
  * 돈도 없다
  * 누가 중간에서 천천히 보내줬으면 좋겠다..
* 그럼 답을 찾아보자

  * 그럼 누구를 믿을 수 있나? → 나보다는 AWS(99.? % 장애 복구 보장)
  * 돈이 안 드는게 있나? → 클라우드 큐?
  * 중간에서 천천히 보내줄 수 있는게 있나? → 클라우드 큐?

  <figure><img src="/files/Jju0TboJQqFZvvTLgrVa" alt=""><figcaption></figcaption></figure>

### Q. 큐를 도입하면서 개선된 부분은 어느게 있는가?

<figure><img src="/files/xrZgQiVh52twS7Cqmb8h" alt=""><figcaption></figcaption></figure>

* SQS는 JSON 데이터를 저장한다
* 데이터를 어떻게 쓸지는 자유다
* 어드민 서버가 데이터를 받아서 쓴다
* 큐당 데이터 12만건 제한 → 두개 만들어서 24만건 쓰면 된다

<figure><img src="/files/GzsySLhFzanyaFAL7iyQ" alt=""><figcaption></figcaption></figure>

* 서버 에러나면 거래처가 다시 올려줘야 함..(본의 아니게 민폐)
* SQS 도입후 처리 실패시 데드레터큐로 보냄..(실패건은 데드레터큐로 확인)

<figure><img src="/files/U8ApDbTxMGBSy2KUmeAi" alt=""><figcaption></figcaption></figure>

### Q. 큐 도입시 주의해야 할 점은 무엇이 있을까?

* Pub/Sub을 쓰면 안되나?
  * 다수에게 받아서 다수에게 전달…?
* 클라우드 큐 꼭 안써도 된다
  * 서버에 남는 코어가 있다면 그 코어를 활용해 큐 서버를 띄우면 됨
* 서버를 한 대 띄울 수 있다면..?
  * 래빗앰큐, 카크카 등을 설치해 메시지 큐 서버로 활용하면 됨
  * 우리가 만든건 장애가 발생할수 있다는걸 꼭 명심해라
* 언제 쓰면 좋을까?
  * 특정 기능만 부하가 몰릴 때
  * 특정 시간에만 부하가 몰릴 때
  * 갑작스럽게 몰려서 오토스테일링이 안 될 때..
* 서버 구조상의 문제
  * 서버 전반적으로 부하가 증가할 때는 스케일업, 스케일아웃과 같이 할것
  * 대기열이 생기므로 느릴수 있다
  * 클라우드 큐 서비스면 매우 낮은 확률로 장애 발생
* 큐 자체의 문제
  * 하나씩 받아서 처리하므로 전체 개수가 몇 개인지 파악 어려움..(한 시간 단위로 전체 갯수를 파악)
  * GCP로 전환할때 서비스 종속성 문제때문에 이슈가 있을 수 있다..