개요

parking server 개선사항에 대해서 작성해 보겠다.

내용

easyocr docker base를 활용하여 ocr(광학 문자 인식)을 하도록 했다.
번호판을 읽어서 처리는 하지만 문제점이 있었다. 속도가 너무 느리다는 것이다.
2가지 문제가 있는 것 같다.
1. 모델 자체가 느리다.
2. rust server에서 ocr 기능을 호출하는 방법이 오버헤드가 크다.

현재 ocr 기능을 호출하는 방식은 다음과 같다.
1. client로부터 image를 base64 인코딩 된 상태로 받는다.
2. base64 디코딩을 하여 temp.png로 저장한다.
3. 저장된 이미지의 경로를 python script를 실행할 때, 인자로 넘겨준다.
4. python이 easy ocr을 활용해 번호판 인식을 한 뒤, 번호판 문자를 출력한다.
5. 출력된 내용을 rust에서 읽어서 처리한다.

불필요한 file i/o와 python process를 ocr마다 생성했다가 삭제하는 오버헤드가 발생하기에 속도가 현저히 느릴 수밖에 없다고 생각한다. easyOCr을 paddleOcr로 모델을 교체하고, python ocr grp server를 띄운 뒤, file i/o를 발생시키지 않고 이미지 bytes를 grpc 통시으로 넘겨 번호판을 인식하도록 하였다.

위 방식을 사용하였을 때는 약 20초가 넘는 시간이 소요되었다.

paddle ocr로 모델만 교체한 경우,

2639ms로 시간이 확실히 줄어든 것을 확인할 수 있다.

paddle ocr과 grpc로 교체 후,

처리 속도가 약 900% 향상되었다.

mosquitto broker의 경우 aws의 가상머신에 띄웠다. 일단은,,, 로컬에서 도커로 rust parking server, python ocr server, db server 띄워두고 있다.

보완해야 할 점은 ocr server를 docker로 실행 시, paddle ocr에 필요한 라이브러리 및 모듈을 다운로드하는 것 같은데, docker image build 시 미리 다운로드하여 실행 속도를 빠르게 개선해야 한다. 미리 설치를 하려고 했으나 잘 안돼서 추가적으로 작업을 해야 한다.

github

// parking server
https://github.com/wangki-kyu/parking_server
// ocr server
https://github.com/wangki-kyu/ocr_server

결론

최근에 gRPC를 사용할 일이 많은데, proto파일을 직접 생성하여, 간단하지만 테스트해 볼 수 있었다. 도커는 Gemini가 없으면 절대 못했을 것 같지만, 어려운 게 아니라 익숙하지 않은 것 같다. 각 운영체제의 script를 자유자재로 알면 좋을 것 같다는 생각이 들었다. async Task의 에러 핸들링 등등 추가하고 보완해야 할 점이 많다. 하나씩 공부해 나갈 예정이다