System performance and stability enhancement for large scale multi-cloud infra

[seokho-son]

What would you like to be added

System performance and stability enhancement, especially for provisioning large scale infra

Why is this needed

We need to keep improving according to research DNA. ;)

Target provisioning scale: handling 500 VMs

[seokho-son]

cb-tb dial tcp io timeout 현상 캡쳐 (500ms 슬립. 종료제어)

cb-tb RequestLimitExceeded 캡쳐

cb-tb RequestLimitExceeded 현상 캡쳐 (100ms 슬립)
![cb-tb RequestLimitExceeded

cb-tb RequestLimitExceeded 현상 캡쳐 (500ms 슬립)

[seokho-son]

각 CSP 별로 100 VM 우선 테스트 진행 및 문제 발생시 개선 예정

[seokho-son]

결국 Spider를 통해 호출되는 CSP API Call 수가 주요 병목이며, CB-TB가 이를 적절히 분산 시켜줄 수 밖에 없는 상황.

코드 내에 MCI 단위로 또는 NS 단위로 병렬처리하는 Go루틴을 전반적으로 살펴봐야 할 필요가 있음.

• 생성, 삭제 뿐만 아니라, 상태 조회, IP 확인 등등 모든 곳을 살펴봐야 함. (또는 Spider 쪽 호출 방식 자체를 개선해야 함)
• 현재는 common.RandomSleep(0, len(vmList)/2) 랜덤 슬립을 활용 중. (단, 세세하게 살펴봐야 한다는 단점이 있음)

[seokho-son]

단일 AWS에서 리전 분산 100 VM씩 해도,
한 CSP에 약 400개 이상의 VM이 만들어지면, Spider에서 오류가 발생하기 시작함.

CB-TB 클라이언트 사이드 캐시가 발동해도, 단 1회의 500 VM 상태 조회도 커버가 되지 않으므로, 캐시의 효용을 보기 어려움.
결국 시스템 스케일에 제약이 발생하는 것.

• MCI 단위로는 call 분산을 하고 있지만, 여러 MCI 단위로는 call 분산을 하지 않으니, MCIs가 단일 CSP로만 구성된 경우, 단일 CSP에게 Call이 집중될 수 있음. Call 별로 줄새우기을 해야 하나??

생성시 실패하는 문제는 retry를 할지 여부를 판단필요.

[seokho-son]

VM 인스턴스 종료/삭제시, CB-Spider에 의해서 누락되는 항목 있음.

• CB-Spider에서는 종료 완료 처리하였으나, CSP에는 남아 있는 경우 발생. (AWS. 100 개 종료 중 3개 누락)
  • CB-TB가 직접 핸들링하기에는 까다로운 문제이며, 다시 문제 발생시 리포트 또는 보안책 마련 필요.
• 별개로, CSP에는 삭제가 되었는데 CB-Spider DB에는 남아 있는 경우도 발생. (AWS. 100 개 종료 중 7개 DB상 누락). DB의 경우에는 CB-TB의 DB를 기준으로 움직이면 문제는 없음. 다만 찌꺼기가 남는 상황. (정렬 및 클린업 필요성 있을 수 있음)

[seokho-son]