[Chapter 10] Q&A

[easyfordev]

[Chapter 10] 알림 시스템 설계

• 궁금한 점 혹은 이야기하고 싶은 주제 코멘트로 정리
• 추가로 같이 보면 좋을 것 같은 기술 블로그, 아티클 등 공유

[easyfordev]

이지

• soft real-time 시스템이란? 응답 시간 제약이 중요하지만, 한계 시간을 초과하더라도 중대한 문제가 발생하지 않는 시스템
  • 반대 개념 : hard real-time
  • https://www.geeksforgeeks.org/difference-between-hard-real-time-and-soft-real-time-system/
• 웹툰 푸시 플랫폼의 push_config 테이블 소개
• 모니터링 : 큐에 쌓인 알림의 개수
  • Kafka의 lag 개념
  • lag가 특정 기준 이상으로 튀면 알람을 받도록 모니터링하고 있음

    질문

• 중복 전송 방지 로직은 '작업 서버'에 들어가는게 맞겠죠?
• 특정 종류의 알림을 보내기 전에 반드시 해당 사용자가 해당 알림을 켜두었는지 확인
  • 이걸 클라이언트(앱)에서 갖고있는게 효율적일까? 서버에서 갖고있는게 효율적일까? 각각 그렇게 생각한 이유는?
• 서드파티 서비스가 알림 전송에 실패하면, 해당 알림을 retry 전용 queue에 넣는다.
  • 그냥 queue에 넣는 것 보다 retry 전용 queue를 분리해두는 것이 일반적인 것이겠죠..?

[zziri]

지훈

• "알림 시스템은 알림 데이터를 데이터베이스에 보관하고 재시도 메커니즘을 구현해야 한다"
  • 구체적으로 재시도를 어떻게 하면 좋을지..??
• 알림 전송률 제한은 구체적으로 어떻게 하라는 걸까 (4장?)
• 중복 전송을 100% 방지하는 것이 불가능하다고 설명하는데, 난해합니다 ㅠ
  • https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/

[meloncha]

민석

분산 시스템에서는 메시지를 정확히 한 번 배달할 수 없다 (https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/)

• 최대 1회 보장 : 발신자는 수신자에게 1번 푸시. 수신자는 받을 수 있거나 못 받을 수도 있다
• 최소 1회 보증 : 발신자는 메시지를 푸시하고 시간 초과로 승인을 기다린다. 제한 시간 내에 승인이 완료되지 않으면 배달을 재시도한다
• 정확히 한 번 처리 : 불가능. 한 번만 처리하는 방법은 있다
  • 중복 제거 : 메시지가 두 번 이상 수신되면 삭제
  • 멱등적 처리 : 메시지를 두 번 이상 적용하면 한 번 적용한 것과 같은 효과 ( 멱등성 : 연산을 여러 번 반복하여도 같은 값을 나타낸다 f(f(x)) = f(x) )

kafka 에서의 exactly-once-delivery 구현

• at-most-once : 실패나 타임아웃 등이 발생하면 메시지를 버릴 수 있다. 데이터가 일부 누락되더라도 영향이 없는 경우엔 대량처리 및 짧은 주기의 전송 서비스에 유용할 수 있다.

• exactly-once : 메시지가 정확하게 한 번만 전달되는 것을 보장한다. 손실이나 중복 없이, 순서대로 메시지를 전송하는 것은 구현 난이도가 높고 비용이 많이 든다.

• at-least-once : 메시지가 최소 1번 이상 전달되는 것을 보장한다. 실패나 타임아웃 등이 발생하면 메시지를 다시 전송하며, 이 경우엔 동일한 메시지가 중복으로 처리될 수 있다.

• kafka의 경우 at-least-once 를 보장하며 일정 버전 이후에서는 옵션을 통해 exactly-once를 적용가능

• 트랜잭션을 적용하여 구현. Producer가 트랜잭션에서 처리한 데이터의 offset을 커밋함으로써, Consumer에 정확하게 메시지를 전달할 수 있다. Consumer에도 트랜잭션을 적용

• Producer to Consumer 까지 가는 파이프라인은 exactly-once 보장. 성능은 떨어짐.

• 파이프라인 전체에 대해 exactly-once를 지원하려면 kafka 외부의 애플리케이션단에서도 중복 처리 이슈가 해결되어야 한다 -> 거의 불가능

참고 )

• https://dhkdn9192.github.io/apache-kafka/kakfa-exactly-once-delivery/
• https://blog.voidmainvoid.net/354

[travelbeeee]

현석

• 민석이형과 지훈이형이 궁금한 내용을 다뤄주고 있어서 따로 질문은 적지 않겠습니다.

[janeljs]

지선

• cronjob
  • https://stackoverflow.com/questions/21615673/difference-between-cron-crontab-and-cronjob
  • https://kubernetes.io/ko/docs/concepts/workloads/controllers/cron-jobs/
• 중복 방지
  • deduplication id
  • https://marketingapi.snapchat.com/docs/conversion.html#deduplication

    To reiterate, there is no such thing as exactly-once delivery. We must choose between the lesser of two evils, which is at-least-once delivery in most cases. This can be used to simulate exactly-once semantics by ensuring idempotency or otherwise eliminating side effects from operations. 출처: https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/

• 알림을 재시도하는 게 작업서버의 장애로 이어지지는 않을지?
  • https://www.ibm.com/docs/en/ibm-mq/7.5?topic=management-what-happens-when-message-cannot-be-delivered
  • https://engineering.linecorp.com/ko/blog/circuit-breakers-for-distributed-services/
  • 지수 백오프

[KKambi]

한비

저는 급하게 읽어서 따로 준비하진 못했습니다. 다음에 꼭! 준비하도록 할게요 ㅠㅠ