채팅 서버 구축기 1 | Elixir Socket Server

들어가며

fromm 서비스를 시작한지도 1년이 넘었습니다.

작고 빠른 실행과 비즈니스를 지향하는 팀의 특성상 서비스 초기에는 모든 것을 처음부터 개발하지 않았습니다. fromm 서비스의 핵심이 되는 채팅 서버의 경우에도 구글의 Firestore를 사용하여 빠르게 비즈니스를 시작했습니다.

1년 동안 서비스의 급격한 성장과 더불어 트래픽 증가와 다양한 해외 유저의 증가를 경험했습니다. Firestore로는 감당하기 어려운 트래픽 수치를 보일 때도 있었고, 중국에서는 Firestore가 작동하지 않는 등 다양한 이슈와 마주했습니다. 이에 팀 내부에서는 다른 솔루션은 없는지 직접 구축하는 것이 최선일지 다양한 방면으로 검토를 진행했고, 결국 직접 구축하는 결정을 내리게되었습니다.

이번 글 에서는 채팅과 관련된 작업 중, 소켓 서버 구축을 하며 겪었던 내용을 공유하고자 합니다.

Elixir ?

첫 번째로 고민했던 부분은 언어와 프레임워크 였습니다.

현재 fromm 백엔드의 대부분은 NodeJS 기반에 Typescript로 작성되어 있었습니다. NodeJS도 굉장히 좋은 선택지이고 모든 팀원들이 익숙하다는 점에서 장점이 있었지만, 좀 더 목적에 맞는 언어는 없을까 열심히 조사를 하던 중에 Elixir를 발견하게 됩니다.

Elixir is a dynamic, functional language for building scalable and maintainable applications. (elixir-lang.org)

Elixir는 고성능 분산 Erlang VM (BEAM) 에서 돌아가는 José Valim이 개발한 함수형 프로그래밍 언어입니다. Erlang은 전화 교환 장비에서 대형 통신 시스템에 사용하기 위해 1986년에 Ericsson사에서 개발된 언어입니다. 분산 환경에서 안정적인 실시간 동시 시스템을 위해 고안된 언어인 만큼 다양한 통신 시스템과 어플리케이션에 사용됩니다.

실제로 Facebook, Rabbit MQ, Whatsapp 등에서 채팅과 메시징 처리로 많이 사용된다고 합니다.

Erlang이 오래전에 개발된 언어다 보니, 현대적 프로그래밍 언어에 맞게 탄생한 것이 Elixir 입니다. 마치 Java와 Kotlin의 관계와 비슷합니다.

뭔가 새로운 것이라 흥미롭기도하고, 서비스가 요구하는 기능을 완벽하게 갖추고 있어서 Elixir를 사용해보기로 했습니다.

Elixir의 인기 (Stackoverflow Programming, scripting and markup languages)

Phoenix Framework

Elixir 자체로도 좋지만, 쉽고 빠르고 안정적으로 개발할 수 있도록 잘 만들어진 프레임워크가 필요했습니다. Phoenix는 Elixir로 작성된 독보적인 프레임워크라 바로 찾을 수 있었습니다.

Phoenix is a web development framework written in Elixir (phoenixframework.org)

Phoenix는 José Valim이 Elixir로 만든 웹 프레임워크 입니다. Ruby의 핵심 개발자였던 그가 Ruby on Rails와 Phython Django에 영감을 얻어 만들었다고 합니다.

Phoenix의 인기 (Stackoverflow Web frameworks and technologies)

Phoenix는 자체 PubSub을 사용하여 Channel, Presence 등의 기능이 잘 추상화 되어있어서 비즈니스 로직만 구현하면 됩니다. 또한 다양한 언어로 Client SDK를 제공하여 웹, Android, iOS 에서도 쉽고 빠르게 개발이 가능합니다.

Local/Remote PubSub을 사용하면 보통 분산 소켓 서버에서 사용되는 PubSub용 Redis 같은 것을 사용하지 않아도 됩니다. 당장은 Phoenix에서 제공하는 Local/Remote PubSub만으로도 충분하다고 판단했으나, 이 부분은 추후에 다양한 운영환경에서 모니터링을 해봐야 할 것 같습니다. 또한 RedisAdapter를 제공하여 Redis를 PubSub으로 사용하는 것도 가능합니다.

다만 분산 환경에서 각 노드들을 연결해주어야 하는데, 이는 libcluster 라이브러리가 해결해줍니다. libcluster는 다양한 환경에서 노드들을 찾아내고 연결을 해주는 역할을 합니다. 연결이 된 이후에는 PubSub을 통해 메시지를 broadcast하면 알아서 전체 노드에 메시지가 전달됩니다.

Local/Remote PubSub

Infra

이렇게 개발된 소켓 서버 어플리케이션을 어떤 인프라에서 운영할지 고민이 되었습니다. 현재 원더월에서는 AWS를 메인 인프라로 사용하고 있습니다. AWS에서 소켓서버를 운영하기에 EKS와 ECS가 무난하다는 생각이 들었고 팀내 노하우가 더 많은 ECS를 최종 선택하게 되었습니다.

Remote PubSub을 위해 ECS task(노드) 간에 연결을 해줘야합니다. task의 IP 주소를 알아야 libcluster가 연결을 해줄 수 있기 때문에 Service Discovery를 구성했습니다. Route53에 private DNS를 생성하고 libcluster에서 DNS query를 통해 각 task의 IP 주소를 알아내 연결을 맺게 됩니다.

Service Discovery

또한 소켓 서버의 고성능이 요구되는 상황이기 때문에, 부하 분산에 적합하며 갑작스러운 트래픽 증대에 최적화 되어있는 Network Load Balancer를 선택했습니다.

부하테스트

위와 같이 구성 후 실제 어느 정도의 트래픽을 감당할 수 있을지 부하테스트를 진행해 보았습니다. 실제 클라이언트에서 소켓 연결을 요청하는 socket connection 성능 측정과, 연결된 소켓에 메시지를 전달하기 위해 서버에서 호출하는 broadcast API 성능 측정으로 나누어 진행했습니다.

Socket Connection

초당 1,000개의 요청 x 100초 = 총 100,000개의 connection

Fargate 4 vCPU x 2 task

• connection time (P95): 100ms
• peak cpu: 66%
• peak memory: 30%

주목할 만한 점은 초당 요청이 증가할수록 peak cpu가 높아지고, 총 connection 개수가 증가할수록 peak memory가 증가한다는점 이었습니다.

broadcast API

소켓 15,000개 연결된 상태에서 초당 10개의 요청 x 요청당 메시지 3,000개 = 초당 총 30,000개의 메시지

요청당 메시지의 수가 어느 수준을 넘어서도 응답속도가 느려지고, 요청당 메시지의 수를 줄이는 대신 초당 요청을 늘려도 느려져서 적정 수준을 찾아야 했습니다.

Fargate 4 vCPU x 20 task

• response time (P95): 671ms
• response time (P99): 713ms
• peak cpu: 9%

Fargate 16 vCPU x 1 task

• response time (P95): 383ms
• response time (P99): 399ms
• peak cpu: 16%

task가 여러개인 경우 총 스펙은 더 높을 수 있지만, Remote PubSub에 시간이 필요하기 때문에 response time은 더 늘어나게 나타납니다. 해당 부분은 추후에 최적화가 필요할 것 같습니다.

개선사항

지금까지 Elixir와 Phoenix Framework를 활용한 소켓 서버 구축한 것을 정리해봤습니다. 현재는 마이그레이션 기간이라 클라이언트에 Firestore와 함께 적용해두고 모니터링을 진행하고 있습니다.

지금은 단순하게 소켓 연결만 하고 메시지를 전달하는 역할만 하고 있지만 여러가지 고도화가 필요합니다.

• 서버 배포시 소켓 연결이 한 번에 끊어지는 이슈
• 연결이 끊겼다가 재연결 된 경우 메시지 누락 이슈
• 채팅 순서 보장

현재는 클라이언트에서 해당 이슈들을 처리하고 있지만, 백엔드에서도 처리할 수 있도록 차근차근 개발해나가야 겠습니다. 그럼 이후에 개선된 모습으로 다시 찾아 오겠습니다.

저희와 함께 재밌게 개발하실 분을 찾습니다! 관심 있으신 분은 아래 채용 공고를 확인해주세요 :)