• 사용 스택 : Vagrant, Virtualbox, Kubernetes, Docker, Kafka, HBase, Hadoop, Django, Python, MongoDB

• 개발 기간 : 2021년 9월 5일 ~ 11월 27일

• Github

  • 서버 : https://github.com/LyunJ/GraduateProject
  • 인프라 : https://github.com/JasonYoo1995/Graduation_Work_Kubernetes

• 시연 영상 : https://youtu.be/lti70hgErhk

• 프로젝트 내용 요약

  • 3가지 종류의 Client(자율주행 차, 데이터 라벨링 알바생, AI 전문가)에게 동시에 서비스를 제공해주는 데이터 파이프라인 구축
  • 미래 확장 가능성과 대규모 처리의 안정성, 성능과 효율성 등을 고려한, 본 팀만의 고유한 아키텍처 설계 (16번에 걸친 아키텍처 수정)
    • Kafka라는 솔루션을 Data Flow의 중추로 삼음
    • Binary 이미지를 직접 전송하지 않고, 그 메타 데이터(URL 또는 Key)를 전송함으로서 성능 최적화
    • 다양한 “클라이언트 - 분산 서버 - 분산 DB” 구조와 시나리오를 고려하면서 데이터 중복 및 유실 등의 무결성 검토
  • 쿠버네티스와 도커 기반의 배포 환경 구성

• 제작 문서

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

• 어려웠던 점

  • 주제 선정과 관련된 의사 결정의 어려움
    • 팀원 2명은 딥러닝 관련 주제를 하고 싶고 팀원 1명은 분산 솔루션들을 다루고 싶었으며 본인은 마이크로서비스 관련 주제를 하고 싶었음
    • 각자의 이해 관계를 모두 충족시킬 수 있는 주제를 찾기 매우 어려웠음
    • 주제가 타협 되지 않아 팀이 분리될 수도 있는 위기에 봉착
    • 일주일 간의 고심 끝에 4명의 이해관계를 모두 충족시킬 수 있는 주제 구상 (주제 : 딥러닝을 이용한 서비스를 데이터 파이프라인 상에 배포)
    • ‘딥러닝 팀’과 ‘인프라 팀’으로 나누어 완전히 독립적으로 개발 진행 가능 → 프로젝트 마지막 단계에만 두 팀 간에 협업.
  • Vagrant, Virtualbox, GPU 드라이버, Kubernetes Object 등을 다룰 때 버전 호환성으로 인해 발생하는 오류들
  • ‘Server → Container → Pod → Deployment → Load Balancer → Ingress → Virtual PC → Host PC’로 이어지는 겹겹이 구조라서 각 Layer에서 별도의 File System이 관리된다는 것과 Port Forwarding도 연속적으로 이루어져야 한다는 것을 알아야 함
  • 개발 환경에서는 문제 없이 실행되는데, 배포 환경에서는 오류가 발생
    • 원인
      • 의존 패키지 설치, 환경 변수 설정, 드라이버 설치, 환경에 의존적인 응용 로직 등
    • 해결
      • nohup.out / Docker Desktop / Kubectl 등을 통해 Log를 출력하여 원인 파악 및 해결
      • 개발자와 배포자 간에 배포 환경에 대한 이해도에 차이가 있기 때문에, 이에 대한 적극적인 소통과 타협이 필요했음. (특히, 의존 패키지를 추가할 때, 패키지명과 버전을 requirement 파일에 업데이트해달라고 개발자 분께 요청함)
  • 새로운 파드의 생성과 동시에 필요한 환경을 세팅하기 위해 Shell Script가 자동으로 실행되도록 하고 싶은데, sudo 권한을 사용하려면 sudo 권한이 필요한 아이러니한 상황 (→ 아직 미해결. 일단은 수작업으로 세팅했음)

• 고민했던 이슈

  1. 각 프로세스에게 적절한 양의 자원 할당
     • 본 팀이 설계한 아키텍처는 최소 18대 이상의 컴퓨터를 요구하는데, 학생이라는 신분 상 단 4대의 컴퓨터만으로 돌려야 하는 상황
     • 따라서 성능은 포기하되, 각 프로세스가 요구하는 자원(CPU, Memory 등)의 양에 따라, 적절한 비율의 자원을 할당하려고 노력
     • 자원 사용량이 적은 프로세스
       • 유휴 자원이 적은 컴퓨터에도 배치 가능
     • 자원 사용량이 많은 프로세스
       • 유휴 자원이 많은 컴퓨터에 배치하는 것이 좋음
  2. 두 로직의 배치 방법에 따른 Trade Off
     • 두 로직을 (같은 프로세스 내의) 다른 스레드로 실행하는 경우
       • 프로세스 스케일링 시 두 로직을 따로 스케일링 불가 (한 로직을 n개 만큼 스케일링하면, 다른 로직도 n개 만큼 스케일링 해야 함)
     • 두 로직을 (같은 컴퓨터 내의) 다른 프로세스로 실행하는 경우
       • 두 로직을 따로 스케일링할 수 있음 (한 로직을 n개 만큼 스케일링해도, 다른 로직은 k개 만큼 스케일링 할 수 있음)
       • 같은 컴퓨터 내에 있으므로 Local File System을 통한 데이터 공유 용이
       • 스케일링을 해도 같은 컴퓨터를 사용하기 때문에 성능 향상 효과가 적음 (잔여 자원이 없을 경우, 병렬 처리로 인한 성능 향상 정도의 이득만 볼 수 있음)
     • 두 로직을 서로 다른 컴퓨터에서 실행하는 경우
       • 다른 컴퓨터 내에 있으므로 Local File System을 통한 데이터 공유 불가 (네트워크 통신을 통해 전달해야 함)
       • 스케일링 시 다른 컴퓨터를 사용하기 때문에 성능 향상 효과가 큼
  3. 데이터를 공유하고자 하는 프로세스들이 서로 격리된 Local File System에 접근하도록 프로그래밍 된 경우
     • NFS를 활용하여 해결
  4. Labeling Service에서 분산 웹 서버와 분산 DB 서버를 어떻게 구성할 것인지
     • 다양한 Scaling 시나리오들을 작성하고, 각 시나리오의 장단점과 발생 가능한 이슈 및 구현 로직을 분석한 후, 실제 적용할 구조를 선정

• 느낀 점 / 깨달은 점

  1. 부하 테스트 시 웹 서버와 DB 서버에서 병목 현상 문제
     • 현상 분석
       • Client가 웹 서버에게 대량으로 요청하고, 이를 웹 서버가 DB에게 요청한 뒤, 요청 결과를 Client에게 응답해주는 과정에서 심각한 Delay 혹은 Crash 발생
       • DB가 관여하지 않고 순수하게 웹 서버만 관여하는 요청은 비교적 양호
       • 그러나 DB 서버가 관여하는 요청에 대해서는 매우 심각하게 느려짐
     • 웹 서버와 DB 서버의 구조 및 동작 원리 조사
       • 스레드 풀 혹은 커넥션 풀이 존재하여, 요청 당 스레드 하나가 매핑되어 처리
       • 요청을 받아들이는 큐잉 메모리가 꽉 차면 요청 메시지 거절
     • 원인 분석
       • 응답 속도가 터무니 없이 느린 것으로 보아, 요청 메시지가 큐잉 되어 있는 시간이 오랫동안 유지되고 있는 것으로 추측
       • ‘메모리 IO’ 혹은 ‘메모리 연산’ 속도보다는 ‘디스크 IO’ 속도가 더 느리기 때문에 병목 현상의 주요 원인은 ”웹 서버”보다는 “DB 서버”일 것이라고 추측
     • 해결 방법
       • DB 서버에 대하여 성능이 매우 좋은 컴퓨터를 사용
       • Read Query의 경우, 멀티 DB로 부하를 분산할 수도 있을 듯
       • 웹 서버와 DB 서버의 각종 메트릭 지표들을 효과적으로 모니터링하여 어떠한 상황에 병목 현상이 발생하는지 쉽게 파악할 수 있다면 ‘추측’만이 아닌 ‘확신’도 할 수 있을 듯
  2. 아키텍처를 설계할 때 ‘디스크’를 “언제”, “왜” 사용하는가?
     • 할 수 있으면 최대한 메모리로 해결하는 것이 좋음 (성능이 빠르기 때문)
     • 메모리로 해결할 수 없을 때 차선책으로 디스크를 사용
     • ex1) 메모리 용량 부족 시 : 들어오는 데이터의 머무르는 시간이 길거나 데이터의 양이 많으면, 메모리의 용량이 부족하기 때문에 어쩔 수 없이 디스크 사용
     • ex2) 시간 차 발생 시 : 두 프로세스 간에 시간 차를 두고 데이터를 공유 혹은 통신하고 싶을 때, 중간 매개체로 Local File System, Kafka, DB 등의 디스크 사용 (= ex1의 메모리 용량 부족과 비슷한 맥락)
     • ex3) 메모리의 휘발성 : 프로세스가 죽더라도 데이터를 안전하게 유지하고 싶을 때 디스크 사용

• 수상 내역

  • 컴퓨터공학과/스마트ICT공학과/전자공학과 통합 SW경진대회에 참가한 70여 개의 팀 중 7등
  • 우수상 수상 + 상금 100만원 수여