Yolo 모델 학습에 도전하였던 포스팅에서 Auto Labeling Tool로 CVAT을 사용하였습니다.해당 포스팅에서는 CVAT을 Docker Compose로 구축하였습니다.CVAT이 Docker Image를 제공해 주기 때문에 쉽게 Docker Compose로 설치가 가능하였습니다.요즘 container 환경은 Kubernetes Cluster에서 구성됩니다.이번 포스팅에서 Docker Compose가 아닌 CVAT을 Kubernetes 환경에 구축하는 것을 정리하였습니다.Helm을 통해 Kubernetes 환경에 CVAT을 설치를 합니다.CVAT 공식 Helm은 Helm Chart Repository에 없습니다.대신 CVAT Github에 Helm Chart가 있어 해당 Github을 clone합니다.근데 여기서 바로 Helm Chart로 install 하지 않습니다.왜냐하면 다른 dependency Helm Chart를 사용하기 때문에 dependency build를 진행합니다.dependecny는 Chart.lock 파일을 통해서 확인 가능합니다.꽤 많은 depency를 가지고 있는 것을 확인할 수 있습니다.CVAT 공식 Github에 2020년 10월에 올라와 있는 Architecture 이미지입니다.참고하시면 좋을 거 같습니다.이번 포스팅에서는 CVAT 분석용으로 쓰이는 Vector, Clickhouse, Grafana는 제외하고 install 하겠습니다.Chart.yaml을 확인해 보면 analytics을 여부에 따라 install 되는 것을 확인할 수 있습니다.이제 values-override.yaml 파일을 작성하겠습니다.helm에서는 values.yaml 파일 내 정의된 값들을 기반으로 template 내 정의된 Object을 생성합니다.원본 values.yaml을 수정 안 하고 수정할 값들만 따로 파일로 정의하면 overriding이 됩니다.ingress 부분은 traefik과 관련되어 있습니다.traefik이 Edge Router로 path에 따라 front, backend 서비스로 라우팅 해줍니다.CVAT을 사용하는 유저의 최접점이 traefik입니다.먼저 host명을 세팅합니다.(host명은 예시, host명을 안 넣으면 ip로 접근 가능)paths은 굳이 바꿀 필요 없이 그대로 넣어줍니다.Nuclio는 Serverless function로 사용하는 오픈 소스 Tool입니다.CVAT에서는 Nuclio를 통해 모델을 배포하여 해당 모델을 기반으로 Auto Labeling을 진행합니다.설정하기에 앞서 Nuclio container 기반으로 동작합니다.Nuclio function을 배포할 Docker Registry가 있어야 합니다.Local이나 Nexus Repository가 필요합니다.Nexus Repsository 구성은 따로 포스팅하도록 하겠습니다.그래서 접근에 필요한 secret을 생성합니다.그리고 Container Runtime을 Kubernetes container Runtime에 맞춰줍니다.제가 테스트

Intro안녕하세요, G플레이스AI개발팀 박상준, 이주영, 민준호입니다.저희 팀에서는 한국, 일본 등의 지역기반서비스를 사용하시는 유저분들께 새롭고 더 개선된 가치를 제공하기 위해 여러가지 AI 모델을 서비스에 활용하고 있는데요.여기서 그치지 않고 더욱 훌륭한 서비스 경험을 제공하기 위한 large model train, 그리고 더 다양한 모델 활용을 목표하고 있습니다.한정된 gpu 자원 속에서 이러한 목표를 달성하기 위해 기존에 운영하던 비교적 작은 모델들을 cpu serving으로 전환할 필요가 있었습니다.이번에 소개드릴 내용은 성능 하락 없이 이전과 동일한 서비스 퀄리티를 유지하면서 기존 model server들을 gpu에서 cpu로 전환하여 연간 약 4억원의 비용절감 효과를 볼 수 있었던 작업에 대한 경험입니다.문제 정의1 — 서비스 아키텍처cpu server 전환 경험을 말씀드리기 전에 내용의 이해도를 돕기 위해 저희 서비스 아키텍처를 최대한 간략화하여 소개해 드리겠습니다.이해를 돕기 위해 최대한 간소화 한 service architecture입니다기본적으로 input을 model이 foward시킬 수 있는 형태로의 전처리 및 inference 결과를 client가 이해할 수 있는 형태로 후처리 하는 CPU intensive한 작업은 App Server(FastAPI)에서 수행하고, Model Server(TorchServe)는 순수하게 inference만을 수행하는 구조를 가지고 있습니다. 안정적인 서비스 운영을 위해 아래 동작이 충분한 처리량과 적절한 latency로 수행되어야 합니다.client는 traefik gateway를 통해 app server로 요청app server는 input을 resize, transform 등을 거쳐 torch tensor로 preprocess 후 model server로 요청model server는 inference 수행 후 app server로 feature를 반환app server는 feature를 사람이 이해하기 용이한 형태로 변환 postprocess 후 client에게 반환2 — 처리량과 latency 측정아래는 G플레이스AI개발팀에서 실제로 운영중이던 이미지 점수 측정 모델을 cpu로 배포한 뒤 단순비교한 결과입니다.cpu가 비교적 저렴한 자원이기 때문에 pod를 3배 늘려서 비교했음에도 10배 낮은 rps와 10배 느린 response time을 확인할 수 있습니다.cpu가 gpu보다 inference 성능이 안 좋은 것은 이제는 상식이기 때문에 놀라운 결과는 아니었지만, 매우 곤란한 상황임은 분명했습니다. 한정된 자원 안에서의 성능 유지를 목표하여 추가 scale out은 고려하지 않았기 때문에 대략 10~20배의 성능 향상이 필요했습니다.3 — 애로사항 : 처리량 측면에서쉽고 효과적이지만 추가 자원이 들어가는 scale in, out을 제외하고, 8core, 3replica를 고정해두었을 때, torchserve framework 사용자들이라면 당연하게도 torchserve

반윤성 2021.07.27. 소개 : Danawa Cloud IDE 개발하면서 종종 가상 IDE가 필요한 경우가 있습니다. 주로 로컬 시스템과 격리된 공간에서 작업을 해야할 때, 현재 시스템과 다른 운영체제를 사용하여 개발할 때 보통 가상화 도구를 사용하기도 합니다. 하지만 번거롭기도 하고 원인모를 오류가 생기기도 합니다. 마이크로소프트에서 개발한 코드 서버(code-server)가 있습니다. 비주얼 스튜디오 코드를 통째로 오픈 소스로 만들어 제공한것으로 개발사에서 지속적으로 유지보수도 제공하는 유용한 도구입니다. 이 기술을 웹 서버에 올려서 사용한다면, 언제 어디서든지 사용자가 원하는 개발 공간을 제공할 수 있습니다. Danawa Cloud IDE는 어떤 웹페이지 안에서 코드를 만들고 고치는 작업 공간입니다. 이곳에서 내 환경과 독립적으로 개발환경을 운용하여 편리하게 사용할 수 있습니다. 최종적으로 개발자들의 편리성을 돕기위해 개발되었습니다. 시스템 구성도 DANAWA CLOUD IDE 시스템 구성도 본 시스템은 기본적으로 자바스크립트 라이브러리 React와 Node.js 서버 환경에서 구동됩니다. 추가적으로 다양한 오픈소스 라이브러리를 활용하여 제작되었습니다. 패키지 매니저인 Yarn을 사용하여 이러한 라이브러리를 관리하며, Express나 mysql, 도커와 같은 도구도 사용합니다. 사용자가 UI를 통해 특정 기능을 호출하면 서버쪽에서 이를 수신해서 Express를 사용해 DB와 연결합니다. 이어서 도커도 호출하는데, 이는 터미널 기능인 Code-Server 이미지를 빌드하여 사용하기 때문입니다. 생성된 컨테이너의 ID를 전달받아서 오픈할 때 도커를 통해 만들어진 터미널 컨테이너로 접속하게 됩니다. 주요 개발내용 정리 이제 중요한 내용인 코드서버 활용법과 URI을 통한 Docker API호출, Docker와 Traefik을 이용한 리버스 프록시 구축 방법에 대해 다뤄 보겠습니다. 우선 구현을 위해 코드서버 프로젝트가 필요합니다. FROM ubuntu:18.04 COPY . /app # code-server WORKDIR /home/danawa/.code-server RUN wget https://github.com/cdr/code-server/releases/download/3.2.0/code-server-3.2.0-linux-x86_64.tar.gz RUN tar xzf code-server-3.2.0-linux-x86_64.tar.gz -C ./ --strip-components 1 WORKDIR /home/danawa CMD ["/bin/bash", "-c", "& /home/danawa/.code-server/code-server --port 3333 --host 0.0.0.0 --auth none"] 코드서버(3.2.0 버전 기준)를 받아서 실행하는 내용입니다. 추가적으로, 오픈하고 바로 JAVA 패키지를 실행할 수 있게 설정합니다. 이를 위해 아래 내용을 수정 및 추가해줍니다. ... FROM openjdk:11 ...

반윤성 2021.07.14. 사내에서 프로젝트를 개발중에 사용자가 특정 동작을 하면 컨테이너를 생성하거나 삭제하는 등의 라이프 사이클 관리가 필요한 시스템이 있었습니다. 초기에는 호스트 서버에서 랜덤한 포트를 골라 직접 컨테이너를 관리했습니다. 하지만 누가 그 포트를 사용할 수도 있고, 미리 점유하고 있는 경우가 발생했습니다. 이 문제를 해결하기 위한 방안으로 앞서 설명한 Proxy의 한 종류인 Reverse Proxy를 구축하여 풀어보고자 노력하였습니다. 이 포스팅은 그 과정에 대해 다루고 있습니다. Reverse Proxy는 기본적으로 클라이언트 요청이 프록시가 끝단이 된다는 개념입니다. 요청은 프록시 앞까지 전달되고 이후의 내용은 중개 서버에서 본 서버끼리 통신하게 된다는 것이 주 골자입니다. 이렇게 네트워크가 통신하는 개념은 알 수 있었는데, 이것만으로는 복잡한 컨테이너를 관리하고 개념을 적용할만한 기술적인 난이도가 존재했습니다. 따라서 가능한 가시적이며 효율적인 도구를 찾게되었고 그것이 바로 Traefik이었습니다. 이 오픈소스 프로젝트는 탄생부터 시스템을 대신하여 요청을 수신하고, 구성 요소를 찾아내는 기술로 출발했습니다. Docker, AWS, Kubernetes와 같은 다양한 클러스터 기술들과 함께 사용할 수 있을 뿐만 아니라 별도의 제어가 필요없이 실행중에 실시간으로 통신되는 요소끼리 찾아서 연결해준다는 기능이 특징입니다. 실제로 Traefik과 Docker를 활용하여 개발을 진행했는데 docker.sock, label을 적절히 셋팅해주면 자동적으로 연결되는 것을 확인할 수 있었습니다. 혹시 초기 셋팅이 필요하다면 이곳에서 소개하는 예제를 활용하면 좋겠습니다. Traefik 구성과 설명 이 문서에서는 Docker와 Traefik을 통해 Reverse Proxy를 구축합니다. 컨테이너 생성을 하고, 다시 Traefik으로 묶입니다. 이를 위해 우선 다음과 같이 도커 컴포즈 파일을 작성합니다. #docker-compose.yml version: "3" networks: web: external: true services: traefik: image: traefik:alpine labels: - traefik.frontend.rule=Host:traefik.example.com - traefik.port=3333 - traefik.enable=true volumes: - /var/run/docker.sock:/var/run/docker.sock - ./traefik.toml:/etc/traefik/traefik.toml ports: - 3333:3333 - 4444:4444 networks: - web #traefik.toml # defaultEntryPoints = ["http", "https"] defaultEntryPoints = ["http"] logLevel = "INFO" [docker] endpoint = "unix:///var/run/docker.sock" exposedByDefault = false # ena