앞선 실습에서는 EdgeX에서 전달된 이미지 데이터를 TensorFlow Serving과 연결하여 Object Detection을 수행하는 Pipeline을 구성하였다.
또한 COCO 2017 validation 이미지 10장을 이용하여 실제 이미지 크기와 TensorFlow Serving용 데이터로 변환한 후의 크기, 그리고 Object Detection 처리 시간을 측정하였다.
이번 글에서는 앞선 실습에서 측정한 데이터를 그래프로 시각화하고, 실습 자료에서 제공된 Machine 1과 Machine 2의 실험 데이터를 Python의 matplotlib을 이용하여 그래프로 재현하였다.

먼저 원본 이미지 파일의 크기와 TensorFlow Serving에 전달하기 위해 변환한 데이터의 크기를 비교하였다.
X축은 Original Image Size (MB), Y축은 Size after Conversion (MB)를 나타낸다.
그래프를 보면 원본 이미지의 크기가 증가할수록 변환 후 데이터의 크기도 전반적으로 증가하는 경향을 확인할 수 있다.
다만 두 값이 정확하게 비례하여 증가하는 것은 아니다.
예를 들어 802.jpg는 원본 크기가 약 0.061 MB로 매우 작지만, TensorFlow Serving용 데이터로 변환한 후에는 약 3.930 MB가 되었다.
반대로 872.jpg는 원본 크기가 0.311 MB이고 변환 후에는 5.902 MB가 되었다.
이는 JPEG 파일을 그대로 전송하는 것이 아니라 이미지를 RGB 픽셀 배열로 변환한 뒤 JSON의 instances 형태로 전달하기 때문이다.
앞선 실험에서 측정한 10장의 평균 크기를 비교하면:
원본 이미지
약 0.174 MB
TensorFlow Serving용 데이터
약 3.194 MB
로, 변환 후 데이터의 크기가 크게 증가하였다.
따라서 JPEG 파일의 크기만으로 실제 Pipeline에서 전달되는 데이터의 크기를 판단하기 어렵다는 것을 확인할 수 있었다.
실습 자료에서도 원본 이미지 크기와 변환 후 데이터 크기 사이에 강한 양의 상관관계가 나타나는 것으로 정리되어 있다.

다음으로 원본 이미지가 TensorFlow Serving용 데이터로 변환된 후 몇 배 정도 증가했는지를 계산하였다.
계산식은 다음과 같다.
Magnification = Converted Data Size / Original Image Size
X축은 원본 이미지 크기이고, Y축은 변환 후 데이터가 원본에 비해 몇 배 증가했는지를 나타낸다.
그래프에서 가장 눈에 띄는 특징은 원본 이미지 크기가 작을수록 상대적인 데이터 증가 배율이 커지는 경향이다.
실제 측정값 중 일부를 보면:
1503.jpg
0.015 MB → 1.161 MB
약 77배 증가
802.jpg
0.061 MB → 3.930 MB
약 64배 증가
5503.jpg
0.058 MB → 2.386 MB
약 41배 증가
처럼 원본 파일 자체는 매우 작지만 변환 후에는 수십 배까지 증가하는 경우가 있었다.
반면 상대적으로 원본 크기가 큰 이미지들은 대체로 15~20배 정도의 증가율을 보였다.
따라서 단순히 "원본 이미지가 작으니까 전송 데이터도 작을 것이다"라고 판단하기 어렵다.
특히 EdgeX를 통해 TensorFlow Serving으로 데이터를 전달하는 구조에서는 JPEG 파일의 원본 크기뿐만 아니라 실제로 변환되어 전달되는 데이터의 크기도 고려해야 한다.
실습 자료에서는 원본 이미지 크기와 변환 후 데이터 증가 배율 사이에 음의 상관관계가 나타나며, 상관계수는 r=-0.767로 제시되어 있다.

다음은 Machine 1에서 실험군과 대조군의 time taken을 비교한 그래프이다.
X축은 이미지 번호이고, Y축은 time taken(sec)이다.
그래프를 보면 실험군과 대조군의 점들이 대부분 가까운 위치에 분포하고 있다.
실습 자료에 제시된 Machine 1 데이터를 기준으로 평균을 계산하면:
Experimental : 약 0.0827 sec
Control : 약 0.0819 sec
으로 두 값이 매우 비슷하다.
따라서 Machine 1에서는 실험군과 대조군의 Object Detection 처리시간 자체에는 큰 차이가 나타나지 않았다.
여기서 time taken과 total time은 구분해서 볼 필요가 있다.
실습 자료에서는 time taken을 이미지 한 장의 Object Detection 수행에 걸리는 시간으로 정의하고 있으며, total time은 이미지 변환, 전달, Object Detection 등의 전체 과정을 포함하는 값으로 측정하고 있다.
따라서 이 그래프만으로 EdgeX Pipeline 전체의 처리시간 차이를 판단하기보다는 이후의 total time 그래프와 함께 비교해야 한다.

다음은 Machine 2의 무선 환경에서 time taken을 비교한 그래프이다.
Machine 1과 마찬가지로 실험군과 대조군의 점들이 대부분 가까운 위치에 분포하고 있다.
평균값은 다음과 같다.
Experimental : 약 0.1108 sec
Control : 약 0.1100 sec
두 값의 차이는 매우 작다.
따라서 무선 환경에서도 Object Detection 자체에 걸리는 시간은 실험군과 대조군 사이에서 큰 차이가 나타나지 않았다.
이 결과는 뒤에서 살펴볼 total time과 비교했을 때 더욱 의미가 있다.
무선 환경에서는 time taken이 비슷하게 나타나지만 total time에서는 두 방식 사이에 상당한 차이가 나타난다.
이를 통해 전체 처리시간의 차이가 Object Detection 연산 자체에서만 발생하는 것은 아닐 가능성을 확인할 수 있다.

이번에는 Machine 1에서 전체 처리시간인 total time을 비교하였다.
time taken과 달리 total time은 이미지 변환 및 데이터 전달 등 전체 Pipeline에서 발생하는 시간을 포함한다.
평균값을 계산하면:
Experimental : 약 0.494 sec
Control : 약 0.532 sec
이다.
그래프를 보면 이미지마다 실험군과 대조군의 차이가 조금씩 다르게 나타난다.
일부 이미지에서는 실험군의 시간이 더 짧고, 다른 이미지에서는 대조군의 시간이 더 짧게 나타난다.
따라서 Machine 1에서는 두 방식의 전체 처리시간이 크게 벌어지는 패턴은 나타나지 않았다.
앞의 Figure 3에서도 Object Detection 자체의 처리시간이 두 방식에서 비슷하게 나타났기 때문에, Machine 1에서는 전체 Pipeline에서도 비교적 비슷한 처리시간이 나타난 것으로 볼 수 있다.

다음은 Machine 2의 무선 환경에서 total time을 비교한 그래프이다.
앞의 Figure 4에서는 time taken의 차이가 크지 않았지만, total time에서는 확실한 차이가 나타난다.
평균값은 다음과 같다.
Experimental : 약 1.532 sec
Control : 약 0.733 sec
그래프에서도 대부분의 이미지에서 실험군의 값이 대조군보다 높은 위치에 나타난다.
특히 이미지 7에서는:
Experimental : 2.695 sec
Control : 1.063 sec
으로 큰 차이가 나타난다.
그런데 Figure 4에서 이미지 7의 time taken을 보면:
Experimental : 0.117 sec
Control : 0.117 sec
으로 거의 동일하다.
따라서 이미지 7에서 나타난 total time의 차이는 Object Detection 연산시간만으로 설명하기 어렵다.
이미지 변환이나 데이터 전달 등 전체 Pipeline에서 추가되는 과정이 영향을 주었을 가능성을 생각할 수 있다.
특히 앞의 Figure 1과 Figure 2에서 확인했듯이 이미지를 TensorFlow Serving용 배열 형태로 변환하면서 데이터 크기가 크게 증가한다.
이러한 데이터 전달 과정은 무선 네트워크 환경에서 전체 처리시간에 영향을 줄 수 있는 요소가 될 수 있다.
실습 자료에서도 네트워크 성능이 낮은 환경에서는 제안 방식과 기존 방식 사이의 차이가 나타날 수 있으며, total time이 네트워크 환경의 영향을 받을 수 있다고 설명하고 있다.

이번에는 Machine 2의 유선 환경에서 time taken을 비교하였다.
그래프를 보면 실험군과 대조군의 점들이 대부분 겹치거나 매우 가까운 위치에 있다.
평균값 역시:
Experimental : 약 0.1095 sec
Control : 약 0.1095 sec
로 거의 동일하다.
따라서 유선 환경에서도 Object Detection 자체의 처리시간은 실험군과 대조군 사이에서 큰 차이가 나타나지 않았다.
또한 Figure 4의 무선 환경과 비교해도 time taken에서는 큰 차이가 나타나지 않는다.
즉, 이번 실습 자료의 데이터에서는 네트워크 환경이 달라지더라도 Object Detection 연산 자체의 처리시간은 상대적으로 비슷하게 나타났다.

마지막으로 Machine 2 유선 환경에서 total time을 비교하였다.
평균값은:
Experimental : 약 0.675 sec
Control : 약 0.721 sec
이다.
무선 환경의 Figure 6과 비교하면 실험군과 대조군 사이의 차이가 상대적으로 작아진 것을 확인할 수 있다.
특히 무선 환경에서는 실험군의 total time이 대조군보다 전반적으로 높게 나타났지만, 유선 환경에서는 두 값이 서로 가까운 경우가 많다.
따라서 실습 자료의 데이터를 통해 네트워크 환경에 따라 전체 Pipeline의 처리시간 차이가 달라질 수 있다는 점을 확인할 수 있었다.
8개의 그래프를 함께 비교해 보면 크게 두 가지 특징을 확인할 수 있다.
먼저 Machine 1과 Machine 2의 time taken 그래프를 비교하였다.
Machine 1
Experimental ≈ Control
Machine 2 Wireless
Experimental ≈ Control
Machine 2 Wired
Experimental ≈ Control
세 환경 모두 실험군과 대조군의 time taken 차이가 크지 않다.
따라서 이번 실습 자료의 데이터에서는 EdgeX Pipeline을 사용하는 실험군과 기존 방식의 대조군 사이에서 Object Detection 자체의 처리시간 차이는 크지 않았다.
반면 total time에서는 환경에 따른 차이가 더욱 뚜렷하게 나타난다.
time taken total time
Machine 1 큰 차이 없음 차이 작음
Machine 2 Wireless 큰 차이 없음 차이 크게 나타남
Machine 2 Wired 큰 차이 없음 차이 상대적으로 작음
특히 Machine 2의 무선 환경에서는 실험군의 전체 처리시간이 대조군보다 전반적으로 높게 나타났다.
반면 유선 환경에서는 두 방식의 차이가 상대적으로 작았다.
따라서 이번 그래프를 통해 Object Detection 모델의 추론시간과 전체 Pipeline의 처리시간을 구분해서 볼 필요가 있다는 것을 확인할 수 있었다.
또한 앞의 데이터 크기 그래프에서 확인한 것처럼 JPEG 이미지를 RGB 배열과 JSON 형태로 변환하면 데이터 크기가 크게 증가한다.
따라서 이러한 데이터 변환 및 전달 과정이 전체 처리시간에 영향을 줄 수 있으며, 특히 네트워크 환경에 따라 그 영향이 달라질 가능성이 있다.
앞의 실험 결과를 보면 time taken 자체의 차이보다는 total time에서 네트워크 환경에 따른 차이가 더 크게 나타나는 것을 확인할 수 있다.
그렇다면 HOST_IP가 localhost로 설정되어 있는데도 왜 네트워크 환경에 따라 전체 처리시간이 달라지는지 의문이 생길 수 있다.
localhost는 현재 실행 중인 컴퓨터 자신을 가리키는 주소이다. 따라서 localhost를 사용한다고 해서 Pipeline의 모든 과정이 외부 네트워크와 완전히 분리되어 있는 것은 아니다.
이번 Pipeline에는 다음과 같이 asc-http-export를 통한 HTTP 통신 과정이 포함되어 있다.
EdgeX
↓
asc-http-export
↓
HTTP
실습 자료에서는 인터넷 연결이 없는 환경에서 asc-http-export가 다음과 같은 오류를 발생시키는 것을 확인하였다.
connect: network is unreachable
이를 통해 asc-http-export의 동작 과정에서 네트워크 통신을 시도하는 과정이 포함되어 있음을 확인할 수 있다.
따라서 무선 네트워크 환경에서 나타난 total time의 증가는 데이터 전달 과정에서 네트워크 성능의 영향을 받았을 가능성이 있다.
다만 이러한 결과만으로 네트워크 성능이 total time 차이의 유일한 원인이라고 단정할 수는 없다. 실습 자료에서도 해당 결과를 바탕으로 네트워크 환경의 영향이 있었을 것으로 추측하고 있다.
또한 이번 실습에서 실제로 측정한 평균 Detection time은 약 0.243초였는데, 이는 TensorFlow Serving에 추론을 요청하고 결과를 받는 데 걸린 시간에 가까운 값이다.
따라서 이 값은 실습 자료의 total time과 동일한 의미로 볼 수 없다.
이번 실습에서 측정한 데이터 크기와 실습 자료의 네트워크 환경별 결과를 함께 보면, 이미지를 배열 형태의 데이터로 변환하면서 데이터 크기가 증가하고, 실제 서버 환경에서는 이러한 데이터 전달 과정에서 네트워크 성능이 전체 처리시간에 영향을 줄 수 있다고 이해할 수 있다.
이번 실습에서는 단순히 TensorFlow Serving에서 Object Detection이 정상적으로 동작하는지 확인하는 것에서 끝나지 않고, EdgeX와 TensorFlow Serving을 연결한 전체 Pipeline에서 이미지 데이터가 어떻게 변환되고, 데이터 크기와 처리시간에 어떤 차이가 나타나는지까지 확인하였다.
실제 COCO 이미지 10장을 이용한 실험에서는 JPEG 이미지를 TensorFlow Serving에서 사용할 수 있는 RGB 배열과 JSON instances 형태로 변환하면서 데이터 크기가 크게 증가하는 것을 확인하였다.
또한 실습 자료에서 제공된 실험 데이터를 Python의 matplotlib을 이용하여 그래프로 재현하고, time taken과 total time을 각각 비교해 보았다.
그 결과 time taken에서는 실험군과 대조군의 차이가 크지 않았지만, total time에서는 네트워크 환경에 따라 차이가 나타나는 것을 확인하였다. 특히 무선 환경에서는 실험군의 total time이 대조군보다 크게 나타나는 반면, 유선 환경에서는 두 방식의 차이가 상대적으로 작게 나타났다.
이를 통해 Object Detection 모델의 추론시간과 이미지 변환, 데이터 전달 등을 포함한 전체 Pipeline의 처리시간은 구분해서 볼 필요가 있다는 점을 확인할 수 있었다.
전체적인 Pipeline은 다음과 같다.
COCO Image
↓
IMAGE to ARRAY for TFX
↓
Device REST
↓
EdgeX Core Data
↓
MQTT Message Bus
↓
HTTP Export
↓
py_rest_server
↓
TensorFlow Serving
↓
SSD MobileNet
↓
Object Detection
이번 실습을 통해 EdgeX가 단순히 IoT 데이터를 수집하는 역할뿐만 아니라, 수집한 데이터를 Message Bus와 Application Service를 통해 외부 AI/ML 시스템으로 전달하여 Object Detection과 같은 AI 처리를 수행하는 Pipeline으로 확장될 수 있다는 것을 확인할 수 있었다.
또한 실제 데이터를 측정하고 실습 자료의 실험 결과를 그래프로 재현해 보면서, 단순히 AI 모델이 정상적으로 동작하는지를 확인하는 것을 넘어 데이터 변환에 따른 크기 증가와 네트워크 환경에 따른 전체 처리시간의 차이까지 함께 고려해야 한다는 점을 확인할 수 있었다.