Spring Cloud with Apache Kafka - 2

최혜성·2024년 1월 17일
0

msa

목록 보기
6/7

들어가기전..

  • Message Queue
    pub sub 방식으로 구독하고 이를 받아볼 수 있는 기능을 제공함
    redis로 이걸 알았는데 문제는 redis는 pub는 하는데, 이미 발행된 내용에 대해선 보증을 안해줌
    RabbitMQ나 Kafka는 이미 내용이 발행된 후 sub를 하면 다시 내용을 보내줌.

예전에 스프링은 아니지만 여러개의 서버간 분산 환경을 다룬적이 있었는데, 확실히 분산환경에서 퍼포먼스가 월등한 모습을 보여주었다.

서버비용이 엄청 늘어났긴 하지만..

본론

참고 url :

Eureka - Setup:
https://velog.io/@haerong22/Spring-Cloud-%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-MSA-2.-Spring-Cloud-Eureka

https://velog.io/@korea3611/Spring-BootSpring-Cloud-Netflix-Eureka-%EC%84%9C%EB%B2%84-%EB%A7%8C%EB%93%A4%EA%B8%B0-MSA1
도메인 모델링:
https://engineering-skcc.github.io/microservice%20modeling/BackEnd-modeling-domainModeling/

https://www.inflearn.com/questions/283964/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C-%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%B3%84-%EC%97%94%ED%8B%B0%ED%8B%B0

https://velog.io/@dasd412/JPA-%EA%B4%80%EA%B3%84%EB%A5%BC-MSA%EC%97%90-%EC%A0%81%EC%9A%A9%ED%95%B4%EB%B3%B4%EA%B8%B0

메인 Request -> API GateWay -> 각 마이크로 서비스
                            ↓
                          Eureka

위와 같은 방식으로 작동하는것 같다. Eureka는 각 마이크로 서비스 별로 번호 불러서 살아 있으면 API GateWay한테 등록했다 알려주고, API GateWay가 직접적으로 어캐할지 처리하는 듯 (Load Balancing..)

가장 헷갈리는점

기존 모놀리식 방식에서는 유저 정보인 User와 주문 정보인 Order와 내부 구매한 아이템인 Item이 있다. 이 관계는 1:N이다.
그러면 주문을 했을때 어디 어디 서버를 경유해야하는가? 각 서버는 어느 테이블까지 접근할 수 있는가, 테이블은 어떻게 접근해야 하는가? 라는 의문이 강하게 들었다.

기존 모듈이 합쳐져 있을때는 자동으로 Mapping되서 신경 쓸 필요 없었는데 (안좋은 버릇)
MSA에서는 어떻게 해야할지 헷갈렸다.
User 서버와 Order서버 Item서버를 분리하자니 Order를 저장할때 Item 데이터들은 어떻게 보내줘야 하는지..

그래서 도메인 모델링 url을 참조했다.
따라서 선택지는 2가지
1. Value Object를 이용하여 전달한다.
2. 외래키 자체를 보내 각 서비스별로 response를 받고 join한다 (ORM을 수동으로)

1번은 말 그대로 각 테이블에 정보를 담는것이다. 주문시 Order API로 주문자 정보, 아이템 리스트를 보내 그걸 저장한다. User는 어처피 id만 참조하면 되고, 아이템 리스트도 item id로 참조하는 방식등으로 VO 를 가볍게 저장해도 될것 같다.
2번.. 도 유사하네

그래서 MSA 설계할때 회의를 많이 하나보다.. 나도 회의 시켜조

2번은 RestAPI의 형태로 각 서비스간 요청을 할 수 있는 OpenFeign를 사용하면 된다. 이것도 보긴 했는데 Kafka랑 이게 뭔 차이일까?

https://www.inflearn.com/questions/630675/feignclient%EC%99%80-kafka%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95%EC%9D%98-%EC%9D%B4%EC%A0%90
인프런 url이긴 한데..
내가 내린 결론은 다음과 같다.

  • 둘중 편한걸로 써라
  • 단, Kafka의 경우 Response를 받는 용도로는 부적합하다. 진짜 이벤트 보내는 용도
  • Feign는 Response 받을때 사용하자.

Kafka의 경우 이미 발행된 메시지더라도 수신되지 않았으면 다시 보내는 보증을 해주기 때문에 업데이트가 확실하게 이루어짐을 확신할 수 있다.
하지만 Feign는 그냥 Rest API를 호출하는 방식이기 때문에 요청을 보낼 순 있지만, 이 메시지를 다른 API서버가 받음을 보장할 수 없다.

그래서 만약 UserAPI서버로부터 유저 정보를 가져올때는 Feign, 유저 정보를 업데이트 할때는 Kafka.
주문을 했을때는 Kafka, 주문 정보를 가져올때는 Feign를 쓰려 한다.
https://techblog.lotteon.com/%EB%89%B4%EC%98%A8%EC%9D%B4%EB%93%A4%EC%9D%98-%EC%B2%AB-msa-%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%8F%84%EC%A0%84%EA%B8%B0-d336186a7e31
https://mr-spock.tistory.com/46

아니 그러면 같은 MSA API서버가 여러개 열려있으면 Kafka는 우짬?

로드밸런싱일땐 여러개의 서버중 1개 선택함. 근데 각 서버가 같은 kafka topic을 구독하면?

https://stackoverflow.com/questions/35213872/can-a-spring-kafka-consumer-run-on-multiple-machines-for-the-same-groip

kafka에는 group이라는게 있는데, 해당 그룹의 딱 1명만 해당 메시지를 받을 수 있다.
이걸 이용하면 될듯?

profile
KRW 채굴기

0개의 댓글