채팅 어뷰징 탐지 시스템 구축기 2부

(주의) 이 글에는 주제의 특성상 비속어 및 욕설이 포함되어 있습니다. 

엔지니어링

데이터 사이언스 파트에 이어서 채팅 어뷰징 탐지 시스템의 전반적인 서비스 흐름과 신규 시스템 도입을 위한 부하 분산 처리 등을 설명드리겠습니다.

데이터 흐름과 흐름도

좋은 서버는 어떤 것일까요. 최신 기술이 들어가고 최대한 많은 데이터를 소화할 수 있는 서버가 좋은 것일까요? 개인적으로 가장 좋은 서버는 프로젝트에 알맞은 사이즈에 필요한 데이터를 처리할 수 있으며, 확장성이 보장된 서버라고 생각합니다. 채팅 어뷰징 탐지 시스템의 서버 작업은 상기 기준에 맞추어 설계를 시작했습니다.

그러나 1차 작업이 완료된 후  나온 L-타입 엔진을 사용한 데이터에서는 직접적인 욕설 등을 파악하는데에는 문제가 없었지만, 욕설이 없는 공격적인 문맥을 가진 문장은 검출이 어려웠습니다. 해당 부분의 결핍을 보충하기 위하여 M-타입 엔진을 추가하게 되었으며, 자세한 내용은 1부 데이터 사이언스 파트를 참조해 주시기 바랍니다.

이 형태의 설계를 완료하고 작업을 진행하였으나 예상했던 결과 보다 현저히 떨어지는 결과가 확인되었습니다. 원인을 파악해 보니 몇 가지 예상하지 못하였던 이슈가 발생하였습니다.

병목현상 발생

L-타입 엔진 처리량 및 처리시간과 M-타입 엔진의 처리량 및 처리시간 비교하면, L-타입 엔진의 처리량은 분당 약 2,100건인데 비해 M-타입 엔진의 처리량은 분당 약 500건이었습니다. 

이 상태는 서버의 가용성이 매우 떨어지는 상태로 스케쥴 서버에서 L-타입 엔진 으로 전송된 데이터가 다시 M-타입 엔진으로 처리됨에 있어 병목이 발생하는 상태였습니다. 그림 3에서 확인할 수 있는 것처럼 L-타입 엔진의 부하는 극히 적지만, M-타입 엔진에서의 처리는 계속하여 발생하고 있는 상태입니다. 우리는 병목현상의 해소를 위하여 몇 가지 방법을 생각하였습니다.

1번 방식은 서버를 추가하여 병렬처리로 데이터를 처리하는 형태를 생각하였습니다. 하지만 첫 번째로 그림 4에서 확인할 수 있는 것처럼 현재 상태는 하드웨어 리소스가 모자란 상태가 아니므로 해당 방식은 의미가 없다고 생각하였습니다.

2번 방식은 L-타입에서 처리가 끝난 데이터를 M-타입 처리를 진행함에 있어 스케쥴러 워커를 증가시키며 병렬 처리할 수 있도록 진행하는 것입니다. 하지만 2번 방식을 진행함에 있어서 이슈가 있었습니다.

해결 방식은 간단했습니다. 스케쥴 간의 데이터 풀링(pooling) 시에  다음 산식을 분리하여 풀링을 진행하면 인덱스가 겹치지 않고 처리하는 것이 가능하였으며, 차후 확장에 있어서도 문제가 없었습니다. 

index number / scheduler worker = scheduler worker number

또한 일간 약 30만 건 이상의 처리된 L-타입 데이터가 새로 쌓이고 있기 때문에 처음 데이터부터 처리하기에는 실시간으로 보여주기까지 시간이 매우 많이 소요되었습니다. 그리하여 M-타입 데이터 처리는 총 3가지의 방식으로 변경하였습니다.

상기 방식으로 진행한 후 병목현상은 해결되어 정상적인 결과를  확인할 수 있었습니다.

부하 분산

신규 게임 출시로 인한 채팅량 급증을 대비하며 우리는 새로운 고민을 하게 되었습니다. 현재까지의 게임은 캐주얼 게임의 비중이 높았습니다. 즉 어뷰징 탐지의 대상이 되는 게임은 채팅이 주가 아닌 게임이 대부분이었으며, 데이터 유입량은 충분히 현재의 로직 설계로도 문제가 없는 상태였습니다.하지만 신규 게임이 출시될 것으로 고려하면 다음과 같은 문제에 대해 검토가 필요했습니다. 

• 채팅의 비중이 굉장히 높은 MMORPG 같은 게임이 추가된다면 현재의 설계로 문제없이 실시간 어뷰징 탐지를 진행할 수 있을 것인가?
• 현재 상태는 게임을 키로 하여 하나의 엔진에 한 개 내지 몇 개의 게임을 설정하여 순차적으로 데이터를 처리. 만약 하나의 게임의 데이터량이 다른 게임보다 압도적으로 많을 경우에는 어떻게 될 것인가?

다른 게임은 처리가 완료되어 실시간으로 데이터가 보이나, 데이터량이 많은 게임은 처리량이 밀려 실시간으로 데이터를 보여줄 수 없을 것입니다. 그렇다면 어떻게 해야 모든 게임들을 실시간에 가깝도록 보여줄 수 있을까요? 어떤 방식으로 처리해야 대량의 데이터가 들어왔을 때 병목현상을 해결하고, 서버의 성능을 최대한 사용할 수 있을까요? 여기서 우리는 몇 가지 방법을 생각해 보았습니다.

• 기성 솔루션을 도입하여 데이터 처리
• 어뷰징 탐지 엔진으로 보내는 데이터를 게임 단위가 아닌 다른 단위로 분리할 수 있는 로직으로 변경

기성 솔루션을 사용하였을 때는 편하고 빠르게 작업을 진행할 수 있으나 제외하기로 한 이유는 다음과 같습니다. 프로젝트에 알맞은 형태로 변경하는 것이 불가피하며, 그럴 경우 절대적인 작업량이 줄어든다고 생각할 수 없습니다. 차후 확장성이나 변경에도 유동적으로 대응하기 쉽지 않다고 생각하였습니다. 그리고 추가적인 비용이 발생할 가능성이 있습니다.

그렇다면 게임 내에서 어떤 방법으로 처리를 하여야만 유동적이고, 데이터를 적절히 분배하여 처리를 할 수 있을까 생각한 결과 결론은 ‘채널’이었습니다. 게임은 각각의 채팅 채널을 운용하고 있습니다. 또한 특정 채널에 유저가 몰려 채팅을 진행하는 특성이 있어 채널별로 채팅을 분리하여 엔진에 처리를 하게 되면 게임별 데이터 사이즈에 상관없이 처리가 가능할 것으로 예상하였습니다.

그림 4에서 보시는 것처럼 한 테이블에 모인 데이터들은 특정 컴포넌트를 통하여 서버에 설정된 게임별, 채널별 데이터로 재수집됩니다. 수집된 데이터는 설정된 엔진 서버로 전송되며, 엔진 서버에서는 기존과 같은 어뷰징을 탐지하여 데이터를 리턴해주게 됩니다. 또한 엔진 서버의 리소스가 부족하여 서버의 개수를 늘리게 되면 자동적으로 채널 설정도 증가하게 되며 그로 인하여 부하를 낮출 수 있을 것을 기대할 수 있습니다.

부하 분산의 결과

그림 5에서 확인할 수 있는 것처럼 약 1,000,000건 이상의 데이터가 유입되더라도 안정적인 자원 상태로 빠르게 처리가 되는 것을 확인할 수 있습니다.

지표 모니터링 및 관리

지금까지 어떤 방식으로 부하를 분산할 것인가, 부하 분산처리를 한 후에 어떤 긍정적인 효과를 기대할 수 있을 것인가에 대한 이야기를 했습니다. 그렇다면 어떤 지표를 기준으로 부하 분산을 할  수 있을까요? 

우리는 그림 6에서 확인할 수 있는 것처럼 매일 각 시간별의 지표와 합산 수치를 수집하였습니다. 또한 그림 7에서 확인할 수 있는 것처럼 동시간 대비 30% 이상의 데이터 증가율이 나타나거나, 합산 수치가 동시간 대비 30% 이상의 증가율이 나타날 경우 채널 분리를 진행하여 부하를 분산처리하였습니다. 그 후 어떤 채널을 분리하여야 하는지, 어떤 방식으로 채널을 분리할지에 대한 방법을 생각해봐야 했습니다. 

• 채널별 데이터의 카운트를 확인할 수 있어야 하나 채널의 수는 매우 많으므로, 상위 100개의 채널의 카운트를 확인할 수 있어야 한다.
• 분리되는 채널을 가시적으로 확인할 수 있어야 하고, 채널별로 수집 또는 비수집을 지정할 수 있어야 한다.
• 채널 입력 시에 범위로 입력이 가능하여야 한다.
• 유효성 확인이 되지 않은 상태는 채널 입력이 불가하여야 한다.

상기 조건을 만족하기 위한 작업을 진행하였으며, 채널의 유입량 체크를 확인 후, 채널을 분리하여 작업을 진행할 수 있습니다.

마치며

현재까지의 채팅 어뷰징 탐지 시스템은 안정적으로 운영되고 있으나, 좀 더 많은 데이터가 유입되어 병목이 아닌 리소스 부족이 발생할 경우에 대한 매트릭스가 아직 설정되어 있지 않습니다. 또한 엔진 리소스 부족 시의 스케일아웃 설정은 자동으로 되어 있으나 중심이 되는 스케쥴 서버의 리소스가 부족할 경우에 대해서는 아직 처리가 되어 있지 않습니다. 이 부분에 대하여 좀 더 확인이 필요하며 대비책을 세워야 할 것으로 보입니다.

이상으로 채팅 어뷰징 탐지 시스템 엔지니어링 파트를 마칩니다. 긴 글 읽어주셔서 감사합니다.