[Review] 시스템 디자인 스터디2 - 2주차 후기

안녕하세요!

K-DEVCON (이하 “데브콘”) 그로스 매니저 박종훈입니다.

 

시스템 디자인 스터디가 돌아왔습니다 : )

이번 스터디에서는  『가상 면접 사례로 배우는 대규모 시스템 설계 기초 2 (1~6장)』  를 보며 함께 디자인 해볼 계획입니다.

 

이 글에서는 12/11 (목)에 진행된 스터디에서 나눈 이야기를 정리합니다.

이번 시간에는 “주변 친구” 에 대한 시스템 설계를 해보았습니다.

---

“주변 친구” 라는 서비스는 뭘 하는 서비스 일까요?
주변 친구 서비스는 본인 위치를 기반으로 인근의 친구 목록을 보여주는 서비스입니다.

지난장에서는 정적인 위치 정보를 다뤘다면 이번 장에서는 동적인 위치 정보를 어떻게 처리할지에 대해서 고민을 할 수 있는 장입니다.

사실 요즘 이러한 서비스는 많이 사라져 있습니다. Telegram 에서는 2024년, Facebook 에서는 2022년, Twitter (현재는 X) 에서는 2019년 사라진 것으로 보입니다. 텔레그램에서 이야기 하기로 이 서비스를 사용하는 유저가 실제로 0.1% 미만이였고, 봇이나, 사기꾼(scammers) 들로 인한 이슈가 있었기 때문에 서비스를 종료하였다고 밝혔습니다.

그래서 과연 우리가 이번장에 대해서 논의할 필요가 있는지 생각도 해보았는데, 그럼에도 스터디 자체로는 의미가 있다고 생각한 내용이였던 것 같습니다.

개인정보와도 연관되어 있기 때문에, 현재는 사람들 간의 거리를 보여주는 것이 아닌, 비즈니스와 연결하려는 형태로 변경되어 운영되는 경우가 많은것 같습니다.

 

[1] 기본적인 시스템 설계

이번 서비스는 동적 위치 정보는 사용자의 이동에 따라 업데이트되어야 하므로, 단순히 정적인 데이터를 처리할 때와 달리 높은 쓰기(Write) 부하와 실시간성 보장이라는 큰 숙제를 안고 있습니다.

 

책에서 제시하는 기초 설계안은 다음과 같습니다. 이번 장의 기초 설계안도 매우 단순합니다.

주변 친구 서비스 개략적 설계안 - 출처: 가상 면접 사례로 배우는 대규모 시스템 설계 기초 2

 

여러분은 이 기초 설계안에 만족하시나요?

 

저는 조금 아쉬움이 남았습니다. 특히 이 서비스는 모바일 환경에서 주로 사용될 텐데, 모바일 OS 특성상 앱이 백그라운드로 넘어가면 웹소켓 같은 지속적인 연결(Persistent Connection)을 유지하기 어렵다는 현실적인 제약이 있기 때문입니다. 또한, 위치 업데이트가 완전한 '실시간'일 필요까지는 없다고 판단했습니다.

 

그래서 저는 웹소켓은 데이터 수신(Read)용으로만 사용하고, 내 위치 전송(Write)은 연결 유지 부담이 없는 REST API로 분리하는 전략을 구상해 보았습니다.

 

변경된 설계안

 

위와 같이 설계할 경우 연결 유지에 들어가는 리소스를 줄이고 확장성을 확보할 수 있을 것으로 기대됩니다.

참고로 웹 소켓 방식에서 쓰기 작업을 HTTP API로 바꾼 사례는 채팅 시스템 설계(https://k-devcon.com/154)스터디 할 때, 슬랙(Slack)의 스터디 케이스 에서도 다뤘었습니다.

 

[2] SSE (server-sent events)

이렇게 구조를 변경을 하고 나니 ‘데이터를 수신만 하는 거라면 웹 소켓이 아니라 SSE 를 사용하는건 어떨까?’ 라는 의견도 나왔습니다. SSE 는 서버에서 클라이언트에게 실시간으로 데이터를 보낼 수 있는 방법 중 하나입니다. 단, 웹소켓과는 다르게 단방향 (서버 → 클라이언트) 으로만 통신이 가능합니다.

 

사실 지난 1권 스터디 때에도 SSE 의 사용 가능성에 대한 이야기를 종종 나눴었는데, 실제로 써본 사람이 없었어서 아쉬운 생각이 있었습니다. 하지만 이번 스터디에서는 실제로 사용중이신 스터디원이 있어 관련된 이야기를 들어볼 수 있었습니다.

 

ChatGPT, Gemini, Claude 등 최근 유행하는 LLM 챗봇들에서 SSE를 적극적으로 사용하고 있다고 합니다. LLM이 답변을 완성하는데 시간이 많이 걸리기 때문에, SSE를 이용하여 사용자에게 중간중간 데이터를 전송하여, 부드럽게 완성되는 것처럼 만들 수 있다고 합니다.

 

기존에 이야기를 나눴을 때, SSE 에 대해 걱정 하는 부분은 데이터 유실 부분이였습니다. 이에 대해서도 어떻게 생각하시는지 여쭈어 보았는데 생각보다 유실이 발생되지 않는다는 답변을 해주셨고, 하지만 그와 동시에 유실이 발생할 수 있는 것은 맞기 때문에 유실이 발생되었을 때 어떻게 처리하는지에 대해서도 설명을 해주셨습니다.

 

데이터가 유실되었을 경우를 대비하여, 최종적으로 생성된 데이터를 한 번에 불러올 수 있는 API를 제공해줍니다. 이를 통해 사용자의 연결이 끊어지더라도 다시 연결되었을 때 원하는 데이터를 조회 할 수 있도록 합니다.

 

[3] Redis Pub/Sub

이번 장에서는 Redis Pub/Sub을 사용하여 데이터를 전파하는 설계를 사용하였습니다.

 

Redis Pub/Sub 의 경우에 사실 대규모 처리에는 아쉬운 부분이 있습니다. Redis 7 에서 나온 Sharded Pub/Sub 를 통해 좀 더 개선되긴 하였지만, 그럼에도 아직 대규모의 처리에는 아쉬움이 있다고 합니다.

 

이를 개선하기 위해 책에서는 서비스 디스커버리 와 안정해시를 사용하는 방식으로 설계를 진행하였습니다. 모든 채널이 독립적 이기 때문에 가능한 방식이라고 생각됩니다.

안정해시를 통한 Redis Pub/Sub 확장 - 출처: 가상 면접 사례로 배우는 대규모 시스템 설계 기초 2

 

안정해시를 통해 어떤 Pub/Sub 서버를 사용할지 정한 후, 해당 서버의 특정 채널에 Publish(발행) 요청을 보냅니다. 그러면 해당 채널을 구독하고 있던 웹소켓 서버는 데이터를 수신하고, 웹소켓을 통해 실제 사용자에게 데이터를 전달하는 방식입니다.

 

처음에는 왜 지난시간에 했던 것처럼 앞단에 Proxy를 두고 클러스터링을 하지 않을까 생각을 했었는데, 검색해보니 Redis Pub/Sub의 경우 Clustering을 하더라도 적절히 샤딩하는 것이 아닌 브로드캐스트 하는 방식을 사용한다고 합니다. 따라서 Proxy를 두는 것이 의미가 없습니다.

또 Sharded Pub/Sub 의 경우에는 이미 내부적으로 라우팅 기능을 가지고 있기 때문에, 마찬가지로 Proxy를 추가하는 것이 크게 의미가 없고 오히려 오버헤드가 될 수 있습니다.

추가적으로 대화를 하면서 Kafka 와의 비교도 간단하게 진행해보았는데요. Kafka는 데이터를 영속적으로 저장하고 분산 처리하기 때문에 데이터 파이프라인, 이벤트 스트리밍, 대규모 비동기 처리에 적합하고, Redis Pub/Sub은 순간적인 알림이나 상태 전파와 같이 데이터 유실이 허용되는 인스턴트한 통신에 강점이 있습니다.

 

[4] 함수형 프로그래밍

책에서 Redis Pub/Sub 에 대한 대체제로 Erlang 과 Elixir 를 언급하였습니다.

Erlang의 경량 프로세스를 사용하여 각각의 사용자를 개별 프로세스로 모델링 하는 방법으로 대체하는 것을 제안합니다. 

 

Elixir 는 BEAM 이라는 Erlang VM 위에서 돌아가는 언어입니다. 좀 더 현대적인 문법을 제공합니다.

(마치 Java 와 Kotlin 과의 관계 같은 느낌입니다.)

 

하지만 아쉽게도 얼랭은 사용자가 많지 않은 언어입니다. 큰 장점이 있지만 일반적인 프로그래밍 언어의 컨셉과는 달라 쓰기 쉽지 않기 때문입니다.

 

Erlang을 사용한 사례가 무엇이 있을까 찾아보니 아래의 두가지 사례를 찾아볼 수 있었습니다.

• WhatsApp(2백만 커넥션/노드)
• RabbitMQ의 코어는 Erlang 언어로 작성

흥미로웠던 점은, 이 두 사례 모두 “대규모 동시 쓰기와 상태 관리”라는 어려운 문제를 다루고 있다는 점이었습니다.

 

—

 

이번주도 재밌게 스터디 하였습니다 : )

 

스터디에서 더 많은 이야기를 나눴지만, 오늘은 여기서 마쳐보겠습니다.

 

우리 스터디에서는 실제 사례들을 통해 문제를 어떻게 해결해 나갔을까 많은 고민을 해보고 이야기를 나눠보고 있습니다. 이번주도 다들 열심히 참여해주셔서 더 풍성한 스터디가 될 수 있었습니다. 다양한 도메인의 사람들이 모여, 다양한 이야기를 나눌 수 있어서 정말 좋은 시간이 되었습니다.

 

✅ 직접 스터디를 개설해보고 싶은 분이 계시다면, K-DEVCON에서 운영을  도와드리겠습니다. 데브콘의 '랩짱'에 도전하여 커뮤니티 성장을 함께 이끌어주세요!  K-DEVCON 운영진 (박종훈, 강시온) 에게 DM 부탁드리겠습니다😉