감정인식AI의 인프라 제안 - 일본IT컨설턴트의 프로젝트 2회차

영상버전 : 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의 관리가 단순하고 편합니다. 그리고 모든 부하분산 룰 설정 및 장애 제외 등등의 기능을 모두 azure의 GUI에서 해결 가능하고 L7이기 때문에 입력값에 따른 세세한 분산이 가능합니다. domain별로 고객을 나누어 분산이라던가 DDoS방어 등의 설정도 체크박스 한 번에 가능하므로 엔지니어가 없어도 해결이 쉽지요. 대신 가격이 가장 비싼 구조 입니다. 

2안 입니다. 

가장 저렴하게 구성할 수 있는 버전이구요.. 

VMSS에 이미지를 넣고 확장 룰만 정하면 됩니다. 

그 대신 VMSS에서 추가된 서버들은 IP를 알 수가 없으니 domain으로 설정해서 dns에서 가져오게 해야 합니다. 여기서 vmss에서 모든 vm을 하나의 IP로 설정하거나 하는 여러가지 옵션들이 있는데, 자동 IP를 할당하면 그걸 dns에 넣는 방법도 있는 것 같습니다. 옵션들이 많은데 azure의 특징은 ip가 변하더라도 리소스 단위로 dns에 설정하거나 하는 기능들이 있어서 그걸 잘 활용해야 하구요, 변경에 대한 처리를 az cli로 scripting하거나 하는 복잡한 스크립팅 기술이 필요한 대신 VMSS설정 외에는 전부 개발자가 해결할 수 있는 방법입니다. 

DevOps를 직접 만들고 싶다거나 하는 사람들에게는 추천하는 방법이지요. 

3안입니다. 

이건 Traffic Manager라는 AWS의 Route53과 같은 DNS기반 로드밸런서를 사용하는 방법입니다. Traffic Manager는 원암(One Arm)방식으로 실제 트래픽이 가는게 아니기 때문에 수억회 리퀘스트가 나와도 큰 비용이 나가지 않는 대신 트래픽이 없기 때문에 패킷 분석이 불가능하여 L7레벨의 분리는 안됩니다. 

하지만 DNS가 못하는 Health check라던가 AWS의 Route53에서 못하는 Sticky등이 지원되므로 적은 가격에 글로벌 로드밸런싱도 되어서 추천할 만 합니다. 

부하 측정 및 확장은 VMSS에 맡기면 되므로 가성비로는 충분하지 않나 싶습니다. 

고객은 성능보다는 가격 경쟁력이 가장 중요하기 때문에, 

그나마 안정적인 3번 안을 기준으로 가고자 했지만, 전체 가격을 먼저 비교하고 싶다고 하여 다음번엔 각 안의 사이징 및 예산표를 만들어주고, 

3번 안으로 했을 때를 기준으로 테스트 플랜을 작성해 주기로 했습니다. 

그게 확정되면 개발팀과 논의해서 테스트 지원해주고, 

테스트에서 발생하는 개발 수정이나 병목이 있으면 해결해주어 

충분한 사이즈에서도 문제 없이 돌아가도록 해주면 제 할일은 끝이 나네요. 

이제 2주차인데 대충 정리가 되네요.. 

보통은 2주에 요건 분석, 4주 쯤에 제안인데, 고객도 벌써 거의 확정안이 나와서 시간에 여유가 생겨서 좋아하는 눈치 였습니다. 

그리고 제가 이번에는 앞단만 봐드리는 것이고, 이후 고객이 늘어나면 뒷단의 PostgreSQL의 병목이 예상되므로 그에 대한 대처 등도 고민이 생기면 계약 종료 후에라도 연락을 달라고 했습니다. 

약간 밀당 같은 것도 해야 좀더 오래 끌고 비용을 받을 수도 있으나, 

저의 경우는 일이 넘쳐나서 굳이 그렇게 하지 않고 확실하게 제 실력을 보여주어 계약이 끝나더라도 다시 찾을 수 있도록 하고 있습니다. 

실제로 이렇게 10년 이상 고객이 된 기업들이 지금의 저의 수입을 만들고 있으니까요.. 

구글에 다닌다고 자랑스러워 하는 것보다 

자기 자신을 브랜드화 하여

자기 자신의 이름에 자랑스러워 하는 분들이 늘어났으면 합니다. 

giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/