Order Messaging 계층 1차 마무리, DataAccess 계층 개발 시작, 독서

이번주부터 도입한 일정관리, 칸반보드 처럼 사용할 수 있는 Trello 를 사용하고 있다.

 

오늘은 항상 그렇듯 오전에 독서를 하고서, 개발을 시작했다. 독서는 DDD 기반의 마이크로 서비스 설계 부분을 독서했다. 오늘 독서는 현 프로젝트의 개선할 부분, 부족했던 부분을 스스로 인지할 수 있었다. 그리고 이 부분또한개선해서 반영할 계획이다.

 

Order도메인의 Messaging 계층 개발을 마무리 지었다. Cosumer(Listener)를 테스트 하는 것까지 완료하고 싶었지만, 해당 이슈를 어떻게 해결해야할지 도저히 감이오지않아, 테스트를 Disabled 해둔 채로 일단 개발을 마무리 지었다. 상당히 매우 몹시 찜찜하지만, 정말 내가 해볼 수 있는 시도는 다 해봤음에도 불구하고 문제 해결을 위한 힌트조차 얻지못하였기에, 지금 이것은 내가 해결할 수 없는 문제로 판단하였다.

 

이번 Messaging 계층을 개발하면서, 내가 빠트린 부분또한 확인할 수 있었다. 해당 부분은  PR을 작성하기 전, 잊지 않기 위해 이슈로 등록해 두었다.

 

PR을 작성하고, 셀프리뷰도 진행했다. 셀프 리뷰 진행 간, 테스트를 위한 스키마를 등록하는 부분을 진짜 너무 개선해야겠다는 생각이 들었다. (당시에 왜 그렇게 하고 넘어갔을까..?) 해당 부분을 개선하고, PR을 마무리 지었다.

 

 

 

---

Order Messaging 계층 1차 마무리

 

벌써 18번째 PR을 작성했다.

 

오늘은 18번째 PR, Feature/order adapter: Messaging 을 작성했다. 해당 PR의 핵심은 kafka 사용을 위해 사용하는 클래스들을 개발했다. 그리고 이와 관련한 avsc 파일, AvroClass 를 추가하고, 테스트 하였다.

 

Feature/order adapter: Messaging by KEEMSY · Pull Request #18 · KEEMSY/shoes-ordering-system

 

 

이번 Order Meesaging 을 개발하기 전까지는 외부계층인 카프카를 테스트하지 않았다. 테스느는 내부(애플리케이션)을 검증하는 것이지 외부(카프카클러스터)를 검증할 필요가 없다고 생각했기 때문이다.

 

이는 지금 생각해보면 다소 엉뚱한 생각이다. 그 이유로 첫번째는, 또 또른 외부계층인 DB(JPA)는 테스트 했다는 것이다. 외부계층을 테스트해야하나? 하는 생각은 앞뒤가 맞지 않는다.(나 뭐냐..)

 

두번째 이유는, 외부계층 또한 서비스 측면에서 내가 책임져야 할 부분에 속한다. 외부계층 또한 전체적인 서비스 측면에서 바라볼 때, 내가 책임지는 부분으로서 당연하게 정상작동함을 검증해야한다.

 

그렇게 나는 해당 계층을 테스트하기위해 고분분투 하기 시작했다.

 

 

---

안정적인 통합테스트를 위한 방법

 

내가 가장 고민이 되었던 것은, 어떻게 이를 안정적으로 테스트 할 수 있을 것인가? 깨지기 쉬운 테스트를 어떻게하면 피할 수 있을까? 였다. 이를 위해 지금까지 도커를 통한 컨테이너를 띄워 테스트한 방식처럼, CI 에 이 설정을 그대로 다 옮겨야하야하나..? 생각이 가장 먼저 들었다.

 

나는 로컬 카프카 클러스터를 구축하기위해 docker-compose 를 활용한다.

 

카프카를 사용해본 사람이라면 대부분 알듯이, 주키퍼를 가동하고, 카프카 클러스터를 가동해야한다. CI에서 컨테이너 순서를 지정하는 것은 어렵지 않게 할 수 있을 것 같은데, 문제는 init_kafka 부분(토픽생성 스크립트)였다. 실제로 로컬에서 개발할 때, 가장 에러(?)가 많았던 파일은 init_kafka 파일이었다.

 

init_kafka 에서는 토픽을 초기화하고 생성하는 역할을 담당한다.

init_kafka 는 최초 카프카 클러스터 구동 시, 한번 실행하는데(신규 토픽 추가가 없다면), 해당 커맨드가 실행되는데 엄청난 시간이 소요되거나, 제대로 끝까지 동작하지 않는 경우가 많았다. 그래서 나는 그냥 해당 컨테이너에 접속하여, 해당 커맨드를 직접 입력하고 토픽을 설정했었다.

 

이러한 경험 때문에 나는 CI 에 이 설정을 올리는 것이 과연 안정적일까..? 하는 의문이 들어 쉽사리 할 수 없었고, 다른 방법을 많이 찾아보았다.

 

나와 같은(?)생각을 한 어느 기업의 기술블로그의 글을 보고서 문의를 남겼다.

 

나는 다른 사람들은 어떻게 해당 테스트를 진행하는지 궁금했다. 그리고 가장 먼저 본 것은 다음 포스팅이었다.

 

[오늘의 헤드라인] 테스트 코드 작성기(2) — Mock

 

하지만 아쉽게도 해당 댓글에 아직까지 답변은 달리지 않았다. 아무래도 일이 많이 바쁘신 것 같다.. 하지만 답글이 없다고 소득이 없었던 것은 아니다.

 

이 글을 계기로 다른 검색을 계속해서 이어갈 수 있었고, 나는 spring-kafka-test 라이브러리를 알게되었고, Embeded Kafka 를 통해 안정적으로 카프카 통합테스트를 진행할 수 있음을 알게되었다.

 

 

---

spring-kafka-test: Embeded Kafka 의 사용

 

나는 이것을 통해 완벽하게 내 고민을 해결할 수 있을 것 이라고 확신했다. 테스트가 가동될 때마다 알아서 주키퍼와 카프카 브로커가 실행되었다. 테스트가 많이 느리지 않을까 걱정했지만, 내 생각보다는 느리지 않아서 괜찮았다. 하지만 다른 문제가 존재했었다. 바로 내가 카프카를 제대로 모른다는 것이었다.

 

관련한 내 TIL 기록

드디어 메시징 테스트 진행, 거의 다 온 것 같다(?)[ 3AM, 문제해결 ]

 

카프카를 그저 사용해본 경험과 코드만으로만 사용했다는 것이 가장 큰 문제의 원인이었던 것 같다. 내가 필요한건 이벤트 버스니깐~ 하는 생각에 이렇게 된게 아닐까? 취업을 할 때, 가능하다면 카프카를 사용하는 곳에 가서 어깨넘어로 공부해야겠다.(물론 혼자서라도 공부할거지만 말이다.)

 

무튼 나는 Embeded Kafaka 를 사용하여 내가 원하는 Producer 테스트를 진행했다. 하지만 Consumer 테스트는 그러하지 못했다.

정말 이해가 되지 않는 경로참조문제에 가로막혀 내가 작성한 클래스를 검증할 수가 없었다.  해결하고 싶지만, 내가 해볼 수 있는 것들은 다해본것 같음에도 불구하고 전혀 감조차가 오지 않아 지금은 잠시 놓아주었다... 나중에 Spring 지식이 좀 더 쌓이게 되면 이 문제를 꼭 해결해야겠다.

 

관련한 내 TIL  기록

예비군 훈련, TestContainer, 예측가능한 코드, 참조오류

 

그리고 다난했던 Messaging 개발은 이렇게 마무리했다.

 

 

---

DataAccess 계층 개발 시작

 

오후가 되고서 두번째 Adapter, DataAccess 를 개발하기 시작했다.