오늘의 픽업 서비스

  • 크게 어드민(접수), 앱(배송) 2가지 서버 운영

→ 접수 과정에서 거래처의 엑셀 데이터가 많은 경우, 어드민 서버 메모리 사용량 증가로 장애 발생

→ 장애 발생 시 접수 및 다음 배송 진행이 안되는 등 회사에서 잡은 ‘당일 배송 + 새벽 배송’ 컨셉을 어기게 됨

⇒ 당일 발생 이슈 당일 해결 필요 → 피로도 증가

모색한 방법

  1. 서버 스케일 업 → 채택 하지는 않음
    1. 트래픽이 몰리는 시간 대비 유휴 시간이 더 길기 때문에 비용 효율적 이지 못함
  2. 서버 스케일 아웃 → 적용 그러나 장애 재 발생
    1. 트래픽이 몰리면 CPU, 메모리 사용률이 바로 100% 피크치기 때문에 효용성이 떨어짐

중요한 발견

→ 한번에 많은 트래픽이 들어오는 것이 근본적인 원인, 누군가 중간에서 천천히 보내줬으면 함! (물론 나는 나를 믿을 수 없고, 돈도 없음)

선택 → AWS SQS (클라우드 큐)

  • S3에 엑셀 파일 업로드 → 람다에서 엑셀 파싱 → SQS 에 파싱한 데이터 하나씩 등록 ← 어드민 서버에서 하나씩 가져와서 처리 → DB 저장
    • 서버에서 한번에 처리 가능한 만큼의 데이터만 가져와서 처리 가능 ⇒ 장애 발생 ↓
  • ‘dead letter queue’ 기능으로 일부 데이터 처리가 실패하더라도 거래처에서 엑셀 파일을 다시 업로드 할 필요 없이 해당 데이터만 다시 처리 함으로써 거래처의 번거로움 제거

끝맺음말

  • 클라우드 큐 언제 사용하면 좋을지
    • 특정 기능/시간에만 부하가 몰릴 때
    • 갑작스럽게 몰려서 오토스케일링이 안 될 때
  • 다만 클라우드 서비스를 많이 사용 하다보면 해당 클라우드에 의존 될 수 있기 때문에 주의



서버 리소스 부족으로 인한 문제를 해결하기 위해 단순히 스케일업으로 해결한 것이 아니라, 장애를 발생시키는 근본적인 원인을 파악하고 이에 대한 해결책을 도입한 것이 인상 깊었다.

최근 인프라, 클라우드 비용 최적화 관련 업무를 하다보니 해당 강의 내용이 조금 더 와 닿았던 것 같고, 앞으로 나도 단기적인 해결책 만이 아닌 근본적인 원인과 비용 효율적인 해결책을 찾으려고 노력 해야겠다고 생각이 들었다.