나는 과연 2주만큼 성장했을까?| 코드스테이츠 PMB 14기 | W7D4

 

 

오늘은 벌써 W7의 마지막 강의날. 

 

W6, W7에서 PM이 알고있어야할 개발 지식들을 배웠는데, 과연 2주동안 난 얼마나 성장했을까?

W6의 시작에 했던 과제를 다시 돌아보고 회고해보자

또 내가 새롭게 알게된 내용들을 더 중점으로 프로덕트를 뜯어보자!

---

    🕐   2주전의 나          

🐻 LINE LIVE 채팅  

LINE LIVE 앱에서는 라이브 방송 중인 동영상을 시청하면서 실시간으로 코맨트를 보낼 수 있는 채팅 기능을 제공하고 있다. 이 기능의 역할은 시청자들이 서로 대화를 즐기는 것에만 국한되지 않고 동영상 송출자가 시청자가 보낸 코멘트에 답변하면서 송출자와 시청자 사이의 접점이 되기도한다. 이런 실시간 채팅 기능은 티빙, 유튜브, 아프리카, 트위치 등에서 도 제공하고 있는 기능이다. 이러한 기능은 어떻게 작동되고있을까?

 

🐻 LINE USER FLOW  

현재 라인에서는 수많은 기능들을 제공하고있지만,

오늘 과제에서는 라인 기술 블로그에 기술되어있는 라인의 "라이브채팅" 기능에만 집중해보자. 

사용자 행동 흐름을 간단히 정리하였다. 

이런 간단한 유저 플로우 뒤에 어떤 개발 백그라운드가 뒷받침 되고있을까 생각해보자 

 

🐻 LINE  Chatting System Architecture  

LINE 의 기술 블로그에 따르면 채팅 시스템 아키텍쳐는 다음과 같고, 이해하기 쉽게 단순화한 차트도 추가하였다. 

여기서의 클라이언트는 같이 영상을 보고있는 시청자 1, 시청자 2라고 할 수 있다. 

위의 차트의 플로우를 따라 메시지가 어떻게 전송되고, 화면에 표시되는지 생각해보자.

 

 

#1 _ 메시지 전송 -  [ 클리이언트-> 서버 ]

시청자 1 (클라이언트 1)이 방송을 보며 메시지를 전송한다. 이 메시지는 클라이언트1과 연결된 채팅 서버1로 넘어간다.

#2 _ 메시지 처리 - [ 서버 ]

채팅 서버에서는 받은 메시지를 메시지 핸들러, AKKa Actors들을 통해 메시지를 처리한다. 

#3 _ 메시지 데이터 전달 - [ 서버 -> 서버클러스터 ]

메시지 처리과정을 거친 메시지 데이터는 서버의 마스터 역할을 하는 서버 클러스터로 publish 된다. 

#4 _ 메시지 publish - [ 서버 클러스터 -> 서버 ]

그 정보는 다시 서버 클러스터가 publish 하여 서버 클러스터를 subscribe 하고있는 다른 서버로 publish 된다.

그럼 다른 서버에 접속한 시청자2[클라이언트2]도 시청자1이 보낸 메시지를 받아볼수있게된다. 

이 메시지 데이터를 받아 각 클라이언트의 화면에 메시지 내용이 뜨게 된다.

#5_ 메시지 데이터 저장 - [ 서버 클러스터 -> 데이터 베이스 ]

이렇게 생성된 메시지 데이터 내용은 데이터 베이스에 저장된다. 

 

 

여기서 서버 클러스터는 각기 다른 서버를 하나로 묶어서 하나의 시스템같이 동작하게함으로써, 클라이언트들에게 고가용성의 서비스를 제공하는 것을 말한다. 쉽게 말해 분리된 채팅 서버1, 채팅서버2 을 하나로 묶어 하나의 시스템으로 작동하도록하는 역할을한다. 일시적인 데이터 저장과 Pub/Sub에 의한 서버 간 코멘트 정보 동기화를 위해 사용한다.

 

채팅 서버 내에는 메시지 핸들러, 채팅룸, 유저액터, 채팅슈버바이저같은 다양한 장치들이 배치되어있다. 이부분에 대해선 자세히 설명하지 않겠다. 

 

라인 라이브는 한번에 많은 양의 메시지 양을 처리하기 위해 채팅룸분할, 채팅 서버 분할 방식을 채택하였다. 

---

        오늘의 나        

 

사실 나는 개발을 했던지라 2주간의 수업내용이 거의 다 내가 얼추 알고있는 부분이 많았다. 

그래서 위에 내용을 수정하기보단 페어로부터 부족했다라고 피드백 받은 부분을 더 보강하고자한다. 

 

위의 과제 피드백에서 서버 작동에 대한 설명이 더 들어있으면 좋았을것같다는 피드백을 받았다. 

그래서 이번엔 그 부분에 대한 내용을 더 추가해보고자한다. 

 

서버에서 메시지를 처리하는 과정은 아래의 사진과 같다. 

채팅서버는 크게 ChatSupervisor, ChatRoomActor, UserActor 세 부분으로 구성되어있다.

각각의 장치들의 역할과 특징은 다음과 같다.  

ChatSupervisor 
JVM에 단 하나만 존재하는 actor이며, actor를 생성하고 감시하거나 외부에서 유입되는 메시지를 그에 대응되는 actor로 루팅하는 역할을 담당합니다. 우리가 정의하는 actor 중 가장 상위에 위치하는 것으로, 로직을 가지지 않으며 각 메시지를 실제로 처리하지는 않습니다.

ChatRoomActor
각 채팅방마다 생성되는 것이며, 채팅방에서의 코멘트 송신과 송출 종료 등의 이벤트를 나타내는 각종 메시지는 일단 여기로 전달됩니다. 자세한 내용은 뒤에서 설명하겠지만, 서버 간의 코멘트 동기화를 위해 Redis에 publish하거나 Redis에 코멘트를 저장하는 것도 여기에서 실시하며, 클라이언트에 전달해야 할 메시지는 UserActor로 패싱됩니다.

UserActor
유저별로 생성되는 actor이며, ChatRoomActor에서 메시지를 수신하여 자신이 담당하는 클라이언트의 WebSocket 커넥션에 페이로드 송신을 명령합니다.

 

각 기능들이 API로 구현된것인지, 단순 객체 생성 및 함수 호출로 구현되었는지 등 자세한 개발적 내용은 나와 있지 않아서 파악이 어려웠다. 또한 각 기능들간에 어떤 페이로드를 주고받는지 또한 궁금한 지점이었는데 이 부분에 대한 언급이 없어서 파악하기 어려웠다. 그러나 위의 서버 시스템 아키텍쳐를 통해 각각의 채팅 내용을 처리할때 스레드를 과도하게 사용하여 서버가 마비되는 일을 방지하기 위해 위의 장치들을 활용하였는지 알 수 있었다. 이런 모습을 보고 서버 리소스 관리의 중요성을 알게되었다. 

 

내가 라인의 PM이라면 채팅이 어떻게 처리되는지, 어떤 장치들에 의해 처리되고, 어떻게 서버들간의 동기화를 유지하고 채팅 내용을 비동기적으로 처리하는가 동기적으로 처리하는 가에 대한 이해는 필요할 것으로 생각이 되었다. 이러한 기술적 시행 내용을 이해하고있어야 고객의 니즈에 맞춰 어떤 부분을 수정 보완하면 될지 계획을 잡고 본격적으로 이야기 나누어볼 수 있을 것이라고 생각했다.