AppRunner, CloudRun (x86)에서 tfserving을 통한 model serving

[mh3ong]

AppRunner, CloudRun과 같은 Fully-managed service에서 tfserving을 이용하여 model serving을 구현할 예정입니다.

테스트할 모델 목록 : CNN

• mobilenet
• mobilenet_v2
• inception_v3
• yolov5

DNN RNN LSTM

[mh3ong]

1. App Runner에서는 gRPC를 사용할 수 없었습니다. (App Runner 앞단 LB에서 HTTP/2를 지원하지 않는듯 함.)
   • 만약 구성을 하게 된다면 REST to gRPC convertor 자료를 참고하여 구성해보아야 할 것 같습니다.
2. GCP CloudRun에서는 gRPC를 지원하여 구성해보았습니다.
   • cold start 환경에서 30개 요청 동시 실행 (1vCPU, 2GB RAM {기존에는 2 vCPU, 4GB RAM으로 테스트 했었습니다.)
   • cold start 이후 다시 30개 요청 동시 실행
   • cold start 시간 GCP console에서 확인

[kmu-leeky]

응 무현아 잘 확인했네. 만약에 AppRunner 에서 gRPC 를 아직 지원하지 않는다면, 굳이 그걸 되게 하려고 노력하기보다 GCP 에서 사용해보면 될것 같아.

[mh3ong]

CloudRun에서 gRPC를 통한 CNN 모델 Serving 구성 완료했습니다. 현재까지 구성 완료된 모델 :

• CNN
  • mobilenet_v1
  • mobilenet_v2
  • inception_v3
  • yolo_v5

추가로, 이번에 새로 구성한 mobilenet_v2, inception_v3, yolo_v5 테스팅 결과입니다. (2vCPU, 4GB RAM 기준)

1. mobilenet_v2 a. with cold start (10 requests)

   b. without cold start (10 requests)

   

   c. without cold start (30 requests)

   
2. inception_v3 a. with cold start (10 requests)

   b. without cold start (10 requests)

   

   c. without cold start (30 requests)

   
3. yolo_v5 a. with cold start (10 requests)

   b. without cold start (10 requests)

   

   c. without cold start (30 requests)

   

[kmu-leeky]

오케이. 무현아 잘했다. yolo 가 상대적으로 warm start 일때도 시간이 오래 걸리는듯한 느낌이네. 모델이 무거워서 일수도 있겠다. 지금 측정되는 시간들은 요청을 보내는곳에서 측정한 시간인거지? 요청을 보내는 서버는 gcp 의 인스턴스 인거고?

[mh3ong]

현재 측정되는 시간은 말씀하신대로 요청을 보내는 곳에서 측정한 시간이 맞습니다. 그러나 현재 요청을 보내는 Instance는 AWS Seoul region에서 보내고 있습니다. CloudRun을 사용하면 해당 도메인의 DNS 레코드(A, AAAA)가 생성됩니다. 그런데, Python의 gRPC 클라이언트가 DNS 쿼리를 했을 때 A와 AAAA가 모두 존재하는 경우, 클라이언트는 무조건 IPv6(AAAA)로 연결하려고 합니다. 그래서 GCP 인스턴스에서 IPv6을 사용하는 방법을 찾지 못해 AWS에서 요청을 보내고 있습니다.

• GCP에서 IPv6를 사용하는 방법 또는 gRPC Client가 IPv6, IPv4 두가지가 존재하더라도 IPv4를 사용하도록 하는 설정을 찾아봐야할 것 같습니다.

추후에 tensorflow model server의 로그를 분석해서 요청이 들어온 시간과 나간 시간을 계산하면 네트워크 지연 시간을 제외할 수 있을 것으로 보입니다.

[kmu-leeky]

오케이. gcp 에서 사용이 제한되는 이슈가 있구나. gcp 의 서비스도 서울지역에서 구동되고 있다면 그래도 영향이 조금 덜할것 같기도 하다. 트래킹 해가면서 분석해나가자.

[mh3ong]

GCP Instance에 IPv6를 활성화하여 AWS가 아닌 GCP에서 측정한 mobilenet_v1 serving test 결과입니다.

아래는 요청을 보낸 서버에서의 시간 측정 입니다. (thread가 종료될 때 까지의)

아래는 CloudRun의 log를 통해 조회한 CloudRun Instance 앞단에 있는 LB?의 로그입니다. (request가 들어오고 response가 나가기 까지의 latency 시간을 빨간네모 박스로 표시하였습니다. 이를 실제 추론 시간으로 보면 될 것 같습니다.) => 물론 CloudRun Instance와 CloudRun LB도 다른 Network/Placement에 위치 하겠지만. Fully-mangaed 내부적인 지연시간, 즉 실제 추론시간에 포함하는 쪽으로 보아야 할 것 같다는 생각이 듭니다. => 46ms 만 소요된 추론의 경우에는, LB와 추론을 실행한 Instance가 상당히 밀접한 위치에 있었다는 가설도 세울 수 있을 것 같습니다.

아래는 세부 로그 입니다.

아래는 현재 병렬 처리 코드입니다.

위 결과를 봤을 때, 현재 2가지 상황 중 하나로 볼 수 있을 것 같습니다.

1. 병렬처리로 요청을 여러개 보내지만, 순서가 중간에 바뀌어서 tfserving에 나타나는 요청 순서가 바뀐 경우
2. 또는 요청을 보낸 순서대로 log에 표시 되었지만, network latency가 들쭉날쭉 한 경우.

이를 정확히 테스트하기 위해 아래와 같이 측정하는 방법을 사용할 수 있을 것 같습니다.

• gRPC Request에 특정 id 값을 넣어서 tfserving logs에서도 확인할 수 있도록 하기. (이런 기능이 있는지 찾아보아야 합니다.) => 가능하다면, 추론 요청 서버 <-> CloudRun Endpoint(LB) <-> CloudRun Instance의 Network Latency를 측정할 수 있을 것 같습니다.
• 우선, 하나씩 로그를 보내 특정할 수 있도록 한뒤, 네트워크 latency data 축적 해보기.

[kmu-leeky]

client 에서 보이는 latency 의 변화폭이 크기는 하다. 서버단에서 inference 를 할 때 의 시간은 없는거지? 서버에서 추론 시간을 확인해보고 그것과 client 간의 요청 시간 차이가 크다면 확실히 LB, 네트워크 단에서 시간 차이가 크다고 볼수 있을것 같아. 그리고 만약에 그렇게 된다면 사실상 우리가 손댈수 있는 부분이 거의 없어서 진행에 제약이 있을수는 있겠다.

[mh3ong]

AppRunner, CloudRun으로 CNN 모델 제공은 완료하였으며, Bert와 같은 무거운 모델은 사용하지 않는것으로 결정되었습니다. 따라서 issue를 close하고 실제 추론 성능 측정 등은 "Container Serverless 환경 ML Inference 성능 측정" issue에서 이어서 작업합니다.

[kmu-leeky]

오케이 무현아 잘 했다. Bert 의 경우 얼마나 무거워서 동작이 쉽지 않겠다고 판단했었지? 메모리 차원이었나? 아니면 이미지 사이즈 문제였나?

[mh3ong]

엣지에서도 메모리가 16GB 이하 디바이스에서 작동이 어려워 비효율적이라는 판단이 들었습니다. 그래도 구성자체는 가능한 상태기 때문에 필요하면 진행가능합니다.

[kmu-leeky]

메모리 이슈구나. 오케이. 일단 그렇게 알고 있고 구현 여부는 꼭 필요하겠다고 판단이 들면 시작해보자.