12월 03일 문제 동기식 서비스 호출 > 이벤트 기반 아키텍처

동기식 서비스 호출 방식에서 이벤트 기반 아키텍처로 전환해야 하는 경우를 가정하고,

동기식 서비스 호출

• 서비스들이 서로 직접적으로 연결이 될 수 밖에 없다

• 한 서비스의 문제가 전체 시스템에 영향을 준다.

이벤트 기간 아키텍처

• 각 서비스가 독립적으로 동작

• 비동기적으로 응답하기에 시스템 응답 속도가 빠름.

• 필요한 서비스만 확장이 가능해진다.

도입 배경과 이를 통해 해결하고자 하는 문제를 설명해주세요.

도입을 왜 해야하나?

• 개인적인 생각으로는 서비스 간의 의존성을 최소화해야하기 때문이라고 생각한다.

• 코드에서도 결합도가 강한 경우 리팩토링이 힘들어지게 되지만, 서버의 경우 결합도가 강한 경우

  • 확장이 너무 어려워지는 문제가 발생한다.

• 모놀리식으로 충분한 경우 굳이 나눌 필요는 없을 수도 있다..

  • 이벤트 쿠폰 관리쪽을 수정하다가 휴먼에러 발생으로 서버에 문제가 생기면

    • 생기는 시간만큼 사용자가 결제하지 못하고 회사는 금전적인 손실을 안게 되는 문제가 있긴하다.

  • 하지만 이는 극단적인 예시로 일반적인 경우 서버비와 관리 오버헤드로 굳이 나눌 필요는 없다고 생각한다.

해결하고자 하는 문제

• 트래픽의 분산에 용이해지기도 하고

• 성장하는 서비스의 경우 도메인 컨텍스트를 나눠야 분업도 가능해지고

• 문제 발생시 빠른 대처가 가능하기도하다

• 또한 시스템의 경직성을 해결이 가능해진다

이벤트 브로커(Kafka, RabbitMQ)를 활용해 대략적인 설계와 이에따른 기술적 문제(메시지 중복 처리, 데이터 유실) 및 이를 해결한 방안에 대해 기술해주세요

이벤트 브로커를 활요한 대략적 설계법

• 이벤트 브로커

  • 말 그대로 여러 서비스 간의 메시지를 중개 해주는 친구이다.

• 일반적으로 발행 - 구독 모델을 가지고 있으며

  • 요즘 왠만한 규모의 프로젝트에 대부분 적용이 되어 있다.

  • 요즘 국가단위 SI 사업도 오래전부터 사용중이라고 들었음..

    • 물론 매번 말하지만 문제가 많다고 한다 항상

    • 올바르게 사용하지 못하면 메시지 유실 등의 문제가 발생할 수 있는 아주 민감한 서비스같다

• 브로커가 메시지를 큐에 저장 → 소비자(다른 서버) 가 이를 가져가서 처리한다

기술적 문제

1. 메시지 중복 처리

   • 동일한 메시지가 여러번 처리될 수 있다

     • 같은 메시지큐이기에 AWS SQS 도 같은 문제를 안고 있는데 AWS 에서는 가시성 타임아웃 이라는 개념이 있다

       1. 메시지를 받은 후 일정 시간 동안 다른 소비사가 해당 메시지를 볼 수 없게 설정함.

       2. 적절하게 설정하면 중복 처리를 줄일 수 있다고 함

2. 데이터 유실 가능성

   • 브로커 장애로 메시지가 사라지거나 전달되지 않을 수 있음.

해결방안?

1. 메시지 중복

   1. 고유 ID 부여

      • 메시지에 고유한 식별자 부여로 중복 여부 체크

   2. 멱등성 처리

      1. 카프카에서는

         1. 멱등성 처리를 할 수 있는 옵션이 있긴함

         properties.setProperty(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, "true");
         

         • 3.0 이후 참 기본

         • 이전 거짓 기본

2. 데이터 유실

   1. ACK 응답

      1. 메시지 성공적으로 처리되었는지 소비자가 브로커에 응답(ACK) 보냄

      2. 뭔가 생겨먹은게 HTTP 3 way handshake 구조같다.

   2. 재시도 매커니즘

      1. 메시지 전달 실패시 자동으로 재전송 설정이 가능

      2. 횟수까지 설정가능 ㅇㅇ

   3. 카프카 파티션 복제