[Docker Swarm으로 고가용성 서버 구축하기 - 5] 도입 후기

회사에 Docker Swarm을 사용하여 현재 하나 씩 Docker rising 하며 옮기고 있습니다. 도입하고 나니 뿌듯함도 있었습니다. 뭔가 많이 개선된 점들이 보였기 때문인데요. 하나 씩 차근차근 살펴봅시다.

CI와 CD의 완전 자동화

기존에는 하나의 서버를 병합 후 배포하는 동안 트래픽이 빠져나가는 걸 확인하고 이 후 배포 한 후 다시 트래픽이 들어오고 나서 개발자가 수동으로 다음 서버를 배포하는 방식이었습니다.

 

하지만 docker compose로 세밀한 배포 프로세스 조정이 가능하다보니 이를 docker swarm에 맡기고 배포 할 때 알아서 트래픽이 들어가야만 다음 컨테이너가 교체되어 개발자 입장에선 자동화 된 시스템에 맡길 수 있게 됐습니다. 이 동안 다른 시스템 배포를 하여 배포 시간을 줄일 수 있었죠.

shell script 감소

shell script는 linux에서 shell 파일을 실행시키기 위한 script 파일인데 이는 가독성도 좋지 않고 복잡한 shell script는 이해하기도 힘들었습니다. 하지만 docker swarm을 이용한 배포로 변경되면서 배포를 위한 복잡한 shell 들이 전부 사라졌고 image 빌드할 때 필요한

 

docker build push spring application build script문이 전부였습니다.
또한 배포도 GUI 기반 portainer로 하였기 때문에 프로세스 자체가 간소화 되어 이해하기 쉬워졌습니다.

신규 노드 추가에 필요한 리소스 감소

보통 신규 노드를 추가한다면 추가해야할게 굉장히 많았는데요 기본적으로 노드 메트릭 정보를 수정하기 위한 수집 agent라던지 Jar파일을 배포하고 log 폴더도 추가해줘야하는 수고로움이 굉장히 많았습니다.

 

하지만 docker는 컨테이너에 모든 세팅을 해놓다보니 이러한 소요가 전부 사라졌고 노드 메트릭 정보를 수정하기 위한 agent는 docker swarm replication 모드를 global로 하여 모든 노드마다 각각 컨테이너가 자동으로 추가될 수 있게 하였습니다.
결국 신규 노드를 추가하면 docker 하나만 설치하면 추가로 설치해야할게 많지 않아진겁니다.

도입할 때 가장 힘들었던 점

도입하면서 가장 힘들었던건 Reference의 부재였습니다. Kubernetes나 docker container에 대한 reference는 굉장히 많았습니다. 하지만 docker swarm에 대한 상세한 Reference나 Traefik에 대한 Reference를 국내 자료로는 한계가 있었습니다.

 

공식 Reference를 spring 다음으로 가장 열심히 봤던 것 같습니다. 또한 공식 Reference를 스프링 말고 참고 안하던 저도 항상 공식 Reference를 챙겨보는 버릇이 생긴건 좋았던 것 같습니다.

https://docs.docker.com/engine/swarm/

Swarm mode overview

https://doc.traefik.io/traefik/

Traefik Proxy Documentation - Traefik

이론과 실습은 다르다 !

도커 스터디를 진행하면서 당시 도입 전 자신감이 가득했었습니다. 하지만 회사에 Docker swarm을 도입하는 과정은 훨씬 고려할 것이 많았습니다. 배포 시 완전한 zero time 운영을 위해 어떻게 운영을 해야하는지

기존에 운영 중인 시스템에 영향을 주지 않고 더욱 더 확장 가능한 서비스로 고도화 하는 전략에 대한 고민 마지막으로 이런 내용들을 동료에게 소개하고 설득하는 과정들이 정말 어려웠던 것 같습니다. 

이론도 정말 중요하지만 이론을 배웠으면 반드시 한 번 써보면 좋겠다라는 생각이 들었습니다. 분명 이론과 실습은 다르고 훨씬 많이 배울 수 있는 것 같습니다. 

백엔드 개발자가 devops를?

백엔드 개발자로 현재 회사에 작년 6월 입사했고 올해 devops성 업무인 docker rising 및 인프라 시스템 개선 업무를 부여받고 수행했습니다. 후기는 정말 좋은 시간이었다는 겁니다. 백엔드 개발자라고 인프라 흐름을 몰라선 안되는 것이고 이러한 경험이 인프라 개발자를 더 이해할 수 있는 좋은 개발자로 성장하는 길이라고 생각했습니다. 

또한 개발자란 문제를 해결하는 직업이기 때문에 저 또한 제가 회사에서 풀 수 있는 문제가 있다면 적극적으로 해결하려고 했습니다. 이 점이 제 커리어에 날개를 달아줄지언정 발목을 잡을 만한 건 절대 아니라고 생각합니다. 

앞으로 남은 과제

현재 도입이 끝난 건가? 라고 하면 그건 아닙니다. 아직 고도화 할게 많은 상황입니다. 앞으로의 과제는 다음과 같습니다. 

• static resource 파일 관리 고도화 : 운영 중에 resource 파일이 교체되더라도 무중단으로 운영되어야 합니다. 
• 배포 직후 latency 발생 : 배포 직후 JIT compiler가 코드들을 효율적으로 최적화할 수 있게 하여 배포 직후 latency 발생을 방지합니다.
• log 중앙화 및 시각화 : log 수집을 중앙화 하고 한 곳에서 로그 확인 및 시각화 하기 위한 인프라가 추가되어 생산성 고도화합니다.