토이프로젝트를 통해 카프카를 처음 사용해보았다.
카프카 사용에만 초점을 맞추다보니 잘못된 상황에서의 카프카 사용인 것을 깨달았다.
처음 설계를 할 때 내가 카프카를 사용한 이유는 2가지 였다.
- 많은 사용자가 사용할 경우 파티션과 컨슈머 서버를 늘려 처리량을 늘릴 수 있음
- 포인트에 대한 안전한 처리
하지만 면접, 스터디를 통해 어뷰징에 대한 지적이 들어왔다.
사용자의 포인트가 현재 100 포인트가 있고 스터디 룸을 만드는데 100포인트가 든다고 하자. 사용자가 스터디 방을 만드는 요청을 보냈고 컨슈머에서 처리는 아직 반영되지 않았다고 하자. 이 때 사용자가 연속해서 5번의 요청을 했을 때의 처리는 어떻게 되는가?
처음 질문을 받고 아무말도 할 수 없었다. 잘못된 설계란 자체도 깨닫지 못했다.
포인트를 증가 시키거나 감소 시키는 요청을 보내는 프로덕트 서버, 이를 실질적을 처리하는 컨슈머 서버가 나누어져있어 포인트를 처리를 하는 데 이 두 서버가 서로의 상태를 알 수 없으니 어뷰징이 생길 경우 막을 수 없다.
그래서 면접관님이 굳이 카프카를 쓰지 않고 하나의 서버에서 처리하는 것이 낫다고 한 것 이였다. 하나의 서버에서 중복 요청 방지와 유효성 체크를 통해 해결할 수 있다.
현재의 해결 방법은 카프카 사용을 하지 않는 것이나 나의 토이 프로젝트 목적은 실제 사용하는 것이 아닌 학습을 위한 토이 프로젝트이므로 잘못된 설계의 카프카 사용을 철회하진 않을 것이다. 그래도 어뷰징을 최대한 막기 위해 1초 이내 중복 요청 방지 처리를 추가할 것이다.
다음 토이프로젝트에서 카프카를 사용할 때 잘못된 상황에서 쓰지 않도록 어뷰징에 대한 고려를 추가해서 해야겠다.
다시 한 번 정리하자면
카프카 이벤트는 비동기적으로 처리된다. 프로듀서와 컨슈머는 서로 현재의 메시지가 어디까지 진행됐는지 알 수 없다. 따라서 컨슈머에서 데이터를 변경하는 부분이 있다면 이 부분의 어뷰징을 고려해 카프카의 사용 여부를 고려해야 할 것이다.
