วีดีโอ

23:37 고분..!! 고군…분투한

말씀하신 방식이 맞습니다. 11:12 에서 미접속 유저에대한 푸시 설명을 하고있어요. > 이 땐 그냥 API 호출을 수행하나요? 그냥 API 호출이 무엇을 의미하는지 잘 모르겠지만, 푸시알림을 담당하는 서비스가 있고 채팅서버는 이쪽으로 gRPC 요청을 보내는 방식이에요. 푸시 알림 담당 서비스는 Android는 FCM, iOS는 APNS을 통해 알림을 모바일 디바이스로 보내고 있어요. 이 때 채팅서버에서 받은 데이터를 적절히 조합해 모바일로 보내기 위한 페이로드를 OS별로 만들어서 보내야해요. 여기에는 title, subtitle, body, badge count, profile image 등이 해당돼요.

@@Andrewkwon-ec7rk 답변 정말 감사드립니다. 추가적인 질문을 드려도 될까요? 1. 컨슈머는 분리된 서버인가요? 만약 그렇다면 채팅 서버와의 웹소켓 세션관리 등을 관리하고 요청과 세션 정보를 토대로 채팅 메시지를 처리할거 같은데, 채팅서버에서 이를 처리해도 되지 않은지 궁금합니다. 2. 그리고 컨슈머가 채팅서버로 메시지를 전달할 때 서버 IP기반으로 Rest API를 호출하나요? 3. 쿠버네티스 환경이라면, 동적으로 늘어나는 파드의 IP(채팅서버의 IP)를 어떻게 불러오셨는지 궁금합니다.

1. 컨슈머는 분리된 컴포넌트로 따로 pod로 띄우고 있어요. 컨슈머에서는 웹소켓 세션관리는 따로 하지 않고 유저가 어느 서버에 접속되어있는지 key value store에서 확인만 해요. 2. 컨슈머가 채팅서버로 전달할때는 key value store에서 조회한 유저가 붙어있는 서버의 IP 기반으로 gRPC 연결을 맺고 요청을 해요. 3. 동적으로 pod가 늘어나도 pod의 IP를 key value store에서 조회해서 알게되는 방식이기 때문에 미리 IP들을 알아내서 연결을 맺을 필요는 없어요. 처음 서버가 연결될때는 커넥션을 맺겠지만 이후 요청은 맺어진 커넥션에서 요청하는 정도일거에요. 추가로) pod의 DNS를 보고 현재 pod가 유효한 pod인지 lookup 하는 단계를 거쳐요, 이 때 유효하지 않은 pod라고 판단이 되면 key value store에 저장된 해당 값을 삭제해서 보정해요. 만약 미리 연결이 필요한 상황이라면 headless service를 이용해 IP를 가져올수 있을거에요.

위에 대한 내용은 7:18, 9:37에서 설명하고 있어요.

@@Andrewkwon-ec7rk 답변 정말 감사드립니다!

input을 조종하는 조종기를 만든셈이네요. 재밌네요.

넵 맞아요. 데이터베이스에 메시지 저장요청을 하고, 클라이언트와 웹소켓 연결을 맺고, 릴레이 요청을 처리하는 등의 작업을 해요

@@Andrewkwon-ec7rk 감사합니다!

1. 예를들어 클라이언트가 최근 메시지가 발생한 채팅방 10개를 알고 싶을 때, 서버에서 display_idx를 기준으로 ORDER BY 처리하지 않는다면 모든(또는 많은) 채팅방 데이터를 조회해서 클라이언트에 내려줘야 해요. 클라이언트는 내려받은 데이터를 기반으로 정렬해야 하기 때문에 그렇게되면 DB 리소스 낭비와 네트워크 비용 증가로 이어질 수 있어요. 따라서 display_idx를 업데이트하면서 서버가 필요한 데이터만 클라이언트에 내려주는 것이 업데이트 비용이 들더라도 DB와 네트워크 리소스를 절약하기 위한 트레이드오프적 선택이었다고 보시면 될 것 같습니다. 2. 일단, 핸들러에서 여러 개의 고루틴을 통해 작업을 처리해도 핸들러에 부하가 크게 발생하지않는 이유는 병렬로 리소스를 로드하는 작업들이 cpu bounded task가 아닌 대부분 DB나 네트웍을타는 io bounded task들이기 때문에, 핸들러 자체에 쉽게 부하가 발생하지는 않아요. 그리고 하나가 딜레이되서 문제가되는 경우에는, 개별적으로 최적화된 타임아웃을 설정해서 가장 느린 리소스가 전체 핸들러를 지연시키지 않도록 설계할 수 있어요. 추가적으로 그 리소스를 제외하고(null처리) 나머지 데이터만 반환하는 방법도 존재합니다. 좋은 질문 감사합니다.

좋은 질문입니다.! 시간관계상 Pub/Sub을 사용하지 않은 이유를 짧게 말씀드렸는데요. 조금더 자세히 말씀드려볼게요. 먼저 Pub/Sub을 사용하게되면 어떤 토픽으로 구독을 해야할지 고민해봐야하는데요. 1. 채팅방 아이디 구독 2. 단일토픽 구독 3. 유저 아이디 구독 4. 서버 인덱스 구독 네가지 정도 생각해 볼수 있어요 첫번째 채팅방 아이디로 구독하는 방식은 유저가 서버1로 접속할때 서버1은 해당 유저의 모든 채팅방 아이디를 가져와서 구독해야하는 상황인데 모든유저가 접속할때마다 유저의 모든 채팅방을 가져오는게 부담이고 토픽수가 너무많아지는 상황이라 성능이슈 문제도 있어서 적합하지 않다고 보았구요. 두번째로 단일 토픽을 구독하는 방식은 메시지가 발생할때마다 모든 채팅서버가 해당 메시지를 처리해야하는 상황이 오고, 이때 접속한 유저가 있다면 해당 서버에서 처리하면되지만 미접속 유저들에게 푸시를 보낼때는 어떤 서버에서 책임지고 푸시를 보내게 할지 설정하기가 어렵다고 판단했어요. 세번째로 유저아이디 기반으로 구독하는 방식은 예를들어 100명 채팅방에서 메시지를 발송한다면 각각의 유저 아이디를 기반으로 100번 이벤트를 발행해야 하고 구독하는 쪽에서 해당유저에게 보낼 메시지이벤트 비즈니스로직을 처리해야하는데요, 이때 배치를 사용해 효율적으로 서비스들에게 요청을 하지 못하고 단건으로 요청하게 되서 비효율적이 될거라고 판단했어요. 이벤트를 발행하기전에 먼저 서비스에 호출해서 데이터를 먼저 패치하는 방법이 있는데 이러면 Pub 메시지가 비대해져서 비효율적이 될거라고 생각했어요. 또한 유저아이디 기반 구독방식의 경우 미접속 유저를 체크하기가 어려워요. Pub/Sub을 사용하는 이점은 유저의 세션정보를 레디스에 따로 저장하지 않는 장점이 있는데 구독은 유저가 접속할때만 될거라 어느 유저가 미접속했는지 판단하는 단계가 또 필요하게 될거라고 보았어요. 네번째로 statefulset으로 생성한 서버 인덱스를 구독하는 방식을 사용할 수 있을텐데요, 유저id를 서버 대수로 샤딩해서 유저 아이디만 보더라도 어느 서버에 붙을지 미리 규칙을 정한뒤 100명 채팅방에 메시지가 발송되면 샤딩기준으로 유저아이디를 묶어서 이벤트를 발행하는 방법이에요. 이 방법을 적용하려면 현재 deployment로 되어있는 서버를 statefulset으로 변경해야하고 웹소켓 서버 앞단에서 유저 아이디 기반으로 서버에 배정하는 프록시 서버를 추가 구현해야하는 상황이에요. 이건 이후에 추가 개선안으로 생각해보고 있는데 릴레이 시스템을 전반적으로 많이 변경해야하는 상황이라 부담이 되어 선택하지 않았어요. AS-IS 구조는 메시지큐로 이벤트를 발행하는 구조였기에 최소한의 수정으로 효율을 낼수있는 방안을 적용하여 개선했다고 보시면 됩니다. 제가 Pub/Sub을 많이 다뤄보지는 않아서, 만약 유저아이디 기반으로 배치를 효율적으로 처리할수있는 방법이 있다면 알려주시면 감사해요~

GPT에 물어보니 PUBSUB NUMSUB [user ids…] 을 사용하면 구독 개수를 확인할 수 있다고하네요. 메시지 요청에 위 연산을 추가하면 0인 값들을 모아서 미접속유저로 판단하고 푸시를 보낼수 있겠군요.

@@Andrewkwon-ec7rk publish를 배치성으로 할수 있지 않나 나이브하게 생각했는데, 제 기억이 틀렸었군요:) Stateful 이용한 구현 또한 오프라인인 유저에게 푸시를 발송하는 로직 + 지금의 key value 와 consumer를 활용한 방법에 비해 큰 이점이 없음(지금 제가 생각하기에는 그런데, 있다면 말씀 부탁드립니다) + 말씀하신대러 추가적인 프록시 서버 구현 필요로 인해 포기할수밖에 없을 것 같아요 다만 지금의 구현에서 consumer가 scale in/out 될시에 rebalance time 때문에 메시지 발송이 상당히 밀리거나 그런 현상은 없었을까요? 만약 mq로 카프카를 사용하고 있었다면 필연적인 일이라서요

@@가사나다 "Stateful 이용한 구현 또한 오프라인인 유저에게 푸시를 발송하는 로직 + 지금의 key value 와 consumer를 활용한 방법에 비해 이점"

에 대해 먼저 말씀드릴게요,
 생각한 아이디어는 다음과 같아요. 1. 유저가 어느 서버에 붙을지 규칙을 정한다. 2. 규칙에 맞게 유저들이 접속할때 해당 서버에 연결시킨다. 3. 메시지 요청시 이벤트를 받아야 할 유저들을 해당 규칙에 따라 어느 서버에 보낼지 나눈다. 4. 서버마다 한번의 요청에 유저 아이디를 묶어서 보낸다. 5. 릴레이 요청을 받은 서버는 유저아이디를 순회하며 접속한 유저에게 이벤트를 전달한다. 6. 유저아이디를 순회했을때 접속하지 않은 유저들에게는 푸시를 보낸다. 위 방법을 적용하면 가장큰 장점은 Redis를 사용하지 않고도 메시지 전달을 할 수 있게된다.
라고 생각해요. Redis에 유저가 접속할때마다 or 배포할때마다 세션정보를 관리하는게 부담이 되서요. Redis 정보를 100% 신뢰 못할때도 있구요

​@@가사나다 "다만 지금의 구현에서 consumer가 scale in/out 될시에 rebalance time 때문에 메시지 발송이 상당히 밀리거나 그런 현상은 없었을까요? " 이건 히스토리를 잘 몰라 팀원분들에게 여쭤봤는데요, 저희 경험을 공유하자면, 현재 저희 시스템에서는 컨슈머가 scale in/out될 때의 리밸런스가 메시지 발송에 큰 지연을 일으키지는 않았어요. 그 이유는 파티션 수가 많지 않고, 컨슈머와 적절히 분배되어 있어 리밸런스에 걸리는 시간이 비교적 짧기 때문이에요. 또한, 운영 중에는 장애 대응을 제외하고는 빈번한 스케일 조정이 없었기 때문에, 리밸런스로 인한 영향을 크게 체감하지 못했어요. 평상시에는 lag이 높은 수준이 아니고 배포 시에는 전체 파드를 한꺼번에 내리지 않고 점진적으로 배포하는 방식을 사용하고 있어 lag를 줄이는 데도 도움이 되고 있어요. scale out 시에는 메시지 처리량이 늘어나 오히려 발송이 밀리는 염려를 줄일 수 있어요. 만약 순간적으로 피크를 치는게 빈번한 환경에서 리밸런스 시간이 걱정된다면 이를 최소화할 수 있는 여러 전략을 고려해 보시는 것도 좋을 것 같아요.

개인적으로 파악된 내용을기반으로 답변드립니다. 1. nextjs가 배제된 사유 nextjs가 배제된 사유는 영상에서도 말씀하시지만 처음ssr을 적용하기때문도 있다고 했는데 이런관점에서는 보통 새로운 프레임워크 도입할때 모든 사람들이 해당 내용을 학습하고 적용하는것도 문제중하나고 많은 실패와 연구를 거쳐서 적용하는게 일반적인데 해당 시기에 그럴만한 여유가 없었을수도 있던것 같습니다. 그리고 nextjs가 좀 최근 몇년간 대격변패치를 좀 자주해서 적용시점이 버전12~13언저리쯤이라면 좀 불안했었을것 같아요. 또하나의 이유는 회사별로 각자의 고유한 관습과 특정 문제를 해결해기위한 방식이 있는데 이를 nextjs에 녹이기에 좀 문제가 있었을수도있습니다. 기본적으로 nextjs는 프레임워크이기때문에 자신의 고유한 규칙안에서 작업이 이루어지는것을 강제할때가 있는데 이와중에 nextjs에서는 핸들링이 안되는 작업이 있었을수도있습니다. 이러한 이유때문에 저같은경우도 nodejs로 express를 올린다음 그위에 nextjs를 올리고 그위에 graphql같은 서버도 올리는형식으로 커스텀해서 사용하며 트랜스파일링또한 nodejs서버따로 nextjs서버따로 진행하여 후처리로 조합하는 형태로 실서버를 운영하기때문에 이와 비슷한 내용이 아닐까싶어요. 2. image 업로드시 업로드되는 속도를 높이는 팁. 이 질문은 개인적으로는 고려해야할 사항이 너무 많아서 잘못된 질문같습니다. 결국 클라이언트에서 각종 서비스 서버까지데이터 전송 및 요청의 과정에서 얼마나 지연을 줄이거나 최적화를 하냐의 관점입니다. 그 과정에서 어떻게 타협하여 무엇을 생략해도 되고 안되는지는 서비스의 상황에 따라 너무나 많아서 좀더 본인의 상황을 자세히 설명해주시면 다른분들이 답변을 더 잘해주실것이라 생각됩니다. 그래도 따라서 영상에서 벗어나지 않는 내용을 기반으로 말씀하신 uploadthing이 "uploadthing.com" 이 플랫폼을 이용하시는것이라면 당장 생각나는것중에 가장 간단한것은 aws s3중 가장 리전이 가까운것을 이용하던가 업로드하는 국가또는 지역과 가장 가까운곳에 스토리지 서버를 운영하는것과 업로드시 데이터를 압축또는 전송에 최적화된 폼,셋을 찾아서 규격화하여 업로드하는것이 지금보다 더 빠른 업로드가 가능하지 않을까 생각됩니다. 이는 운영 및 배포와 관련된 도메인지식이 꽤나 필요해서 질문의 상황으로 봤을때 직접 여러 환경에 배포 해보시면서 실험을 하며 맞춰가보는것이 제일 최선일것같습니다. 여기서는 굉장히 간략하게 설명하고있지만 실제로는 시장평가를 받은 서비스의 경우에는 서버에도 한개의 서버에서 모든것을 핸들링하지않고 메일을 처리하는 서버, DB를 처리하는서버, 캐싱하는 서버등 각각 세부적으로 나누어서 관리하는것이 일반적인 관행입니다. (시장평가를 받기전 방법은 다름) 이곳에서 굉장히 생략된 방식의 흐름은 (클라이언트 => CDN => 릴레이서버(있을수도있고 없을수도 있고 순서가 이곳이 아닐수도있음) => 웹서버 => 각종 서비스 서버) 이런식인것 같습니다. 3. expo를 이용하여 안드로이드와 ios를 동시에 개발한건에 관하여 말씀하신 내용은 크로스플랫폼과 하이브리드 앱개발에대한 내용이 동시에 들어가 있는 내용인데요. 지금은 잘 모르겠으나 1년쯤전에 expo를 접했을때는 간단한 내용들을 개발하기엔 굉장히 쾌적했지만 조금만 커스텀하게 제어하는 상황이 발생하는경우에는 핸들링하지 못해서 결국 react native를 쓰는것보다 난이도가 더 올라가는 상황이 발생했던것으로 기억합니다. 저는 최근 다시 flutter를 이용하여 동일한 개념으로 접근하여 개발하고있지만 expo는 실제로 의미있는 서비스를 개발할때는 추천하지 않습니다. 지금도 그런상황인지는 파악이 안돼서 확실하게 답변은 못드리겠으나 1년사이에 그렇게 많이 달라지지 않았을 것 같습니다. 그리고 속도는 당연히 네이티브보다 느릴수 밖에 없는이유가 개념자체가 크로스플랫폼은 한번의 개발로 안드로이드와 ios를 둘다 대응하고싶어서 나온 개념이기도 하기때문에 최적화적인 이슈가 생길수밖에 없습니다. 네이티브를 사용하며 얻는 이점은 사용하는 기기의 os친화적인 언어를 이용하여 직접 개발하기때문에 한번 개발하고 빌드된 파일은 별도의 번역이 필요없지만. 크로스플랫폼은 빌드된 파일이라고 하더라도 해당 파일을 항상 번역하는 기능이 필요한 상태입니다. 따라서 이런 요인들로 크로스플랫폼쪽 개발 즉 ,여기서는 말씀하신 expo가 더 느릴 수 밖에없습니다. 하지만 개발하고자 하는 내용이 매우 단순하고 간결하다면 이러한 내용은 무시하시고 개발을 진행하셔도 됩니다. 당근테크의 개발자분들께서 답변을해주시길 원하셨을텐데 뭔 지나가던 웹개발자가 답변을드려 좀 죄송스럽기도 합니다. 정확하지 않고 모호한 내용들 또한 죄송하며 다른 고수분들께서 추가적인 답변을 보다 자세히 해주시지 않을까 기대합니다. 건승하세요.!

@ 상세한 답변 정말 감사드립니다. 이렇게 장문의 글을 남겨주시니 몸둘바를 모르겠습니다. 독학으로 여기저기 헤매다가 한줄기 빛을 얻은거 같습니다. 코드 최적화 및 서버 리전(유료결제) 변경으로 속도는 어느 정도 타협했고 말씀해주신 서버 배분에 대해서도 헤딩?을 해보려 합니다. 다시 한번 시간 내주셔서 감사드립니다. 꾸벅

와드박고갑니다 저도 알려주십셔😢

클라이언트에서 채팅방 리스트 조회 요청을 할때 최신순으로 보여주기 위함인데요, 만약 최신순으로 정렬을 하지 않고 서버에서 보내줘야 한다면 페이징 없이 해당 유저의 모든 채팅방을 다 보내줘야하는 문제가 생겨요. 간단히 말하면 유저의 채팅방을 최신메시지 페이징 단위로 조회하기 위함이라고 보시면 됩니다.

매롱