2024.03.08
전에 socket 연결 관련해서 선임 개발자 분이 redis를 고민하시며 pub-sub 형태에 대하여 잠깐 이야기하는 걸 들은 적이 있다. 궁금해서 몇 가지 여쭤보고 수박 겉핥기로 배웠었는데 좀 정확하게 알아보자.
아키택처를 설계할 때, request를 보내는 주체와 response를 받는 주체가 모호할 때. 즉 참여하는 단위들이 정보를 제공하기도 하고 정보를 제공받기도 해야하는 상황일 때. 거기에 추가적으로 그러한 단위들이 늘거나 줄거나 해도 서비스의 전체 이용에 지장이 없어야 할 때 사용하는 model이다.
정보를 주는 과정은 이러하다. Publisher가 middle ware에 특정 topic으로 데이터를 public 한다. 그럼 그 topic을 subscribe 하고 있는 subscriber가 middle ware에 접근하여 해당 topic의 정보를 가져간다. 제일 중요한 정보는 Publisher와 Subscriber는 나누어져 있는 것이 아니라 어느 단위이던지 두 가지 역할을 모두 할 수 있다는 점이다.
정보를 제공하는 주체는 정보를 제공받을 주체들을 모두 알지 못해도 된다. 이 말은 즉슨 제공받는 주제들과 의존성이 제거되어 느슨하게 결합되기 때문에, 정보를 제공받는 주체들을 늘리고 줄이는 데에 지장이 없어진다는 점이다. 해당 모델을 사용하지 않는다면 pulisher는 새로운 대상에게 정보를 제공해야할 때마다 새로운 함수를 추가하거나 제공받아야 하고 그 대상이 제거되면 다시 그 함수 또한 제거하는 과정을 거쳐야 한다.
오 심지어 어디까지 일이 진행되었는 지에 관한 정보 또한 middle ware가 관리하기 때문에 subscriber는 죽었다 살아나더라도 자신이 진행하던 일을 진행할 수 있게 설계할 수 있다. 그리고 이는 scaling의 유동성을 보장할 수 있다.
비동기 처리와 어울린다. 이러한 model의 구조는 publish 이후에 response를 받지 않고 subscriber가 알아서 가져가도록 하기 때문에 정보 제공자는 response를 기다릴 필요가 없다. 그리고 해당 task가 비동기 적으로 일 처리가 끝나 종료되었음을 다시 request를 받지 않아도 된다. 그 정보를 subscribe 해놓고 기다리면 해당 topic의 정보가 최신화 되었을 때 알아서 읽으면 되기 때문이다.
이거 완전 채팅이랑 어울린다.
내가 바로 든 생각은 카카오톡이었다. (비단 카카오톡 뿐만 아니라 모든 채팅 툴에도 적용될 수 있다. 그래서 채팅을 할 때 socket 연결에 추가적으로 pub/sub 구조가 필요하구나를 느꼈다.) 우선 카카오톡은 모든 client들이 정보를 제공 할수도 제공 받을수도 있다. 그리고 개개인끼리만 채팅을 하는 것이 아니라 단체 채팅방을 개설할 수 있으며, 단체 채팅방은 유저가 늘었다 줄었다 할 수 있다. 완전히 pub/sub model과 잘 어울리는 구조라고 생각했다.
데이터 흐름이 복잡한 대규모 서비스와 비동기 처리에 잘 어울리겠다