본론에 들어가기 앞서, 해당 글은 필자의 개인적인 경험을 많이 포함하고 있습니다.
Docker가 개발 환경에 왜 필요한지가 궁금하신 분은, 도커가 필요한 이유 부터 확인하세요
레거시와의 만남
필자는 대학생 당시, 우연한 기회로 학내에서 사용되는 온라인 저지 머신을 유지보수 할 기회가 있었다.
온라인 저지 머신이란, 교수님들이 문제를 출제하고 학생들이 코드를 제출하면, 학생들의 코드가 정확한 로직을 가지고 있는지 검증하는 서비스이다.
최근에는 많은 기업에서 코딩 테스트가 채용 프로세스에 추가되면서, 유명해진 Baekjoon Online Judge과 동일하다고 보면 된다.
현재도 리트머스 라는 이름으로 학내에서 이용되고 있을 것이다.
다만 해당 시스템은 개발 이후 방치되어 있었다고 봐도 무방할 정도로 지속적인 관리가 이루어지지 못했다.
아래는 필자가 리트머스 시스템 관련 보고서에서 해당 시스템에 대해 언급한 내용이다.
문제는 이렇게 유용하게 이용되는 서비스의 유지보수가 지속적으로 진행되지 않았다는 점입니다. 10 년이 넘는 기간 동안 유지 보수의 주체가 명확하지 않고,
지속적인 지원이 존재하지 않았기 때문입니다.
문제의 시작
어찌되었든 필자는 대학교 2학년의 신분으로 해당 시스템의 관리를 맡게되었다.
처음엔 별일 없겠지.. 라고 생각했지만 그건 오산이었다.
문제는 나를 아끼시던 교수님의 부탁으로 시작했다.
1학년 교양 수업에 파이썬을 사용하게 되어서,
파이썬도 리트머스에서 사용할 수 있게 해주면 좋을 것 같구나.
처음 시스템을 맡아 유지관리 할때에는 구조에 대한 이해도 없었기 때문에,
동아리 지도 교수님의 도움을 받아, 작은 구조부터 이해하기 시작했다.
그러다보니, 차츰 문제점들이 발견되고 느껴지기 시작했다.
아래는 당시 작업을 하며 느꼈던 문제점들이다.
테스트 서버의 부재
리트머스라는 서비스는 실제 현재 서빙되고 있기 때문에,
개발 후 배포 전 정상 작동 여부를 확인하고, 다른 기능에는 영향이 없는지 확인하기 위해서는
테스트 서버가 필수적이었다.
초기에는 테스트 서버가 존재했지만, 비용 문제인지 어느샌가부터 운영서버 하나만 가지고 운영이 되기 시작했고, 내가 관리에 투입되었을때 쯤엔 테스트 서버는 구경할 수 조차 없었다.
결국 동일한 환경의 테스트 서버를 구축하는데에서 부터 실패했다...😭
버전 관리의 부재
코드 버전 관리를 위한 Git 또는 SVN과 같은 버전 관리가 진행되고 있지 않았다.
단순히 코드 뭉치를 tarball형태로 관리가 되어 있었고,
이마저도 한참 전에 백업된 백업본을 가지고 있었다....ㅠ
서버 노후화로 인한 서비스 불안정
2020년 당시, 장마가 유독 길고, 비가 많이 왔었다...!
관련 나무위키 문서
폭우도 왔기 때문에, 건물 서버실에 잦은 정전으로 인해 안그래도 노후화되어 느린 서버가, 점점 문제가 발생하기 시작했다.
잦은 서버 다운으로 인해, 이럴 때마다, 매번 서버실로 뛰어가 물리적으로 부팅해야 했다...
유지보수 관련 문서 부재
당연히 유지보수 문서는 존재하지도 않았다...!!
(그나마 계정 정보가 남아있는게 다행이여야 할 정도)
처음부터 끝까지 알아서 스스로 해야했다.
🤯 그래서 도커가 왜 필요하냐구!
도커(컨테이너 기반 가상화)는 아주 중요한 2가지 속성을 만족시키는 가장 쉬운 개발 툴이다.
Infrastructure as a Code
IaC(코드로 관리하는 인프라)는 코드 기반으로 인프라를 정의한다는 개념이다.
서버를 어떻게 구성할 것인지, 어떤 라이브러리와 도구를 설치할지를 코드로 정의한다. 또한 셰프(Chef)나 앤서블(Ansible) 같은 프로비저닝 도구로 서버를 구축한다.
수작업이 개입할 여지를 줄이고 코드 중심으로 바꿈으로써 쉽게 같은 구성의 서버 여러 대를 복제할 수 있다.
Immutable Infrastructure(불변 인프라)
앞서 언급한 IaC만 만족한다고 모든 문제가 해결되는 것은 아니다.
같은 코드라도 결과물이 다를 수도 있다. 예를 들어, Stable 버전이라고 코드에 명시해 놓으면 시기에 따라 Stable 버전이 달라 다른 결과가 나타날 수도 있다.
따라서 언제든 몇 번을 실행해도 같은 결과가 나온다는 멱등성이 보장되어야 한다.
따라서 이러한 문제는 불변 인프라가 해결해줄수 있다.
불변 인프라는 어떤 시점의 서버의 상태를 저장해 복제할 수 있게 하자는 개념이다. 제대로 설정된 상태의 서버를 항상 사용할 수 있다는 점이 가장 큰 장점이다.
서버에 변경을 가하고 싶은 경우에는 기존 인프라를 수정하는 대신 새로운 서버를 구축하고 그 상태를 이미지로 저장한 다음 그 이미지를 복제한다. 한번 설정된 서버는 수정 없이 파기되므로 멱등성을 고려할 필요도 없다.
긴 글의 결론.
도커를 사용하면 위 2가지 개념을 낮은 비용으로 쉽게 구현할 수 있다. 따라서 도커만 제대로 사용했어도, 내가 그런 문제를 겪지는 않지 않았을까...?? 라는 조심스런 의심을 해본다
