[시스템디자인 3편] 메시지큐에 이벤트가 대량으로 생성된 경우

목차는 시스템 디자인 목차 에 있습니다.

추후 내용을 더 정리할 예정입니다. 간단하게 정리했습니다.

[시스템디자인 3편] 메시지큐에 이벤트가 대량으로 생성된 경우

Case 1. 메시지큐에 이벤트가 대량으로 생성된 경우

• Kafka 의 파티션에 대량 이벤트가 생성이 됐다고 가정하겠습니다. 주기적으로 발생하는게 아니라 특정 시간에만 발생했다고 가정합니다.
• 메시지 이벤트는 MySQL, Redis 등 다양한 스토리지를 사용한다고 가정합니다.
• 메시지 이벤트가 너무 많이 생성 -> MySQL 부하 -> MySQL session 이 고갈 -> Application Thread 고갈 가정합니다.
• 메시지큐가 kafka 라고 한다면, 오프셋 랙(offset lag) 이 증가하며, consumer 서버 쪽의 gc, cpu 사용량 등이 급증한다고 가정하겠습니다.

해결방안 1 DB 파티셔닝

• 파티셔닝으로 처리가 가능한 경우 파티셔닝으로 처리합니다.
• Range-hash 와 같은 파티셔닝 기법을 사용해서 처리합니다.
  • 예를 들면, 날짜나 범위와 관련된 컬럼을 기준으로 데이터를 range 하며, 데이터가 골고루 분배되도록 hash 키를 설정합니다.

해결방안 2 DB 샤딩

• DB 샤딩을 한다고 가정하면 DB 샤딩으로 어떤 키를 사용할지 고민합니다. 데이터가 골고루 분배되야합니다.
• 특정 시간에 이벤트가 대량으로 생성된다면, 전체 샤드를 추가하거나 샤드의 복제본 수를 늘리는 수평적 방식을 고민해볼 수 있을 것 같습니다.

Case 2. 메시지큐 특정 파티션에 이벤트가 대량으로 생성된 경우

• Kafka 의 파티션에 대량 이벤트가 생성이 됐다고 가정하겠습니다. 주기적으로 발생하는게 아니라 특정 시간에만 발생했다고 가정합니다.
• 메시지 이벤트는 MySQL, Redis 등 다양한 스토리지를 사용한다고 가정합니다.
• 메시지 이벤트가 특정 파티션에 대량으로 생성 -> MySQL 특정 샤드에 부하가 된다고 가정합니다.
  • 좀 더 부연 설명을 하면 샤드를 나누는 키를 ID 라고 가정할 때, 특정 ID 에서만 요청이 급증해 특정 샤드에 부하가 몰린다고 가정하겠습니다.

해결방안 1 특정 요청을 캐싱해서 요청을 줄임

• 요청을 count 한 후, 기준 count 를 넘어서면 잠시 Redis 에 저장해서 나중에 처리합니다. 즉, 지연 처리를 합니다.
• count 는 redis 에서 관리합니다.

참고

• https://engineering.linecorp.com/ko/blog/how-line-openchat-server-handles-extreme-traffic-spikes