Docker 이야기

도커가 대중화된지 꽤 오래됐으나 배포 빈도/ 새 환경 구성, 오토 스케일링이 덜 필요한 환경에서 일할 수록 도커의 필요성이 상대적으로 우선 순위에서 밀리는 일이 비일비재했다. 나 역시 그랬고, 가볍게 사용해보거나 일부 서비스에서 도입했을 뿐이었다.

대 다수 개발자들은 아직도 서버를 새로 띄울 때 Dockerfile을 작성하고 Docker위에 올리기보다는 바이너리 빌드 후, 바이너리를 업로드 하고, 서비스 스크립트 작성하고, 서비스로 가동 시키는 데에 좀 더 익숙했고, 그렇게 가동 하게 되는 일이 많았다.

일부 서비스라도 도커로 올려보자는 설득에도 수 많은 관리자들이 반색을 내비치는 일이 비일 비재했다. VM이 거쳐온 길이 그랬듯 기반 환경이 달라지는 데에 대한 부담이 아주 커서일 것이라고 본다.

VM이 오랜 시간 개발자들에게 리얼 머신을 대체제로 자리잡았음에도, 그런 VM마저 서비스의 온전한 격리가 이루어지지 않는 경우가 비일비재해, 동일 호스트 머신에서의 서비스가 CPU 사용량이 급증하면 장애가 전파되는 일, 네트웍 격리가 제대로 이루어지지 않아 네트웍 트래픽을 과다 사용하는 서비스가 있을 경우 영향 받는일, 떨어지는 캐시 히트률로 인한 성능 저하 등 VM에 대한 우려도 있는 마당에, 도커 구동 환경, 도커 호스트 머신 이슈에 대한 막연한 불신도 어느정도 자리잡혀 있지 않나도 생각한다.

또한 안정성이 최우선이어야 하는 서버 프로그램, 서비스를 도커라는 (잘 모르기 때문에)불안한 기술 스택위에 올리고 싶지 않음도 한몫한다고 생각도 하고.

역사는 반복됐지만, 프론티어이자 Tech Freak 들은 도커를 시도했고, 도커로 서비스가 VM보다 유연한 어플리케이션 구동 환경을 유연하게 만들어준다는 것을 증명했다.


그나마 VM이 빠르게 시장에 안착한 이유는, 가상화라는 불안요소를 제외하면, 리얼 머신과 동일하게 운용 전략을 가져갈 수 있다는 점이다.

반면 Docker는 기본적인 용법으로 사용시 Docker 내부 데이터를 확인하기 위해 다른 명령어를 이용해 확인해야하고, 저장소를 다루는 방식, 포트 연결등 익혀야 될 명령어가 있다는 것 자체만으로도 (막상 써보면 그렇게 어렵지 않지만) 심리적 저항감과, (귀차니즘과 시간 소모가 아무래도 더 되기 떄문에)실천적 저항감을 같이 가져다 준다.

Docker로 어플리케이션 구동시 가장 큰 장점은 격리된 환경이다. 리얼 머신은 자원 효율, 수급 문제, 비용 문제등으로 한 머신에 여러개의 인스턴스 혹은 서비스를 올리는 선택이 어느정도 있을 수 밖에 없다.

(너무 슬프지만) VM의 경우에도 한 VM위에 여러개의 서비스를 올리는 경우가 빈번하다. 세팅 이슈나 자원 조절, 디스크 공유 등의 여러가지 이유에서 말이다.

VM의 경우에 Chef와 같은 환경 구성 도우미가 있다지만, 이미지를 조금만 잘못써도, 패키지 저장소, 버전, 패키지 업데이트 상황등이 조금만 달라져도 스크립트가 오류 나기 쉽상이며, 같은 스크립트 임에도 연관 패키지들의 업데이트만으로 not working이 되기 쉽상이다.

이에 대응되는 환경 구성 도우미 도구를 지원해주는 클라우드 서비스를 이용하거나, 이미지를 구워놓고 가동하는 방법도 방법인데, 여전히 업데이트 시의 실패에 대한 구멍이 남아있으므로 번거롭고, 제약이 많다.


도커는 애초에 이미지를 생성 할 때 연관 패키지들을 모두 포함 시킬 수 있으므로 격리된 환경 구성에서 훨씬 유연하다.

VM 이미지를 복사해서 가동까지 필요한 시간에 비해, 도커는 가동 속도도 우수한데가, 격리가 훨씬 더 우월하다. 애초에 서비스마다 내부 포트로만 동작하며, 선택적으로 외부 포트로 바인딩되므로 포트 이슈나 설정 이슈에서 혼란을 겪을 일이 훨씬 적어진다.

종종 잊혀지는 사실인데, 도커는 (VM에 비해)경량 컨테이너다. 구동까지 필요한 자원이 VM보다 훨씬 적게 소모된다. 이에 대한 자세한 내용은 아래 글을 참고 하면 좋겠다.

디스크는 기본적으로 영속성이 유지되지 않고 휘발성으로 동작하는데, 이에 맞게끔 운용해주는 것이 필요하다. (특히 여러 오케스트레이션 도구를 통해 스케일 인-아웃 설정시 로컬 디스크 데이터는 사라진다고 보는 것이 옳다)

이런 몇가지 특성에 대해 이해를 하고, 도커를 통한 운용에 적응이 되고 나면, 자연스레 오케스트레이션 도구에 관심이 갈 것이다.

도커의 장점인 격리된 환경 구성, 빠른 가동을 잘 활용하려면 당연히 오토 스케일 인/아웃, 빠른 서비스 배포를 해야 한다. 이를 위해서 Docker 스크립트 셋으로 구축하는 것보다 이미 잘 갖춰진 오케스트레이션 도구를 사용하는 것이 더 효율적이며, 충분히 활성화 되어 생태계가 구축되어있으니, 잘 활용만 하면 아주 편한 배포/운용 환경을 구축할 수 있게 된다.

그 중 가장 유명하고, 많이 이용되고 있는 오케스트레이션 도구인 쿠버네티스에 대한 감상은 다음 글에서 자세히 다뤄보도록 하겠다.

Comments

comments powered by Disqus