Deep:Securiry :

과제에서 판매 가능한 Product 까지의 여정

1. 왜 이일을 진행하게 됬나 기존의 제품은 사용자 측면 에서 많은 불편함이 있었고 개발자 측면 에서도 많은 불편함이 있었음
   • 영상 끊김
   • 슬로우 쿼리
   • 낮은 유지보수성
   • 잦은 이슈 발생
2. 결단
   • 더이상 방치하면 향후 사업 확장 및 이슈 대응에 어렵다고 판단 전면적인 성능 개선을 하기로 결정함
   • 기존의 코드는 거대한 하나의 코드 집합군 이었음
   • 이는 곧 코드의 분석, 개선이 어려움을 의미함
   • 향후 개발및 유지보수의 어려움을 통감함
   • 이를 개선 하고자 전체적인 리팩토링을 진행 하고자 함
3. 시도
   • 기존 코드 자료구조 개선 -> 성능이 개선 되긴 했으나 높진 않음
   • 코드 관계 분리 및 구조 분산 구현 -> 코드 가독성의 증가
   • 싱글 프로세스 -> 멀티프로세스로 개선 -> 리소스 활용성 증가, 여전히 성능은 부족 하지만 추가 개선 버전을 적용하는데에 있어 발판이 됨
   • Redis 도입 -> 성능이 증가 되었지만 싱글 스레드 기반인 레디스에 동시 접근이 불가해 Pending발생
   • Redis-Stream -> 성능면에 있어 가장 좋은 아웃풋을 보여 주었지만 공급 보다 처리 연산이 부족해 OOM발생
   • API 구조 도입 -> Redis를 제거하고 API를 호출 하는 방식으로 변경 -> 영상 처리 능력은 극대화 되었으나 Inference횟수가 적어지며 BBox Tracking이 느려지는 이슈 발생
   • 비동기 API구조 도입 -> 요청 특성상 IO가 주로 발생하기에 대기 시간을 최대한 줄이고자 비동기 처리 방식 도입
   • FrameHosting Server Framework 교체 -> Flask to Fastapi -> Request에 대해 빠른 응답 및 성능 향상을 위해 프레임 워크 교체 그러나 BBox Tracking이 여전히 느리다는 이슈 발생
   • SharedMemory 도입 -> 기존에 작업한 API 구현체 제거후 공유 메모리 에서 참조하게끔 구현 또한 참조만 할것 이기에 락 기능을 제거한 후 구현함 -> 괄목할만한 성능의 증가가 됨으로써 이슈 대응 완료
4. 이후
   • 최종 성능 개선본에 대해 사용에 무리가 없다는 평가 -> 사용자 만족도 증가
   • 기존의 Robustness 방안 새롭게 재구현 -> 셀프 리커버리 기능 구현
   • 그러나 여전히 거대한 레거시 코드 존재 -> 이는 리빌딩으로 전체적인 아키텍처 및 재구현 예정
5. 후기
   • 작업한 내용에 대해 회고 하며 복기를 진행할수 있었음
   • 차후 진행 방향에 대해서 갈피가 잡히는것 같으며 향후 개선 방향으로는 기존 의 불안정한 기능들을 먼저 안정화 한후 추가적인 기능 개발에 전념 하는것이 좋다고 생각됨.

👉 이 문서는 회고록으로 작성되었습니다.