Need to check the number of API calls for VM provisioning for each CSPs

[seokho-son]

CB-TB에서 대규모 인프라 프로비저닝을 위해서, 다양한 조정 및 테스트를 진행하고 있습니다.

결국 CSP call 제약에 의해서, 문제들이 많이 발생하게 되는데,

현재 CSP별 드라이버에서 VM 생성시에 어느 정도 횟수로 API Call을 수행하는지 파악해두고자 합니다.

일단 3개의 CSP에 대해서 공유 요청 드립니다. (대략)

1. AWS
2. GCP
3. Azure

• 필요정보1: VM 생성 전체 과정에서 일반적인 API 호출 횟수
• 필요정보2: API 호출 재시도 매커니즘 및 횟수
  • 예시: VM 생성 상태 조회 API(타임아웃: 5초)를 매 2초 재시도. 3번 반복.
  • 예시: IP 조회 API(타임아웃: 5초)를 매 2초 재시도. 3번 반복. 등.

[powerkimhub]

@seokho-son

• 현황이 다음과 같습니다.
• (StartVM TerminateVM) API Call Counts and Waiting Status

[powerkimhub]

@MZC-CSC @ish-hcc @innodreamer

[Notice]

• 현 이슈 지원을 위해서,
• AWS, Azure, GCP Driver에 다음 commit을 진행하였습니다.
  • 310b9ef
• Driver 내 다른 부분 영향이 없을 거라 생각하지만,
• 혹시 몰라, 현황 공유 드리오니 이상 증상 발생시 의심해주시기 바랍니다.

[Plan]

• 추가로, AWS, Azure SDK 내부에서 반복 waiting 시 default interval이 15초 내지, 30초 주기 입니다.
  • 장시간 경험에 의한 최적화된 시간이라고 생각됩니다.
• 현재, Spider 서버의 경우 5초, driver의 경우 1초인 경우가 있습니다.
• 비교적 긴 시간이 필요한 API인 점, CSP API Call limit 등을 고려할 때, 너무 빈번한 호출인 듯합니다.
• 일단, AWS, Azure, GCP의 StartVM, TerminateVM 내부의 waiting 주기를 15초, Timeout 600초로 일괄 적용하고자 합니다.
• 관련하여, 우려되는 부분이 있으시면, 댓글 부탁 드립니다.

[powerkimhub]

• 일단, AWS, Azure, GCP의 StartVM, TerminateVM 내부의 waiting 주기를 15초, Timeout 600초로 일괄 적용하고자 합니다.

• 호출 주기 및 Timeout 반영 후 CSP API 호출수 변화 (v0.9.8)

[AWS]

• Start: 14회(무변)
• Terminate: 12회 => 8회

[Azure]

• Start: 9회(무변)
• Terminate: 6회(무변)

[GCP]

• Start: 15회 => 14회
• Terminate: 10회 => 5회

[seokho-son]

@powerkimhub 빠른 확인 및 대응 감사합니다.

추가로 확인차 문의드립니다.

Public IP 확인을 위한 재시도 주기가 5초에서 15초로 변경되었는데도

[AWS] Start: 14회(무변)
AWS API call 횟수가 변하지 않았다는 말씀이 맞는지요?

그렇다면 이야기는 14회의 API call은
Public IP 확인 API 재시도에 대한 API call 이 아니라는 의미로 받아들여집니다.

[powerkimhub]

@seokho-son

• Call이 CSP까지 내려 가면, Waiting은 다음 순으로 발생합니다. ((1) -> (2) -(3))
  • (1) CSP 목표 상태를 위한 자체 Waiting
  • (2) Driver 목표 상태를 위한 자체 Waiting
  • (3) Spider Server 목표 상태를 위한 자체 Waiting

• 위 flow는 전체 CSP에 동일하게 적용되며, CSP에 따라서는
  • (1)이 만족하면 (2), (3)이 동시에 만족하는 경우가 있을 수 있습니다.
  • 이 또한, CSP 실행 환경에 따라서 (1) -> (2) waiting까지 진행되어야 할때도 생길 수 있습니다.

• Spider 서버에서 PublicIP 확인은 VM 정보를 얻어와서 확인하므로,

  • CSP API Call이 발생합니다.

• 실제로는 PublicIP 확인 이후에 SSH Daemon 확인하는 Waiting도 있지만,

  • 이 경우는 ssh 직접 체크로 CSP API 호출과는 관련이 없어 추가하지는 않은 상태입니다.

[seokho-son]

@powerkimhub

제가 말씀하신 내용의 취지를 잘 이해했는지 모르겠네요.

일단 다른 예시를 들어보자면, 아래와 유사하게 되기 때문에,
Spider server 차원에서 재확인 인터벌 시간을 늘려(5->15)도 크게 영향이 없다는 말씀인지요?

예시 및 추정

(Driver 및 CSP SDK)
VM 생성 API: 1회 (소요시간: 5초)
기타 등등 API: 2회 (소요시간: 5초)
VM 생성 상태 확인: 9회 (소요시간: 15초*9회)

(Spider Server)
IP 할당 확인: 1회 (소요시간: 1초*1회, 재확인 없음)

재확인이 1회~2회 수준이어서, 5초->15초 영향이 크지 않음.

[powerkimhub]

@seokho-son

영향이 별로 없는 경우도 있고, 민간한 경우도 있을 겁니다.
API Call 수는 CSP별, 필요 자원별 및 생성/삭제 부하 별로 다를 수 있으며,
publicip를 예시로 설명 드리자면, 다음과 같은 상황입니다.

[AWS와 같은 경우]

• 현재, CSP가 public ip VM에 붙여서 올려줌
• AWS의 경우 public ip 정보 확인은 거의 1회 Call로 끝날 수 있을 것으로 보임

[publicip 별도 추가 CSP 경우]

• CSP가 준비되었다고 반환을 했어도, 실제 VM 정보로 public ip를 얻을 수 있으려면 시간이 필요
• 실제로 국내 CSP의 경우 VM을 반환 받고 한참 후에에 public ip 활용 가능한 사례가 있었음
• 이와 같은 경우에는 VM 생성/삭제 부하가 커질수록 API Call 수는 증가하게 될 것이고,
  • Interval이 짧을 수록 API Call 수는 증가하게 될 것입니다.

[powerkimhub]

@MZC-CSC (@seokho-son )

• 위 분석 과정에서 무한 루프 가능성이 있는 코드블록을 아래와 같이 개선하였습니다.
• 무한 루프 발생은 희박하지만, 유사 상황 보고된 바가 있어 반영하였습니다.
  • 현재 Tumblebug에서 500 VM 성능 목표 달성을 위해서 극한으로 활용 중이라 시급하게 보완한 상황입니다.
• 현황 공유 드립니다.
  • Enhance: 569a822
  • 오류로 다시 Patch: 411d1a4

@seokho-son

• 현 개선 내용까지 v0.9.8에 추가 반영하였으니,
• 활용에 참고하세요.