이전에 작성했던, [일단 박죠] O2O Object Detection 서버 Message Queue 적용을 위한 분석 에서 O2O Object Detection 서버에 Message Queue를 적용하기 위한 분석을 진행했었다. 하지만 프로젝트를 진행하면서 발견한 몇 가지 문제점들로 인해 구조를 재고하게 되었다. 지난번 개선안에서 제시한 구조에 대해 다시 살펴보며 발견한 문제와 그 해결 방안을 이번 글에서 다루겠다.

1. 현재 구조의 문제점

지난번에 개선하였던 구조이다. 비동기 방식과 서버간의 결합도를 낮추기 위해서 kafka connect를 도입하였다. 그 당시에는 문제 없어 보이는 구조였지만, 해당 구조를 직접 그려보면서 점검해본 결과 문제점들을 발견하였다.

• 상점의 데이터베이스에 여러 곳에서 접근하게 되면서 데이터 일관성 관리에 어려움이 생겼다.
• 모든 API 요청을 상점용 스프링 서버가 처리하게 하여 서버 부하 및 유지보수의 복잡성이 증가했다.
• 상점 관리 서버가 상점 물품 사진을 받아 Kafka를 통해 객체 검출 서버로 전송하는 과정이 불필요하게 복잡하고 비효율적이다.
• Kafka와 Kafka Connect의 동시 사용은 시스템 복잡성을 불필요하게 증가시키는 오버엔지니어링이다.

해당 문제점들을 해결하기 위해 여러가지 방안들을 생각해 보았다.

2. 문제점의 해결 방안

문제 해결을 위해 Spring Cloud Gateway의 도입을 결정했다. MSA를 고려했으나 프로젝트의 규모와 현재 상황을 고려할 때, 전체적인 오버헤드가 늘어나는 오버엔지니어링이 될 것이라는 결론에 도달했다. Spring Cloud Gateway를 사용하면 다음과 같은 이점을 얻을 수 있다.

• 상점 서버는 인증이나 사진 전달과 같은 자신과 무관한 역할에서 해방되어, 상점 관리에만 집중할 수 있게 된다.
• 나중에 고객 관리 서버를 추가할 때도 효율적인 구조를 유지할 수 있다.
• 상점 관리 데이터베이스는 오직 상점 관리 서버를 통해서만 접근되어, 데이터 일관성이 유지된다.

결론적으로, Spring Cloud를 이용한 구조 변화는 비동기 방식과 서버 간 결합도를 낮추는 Message Queue의 장점을 유지하면서도, 서버의 본연의 역할에 집중할 수 있게 해준다.

3. 해결 방안의 단점

이 구조에서는 Kafka 도입이 오버엔지니어링일 수 있다고 생각한다. 객체 검출 서버와 상점 관리 서버 간 HTTP 요청으로 검출 결과를 충분히 전송할 수 있기 떄문이다. 그럼에도 불구하고 Kafka를 선택한 것은, 시스템 간 결합도를 줄이는 관점에서 보았을 때의 이점 때문이다. 실무 경험이 부족하여 이 구조가 최적인지 확신할 수는 없으나, 계속해서 발전시켜 나갈 계획이다.

앞으로는 프로젝트 구현한 내용을 공유하도록 하겠다. 하지만 대부분의 주요 내용은 이미 스프링 공부 및 생각 정리 에서 다루었기 때문에 O2O 시리즈에서는 간단하게 소개하는 방식으로 진행하겠다.