version 0.3

🚨 DB IOPS의 한계

초당 2천 건의 트래픽부터 에러 발생

🔍 원인 분석

• 초당 2천 개 이상의 DB Insert 요청 시 mongoDB M10의 한계인 DISK IOPS 1K를 넘지 못함
• DB가 초당 처리할 수 있는 데이터 수의 한계가 발생하며 응답 시간 지체

🛠️ 해결 시도

• M30으로의 db scale up

  • Disk IOPS가 3K인 M30으로 scale up

  

  • 하지만 db는 기대이하의 성능 향상

• DB 부하가 아닌 다른 곳의 문제가 있다고 판단

  1. 서버가 병목 지점일까?

  2. t3 small(CPU 2, RAM 2G) ec2를 총 3개 사용하고 있는 상황에서 서버의 스레드 부족으로 인한 병목 지점이 되고 있지 않을까?

  3. 그리고 도커 컨테이너가 cpu의 성능을 모두 활용하지 못하고 있지 않을까?

     

     • 서버의 cpu 사용률은 안정적이고 효율적으로 사용 되고 있음을 확인→ 병목 지점으로 판단하기에 무리가 있다고 판단
     • 추가적인 스케일 업, 스케일 아웃을 통해 테스트를 시도하였지만 에러가 해결되지 않음

• 아키텍처 및 데이터 플로우에 대한 고민

  • 서버와 DB의 성능 개선으로 문제가 해결 되지 않아 아키텍처에 대해 고민함
  • 채팅 데이터를 저장하는 과정으로 인해 생기는 트랜잭션 발생은 ‘실시간 대용량 트래픽 처리 성능’에 민감할 수 밖에 없다고 판단

  

  • 유저에게 데이터 전송에 대한 응답을 확실하게 부여
  • 트랜잭션 발생을 막을 수 있는 아키텍처
  • 결국 서비스 애플리케이션들의 실시간 데이터를 짧은 지연시간으로 처리가 가능한 스피드 레이어가 필요했고 kafka가 적절한 해결책으로 떠올랐다.

• kafka의 활용

  

  • 클라이언트의 채팅 데이터 전송은 ‘DB에 저장하는 과정’과 ‘STOMP를 통해 채팅방에 전달되는 과정’을 비동기 처리하여 성능향상
    • kafka에 데이터를 전송한 뒤 잘 받았다는 응답을 돌려받은 후 채팅방에 데이터를 전달하는 동기처리 이용 → 채팅 전송에 대한 성공/실패 응답을 클라이언트가 확실하게 받을 수 있음
    • ‘kafka의 데이터를 DB가 consume하는 과정’과 ‘채팅방에 데이터가 전달되는 과정’은 비동기적으로 일어나게 됨
    • 서버와 DB간의 트랜잭션 발생 없이 채팅 전송은 빠르게 이루어 질 수 있음
  • DB는 kafka가 데이터를 consume 하는 방법
    • kafka sink connetor의 Batch Processing을 통해 mongoDB에 적은 IOPS로 많은 데이터를 저장
    • kafka의 레플레카 및 ark를 통해 데이터들의 정합성을 보장