카카오톡 시스템 디자인 | WebSocket | 메시지 큐 | SQL vs NoSQL

[@llollapalooza]

제발 이런 시스템 디자인 많이 해주세여.. 한국은 시스템 디자인 컨텐츠가 너무 없어 씨가 말랐네여 ㅠㅠ 빅테크 전부 해주세여 🙏

[@hlog2e]

공감합니다.

[@이인호-x9s]

정말 유용한 내용이라서 감사합니다.. 그리고 정말 개발 잘하게 생기셨어욤..

[@kims_family]

완전 너무 좋습니다ㅎㅎ 이런 유익한 영상들 만들어서 올려주시니 정말 감사할 따름입니다. 올 연말도 즐겁고 행복하게 보내세요~

[@comg-dev]

감사합니다 행복한 연말 보내세요 ~

[@danteneha2058]

와...대박...고맙습니다 너무소중합니다..

[@Dreamain1102]

유튜브도 시스템 디자인이 궁금합니다.

[@comg-dev]

기본적인 비디오 플레이 방식은 제 체널에 있는 트위치 시스템 디자인과 비슷할 것 같습니다. 다른점은 트위치 같은 경우에는 비디오가 업로드 되는 동시에 video segment 들을 transcoding 하고 manifest 파일을 만들어야 하는데 유튜브 같은 경우에는 비디오 업로드와 시청이 동시에 일어나지 않기 때문에 업로드 할 때 transcoding 과 manifest 파일을 다 만들어 놓을 수 있기 때문에 좀 더 간단 할것 같습니다. 추천 알고리즘은 한번 공부해 보고 커버해보겠습니다.

[@Dreamain1102]

@@comg-dev 답변 감사합니다 연구 해볼게요 !

[@sapzilking]

정말 좋은영상이네요 감사합니다😊

[@comg-dev]

감사합니다 ~~~

[@콕월드]

시스템 디자인 재밌네요! MQ 핵심 기능 축약적으로 설명해주시고 넘어가주셔서 영상의 핵심 내용인 시스템 디자인에 더 집중할 수 있었어요! 다음 편도 완전 재미있을 것 같아요!

[@comg-dev]

감사합니다! 시스템 디자인 영상 안한지 좀 됐는데 조만간 한번 준비해야겠네요 ~ ㅎㅎ

[@박성수-u3v]

오… 너무 좋은 영상 감사합니다!! 이 시리즈 너무 유익해요!!

[@comg-dev]

힘이 되는 댓글 감사합니다!! 꾸준히 해보겠습니다 ~

[@jdhcoebakf]

채팅 앱 동시 사용자 수가 대략 100만명 정도라면, Chat Server는 (Scale out을 통해서든, 어떤 방법을 써서든) 최소 100만개의 Thread가 동시에 존재할 수 있어야 하는 환경으로 설정이 되어야 하는게 맞을까요?

[@comg-dev]

말씀하신것 처럼 동시 사용자 수가 100만이라면 최소 100만개의 Thread 가 동시에 존재할 수 있어야 합니다. 그래서 horizontal scaling 을 할수 있도록 design 하는게 중요한것 같습니다. 유저가 늘어남에 따라 linear 하게 scale 할 수 있도록

[@jdhcoebakf]

답변 너무 감사합니다!!🙇🏻‍♂️

[@comg-dev]

@@jdhcoebakf 네 또 놀러 오세요 ~

[@user-gs7ix3ui9x]

100만개. 스레드라니요 그걸 생성하는 순간 다 죽을겁니다 리눅스 건. 윈도우즈건 최적의 서버모델이 잇습니다

[@se_787]

시스템디자인 배울 곳이 마땅치 않은데 정말 잘 배워갑니다.

[@cncirhfiajdf]

push noti 서버와 로그아웃되어있다는 기준이 애매해서 질문드려요 일반적인 push noti라하면 카카오톡 기준 로그인이 되어있는 대상에게 전송된다고 생각하는데요.(로그인 되어있지만, 카톡이 백그라운드 상태) 애초에 백엔드에서 client로 보내려면 영상 설명처럼 chat server와 백그라운드에서라도 커넥션이 살아있어야하니까요. 보통은 로그아웃된 유저가 로그인된다면 그때 커넥션이 다시 연결되면서 push noti의 메세지가 전송될거 같아서요 (오래된메세지는 단순하게 db 정보를 http server로주터 받을 수 있고요) 영상의 flow chart는 push noti가 비로그인 대상이 추후 로그인후 커넥션이 연결됬을때 메세지를 보내기위한 일종의 예약 큐라고 이해하면 될까요?

[@comg-dev]

좋은 질문 감사합니다! 로그아웃한 경우보다는 앱이 켜져있는냐 꺼져있느냐의 차이로 보는게 맞을것 같습니다. 말씀해주신 것 처럼 로그아웃 되어있으면 push noti 가 가면 안되니까요. push noti 같은 경우에는 제 영상에서 설명하는 websocket 커네셕은 필요하지 않습니다. 챗 백엔드에서 직접 보내주는게 아니라 push notification 서비스를 통해서 나가기 때문입니다. push notification 의 시스템 디자인에 대해서 다음에 좀 더 깊게 들어가는 영상 한번 만들어 보도록 하겠습니다!

[@cncirhfiajdf]

@@comg-dev push notification 시스템에 대해서 찾아보고 공부해볼 수 있었습니다! 아주 유익하네요 감사합니다-!

[@comg-dev]

@@cncirhfiajdf 감사합니다!!

[@jaepark12]

너무 재밌어요! 감사합니다 :)

[@comg-dev]

재밌게 봐줘서 감사합니다 ~

[@legel9559]

감사합니다 ㅠㅠ 너무 도움됩니다

[@comg-dev]

감사합니다 ~ 널리 알려주세요 ~~

[@danielkim498]

잘 보고 있어요~ 🫡

[@comg-dev]

감사합니다 ~

[@soominhwang2542]

오늘도 유익한 내용 너무 감사합니다~~ 😊

[@comg-dev]

감사합니다 ~~

[@botbot-c2c]

항상 영상을 보면 정보 전달의 수준을 넘어서 어떻게 말을 해야 청취자들이 이해하는데 더 도움이 되는지 너무 잘 아시네요 ㅎㅎ 그렇게 말 하신다는건 설명하려는 부분을 완전히 이해를 바탕으로 말하시는걸텐데 코맹님은 모르는 내용이나 새로운걸 공부할때 어떤식으로 공부하시나요? 새로운 시스템디자인을 접한다고 했을때 구글링하는 팁이나 이렇게 피피티 만드는걸 실시간으로 방송해주시면 진짜 유익할것같아요!! 내용을 어떤식으로 정리하는지? 그런 부분도요 ㅎㅎ

[@comg-dev]

과찬이십니다 ㅎㅎ 요새 올리는 시스템 디자인 영상은 저도 공부를 해서 올리는중인데요. 일단 공부를 하기전에 대충 생각을 한번 해보는 편인것 같아요. 이번 영상을 예를 들면 내가 카카오톡을 만든 다면 어떻게 할까 해서 미리 생각을 해보고 어느정도 머리속에서 정리가 된 다음에. 공부를 하면서 제가 가지고 있는 생각이 맞는지 확인해보는식으로 공부를 하는것 같습니다. 맞는부분은 확인을 하고 틀린부분은 이게 왜 다른지 이해하려는 방식으로. 이렇게 하는게 아에 백지상태로 그냥 읽는것 보다는 효율적인것 같더라구요. 라이브로 준비하는거 하는것도 좋은 생각인것 같습니다. 기회되면 한번 해볼게요 ~~ 항상 감사합니다 ~

[@iihhhh0099]

너무 재밌습니다 감사합니다

[@comg-dev]

재밌게 봐주셔서 감사합니다 ~ ㅎㅎ

[@argenyoo9456]

좋은 영상 감사합니다! 채팅 별거없을 줄 알았는데, 생각 이상으로 어마무시한 시스템이었네요 머리가 아프지만 행복합니다~

[@whyyyyy7404]

웹소켓에서 갑자기 메시지 큐로 넘어가는게 궁금합니다! 웹 소켓으로 클라이언트와 연결을 하고, 그걸 통해 메시지를 받으면 카프카(메시지큐)에서 그걸 또 받아서 저장하고 채팅 서버로 보내는건가요..?? 혹시 답변해주신다면 감사드리겠습니다..!

[@comg-dev]

10:40 쯤에서 설명을 좀 더 자세하게 하는데. 웹 소켓으로 클라이언트와 연결을 하고 메세지를 채팅 서버가 받으면 그걸 메시지큐에 넘겨줍니다. 그러면 그 메세지 큐에 subscribe 하고 있던 서비스들이 새로운 메세지를 받아서 처리를 해주게 됩니다!

[@whyyyyy7404]

@@comg-dev 답변 감사합니다!! 혹시 만약 그럼 여기서 더 아키텍처가 변한다면 어떻게도 나아갈 수 있을까요?? redis pub/sub 을 추가하거나 그런 것들이 조금 헷갈리는데 궁금해서 여쭤봅니다..!

[@joont92]

와 궁금했는데 감사합니다. 설명을 정말 잘하시네요😊😊 하나 추가로 궁금한게 있는데요 메시지의 경우 우리가 카카오톡 채팅을 들어가있을 경우에는(정확히는 특정 채팅방에 들어가있을 경우) notify를 받지않고 바로 메시지를 수신하게 되는데요. 이게 가능하려면 chat server와 notification 서버 둘 다 토픽에 대한 subscribe를 하고, 뭔가 챗 서버에 접속중이라는 플래그를 통해 push 서버에서 해당 메시지를 버리거나 해야 할 것 같은데 맞을까요? 또 지금 쓰면서 생각해보니 일단 push는 다 보내고, 클라이언트에서 이미 읽은 메시지면 push를 버리는 방법도 있을 것 같은데 어떤식인지 궁금하네용

[@joont92]

그리고 또 하나 궁금한점..! 챗 서버는 유저 수 만큼 뜨게 될려나요? 그리고 유저와 유저 사이 관계 개수만큼 생기게 되는 구조인 것 같고 그러면 엄청나게 많은 토픽이 생성될 것 같은데 요것도 궁금합니다

[@comg-dev]

제가 푸시 노티피케이션을 많이 다뤄보지 않아서 정확한 답변은 힘들것 같은데요. 저는 서버 엔지니어라 Notification 보내기 전에 지금 접속중인지 한번 확인하는 방식으로 하지 않을까 싶은데요. 클라이언트에서 앱이 켜져있을 때 푸시 노티를 버리는 기능이 있는지 모르겠네요. 그게 가능하다면 그렇게 하는게 간단할것 같습니다!

[@comg-dev]

@@joont92 챗 서버 하나에 유저 여러명을 처리하기는 하겠지만. 결국 유저 숫자에 따라 Scale 하게 됩니다. 토픽수가 많이 생길것 같기는 합니다. 저도 구현을 해본건 아니여서 디테일로 들어가면 어떨지 확실하진 않은데 제가 알기로는 일단 메세지 큐들이 처리할수 있는 토픽수가 많은걸로 알고 있습니다. 그래도 너무 많아지다 보면 아무래도 Active 한 챗방 과 inactive 한 챗방을 좀 다르게 처리하는 방향으로 가야되지 않을까 싶어요. 그래서 inactive 한 챗방은 좀 느리지만 싸게 처리할 수 있는 인프라로 커버하지 않을까 싶습니다.

[@user-tw3be5ip9h]

진짜 쉽게 잘 알려주시네. 미쳤다맂.. 🎉

[@hlog2e]

어디서도 얻을 수 없는 지식을 배워갑니다. 감사합니다:)

[@johnchung8642]

클럽하우스처럼 소수가 말하고 200명 이상의 많은 사람들이 대화방에 참여하는 경우에는 어떤 식으로 메세지 큐를 사용하면 될까요?

[@comg-dev]

클럽하우스 같은 경우에는 말하는 사람들과 듣기만 하는 사람들 처리를 다르게 할 것 같다는 생각이 드는데요. 듣기만 하는 사람들의 경우에는 카톡같은 메세지 앱 보다는 트위치 같은 라이브 스트리밍과 디자인이 비슷하지 않을까 싶네요. 트위치 시스템 디자인도 영상중에 있으니 한번 확이해보셔요 ~

[@쇼츠생성-d3i]

유튜브 하면서 처음 댓글 남겨봐요! 유익한 영상 정말 감사합니다

[@goodjob4267]

신기하네요 ㅎㅎ 항상 느끼지만 헤어스타일은...? 자유로운 영혼 같으십키다

[@comg-dev]

ㅎㅎㅎ 자주 듣는 말입니다 ㅎㅎ 관리좀 해야되는데... ㅋㅋ

[@kohahn21]

그룹채팅에서 200명 제한이 아니고 1000명 정도 된다면 어떤 식으로가져가야될까요 ? group chat db를 캐싱하는 방향으로 가는게 맞을가요

[@comg-dev]

1000명 정도면 비슷하게 가면 될것 같은데 그룹챗이 10만 100만 정도 지원해야 된다 하면 좀 더 생각을 해봐야될것 같아요!

[@yujinkoh4129]

항상 유익한 비디오 감사합니다!! 다른 종류의 DB 비교하는 영상도 많이 도움될것 같아요~

[@comg-dev]

감사합니다 저도 항상 궁금해 하는 부분인데 한번 공부해보고 영상만들어 보겠습니다 ㅎㅎ

[@_14_69]

Push notify에 대해 질문이 있습니다.... 해당 서비스는 Chat Server가 아무도 구독하지 않을 때 넘어가는 구독서비스 입니까??? 기본적으로 Push notify는 모든유저를 구독하고 있고 web socket이 연결되면 Push Notify에서 구독을 취소하고 web socket이 끊어지면 Push Notify에서 다시 해당 유저를 구독하는 것입니까?

[@comg-dev]

좋은 질문 감사합니다. 개념 상으로는 말씀하신 방법이 맞습니다. 좀 더 디테일 하게 설명을 하자면 영상에서는 좀 간략하게 하려고 빠진 부분들을 넣어야 할텐데요. 일단 지금 로그인 해 있는 유저들이 누가 있는지를 트랙하는 서비스가 있어야 됩니다. 그리고 푸시 노티피케이션이 집접 메시지큐를 subscribe 하는게 아니라 그 앞에 작은 서비스가 subscribe 를하고 메시지 큐에 새로운 챗이 왔을 때 이 메시지를 받는 사람이 로그인 해 있는지 확인 하고 안 했을 경우에만 푸시 노티피케이션을 보내는 식으로 구현을 해야될 것 같습니다

[@layer9124]

자바 stomp socket으로 채팅방을 구성하는데 카프카랑 차이점이 궁금합니다.

[@userdbcjzs]

이 구조에서 각 마이크로서비스의 디펜던시가 되는 message queue가 spof가 될 수 있을 것 같은데, 이 문제는 어떻게 해결할 수 있을까요? secondary message queue를 하나 더 둬서 failover를 해야할까요?

[@김우성-q1o]

안녕하세요, 강의 잘 들었습니다. 그런데 HTTP polling은 쓰임새가 애매하다는 느낌을 받았는데요. 알람같은 기능은 SSE로 대체가 가능하고 완전 실시간이면 소켓을 쓰면 될 것 같은데 그렇다면 polling을 사용할 이유가 있을까요?

[@ziake]

Topic 을 per user 보다 chat room으로 하는게 좋을거 같네요

[@koonskoonskoons]

메세지 큐 랑 테스크 큐랑 항상 헷갈리는데 나중에 시스템 디자인에 테스크/worker 도 다뤄주시나요?

[@comg-dev]

말씀하시는 테스크 큐가 어떤건지 혹시 조금만 설명해주실 수 있을까요? 제가 생각나는건 Single server 안에서 multi-threading 할때 worker thread pool 과 task queue 를 가지고 하는거 인데 혹시 다른걸 생각하고 있는지 싶어서 물어봐요 ~

[@주성문-d6z]

안녕하세요 좋은 영상 만들어주면서 감사합니다. 시스템디자인에 궁금한게있었는데 많은 도움얻어갑니다! 그런데 혹시 영상에서 메시지큐는 다른영상에서 다뤄주신다는거 같은데 혹시 아직이신걸까요 찾아보니 없어서요!

[@comg-dev]

네 아직 … 시스템 디자인 컨텐츠도 다시 하려고 하는데 요새 정신이 좀 없어서 늦어지고 있네요! 조만간에 커버하도록 할게요 ~

[@sungtaekim8089]

영상 잘 보고 있습니다! 질문이 하나 있는데요, 웹소켓에서 Open connection을 유지하는 데에는 부하가 얼마나 드나요? 폴링, 롱폴링보다는 훨씬 작겠지만 그래도 무시할 수준은 아닐 것 같은데 대략적인 수치 비교가 궁금합니다

[@comg-dev]

제가 이쪽 전문은 아니라 잘은 모르겠지만 그냥 커넥션을 가지고 있다는 것 만으로는 리소스를 많이 먹지는 않을거에요 (어느정도의 메모리는 사용하겠지만). 그 open connection 을 통해서 얼마나 많은 데이터가 왔다갔다 하는지가 더 중요할 것 같습니다. 그리고 또 한가지는 cpu / memory / network bandwidth 이외에도 컴퓨터 하나가 가질수 있는 포트의 숫자가 65535개로 제한 되어있기 때문에 동시에 open connection을 65535개 이상 유지할 수 없다는 제한도 있습니다.

[@김정훈-l3v]

안녕하세요~ 항상 재밌게 보고있습니다! 오늘은 보다가 한가지 궁금한 내용이 있어서 댓글드려요~ 한명당 토픽하나를 생성한다고 말씀해주셨는데, 그럼 글로벌한 서비스라 억이 넘는 사용자들이 있다면 그 갯수대로 토픽을 생성하는것일까요? 서버를 스케일 업이나 아웃하여 가능은 할 것 같은데, 혹시 인원이 매우 많아질 경우 메시지큐 기반으로 다른 디자인이 있는것인지 궁금합니다!

[@comg-dev]

좋은 질문 감사합니다. 일단은 유저 수 대로 토픽을 만든다는게 영상에서 설명하는 디자인입니다. 아쉽게도 제가 메시지 큐를 직접 큰 스케일로 사용해본적이 없어서 이렇게 하면 스케일 하는데 전혀 문제가 없을거라고 확실히 답은 못해드릴것 같은데요 ㅜ. 시스템 디자인을 공부하다 보니 메시지 큐 가 많이 사용되는것 같아서 한번 좀 더 깊게 공부해볼 생각인데 깨달음이 있으면 따로 영상 만들어보도록 하겠습니다. 재밌게 봐주셔서 감사합니다 ~

[@Hola-u6i4h]

❤ 좋은 영상 너무 감사드립니다

[@mindolll]

영상 잘봤습니다! 그룹 영상통화같이 메시지보다 무거운 영상 트래픽은 어떻게 처리하는지도 궁금해지네요 ㅎㅎ

[@comg-dev]

오 좋은 댓글 감사합니다! 영상통화는 webRTC 라는걸 더 많이 사용한다고 알고있는데 저도 항상 궁금했던거라 한번 공부해보고 영상만들어 보겠습니다 ~

[@rm_rf]

잘 봤습니다 감사합니다~ 큰 그룹챗의 fan out 핸들링 방법도 알고싶네요.

[@quew9b]

메시지큐에 대한 심도 있는 영상도 있나요?

[@koonskoonskoons]

polling 같이 리퀘스트가 많으면 문제가 많이 생기는데, 전에 backend 서비스가 잠깐 다운/리부트/바운스 시켰을때 많은 클라이언트들이 polling 하고 있는상황 + 클라이언트가 다시 리트라이 하는 과정에서 저희 백앤드 서비스드들을 실수로 ddos 시킨적이 기억 나네요 허허;;;

[@comg-dev]

ㅎㅎ 이 댓글을 보니 리트라이 때문에 오히려 서버 오버로드되서 서비스 리커버리하는데 더 오래걸린 기억이 나네요 ㅎㅎ 이렇게 성장해나가는거 겠... 죠? ㅎㅎ

[@nick6267]

그룹에 있는 사용자가 여러 사용자에게 메시지를 보낼때 좀 더 디테일 하게 알 수 있었으면 좋았을 것 같아요! UserA, UserB를 유저별로 토픽을 만들 순 없을거고... 한명의 유저가 그룹내에 있는 199명에게 보낸다면 메시지를 처리할 때 컨슈머에서 그 데이터를 어떻게 처리하는지 또 서버가 300대인데 그룹 내 유저수가 200명이면 300대의 서버가 하나의 토픽을 컨슈밍 하는지?(카프카는 300개의 파티션으로 나뉘어져있지 않다면 불가능 그래서 300대면 파티션을 300대로 나눌까? 아니면 토픽을 더 만들까 등등) 또 위의 상황에서 유저를 가지지 않는 서버가 존재하게 될텐데 그 서버도 메시지를 컨슘해서 해당 서버에 이 요청을 처리할 수 있는 소켓이 있는지 체크하는지?ㅎㅎ이런 것들이 좀 궁금하네요 물론...좀 딥다이브 한 내용이기는 하지만요 항상 영상 잘 보고 있습니다 감사합니다

[@comg-dev]

좋은 피드백 감사합니다 ㅎㅎ 영상에서 이야기하는 디자인은 UserA, UserB를 유저 별로 토픽을 만드는걸 생각하고 있습니다. RabbitMQ 같은 경우 노드 하나당 >10,000개의 큐(토픽)를 핸들할 수 있다고 하니까 가능은 할 것같은데. 제가 이걸 직접 구현해 보지는 않았고 글로 공부한 거라 실제로 어떨지는 구현하면서 봐야될 것 같습니다. 이 질문에 답하려면 제가 좀 더 메시지 큐에 대해서 깊게 공부해봐야 될것 같습니다! 좋은 질문 감사합니다!

[@roeniss]

제목은 카카오톡 시스템인데 실상은 베이직한 채팅 시스템이라 조금 아쉽습니다. 현재 내용도 충분히 고퀄리티지만 (Facebook의 HBase를 설명하듯) 카카오톡만의 특징을 부록처럼 넣었으면 더 좋았을듯 합니다

[@comg-dev]

피드백 감사합니다!

[@핵자전거]

도대체 이해가 안가는게 카톡은 웹 앱도 아니고 그냥 스맛폰앱인데 왜 구지 http 프로토콜을 사용해서 wbesocket을 쓰고 또 메시지큐를 쓰는지 모르겠습니다. 그냥 socket으로 tcp송수신 하게 만들면 훨씬 간단하게 만들 수 있을 텐데 말입니다. socket으로 직접 코딩할 경우 기본 양방향에 kafka 같은 mq도 앗사리 필요 없겠죠. 성능도 완전히 넘사벽 수준으로 큰 차이가 날 것이고 운영비도 아마 수십 배 차이 날 수도 있을 겁니다. (socket으로 직접 코딩하는 것과 http 프로토콜과 kafka를 사용한 서버 성능차 생각보다 엄청나게 많이 납니다.) kafka 성능 좋아서 뭐 빠를 것이다 생각하시는 분들이 많은데 실상 kafka가 빠르다고 해도 http request에 비해 빠른 것이지 일반적인 socket의 메시지 송수신에 비해서는 성능 많이 떨어집니다. 또 kafka는 성능 향상을 위해 gathering을 하기 때문에 delay도 엄청나게 크죠.

[@comg-dev]

챗 서버랑 연결하는 할 때에는 Socket 으로 직접 연결해도 될것 같기는 합니다. 제가 전문가가 아니라 좀 틀릴수도 있는데 Socket 을 직접 쓰면 챗 서버 앞에 load balancer 가 있는 경우 혹은 앞에 Proxy 서버가 있는 경우에 Connection 을 route 하는게 http 프로토콜을 사용 할 때 처럼 편하게 될지 궁금하네요. Socket 으로 연결한다고 양방향에 메세지 큐가 필요없게 되지는 않을 것 같은게 항상 상대방이 온라인인게 아니기 때문에 메세지 온걸 MQ 넣어주고 그 MQ 의 subscriber 들이 받는 사람이 온라인 이냐 아니냐에 따라 알아서 처리 할 수 있도록 abstraction layer 가 있는게 나쁠것 같지는 않습니다. maintainability 와 efficiency trade off 는 항상 재미있는 토픽인것 같습니다. 좋은 의견 감사합니다!

[@핵자전거]

​@@comg-dev http 프로토콜도 어차피 tcp socket에서 동작하는 하나의 프로토콜일 뿐입니다. http 소켓은 stateless로 동작한다는 개념 하에 일반적으로 한 번의 request를 위해 1번의 접속을 수행하고 response를 받은 후 접속을 종료하기를 반복하죠. 1번의 request를 위해 매선 tcp 소켓을 접속했다 끊었다 하는 것입니다. tcp socket의 접속과 접속 해제 비용 상당히 비싼 처리입니다. 접속 시에 3번의 handshaking을 수행하며 접속 끊을 때는 더 많은 송수신을 수행합니다. 배보다 배꼽이 더 큰 처리란 것이죠. 이 과정에서 http는 엄청난 낭비가 일어나고 있다는 것입니다. 한번의 request 송신과 reponse 수신을 위해 수많은 데이터 송수신을 교환하는 것이죠. 또 보안 송수신을 하려면 훨씬 어마어마한 비용이 들어갑니다. 이것만 가지고도 그냥 socket 송수신 하는 것에 비해 10배에서 100배 가량 성능 차이가 날 수 있습니다. 게다가 text 기반의 protocol이기 때문에 이것을 매번 parsing해야 하고 메시지의 header 구조도 복잡하고 상당히 무겁습니다. 그냥 tcp socket으로 직접 프로토콜을 구현할 경우 1개 maching당 1초에 100만 request도 어려운 것이 아닙니다. 하지만 http로 하면 매번 request마다 접속과 접속 해제를 해야 되기 때문에 몇 만request도 쉽지 않습니다. 채팅서버 같은 경우 동시 접속수 역시 매우 중요한데... 접속과 접속해제를 반복하도록 설계된 웹서버의 특성상 apach 서버는 최대 동접 256 접속 밖에 허용하지 않습니다. 10k 문제를 극복한 ngix같은 웹서버도 많은 동접을 처리하기에는 성능이 많이 떨어집니다. 하지만 원하는 서비스에 특화된 tcp socket 서버는 수십만 접속도 처리 가능합니다. kafka를 사용하면 어느 정도 성능 문제 완화를 할 수 있지만 한계가 있다고 봅니다. 웹서버로 고성능 처리를 한다는 곳도 machine당 초당 수 십건 정도 처리하는 것이 현실입니다. 반면 tcp socket 으로 채팅 서버 같은 서비스를 구현하면 초당 수십만건 처리도 어렵지 않을 정도로 성능차이가 많이 납니다. 웹서버와 웹서비스는 어디까지나 stateless의 웹서비스를 개발하기 위해 설계된 것들입니다. 그걸 stateful 서비스에 양방향 송수신을 해야 하는 맞지도 않은 시스템에 억지로 적용해서 개발면 성능이 많이 떨어지는 것은 어떻게 보면 당연한 것이겠죠. 실제 카카오 채팅 서비스는 c++로 구현된 tcp socket 서버로 1 machine 셋당 수십만 접속 정도를 유지하도록 설계되어 있었던 것으로 알고 있습니다. 최근에는 이 c++로 개발된 서버를 개발자 수급으로 인핸 유지보수 문제로 웹기술들과 kafka를 사용한 구조로 바꾸려고 하는데 쉽지 않은 것으로 알고 있습니다.

[@comg-dev]

오 그렇군요 꿀 정보 감사합니다!!

[@nu11111]

socket은 접속이 끊겼을 때의 문제를 처리해주는 데 공수가 들어서 웹소켓으로 대체를 해서 사용하는 거로 알고있고, kafka는 데이터 유실 방지하기 위해 사용하는 거로 알고있습니다. 채팅에서 속도보다는 메시지가 정확히 오고가는게 중요할 것 같다는 생각이 드네요.

[@핵자전거]

@@nu11111 뭔 말같지도 않은 소린가요. socket 접속 끊겼을 때 문제 처리 공수가 들어서 웹소켓으로 한다??? 웹소켓도 그냥 tcp socket을 만든겁니다. 웹소켓 자체가 socket으로 만들어서 프로토콜만 입힌겁니다. socket에 문제가 있으면 Web socket도 똑같은 문제가 있어요. kafka는 데이터 유실 방지해요? 참... 안타깝습니다.