연결 계층 분리

연결을 받는 계층을 떼어냅니다. 연결은 상시 점유이고 메시지 처리는 순간 부하라 자원 성격이 다릅니다.

한 서버에 두면 둘 중 하나가 낭비됩니다. 조용한 시간대에는 연결 때문에 늘린 서버의 CPU 가 남고, 활발할 때는 그 반대입니다.

배포도 이유입니다. 함께 두면 로직을 고칠 때마다 20만 개의 연결이 끊기고, 동시 재접속이 그 자체로 부하가 됩니다.

흔한 실수: 초당 메시지 수만 계산해 서버 수를 정하는 것. 채팅은 연결이 오래 살아 있는 종류라 요청 수로 환산하면 병목을 반대로 짚습니다.

게이트웨이는 채팅 로직을 모르고 접속 위치만 압니다. 처리 계층이 전달을 요청하면 해당 게이트웨이로 넘깁니다.

이 정보는 접속과 종료가 잦아 자주 바뀌고 짧게 삽니다. 그래서 영구 저장소보다 만료가 있는 캐시가 맞습니다. 게이트웨이가 죽으면 그 항목이 알아서 사라져야 합니다.

흔한 실수: 접속 위치를 데이터베이스 테이블에 두는 것. 초당 수천 번의 갱신과 삭제가 일어나고, 게이트웨이가 비정상 종료하면 정리되지 않은 항목이 남아 없는 곳으로 전달을 시도합니다. 만료가 그것을 대신 치웁니다.

정상 상황으로 다룹니다. 모바일에서 연결은 수시로 끊깁니다.

게이트웨이는 끊김을 오류로 기록하지 않습니다. 접속 위치를 지우고, 그 사용자에게 갈 메시지는 채널에 남겨 둡니다. 다시 붙으면 못 받은 것부터 가져갑니다.

마지막이 놓치기 쉽습니다. 지하철에서 몇 초 끊기는 것마다 상대 화면의 표시가 바뀌면 신뢰가 떨어집니다. 짧은 유예 안에 다시 붙으면 상태를 유지합니다.

흔한 실수: 끊김을 장애로 집계하는 것. 정상 동작이 지표를 오염시키면 진짜 장애가 묻힙니다. 비정상 종료와 정상 종료를 구분해 세야 합니다.

기존 연결은 그대로 남습니다. 이미 맺어진 연결을 새 노드로 옮길 수는 없습니다.

새로 들어오는 접속만 새 노드로 갑니다. 그래서 노드를 늘려도 부하가 즉시 고르게 퍼지지 않고, 기존 노드는 연결이 끊길 때까지 계속 붐빕니다.

줄일 때가 더 위험합니다. 한 노드를 내리면 거기 붙어 있던 수만 개가 동시에 재접속을 시도합니다. 그래서 한 번에 하나씩, 간격을 두고 내리고 클라이언트 재시도에 무작위를 섞게 합니다.

흔한 실수: 연결 수를 기준으로 자동 확장을 걸어 두는 것. 늘어난 노드가 즉시 부하를 가져가지 않으므로 지표가 안 내려가고, 그래서 계속 늘어납니다. 확장 기준은 새 접속 수용 여력이어야 합니다.