카프카를 활용한 워크 큐
정말 오랜만에 글을 쓰는 것 같습니다. 한번 쓰지 않기 시작하다 보니 이렇게까지 늘어졌네요;; 최근에 카프카 운영과 관련해 어드민 페이지 개선 작업을 했고, 워크 큐(work queue)로 카프카를 활용하여 프로세스를 개선한 과정과 느낀 점을 공유하고자 합니다.
배경
현재 전사 공용 카프카를 운영하면서, 필요한 어드민 페이지 일부는 제가 직접 만들어서 사용하고 있는데 그중 대표적인 툴 중 하나는 토픽 생성 페이지입니다. 해당 페이지의 용도는 카프카 사용을 원하는 개발자들이 직접 빠르게 토픽을 생성할 수 있도록 해주는 툴입니다. 해당 페이지는 python+flask를 이용하여 개발하였지만 제가 개발 경험이 많이 부족하여 개선해야 할 점들이 무수히 많았습니다.;; 그래서, 개선해야 할 점들은 저의 To-Do list 중 하나로 마음속에만 남아 있는 상태였습니다.
그러던 중 최근 저희 부서에 새로 입사하신 능력자분이 다른 어드민 툴 중 하나를 python+flask를 이용하여 제가 원하고 고민했던 내용들을 매우 능숙하게 만들어 내는 것이었습니다. 저는 한편으로 부럽기도 했고, 저도 한번 해보고 싶었습니다. 어떻게 그렇게 잘하냐고 물었더니, 매우 간단하게 할 수 있다는 이야기를 해주면서 조금만 해보면, 저도 금방 할 수 있을 거라고 이야기를 해주었습니다. '나도 한번 해보자'라는 마음과 '노력하면 나도 할 수 있다'는 마음이 강하게 들었고 옆에 든든한 지원자도 있으니, 바로 시작하기로 마음먹었습니다. 과거 django를 이용하여 한번 페이지를 만들고 싶어 야심 차게 시작했다가 model 개념이 나오기 시작하면서 책을 덮고, flask로 방향을 바꾸었는데, 이번에는 지난번 포기했던 django를 다시 정복해보고 싶다는 욕심도 생겨, 공부도 할 겸 django로 개선 작업을 시작했습니다.
문제점
토픽 생성 페이지에는 여러 가지 문제점들이 있었지만, 가장 개선이 필요하다고 생각한 부분은 바로 토픽 생성 시 개발용과 서비스용을 분류한 것입니다. 이렇게 두 개로 분리하여 운영하게 된 배경은 토픽 생성의 몇 가지 조건 때문이었는데, 조건들을 요약해보면 아래와 같습니다.
개발 클러스터는 어떠한 제한 없이 누구라도 토픽을 생성할 수 있어야 하고 즉시 생성되어야 한다.
서비스용 클러스터는 허용된 토픽만 생성되어야 한다.
서비스용 클러스터에 토픽 생성 제한을 둔 이유에 대해 궁금하실 수 있어 간략히 말씀드리자면, 아무래도 서비스용으로 사용하는데 무작위로 토픽이 생성되면 그와 관련하여 카프카가 영향을 받을 수 있는 부분도 있고, 관리 등의 목적도 있습니다. 인증을 붙이는 방법을 고민하기도 했었는데, 인증을 붙여 권한을 추가하면 그 권한을 가진 사용자는 이미 권한을 가진 상태이므로, 이후에 언제든지 원하는 토픽을 바로 만들 수 있기 때문에 위에서 말한 두 가지 조건을 모두 적용하기에는 좋은 방법은 아니라고 생각하였습니다. 그 외에도 이런저런 방법을 고민했지만, 마땅히 뾰족한 방법을 생각하지 못하였습니다. 결국 해당 프로세스를 두 개로 분리하게 되었고, 두 개의 프로세스는 다음 그림과 같습니다.
개발 카프카 클러스터의 경우
1: 사용자가 토픽 생성 웹에서 토픽명을 적고 생성 버튼을 누릅니다.
2: 해당 요청을 통해 개발-카프카 클러스터에 즉시 생성됩니다.
3: 사용자는 생성 완료되었다는 내용을 확인하고 즉시 해당 토픽을 사용할 수 있습니다.
서비스 카프카 클러스터의 경우
1: 사용자가 토픽 요청 웹에 토픽명 생성 요청을 적습니다.
2: 관리자가 해당 요청을 보고 수동으로 서비스-카프카 클러스터에 토픽을 생성합니다.
3: 해당 토픽이 즉시 생성됩니다.
4: 관리자는 요청 웹에 생성되었다고 코멘트를 남깁니다.
5: 사용자는 생성되었다는 내용을 확인하고, 이제 해당 토픽을 사용할 수 있습니다.
개발 카프카 클러스터의 경우도 몇 가지 문제점이 있었지만 서비스 카프카 클러스터에서 몇 가지 문제점들이 있습니다. 가장 큰 문제점은 토픽 생성 요청 후 토픽 생성까지 시간이 오래 걸린다는 것입니다. 그 외에도 유저가 토픽 생성 요청을 하고, 관리자가 해당 요청을 미처 보지 못하고 누락하는 경우가 발생하기도 하고, 관리자가 완료되었다고 메시지를 남겼는데, 사용자가 뒤늦게 확인을 하는 경우 등이 있습니다. 또 다른 문제점은 관리자의 실수입니다. 관리자는 토픽 요청 내용의 글을 보고 토픽을 생성하게 되는데, 복사 붙여 넣기의 실수 또는 타이핑의 실수 등으로 요청과 다른 토픽을 생성하기도 합니다. 저는 이러한 부분들을 모두 해결하고 싶었고, 여러 가지 고민 끝에 요청 -> 관리자 승인이라는 비동기 방식을 이용하기로 했고, 이 비동기 처리에 필요한 워크 큐는 카프카를 활용하기로 했습니다.
개선
개발용 클러스터의 경우 기존 방식과 크게 개선할 부분이 없었습니다. 단지 HTML에서 검색 등의 기능이 필요했기 때문에 이는 HTML에서 페이지 보여주는 부분만 개선하면 되었습니다. 반면 서비스용 클러스터의 경우는 프로세스를 변경해야 했습니다. 작업 큐를 이용하는 변경된 프로세스에 대한 요약 그림은 다음과 같습니다.
개선된 프로세스
1: 사용자가 토픽 생성 웹에서 토픽명을 적고 생성 버튼을 누릅니다.
2: 해당 웹에서 개발 클러스터의 경우 앞서 설명한 그림과 같이 즉시 생성되고, 서비스 클러스터의 경우 별도의 작업 카프카에 유니크한 이름으로 토픽을 만들고 그 토픽에 해당 요청 내용을 메시지로 보냅니다. 그와 동시에 관리자에게 해당 요청 내용과 승인 메시지를 전송합니다.
3: 관리자는 해당 내용을 확인하고 승인을 누르게 됩니다.
4: 관리자의 승인을 받으면, 2번에서 생성한 유니크한 이름의 토픽에서 요청 메시지를 읽어옵니다.
5: 메시지 내용에 따라 해당 서비스 카프카에 토픽을 생성합니다.
6: 토픽 생성 완료되면, 사용자에게 완료 메시지를 전송합니다.
추가적으로 유니크한 이름의 토픽을 사용하게 된 이유에 대해 잠깐 설명하겠습니다.
처음에는 워크 큐 역할을 담당하는 토픽을 하나의 토픽으로만 구성하려고 생각했었습니다. 하지만, 카프카는 일반적인 메시징 큐 시스템인 RabbitMQ와 달리 이미 처리한 메시지를 삭제하지 않고 보관하고 있기 때문에 오프셋의 리셋 등이 발생할 때, 해당 토픽에 이미 처리되고 보관 주기가 남아 있는 메시지들은 중복으로 될 수 있었습니다. 그래서 보다 더 효율적인 방법은 없을까를 고민한 끝에 유니크한 이름의 토픽을 생성하고, 해당 토픽으로 들어온 작업이 완료되면 해당 토픽을 삭제하는 방법으로 처리하면 매우 깔끔하게 처리할 수 있을 것 같아 유니크한 토픽 이름을 사용하였고, 실제로 너무 잘 동작하였습니다.
위의 그림과 같이 프로세스를 변경한 후 관리자의 누락이나 실수 등을 최소화할 수 있게 되었고, 토픽이 실제로 생성되기까지의 시간도 기존의 방식과 대비하여 매우 짧아졌습니다. 새롭게 만든 페이지는 기존 대비 불편사항들이 많이 개선되었고, 카프카를 사용하는 사용자들도 편하게 사용할 수 있게 되어, 저 개인적으로 굉장히 만족스러웠습니다.
결론
이번 개선 작업을 진행하면서, 저 개인적으로 전에 이루지 못했던 django에 대한 공부도 했고, 그 외 여러 가지 고민을 하면서 배우는 점도 많았습니다. 또한 전체적인 프로세스도 개선되어 굉장히 만족하고 자신감도 얻게 되었습니다. 하지만 저 혼자였다면 절대로 할 수 없었고, 제가 잘 모르는 부분을 옆에서 친절히 잘 알려주신 동료분들 덕분에 마무리할 수 있었다고 생각합니다. 같이 일하고 있는 동료들의 고마움을 다시 한번 느꼈고, 저의 이 글을 통해 카프카 활용을 고민하시거나 저처럼 토픽 생성 페이지를 만들어야 하는 분들에게 조금이나마 도움이 되었으면 합니다. 추운 겨울 감기 조심하세요!!
Special thanks to 블리*, 루나*, 코*
