클라우드 기반 실시간 알람 시스템 설계에 대한 고찰

설계의 고찰

기존의 알람 시스템은 각 공장마다 하나의 서버에 하나의 알람 시스템이 배포됐습니다. 이로 인해 부하가 가장 심한 시점에도 20~30건 정도의 알람만 처리되었고, SMS 대행사도 단일 대항사만을 이용했기 때문에 시스템 설계는 크게 중요하지 않았습니다.

 

그러나 회사에서 클라우드 서비스를 통해 여러 공장을 관제하게 됨에 따라 하루 최대 부하량이 백 건을 넘어서게 되었습니다. 또한 단일 대행사뿐만 아니라 다른 3rd-party 플랫폼(ex. 텔레그램)을 추가로 지원해야 했습니다. 이에 따라 알람 시스템 설계가 중요해졌습니다.

 

고객사는 처리 속도에 대한 요구를 내어놓았습니다. 긴급한 알람(실시간 환자 감지, 누수 감지, 화재 감지 등)은 소프트 실시간으로 처리되어야 하며, cron 작업으로 돌아가는 알람은 약간의 지연이 있어도 괜찮다고 합니다.

 

기존 시시템 설계

기존 시스템의 설계는 아래와 같습니다. 각각의 역활을 기술해보자면 

Cron job, Real Time alarm 서비스들은 알람 내용을 구성하여 알람서버가 제공한 API로 요청합니다.

알람 서버는 이러한 요청을 수신 받고 SMS 대행사로 보낼 수 있게 제3자 서비스에 전달할 알람 페이로드를 만들어 냅니다.

위 설계가 가지는 문제점은 다음과 같습니다.

1. SPOF: 알람 서비스에 서버가 하나밖에 없다는 점은 그 서버에 장애가 생기면 전체 서비스의 장애로 이어진다는 뜻입니다.

2. 성능 병목: 지금의 경우 사용자에게 문자를 보내기 위해서 HTML 페이지를 만들고 해당 HTML을 이미지로 변환하는 과정이 있어서 자원이 필요로 하는 작업이다. 만약 하나의 서버가 더 많은 대행사의 처리를 담당하게 된다면 서버는 과부화 상태에 빠질 수 있다.

3. 알람 소실 가능성: 알람 서버가 SMS 대행사로 전송을 하고, 네트워크 등의 이슈로 성공 응답을 못받으면 최종 사용자에게 전달되지 않는 구조이다.

 

따라서 이런 방식을 해결하기 위해서 여러가지 책을 참조했고, 그 중에도 가상 면접 사례로 배우는 대규모 시스템 설계 기초를 참조해서 만들었다.

 

변경 시스템 설계

변경된 시스템은 아래 그림과 같다. 동작 순서는 왼쪽에서 오른쪽이다.

가장 큰 변경 점은 메세지 큐와 작업 서버가 추가됐습니다.

 

메세지 큐의 도입 장점은 아래와 같습니다.

1. 실시간 통신 vs. 비동기 통신:
   • API 통신은 보통 동기적이며 실시간으로 이루어집니다. 클라이언트가 요청을 보내면 서버는 즉시 응답을 반환합니다. 이는 클라이언트와 서버 간에 직접적인 의존성을 만듭니다. 따라서 서버의 부하나 응답 지연이 발생하면 클라이언트에게 직접 영향을 미칠 수 있습니다.
   • 반면 메세지 큐는 비동기적입니다. 송신자는 메세지를 큐에 넣고 그 즉시 응답을 기다리지 않고 다른 작업을 수행할 수 있습니다. 수신자는 자신의 속도로 메세지를 처리할 수 있습니다. 이로 인해 컴포넌트 간의 직접적인 의존성이 줄어듭니다.
2. 느슨한 결합(Loose Coupling):
   • 메세지 큐를 사용하면 송신자와 수신자 간의 결합이 느슨해집니다. 송신자는 메세지를 보내고 그 즉시 다른 작업을 수행할 수 있습니다. 수신자는 메세지를 자신의 속도에 맞게 처리할 수 있습니다. 이는 각 컴포넌트가 서로의 내부 동작에 대해 알 필요가 없음을 의미합니다.
   • 반면 API 통신은 직접적인 호출과 응답을 필요로 하므로 두 컴포넌트 간의 결합이 상대적으로 더 강합니다.

따라서 메세지 큐는 컴포넌트 간의 의존성을 제거하고 느슨한 결합을 유지하는 데 도움을 줄 수 있습니다.

 

작업 서버의 도입 장점은 아래와 같습니다.

1. 부하 분산: 특정 서버에 모든 작업을 집중시키지 않고 여러 작업 서버에 작업을 분산하여 전체 시스템의 성능을 향상시킬 수 있습니다.
2. 장애 대응: 여러 작업 서버를 운영함으로써 단일 장애 지점(SPOF)을 줄일 수 있습니다. 한 작업 서버에 장애가 발생해도 다른 작업 서버가 작업을 계속 처리할 수 있으므로 전체 시스템의 가용성을 향상시킬 수 있습니다.
3. 확장성: 작업 서버를 추가하여 시스템을 더 쉽게 확장할 수 있습니다. 사용량이 증가하거나 더 많은 리소스가 필요한 경우, 새로운 작업 서버를 추가함으로써 시스템을 쉽게 확장할 수 있습니다.

 

추가 기능

알람 전송 시스템의 가장 중요한 요구사항 중 하나는 어떤 상황에서도 알람이 소실되면 안되는다는 점이다. 알람이 지연되거나 순서가 틀려도 괜찮지만, 사라지면 곤란하기 때문에 알람을 데이터베이스에 보관하고 재시도 메커니즘을 구현해야 한다.

 

아래는 재시도 메커니즘을 구현한 시스템 디자인이다.

1. 작업 서버는 메세지 큐에서 작업을 가져와 DB에 메세지 큐에 있는 Payload를 저장한다. 
2. 그 후 Payload를 3rd-party에 맞게 재구성 후 대행사에 요청한다.
3. 대행사가 응답으로 성공을 보내면 DB에 발송 결과는 성공이라고 기록되고, 해당 메세지는 제거된다.
4. 대행사가 응답을 보내지 않거나 실패라고 보내게 된다면 해당 메세지는 실패큐로 이동된다.
5. 실패큐를 처리하는 프로세스가 큐에서 메세지를 꺼내 DB에 결과를 기록한 후 메세지 큐에 다시 넣어준다.
6. 위 작업을 Retry Count의 임계값을 넘어설 때까지 반복해준다.
7. 만약 임계값을 넘게되면 개발자에게 알람 전송