[sendbird - 3]사내 서비스 샌드버드 도입기 (feat.처음 그려보는 시스템 아키텍처 구성도)

[sendbird - 1]샌드버드 chat의 사내 도입? api 사용해보기 / Next + Nest

[sendbird - 2]샌드버드 chat 도입에 대한 고찰

 

---

 

 

도입 결정

장장 10월말부터 시작된 도입에 대한 얘기가, 일정이 밀리고 밀려 2월 초부터 시작되었다.

밀리고 밀린 일정인데 앞 뒤의 일정들이 모두 빡빡해서, 단기간에 제작해야했다.

 

다시 정리하자면, 기존 채팅서비스의 가장 큰 크리티컬한 이슈인

모든 작업이 끝난 후 렌더링이 된다는 점 (모든 동작을 수행하는 데 3~10초로 긴 시간)

 

을 해결하기 위해 소켓 서버에서 메세지 송신 시 동작을 최대한 경량화 했지만, 1~3초로 긴 동작시간을 가질 수 밖에 없었다. 기존 서비스에서, 메세지 기록을 남기고, 사내 고객 담당자들이 업무를 편하게 하기위한 관련 데이터도 따로 저장되어 나오기 때문에 더이상 경량화 할 수없었다.

 

카카오톡의 선렌더링 후 메세지 전송 실패 시의 UI

 

카카오톡처럼, 먼저 렌더링 시킨 후 서버 동작에 따라 송신 성공 여부를 보여주면 되지 않냐?

라는 측면에서 봤을 때에도 문제가 있었다.

 

채팅 리스트, 채팅 내부 코드를 전부 걷어내고 새로운 작업을 해야만 하는데, 내부 일정이 너무 빡빡하여 해당 작업에 시간을 할애할 수 없었던 환경 탓에, 수뇌부 측에서 샌드버드를 도입하자! 라는 결론이 나오게 되었다.

 

 

 

---

 

 

ERD

 

샌드버드 관련 테이블.

 

 

샌드버드 관련 부분만 떼내어 재생성한 테이블 구성도이다.

 

메세지 관련 작업이 가장 우선시될 것이기에 위와 같이 설계했던 것 같다.

 

샌드버드 서버 내에 다 저장이 되는 부분들이지만

서비스 특성상 고객을 담당하는 담당자가 배정되기 때문에, 담당자를 위한 기존 시스템에서 해당 채팅들을 불러오고, 기존 기능들이 원활히 동작하게 하기 위해, 혹시모를 백업을 위해 따로 사내 DB에 데이터를 저장하기로 했다.

 

 

 

 

시스템 아키텍쳐

 

★직접 구성해보고 그려보는 것이 처음이라 어색하거나 비효율적인 부분은 알려주시면 적극 피드백 수용하겠습니다.

 

처음 그려보는 구성도가 어색하실 분들을 위해.. 설계 의도 및 구성은 다음과 같다.

 

1. 개발 코드는 Git을 통해 관리되며, Git Action을 통해 CI/CD됨
2. Action running 시 각각 main / dev 브랜치를 통해 production / staging 컨테이너로 배포됨
3. production은 무중단 배포를 적용 시켜놓았음 (blue/green 배포, 백업/롤백 전략이 있음)
4. 클라이언트에서 nginx를 통해 프론트 컨테이너로 접근하고, 백엔드 컨테이너와 상호 소통을 함.
5. 프론트 단에서 sendbird SDK를 사용해 샌드버드 서버에 접근함.
6. 백엔드 단에서는, 서버 내의 DB 서버와, 필요 시 REDIS를 사용할 수 있게 구성.
7. 백엔드 단에서, 로그 수집과 시각화를 위해 PLG스택을 사용.

 

 

아래는 샌드버드의 docs에 있는 아키텍처 구성도. 

채팅 서비스만 상세히 설명해놓은 아키텍처 설명은 없었지만, Salesforce에서, salesforce만 빼면 전반적인 채팅에 대한 구성도가 되지 않을까 싶어 참고했다.

 

 

 

 

 

---

 

 

 

후기

sendbird SDK자체는 엄청 개발하는데 있어 사용하기 쉽고 편리했다.

 

또한 전반적인 작업을 맡은 내가 프론트 개발자가 아님에도 불구하고, 커스터마이징을 한다거나 채팅 혹은 채널이 랜더링 될 때 핸들링해서 추가작업을 하기에도 편했다. (UI KIT 내부를 뜯어보고 하나하나 사용하면 되었다.)

 

하지만 사내 서비스에 올리는 과정에서, 서비스팀의 업무를 위한 쪽도 고려하면서,

포스팅에 나타낼 수는 없지만, 최대한 레거시랑 분리하기 위해 많은 시도들을 했다. 이 과정에서 필연적으로 수행해야하는 작업들이 있는데, 효율적이지 못한 작업들이라 아쉽다.

 

하지만 가장 큰 이슈였던 채팅 서비스의 가장 큰 본질인 화면의 빠른 갱신 (채팅의 주고받음에 있어) 이라는 목적은 달성한게 아닌가? 라는 생각에는 긍정적이다.