Intro
서버: 주인님…혼자는 이제 무리에요…제발 인원좀 추가해주세요
개발자: 그래? 그럼 인원 추가해줄께! 잠시만 기다려봐!
(… 🔥🔥🔥🔥🔥 … )
.
.
.
개발자: 짠! 너의 분신이야 이제 일할수있지? 어..? 왜 집이 없지...!?
전 회사를 다니면서 배포 시간이 얼마나 중요한지 한번 겪어봤던 적이있어서
이런 상황을 해결하고자 Docker 를 도입하게 되었는데 그 과정을 기록하고자 남기려고 합니다.
첫번째 사례
요약: AWS 가용영역 때문에 ARM 만 대여가 가능했고 이때
Node 17버전대신18 버전으로 강제로 버전 하면서 배포 시간이 올라갔다.
한때 자사 상황상 서비스를 분리하고자 새로운 서버 컴퓨터로 이전 하게 되면서 발생을 했습니다 ㅠ
당시 앱 서비스의 개발 스택은 다음과 같았습니다
Node 17 버전MySQL 8.0 버전
이전 서버에서는 Node 설치가 17버전으로 깔려있어서 무난 하게 의존성문제가 없었지만
이전 보다 서버의 크기가 커지고 내부 서비스 로직이 많아지면서 서버의 크기가 점덤 커진 상황이라
당연히 이전 EC2 의 스펙을 업그레이드 해서 대여를 완료한 상황이였다
이제 Node 17버전 을 깔려고 했지만
안탑깝게도 대여한 CPU 아키텍처 때문에 설치가 불가 했다
이유인 즉슨 이전하는 김에 보안도 강화할 겸 ProxyServer 를 제외한 나머지 자원들을 VPC 내부 네트워크로 구성하고 있었는데
이때 프라이빗 가용영역에서 X86 을 지원하지 않고 오로지 ARM 만 대여가 가능했기 때문이다
덕분인지…이상하게 Node 17버전을 깔지 못하고 18버전만 깔리게되는 이상현상이 있었다
그래서 결국 배포 버전은 18버전으로 세팅이 되는데
이때까지 걸린시간이 무려 1시간 가까이 됬던 것같다
심지어는 중간중간 NPM 버전 충돌 때문에
반납하고 다시 받고를 2회정도 반복 한 기억이 난다
겨우 겨우 세팅을 하고 서버를 올리니 바로 의존성문제가 터지게 되면서 해당 라이브러리들을 전부다 각각 업데이트 하게되면서 시간은 더욱 흘러갔다.
누군가 말했던 말이 생각났다
세팅이 반이상이라고… 그게 지금같은 상황을 의미하는게 100% 다 라고 느껴질 정도로
다운로드 - 설치 - 확인- 삭제 - 완전삭제 등등
혹시나 될까? 하는 마음으로 꾸준하게 시도를 해본것같다
결국 설치를 마무리 하긴 했지만 압선 시도들 때문에 하나라도 잘못 건들이면 무너질 것같은 불안감이 엄슴했다
두 번째 사례
요약: 극악의
PythonAnaconda,Tensorflow설치와Apple M1간의 호완성 이슈
바로 의존성과 관련된 사례이다
서비스 특성상 AI 를 다룰일이 있어서 Python 도 겸해서 설치를 한적이있는데
AI 를 다루는 사람들이라면 Tensorflow 의 설치방식에 치를 떨었을 것이다.
특히나 M1 유저라면...!!
Intel 과 윈도우는 정상작동
심지어 이번 사례는 배포버전도 배포버전이지만
개발 컴퓨터에서부터 설치에 난항을 겪었다 ㅠㅠ
당시 쓰고있던 컴퓨터는 맥북 M1 프로 13인치 였는데
CPU 자체가 Apple 사에서 만든 m1 칩이라 기존의 Tensorflow가 지원을 하질 않았다
그래서...3일간의 고생을 기억하자면..!
Tensorflow 에서는 애플 칩지원을 하질 않기 때문에...!
기존CPU를인텔로 바꿔주는 환경을 만들어야 해서
iterm 을 Rogetta 버전으로 열고… 실행하고...
거기서 또GPU를 연산할 수있도록 하는CUDA를 깔고….
라이브러리 다운시AppleSlicon을 위한 패키지 저장소를 수정하고...
... 많은 일이 있었습니다...기억이 나질 않을 정도로..
정확하게 어떤 라이브러리를 했는지는 기록을 하질 않아 기억이 잘 나진 않지만
저런 식으로 전개가 됬던 것 같았다.
안타까운건 이걸 다 했는데도 결국 의존성문제도 터져버렸다…
Python 버전 또한 3.8 이였는데
특히나 얼굴인식을 하는 중요한 라이브러리인
MediaPipe 에서 메소드 실행이 안되었고
구글링 해보니[stackOverFlow]...Python 3.7 버전까지 지원한다는 이야기를 듣고 혼이 다빠져 나가버렸다.
여기서 나는 결심을 하게 됬다
이전 부터 조금씩 알고 있던 Docker 를 도입할 때가 되었다고 말이다
Docker: 헤이 모두들 안녕~ 내가 누군지 아늬!?
우선 Docker 의 장점 중 가장 매력적이였던 점은 서버 환경이 어떻든 간에
개발과 같은 환경에서 동작한다는 것이였다
???: 내컴퓨터에서는 되는데요??
이 말을 자주 했었고 들었던 입장에서 굉장히 안타까웠다. 실제 배포 서버에서 실행하면 문제가 터져버리니
테스트 서버를 아무리 열심히 배포를 하더라도 비용 때문에 운영서버 보다 스펙이 낮게 설정해야만 해서
환경이 살짝 달랐다
그래서 문제가 없다고 생각했지만 의존성문제는 역시 실제 서비스가 동작하는데에서 되질 않으면 큰 일이 날 뿐이다
이런 점을 명확하게 하기위한 Docker 의 장점이 굉잘히 눈에 잘들어왔고 이전에 서버를 복제하는 과정에서도 더 빠르게 배포될 거라는 확신을 갖게되어 선택했다
다른 컨테이너 솔루션도 있었지만 상황이 상황인지 가장 대중적이고 버그가 없도록 빨리구현하고 싶었어서 바로 공부를 했던 것같다
요약: Docker 의 장점 중 개발 환경과 배포환경이 동일할 수 밖에 없다! 라는 점 때문에 Docker 도입을 결심함
그래서 어땠냐면...!
제일 먼저 사용하게 된 Python 환경에서의 Docker 도입은 할말이 잃을 정도 간단했고 실행도 매우 잘되었다...
마치 그동안의 고생이 의미가 없는 것처럼...말이다.
심지어는 구동될 환경에 따라 단순히 명령어만 입력해주면 알아서 구동이 되는 부분이 너무 감격스러웠다..!
# docker build 시 Terminal 명령어 - 개발 컴퓨터
docker build -t [태그명]:[버전] --platform linux/amd64
# docker-compose.yml - 배포 컴퓨터
services:
[서비스이름]:
container_name: "[서비스 이름]"
image: [이미지이름]: [태그]
ports:
- "8888:8888"
environment:
- [환경설정]:[값]
restart: always
platform: linux/amd64 // <- 해당 부분이 CPU 아키텍쳐에 따라 수정이 가능하다!!
그래서 AI 과 관련된 Flask 를 구동할 때 문제가 되질 않았고
무거워진 Node Server 또한 같은 방식으로 Docker Image 파일을 만들어 Hub 에 저장해 놓으니
서버를 증설하거나 실 개발 서버를 배포를 할때도 시간이 매우 단축되었다.
EC2를 대여한 후- 패키지 업데이트 -
apt-get update docker,docker-compose설치docker-compose.yml작성(복사).env파일 작성(복사)- 컨테이너 실행
이러한 과정을 미리 만들어 두었더니...!
몇 달뒤 트래픽이 갑자기 폭증하여 AWS CPU 시용량이 99% 를 찍었을 떄
10분 만에
서버를 증설하여 Nginx 설정 수정 후 바로 트래픽을 분산할 수 있었다.
당시 이런 조치를 미리 손을 보지 않았다면... 당시에 또 얼마나 멘탈이 붕괴 되었을지...상상이 가질 않는다...
덤으로 알아본것 들
AWS 에서 아에 Docker 를 이용해서 아에 Image Container 만으로 Application 올리는 방식이 있다고 들었다
ECS - Elastic Container Service 의 준말로
기본적으로 서버컴퓨터를 대여하는 EC2 에서
어차피 Dokcer 로 이미지만 돌릴거면 이미지만줘 내가 컨테이너 만들어줄께
이런 느낌으로 다가온 서비스 였는데
Docker Image 를 이용하여 이미지별로 Continaer 를 생성, 추가 할 수 있는 서비스 이다.
이것도 적용하면 좋을 것같았는데 느낌상 비용이 일반 EC2 보다 높아보였고 이걸 한다면 로드밸런서 설정도 해야한다고 들어서
그렇게 까지는 구성하고 싶은 생각이 없었다.
Outro
혹시라도 아직 Docker 라는 솔루션을 이용할지 모른다면
그리고 현재 개발환경을 직접 세팅하는 분들이 계시다면
가장 강력하게 Docker 로 가야한다고 말해주고 싶다.
Docker 를 이용한다면 기존 설치과정보다 훨씬 앞도적으로 줄일 수 있으니까 말이다.
