표지판 분류 딥러닝 및 데이터 파이프라인 구축 문서

설계 수정 사항

1차 수정 : Web Client는 Hadoop이 아닌 NoSQL을 통해 빠른 성능으로 DB 사용
2차 수정 : Hadoop에 2개의 폴더를 만들어 정확한 라벨과 부정확한 라벨을 구분
3차 수정 : NoSQL에도 2개의 테이블을 만들어 정확한 라벨과 부정확한 라벨 구분
4차 수정 : Kafka Broker를 데이터 통신의 중추로 삼아, 모두 Kakfa Broker를 거쳐서 데이터 전달. NoSQL와 Hadoop의 연결 관계를 분리. Hadoop은 정확한 라벨만 저장. 마이크로서비스 상에서 필요한 요소들 (Eureka Server, Config Server, API Gateway를 구성)
5차 수정 : NoSQL을 MongoDB로 채택. MongoDB는 부정확한 라벨만 보관. 각 서비스들의 스케일 아웃 시나리오 작성. 특히 Label Service는 Web Server와 MongoDB, Kafka Broker 3개 간의 Data Flow 이슈를 검토하되, Single DB를 쓰는 경우 / 복제된 Multiple DB를 쓰는 경우 / Write DB와 Read DB를 나누어 쓰는 경우 등의 시나리오를 검토.
6차 수정 : Write DB와 Read DB를 나누어 쓰는 방법을 채택. DB 스키마 설계. Client의 요청에 따른 멀티 서버 상에서의 데이터 중복 또는 유실 문제 검토
7차 수정 : 1개의 Write DB와 여러 개의 Read DB를 사용하는 방법 검토
8차 수정 : 통신 시 Payload의 형태 정의. Primary DB와 Secondary DB를 사용하는 전략 검토.
9차 수정 : Read Operation이 자주 일어나는 DB와 Write Operation이 자주 일어나는 DB를 따로 관리하는 것으로 확정. 각 DB는 Replica를 두어 가용성을 보장.
10차 수정 : 쿠버네티스 도입. 자바 기반의 마이크로서비스들(Eureka Server, Config Server, API Gateway 등) 철회. Kafka Consumer Process와 Web Server를 분리. Web Server에 Kafka Producer 로직을 포함.
11차 수정 : 모든 Service들에 대하여 Consumer와 Django 서버를 분리.
12차 수정 : HPA를 통한 동적 스케일링 적용. 고용량 데이터(Image/Parameter)의 흐름을 Cloud Data Store의 URL로 대체. MongoDB의 ReadDB 제거
13차 수정 : 연관 Service들을 서로 같은 PC로 묶고, Local File System으로 Storage 공유 (NFS 사용)
14차 수정 : Consumer와 Django 사이에는 Local File System을 통해 데이터 공유. 특히, Model Service 쪽에서는 File System이 Container > Pod > Host 순으로 3중으로 걸쳐 있기 때문에, 서로 다른 Level의 File System 간에 Path를 Binding하여 공유하기 위해 NFS 사용. 각 SW를 어떤 HW에 배치할 것인지 지정. 테스트 시나리오를 5가지로 분리.
15차 수정 : 포트 포워딩과 같은 네트워크 구성도 작성