영상버전 : https://youtu.be/mVwIZ1nof8w 지난 번에 고객의 현재 상황 및 요건을 들었습니다. 원래라면 분석에 2주를 잡긴 하지만, 이번은 아주 간단해서 바로 1차 제안을 세 종류 만들어 봤습니다. 현재 개발사가 제안한 scaling에 대한 문제를 제기해야 겠지요.. 우선 원래 시스템 중 문제가 있는 서버의 프로세스 구성입니다. 하나의 VM에 Listener, Real time analyzer, Final Analyzer의 세 개가 돌고 모든 IP PBX의 스트리밍 데이터를 받아서 하나의 VM이 처리를 하고 있는 식이죠. 이걸 분산하려고 하고 있습니다. 우선 개발사가 생각한 1안입니다. 하나의 인스턴스에 Thread를 나누어 처리를 하려고 합니다. 하지만 같은 인스턴스다보니 CPU가 터지는 지금 상황에서는 Thread를 분리해봤자 분리된 Thread가 터져서 인스턴스가 뻗을 것 같네요. 개발사가 제안한 2안 입니다. 이건 두 개의 인스턴스로 나누어 왼쪽에 IP PBX에서 데이터를 받아 리얼타임으로 저장하고 CPU부하가 큰 Final analysis는 다른 인스턴스에서 땡겨서 처리하겠다는 발상인데요.. 아마 이번에 테스트한 50세션 동시 처리에는 먹힐 지도 모르겠습니다. 30정도에서 터졌으니까요.. 하지만 이건 일시방편이지, 유저를 계속 늘려가는 서비스 입장에서는 오히려 왼쪽 입구에서 받는 트래픽에 그걸 모아서 오른쪽의 VM 복수개에 동시에 파일을 내보내면 트래픽 병목으로 전송 실패가 나겠죠. 아마 700세션 전후에서 터질 것입니다. 그래서 제가 이 내용을 기준으로 일반적인 제안을 했습니다. 1안입니다. 전형적인 Application Gateway에 VMSS설정으로 Application gateway가 알아서 분산하고 VMSS가 알아서 부하도에 따라 증가 시키는 방식이죠. 장점은 Application Gateway에서 SSL을 관리하므로 SSL의 관리가 단순하고 편합니다. 그리고 모든 부하분산 룰 설정 및 장애 제