오늘 뭐 개발하지?

설치 환경

• Windows 10 WSL2
  • Ubuntu : 20.04 LTS
  • Docker : v20.10.6
  • kuberenetes, kubectl : v1.19.7
  • Kubeflow : kfctl_k8s_istio.v1.0.0.yaml
  • kfctl: v1.2.0-0-gbc038f9
• 단일 사용자가 로컬에서만 사용할 경우 : kfctl_k8s_istio
• 여러 사용자가 사용해야 해서 인증이 필요한 경우 : kfctl_istio_dex

(istio_dex를 사용할 경우) kubernetes 설정 수정

Kubeflow를 설치하기 위해서는 kubernetes API server를 수정해야 하는데, Docker Desktop을 통해 kubernetes를 사용하고 있기 때문에 설정 파일이 로컬에 존재하지 않는다.

$ cat /etc/kubernetes/manifests/kube-apiserver.yaml cat: /etc/kubernetes/manifests/kube-apiserver.yaml: No such file or directory

따라서, 다음 방법을 이용하여 API server를 수정한다.

# Edit kube-apiserver.yaml in docker-desktop 
# docker run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh 
# vi /var/lib/kubeadm/manifests/kube-apiserver.yaml 
# ADD FOLLLOWING: spec.containers.command 
# - --service-account-signing-key-file=/run/config/pki/sa.key 
# - --service-account-issuer=kubernetes.default.svc 
# - --feature-gates=TokenRequest=true # - --feature-gates=TokenRequestProjection=true

sa.key 파일이 해당 위치에 없을 수도 있으므로 /etc/kubernetes/pki/sa.key 등에 있다면 해당 경로에 맞춰 내용을 수정한다.

kfctl 설치

wget https://github.com/kubeflow/kfctl/releases/download/v1.2.0/kfctl_v1.2.0-0-gbc038f9_linux.tar.gz
tar -xvf kfctl_v1.2.0-0-gbc038f9_linux.tar.gz
sudo mv kfctl /usr/local/bin/
rm kfctl_v1.2.0-0-gbc038f9_linux.tar.gz
kfctl version # kfctl_v1.2.0-0-gbc038f9

/usr/local/bin 으로 이동시키지 않을 경우 $PATH에 추가해서 사용할 수도 있다.

Kubeflow 설치

• k8s_istio

wget https://raw.githubusercontent.com/kubeflow/manifests/v1.2-branch/kfdef/kfctl_k8s_istio.v1.2.0.yaml
kfctl apply -f kfctl_k8s_istio.v1.0.0.yaml -V

• istio_dex

wget https://raw.githubusercontent.com/kubeflow/manifests/v1.2-branch/kfdef/kfctl_istio_dex.v1.2.0.yaml
kfctl apply -f kfctl_istio_dex.v1.0.0.yaml -V

설치가 완료되면 port-forward 명령어로 8080 포트로 접속할 수 있도록 한다.

kubectl port-forward svc/istio-ingressgateway -n istio-system 8080:80

istio_dex의 경우 초기 아이디와 비밀번호는 admin@kubeflow.org / 12341234 이다.

유저를 추가하는 방법에 대해서는 document에 나와있다.

localhost:8080 으로 접속하여 Kubeflow Dashboard에 접속했다면 설치 완료!

설치 완료 후 초기 컨테이너 image를 pull하고 running 하느라 시간이 다소 걸릴 수 있다. kubectl get pods -n kubeflow 에서 모든 pod 가 생성되어 동작할 때 까지 기다린다.

• 1.2.0 버전에서 pipeline으로 바로 전송 시 에러가 발생하여 1.0.0 버전을 설치하였다.

모델을 서빙하기에 앞서 무료로 쓸 수 있는 클라우드 서비스 중에 딥러닝 모델을 서빙할 만한 곳을 찾고 있었다.

딥러닝 모델이니 당연히 GPU 자원을 쓸 수 있는 곳이어야 한다고 생각했는데, 잘 생각해보니 그럴 필요가 없었다.

왜냐하면 딥러닝 모델에서 GPU를 사용하는 이유는 분산처리인데 내가 만들 서비스는 이미지 하나를 입력으로 받으므로 굳이 GPU를 사용할 필요가 없었던 것이다.

Deep Learning Inference & Serving Architecture 를 위한 실험 및 고찰 1 - GPU vs CPU 이라는 글에서 이미 어느 정도 정답을 유추할 수 있었다.

그러나 해당 글이 2017년도에 작성된 글이고, 그래도 얼마나 차이가 있을까 궁금하여 일단 실험을 진행해보았다.

실험 사양의 CPU는 AMD Ryzen 7 3700X 8core, GPU는 RTX 3070 8GB이다.

실험은 Jupyter notebook에서 %time, %timeit Magic Command를 이용하여 진행하였다.

실험 결과를 정리해서 나타내면 다음과 같다.

실험 결과는 GPU를 이용했을 때가 당연히 빨랐다. 다만, GPU는 첫 Inference에서 CUDA 라이브러리를 불러오는데 시간이 걸려서 약 6.7초 정도가 걸렸다.

CPU를 이용한 Inference도 트래픽이 많지 않다면 충분히 사용 가능하다고 생각했다. 물론 초당 수백, 수천장의 이미지가 들어온다면 문제가 발생하겠지만 지금은 서빙하는 것이 목적이기 때문에 크게 상관 없을 것 같다.

결과만 보면 위 글에서 도출한 결론과는 상반대는 결론이 나왔다. 이 부분은 아무래도 그 동안 CPU 성능의 발전에 비해 GPU 성능의 비약적인 발전때문이 아닌가 싶다. 4년 전에는 서버용 CPU와 K80의 부동소수점 연산 속도(FLOPS)가 비슷했을지 모르지만, 당장 수치적인 부분만 놓고 봐도 K80의 FP32(float) TFLOPS는 4.113 * 2인 8.226 TFLOPS이고, RTX 3070의 FP32(float) TFlops는 20.31 TFLOPS로 2.5배 정도 차이가 난다. 실제로 결과도 K80 Single Inference에서 50ms 정도인 것과 RTX 3070의 Inference Time을 비교해보면 2배 이상 차이가 난다. 또한, 3700X CPU의 FLOPS는 1,689.6 GFLOPS로 약 1.7TFLOP로 볼 수 있으니 RTX 3070의 Inference Time과 TFLOPS를 비교하면 얼추 일치한다고 볼 수 있다. 즉, 4년 전에 사용한 Azure VM의 CPU TFLOPS는 약 8~9 정도로 K80와 비슷한 성능이었기 때문에 이번에 진행한 실험과는 다른 결과가 나타났다고 생각할 수 있다.

항상 딥러닝 모델을 서빙하려면 좋은 컴퓨팅 자원이 있어야 한다고 생각했다. 물론 회사에서 서비스할 때에는 그렇겠지만, 개인이 테스트나 프로젝트를 목적으로 한다면 굳이 GPU를 사용하지 않고 CPU만으로도 충분한 Inference가 가능하다고 생각한다.

4월 15일부터 train을 시작하여 1epoch당 30분씩 약 300epoch을 돌리는데 무려 150시간이나 걸렸다.

자는 시간 제외하고는 항상 컴퓨터를 쓰고 있으니 자는 시간에만 틈틈이 학습시켜야 했는데, 메모리 부족으로 한 번에 10epoch이상 돌릴 수가 없었다.

원래 데이터셋도 6만장을 사용해야 했는데 1.6만장으로도 이 정도 걸린 걸 생각하면 더 많은 시간이 걸렸을 것이다.

300epoch 훈련시킨 결과는 생각보다 만족스럽지 못하다. auto-painter 논문에서는 되게 잘 되는 것 처럼 보였으나, 실제로 해당 논문을 구현해놓은 github을 clone해서 직접 실행시켜보니 여전히 실제로 사용하기엔 한참 모자라보였다.

다만 해당 논문에서는 훈련시킬 때 두 가지 모델을 만들었는데, 하나는 픽셀 정보를 일부 남겨놓고 학습을 시켜서 추후 inference할 때 input image에 일부 색을 칠해주면 해당 부분은 그 색으로 칠해지는 경향이 있었다. 아마 이 부분에 있어서 모델을 더 개선시킨다면 재미를 줄 수 있는 정도의 서비스는 되지 않을까 생각한다.

그래도 완전 못 봐줄 정도의 성능은 아닌 것 같다. 일부 색을 비슷하게 추론하는 경우도 생각보다 많이 보였고, 신기한 것은 완전히 대비되는 색상을 가진 그림들이 많이 보였다. 무엇보다도 캐릭터의 피부색 만큼은 잘 찾아서 적절한 색으로 칠해지는 것을 확인할 수 있었다. 이 부분은 아무래도 VGG를 이용하여 feature를 추출한 것과, 일정한 형태(사람 모양)을 한 캐릭터들이기 때문에 가능했던 것 같다.

우선 이 모델을 이용해서 서빙해볼 생각이다. 지난번엔 Ainize를 이용하였지만, 이번엔 가능하면 아마존 클라우드를 이용해볼 생각이다. 아무래도 딥러닝 모델이다보니 inference에 컴퓨팅 파워가 필요해서 무료 플랜으로 가능한지는 모르겠지만 시도는 해봐야겠다.

더 많은 시도를 통해 모델을 개선해보고, 파라미터를 수정해보고 하고 싶은데 개인 컴퓨터로는 아무래도 한계가 있는 것 같다. 그래도 취미로 하기엔 재밌어서 다행이다. 추후 여유가 된다면 더 좋은 GPU로 실험해보고 싶다.

  이번에 아이펠 진행하면서 EDA 하는 방법에 대해 조금 더 자세히 학습했었기 때문에 배운 걸 이용해서 데이콘에 참가해봤다. 처음엔 아무런 EDA도 하지 않은 데이터에 RandomForest로 baseline을 잡고 시작했는데 생각보다 좋은 점수가 나온 것 같다. 모델은 당연히 lightgbm을 사용하였고 이전에 kaggle 대회 연습하면서 optuna를 사용해봤기 때문에 이번에도 역시 optuna를 이용하여 hyperparamter를 tuning 하였다.

  점수를 더 올리려면 train data가 더 필요하거나 feature engineering을 해야 할 것 같은데 아직 많이 경험해보질 않아서 어떤 feature를 조합해야 할지 감이 잘 오질 않는다. 시간이 될 때 kaggle의 다른 비슷한 대회를 참고해서 힌트를 얻어봐야 겠다.

  아직 대회 초반이라 분명히 아래로 밀릴 순위겠지만... 그래도 주말 내내 대회에 매달려서 10등 안에 들어본 것으로 만족한다. 이 기세를 유지해서 상금도 탈 수 있었으면 좋겠다 ㅎ

이전부터 뭐든 실제로 서비스를 만들어보는 것이 중요하다고 생각하여 아이펠을 진행하면서도 틈틈이 프로젝트를 위한 공부를 따로 하고 있었다. 그러다가 GAN을 이용한 노드를 진행했을 때, '이거다!' 하고 느낌이 와서 실제로 프로젝트로 진행해보기로 했다.

우선 기존에 아이펠 노드에서 진행한 모델은 내가 잘못 한건지, 노드가 잘못된건지 학습은 되는데 어딘가 이상한 결과물이 나와서 텐서플로 공식 튜토리얼을 보고 다시 모델을 만들어보았다.

데이터셋은 kaggle의 Sketch2Pokemon 데이터셋을 학습시켰다. train 이미지가 830장 밖에 되질 않았고, test 이미지도 train 이미지에 있는 중복 이미지여서 데이터가 부족하긴 했지만, 일단 서비스로 배포해보는 것에 의의를 두기로 했다.

프로젝트 진행은 다음과 같이 이루어졌다.

• 2021-03-28 : 프로젝트 시작
• 2021-03-28 ~ 2021-03-29 : 첫 번째 모델 학습 및 결과 확인
• 2021-03-29 ~ 2021-03-30 : 두 번째 모델 학습 및 결과 확인
• 2021-03-30 ~ 2021-04-01 : 모델 서비스화 진행 중
• 2021-04-02 : Ainize로 배포 완료

기존과의 차이점이라고 한다면 이미지를 Normalize 해주는 시점이 조금 다르다는 것이다. 아마 이 부분에서 문제가 생겨서 위와 같은 이미지가 학습된 것으로 보인다. 또한, 이미지 데이터를 다룰 때에는 항상 Normalize, Denormalize에 신경써야 하는 것 같다. 어떤 Activation Function을 사용하느냐에 따라 Normalize 범위를 [-1, 1]로 할지, [0, 1]로 할지가 결정되기 떄문이다. 이번에 사용된 모델에서는 tanh를 Activation Function으로 사용했기 때문에 [-1, 1]의 범위에서 Normalize 해주었다.

우선 시작부터 1000 epoch 정도를 돌려보고 시작하기로 했다.

• 학습 과정을 시각화 해본 결과, 400 epoch 정도 부터 큰 변화가 없는걸로 보아 local minima에 빠졌거나 학습이 종료된 것 같다.
• 750 epoch 의 checkpoint를 불러와서 기울기를 1/10으로 줄여서 50 epoch 정도 더 학습을 시켜보았으나 큰 변화는 없는 것 같다.
• 750 epoch 의 checkpoint를 불러와서 기울기를 10배로 늘려서 50 epoch 정도 더 학습을 시켰더니 오히려 원하지 않는 방향으로 학습이 진행되었다.

750 epoch에서의 learning rate 테스트는 자원이 남아서 학습이 종료됐을 때 learning rate를 조절하여 다시 학습시키면 어떻게 될까 궁금해서 진행해봤다.

모델을 학습해본 결과, 두 Loss를 비교해봤을 때, disc_loss는 감소하고 gen_loss는 증가하는 것으로 보아 generator가 discriminator를 속이기 위한 이미지를 잘 생성하지 못하는 것으로 판단된다. 실제로 train과 test에 없는 전혀 새로운 이미지를 입력했을 때, 다음과 같이 잘 생성하지 못하는 결과를 보여줬다.

아무래도 기존에 있는 이미지는 원본이랑 비슷한 정도로 생성하는 것으로 보아 train set에 overfitting 된 것 같다. 추가로 다른 데이터셋을 더 활용하거나, 모델의 구조를 바꾸어서 다시 학습시켜봐야겠다.

프로젝트를 진행하면서 많은 문제점과 어려움을 겪었다. 우선 웹페이지에 이미지를 하나 띄우는 것 까진 쉬웠지만 생성된 이미지를 다시 화면에 출력하는 것이 이렇게 어려운 작업이 될 줄은 몰랐다. 프론트엔드 개발자들 대단해...

겪었던 문제점들을 정리해보면 다음과 같다.

• 프론트엔드/백엔드 지식이 전혀 없어서 HTML부터 공부해서 페이지를 제작함
• Inference 결과 tensor object로 반환되어 해당 object를 바로 웹에서 rendering 가능한 방법을 찾다가 결국 이미지로 저장하여 rendering 하는 방식으로 진행
• 페이지는 정상적으로 만들어졌는데 계속해서 기존의 이미지를 가져옴 -> 브라우저 쿠키 문제
• model의 크기가 100MB가 넘어가서 git lfs를 이용하여 git에 업로드 하였으나 Ainize에서 불러오지 못하는 문제가 발생
• heroku에서 배포를 시도하였으나 메모리 용량 부족(500MB)으로 배포 실패
• 기본 git lfs 용량을 모두 사용하여 wget으로 바로 다운로드 가능한 무료 웹서버를 찾아보았지만 당장 쓸 수 있는 게 없어서 개인 웹서버 이용하여 모델 다운로드 후 Ainize로 배포

모델을 만들어서 학습시키고 실행 가능한 python 파일로 정리하는 것 까진 어렵지 않았는데 웹페이지를 구축하는 게 가장 어려웠다. 단순 텍스트 데이터가 아닌 이미지 데이터를 웹에서 띄우는 방법을 몰라 html을 공부해서 겨우 띄울 수 있게 되었는데 브라우저 캐시 때문에 정상작동 하는 걸 오작동으로 인식하여 다른 방법을 찾았다. 결국 프론트엔드를 공부하고 있는 sunhpark에게 도움을 요청하여 js로 웹페이지를 좀 더 깔끔하게 만드는 데 성공했다.

로컬에서 테스트 할 땐 잘 되었는데 막상 배포하려고 하니 적절한 서비스가 없었다. 우선 git에 모델 용량이 100MB를 초과해서 git lfs를 이용하여 Ainize로 배포를 시도하였으나 디버깅 하다가 git lfs 무료 사용량을 전부 사용하여 다른 서비스를 찾아보았다. heroku로 배포를 시도했을 땐 메모리 용량 부족으로 실패하였다.

마지막 남은 EC2는 1년만 무료여서 최후의 보루로 남겨두고 Ainize로 배포해보기 위하여 무료 파일 서버 서비스를 찾아보았지만 마땅한 게 없어서 결국 임시로 웹서버를 만들어서 Ainize에서 Dockerfile을 빌드할 때 모델을 받아올 수 있도록 하였고, 결국 성공하였다.

구글 드라이브나 네이버 클라우드 같은 곳에 파일을 업로드해서 wget으로 다운로드 받는 방법도 생각했었다. 그러나, wget으로 직접 다운로드 가능한 링크들이 아니어서 다른 방법을 찾았던건데, 나중에 찾아보니 구글 드라이브에 올린 파일도 wget으로 받을 수 있는 방법이 있었다. 당시엔 배포에 정신이 팔려 있어서 검색해볼 생각도 못 했나보다.

이번 프로젝트를 진행해보면서 왜 직접 해보는 것이 중요한지 확실하게 깨달았다. 아주 작은 토이 프로젝트였지만 어떻게 보면 프론트엔드와 백엔드 두 부분 모두 조금이나마 경험해볼 수 있었고, 직접 모델 설계부터 서비스까지 배포한 것은 MLOps라고 볼 수도 있지 않을까?

다음번엔 서버에 데이터 저장도 하고, 실제로 아마존 EC2나 GCP, Azure 같은 서비스를 이용하여 배포도 해보고, 좀 더 재미있는 아이디어를 가지고 팀원도 모아서 프로젝트를 진행해보도록 해야겠다.

해당 서비스는 다음 링크에서 테스트해볼 수 있다.

은 포기하는 게 좋다.

scikit-learn과 같은 라이브러리를 이용해서 만든 머신러닝 모델들은 가능할 지도 모르겠지만,

내가 시도했던 GAN 모델 중 하나인 U-Net구조의 Pix2Pix 모델만 해도 Heroku에서 배포가 불가능 했다.

로그를 확인해보면 알겠지만, heroku에 할당되는 container에는 약 500MB의 메모리가 할당되는 것 같다. 그러나 딥러닝 모델을 돌리기엔 턱없이 부족한 메모리이기 때문에 모델을 불러오는 과정에서 이미 메모리 부족으로 에러가 발생한다. 따라서 딥러닝 모델을 배포하려면 Ainize나 아마존 EC2와 같은 클라우드 서비스를 이용하는 것이 좋을 것 같다.

• VERY DEEP CONVOLUTIONAL NETWORKS FOR LARGE-SCALE IMAGE RECOGNITION

개요

VGGNet은 2014년 ILSVRC(ImageNet Large Scale Visual Recognition Challenge)의 Classification+Localization 분야에서 1, 2등을 했을 만큼 당시에 Classification 분야에서 좋은 성능을 낸 대표적인 모델 중 하나이다. VGG는 Visual Geometry Group의 약자로 연구팀 이름으로, VGG뒤의 숫자는 신경망 모델의 깊이(레이어 수)를 나타낸다.

모델의 구조

• Input : 224 x 224 RGB image
• 이미지 전처리 : train set의 RGB 평균값을 각 픽셀로 부터 계산하여 빼줌
• filter : 3 x 3, 1 x 1(input channel 에서 linear transformation 할 때)
• stride = 1, padding = same
• max-pooling : 2 x 2, stride = 2
• 3개의 FC Layer : 4096 → 4096 → 1000(classification, softmax)
• activation function : ReLU
• total 144M parameter(VGG-19)

모델의 구성

아래의 표 1에서 볼 수 있듯이, A-E라는 이름의 모델들을 11개의 layer(8 conv. + 3FC layers) 부터 최대 19개의 layer(16 conv. + 3FC layers)까지 모델의 깊이를 변화시켜가며 실험을 진행하였다.

VGGNet은 이전에 7x7의 filter를 사용하는 모델들과 달리 상하좌우의 feature를 추출할 수 있는 가장 작은 크기의 filter인 3x3을 사용하였다. filter의 크기를 줄이는 대신 layer를 늘려 7x7 filter와 동일한 receptive field를 갖도록 했다.

3x3 filter를 사용함으로써 얻는 이점은 다음과 같다.

1. 결정 함수의 비선형성 증가 7x7 filter를 사용했을 땐 activation function을 한 번 밖에 통과하지 않지만, 3x3 filter의 3개 layer를 사용했을 땐 activation function을 3번 통과하므로 함수의 비선형성이 증가하게 된다. 따라서 모델이 더 복잡한 특징도 추출할 수 있게 된다.
2. 학습 파라미터 수의 감소 7x7 filter를 사용한 C채널의 학습 파라미터 수는 $7^2C^2$로 총 $49C^2$이다. 그러나 3x3 filter를 사용한 3개 layer의 학습 파라미터 수는 $3(3^2C^2)$으로 총 $27C^2$이다. 7x7과 3x3의 3layer는 동일한 receptive field를 가지지만 parameter 수는 약 81% 감소했다. 따라서 학습시간에 있어서 더 유리하게 된다.

모델 학습

VGGNet은 다음과 같은 최적화 방법을 사용하여 모델을 학습시켰다.

• mini-batch gradient descent
• Momentum (0.9)
• batch_size = 256
• weight decay (L2 = 5e10-4)
• Dropout (0.5)
• Initial learning rate = 0.01
• 모델을 학습하면서 validation set accuracy가 증가하지 않을 때 learning rate를 1/10으로 감소시켰으며, 370K iterations (74 epochs)를 진행하는 동안 3번의 learning rate 감소가 이루어졌다.
• Initial weight는 N(0, 0.01^2)을 따르는 정규분포에서 sampling
• Initial bias = 0
• 고정된 224x224의 image를 얻기 위해 train image를 random하게 crop하거나 rescale하였고, 더 나아가 augmentation을 위해 random하게 수평으로 flip하거나 RGB color를 shift 하였다.

평가

1. local response normalization (A-LRN network)을 사용한 것은 큰 효과가 없었다. 따라서 더 깊은 레이어(B-E)에서 normalization을 사용하지 않았다.
2. ConvNet의 깊이가 증가함에 따라 classification error가 감소하는 것을 확인할 수 있었다. 해당 Dataset에서는 19개의 layer로도 error rate가 saturated 되었지만, 더 큰 Dataset에서는 더 깊은 layer가 유용할 수 있다.

결론

• ConvNet에서 layer의 깊이를 증가시키면 classification accuracy를 향상시키는 데 도움이 되며, ImageNet challenge dataset에 대한 state-of-the-art 성능을 얻을 수 있음을 증명하였다.

해당 모델을 코드로는 구현 해보았으나, 실제로 학습을 시켜보진 않았다. 150GB나 되는 ImageNet Dataset을 받아서 학습을 시킬 엄두가 나질 않았기 때문이다. ImageNet을 학습시키는 데 걸리는 시간은 P100 256개를 병렬로 연결해도 1시간이나 걸리는 것으로 알고 있는데, 단일 GPU를 사용하면 아마 몇 주 단위의 시간이 소요될 것이기 때문에 어쩔 수 없었다.

이 논문을 봤을 때, 딥러닝은 역시 컴퓨팅 파워가 중요하다고 생각했다. 과연 2014년 이전에는 deep network에 대한 인식이 없었을까? 물론 이전에도 deep network를 위한 시도는 있었으나 컴퓨팅 파워의 부족으로 ILSVRC의 dataset를 학습시킬 수 없었기 때문에 할 수 없었던 것으로 보인다. 분명 2021년인 지금도 엄청나게 깊은 deep network에 대한 시도는 계속 되고 있을 것이라고 생각한다. 다만 해당 network를 학습시킬 만한 컴퓨팅 파워가 부족하기 때문에 해당 network의 성능을 확인할 수 없을 뿐이라고 생각한다. 만약 딥러닝의 'deep'이 정말로 우리가 생각도 못할 만큼 'deep' 해야 한다면? 지금의 딥러닝 모델들이 이제 겨우 시작이라고 한다면?

실제 구현 코드는 깃허브로