[고찰] 반려동물과 가축의 DevOps에 대한 고찰

우선 DevOps에 대한 생각은 개발과 동시에 build, release, deployment 및 운영을 같이 해 본다면
아주 오래 전부터 고려해 보았던 아주 지극히 손발이 게으른 개발자의 관점을 떠 올릴 수 있을 것입니다.

우선 그 유명한 DevOps 의 그림을 보도록 하겠습니다.

(위의 그림은 해당 페이지에서 인용하였습니다)

왼편 개발하는 곳에서 계획(plan)을 세우고 코딩(code)을 한 다음 빌드(build)를 하고 테스트(test)까지 성공하게 되면
일반 개발자의 역할은 종료 됩니다. 그리고 다시 위의 사이클을 돌게 되지요.

그 다음 운영의 역할에 대해 살펴보겠습니다.

운영자는 테스트가 끝난 개발자의 결과물을 특정 버전으로 릴리즈(release) 하고 이를 On-Premise나 클라우드에 배포(deploy) 하게됩니다. 그러면 운영(operate)을 하면서 시스템을 잘 모니터링(monitor) 하여 여기서 발생하는 문제점이나 요구사항 등을 다시 개발자의 개발 계획(plan)에 피드백합니다.

이렇게 하여 개발(Dev) 진영과 운영(Ops) 환경이 무한루프를 돌게 되는 것이지요.

요즘에는 이런 쳇바퀴를 빨리, 많이 도는 회사일 수록 경쟁력이 더 뛰어나다고 할 수 있겠네요.

자.. 이제 다른 그림을 하나 더 살펴보겠습니다.

(해당 슬라이드의 31페이지에 있는 내용입니다)

서버의 개발 및 운영 관점에서 바라본 그림이라 이해해도 됩니다.

우선 반려동물(Pet)을 살펴보면 우선 이름을 가지고 있고, 이름으로 부르며 밥을 주고 같이 생활하며 아픈 경우에는 병원을 데려가서라도 고치도록 노력합니다. 이를 서버로 비유해보면 지금까지 전통적인 방식의 서버라 생각하시면 됩니다. 고유 이름 (FQDN)을 가지고 있습니다. 90년대 초 KRNET의 소백 등의 서버는 아직도 기억에 남아 있군요. 그것을 운영하고 관리하는 관리자는 매일같이 들어가서 상태를 살펴보고 혹시라도 병이 나면 (하드가 고장나는 등) 어떻게든 고치려고 노력합니다.
또한 이런 반련동물 서버가 너무 늙어 성능이 딸린다 하면 CPU, Memory, HDD 등을 증설을 하던지 합니다. (Scale-up 이라 볼 수 있겠군요)

반면 가축(Cattle)을 살펴보겠습니다. 이런 가축은 이름 대신 번호를 가지고 있습니다. 각 가축의 번호에 따라 구별하기 보다는 동일하다고 생각합니다. 만약 아프거나 하면 돈을 들여 고쳐주기는 커녕 빨리 도축을 위한 출하를 시키겠지요. 이를 서버로 살펴보겠습니다. VM 기반의 IaaS 등이거나 또는 On-Premise 중에서도 VSphere Server 또는 XEN Server 처럼 VM을 자동을 만들거나 삭제하는 등을 할 수 있겠지요. 또는 컨테이너 기반인 경우에는 더 쉽게 해당 컨테이너를 만들고 지우고 다시 만들고 등을 VM에 비하여 아주 쉽고 빠르게 할 수 있습니다. 해당 VM 이나 컨테이너가 고장났을 (해당 특정 서비스가 멈추었거나) 경우 해당 VM이나 컨테이너를 지우고 다시 띄우면 됩니다. 또한 성능이 부족하다고 생각될 경우에는 CPU, Memory, HDD 등을 업그레이드 (Scale-up) 하는 대신 여러 개의 VM/컨테이너를 더 띄우도록 (Scale-out) 하는 방안을 고려하게 됩니다.

위의 반려동물 서버와 가축 서버를 DevOps와 연동해서 살펴보도록 하겠습니다.

개발자들은 처음부터 가축 서버에서 개발하는 대신 반려동물 서버와 같은 자신의 데스크탑 또는 개발 서버에서 개발을 합니다. 처음부터 가축 서버와 같은 곳에서 개발하는 회사라면 이미 대단한 자체 DevOps 환경을 구축하지 않았나 싶네요. 그리고 요즘의 대세로 운영에는 가축 서버를 이용하지요. 

만약 모르긴 몰라도 현재 가축 서버를 개발은 커녕 운영에도 적용하고 계시지 않다구요??

제가 알고 있는 수십년 전부터의 개발 운영은 모두 반려동물 서버 환경이라 할 수 있겠군요. 이를 다른 구조적 관점에서 살펴보겠습니다. 모놀리식 구조(참고내용)라 불리는 것이라 할 수 있겠네요. 마치 JSP, PHP, ASP 등의 서버사이드 스크립트를 이용해서 웹 서비스를 담당하고 해당 RDB도 모두 설치해 놓아서 해당 서비스가 돌고 있는 형태이지요. 이와 같은 경우에는 성능향상을 위해서 스케일-아웃 보다는 스케일-업 방식을 사용해야 합니다. 

이와 반대되는 구조로 SOA를 거처 MSA 라는 구조가 최근 몇년간은 큰 유행이 되었습니다. 제가 보는 관점에서 그 이유는 이렇습니다. 모든 것을 한데 모아 개발되던 것을 프론트엔드, 백엔드로 크게 나누고, 백엔드로 아주 쉽게 스케일 아웃을 할 수 있도록 더 잘게 웹서버, API 서버, DB Access, 저장소 등으로 잘게 나누어 놓고 서로 서로 유기적으로 묶이도록 함으로써 결국 가축 서버 형식을 구성했다 할 수 있겠습니다. (해당 블로그 참조)

제가 보기에 기존에 수없이 많은 회사 (특히 역사가 오래된 경우 일 수록)가 이런 반려동물 서버 식의 구조 및 개발 운영인 상태에서 기존의 모든 소스를 모놀리식 구조 대신 MSA 구조로 나누고 바꾸어 VM/컨테이너로 돌릴 수 있게 해야만 되는데 결코 쉽지 않습니다. 아무리 DevOps가 좋아도 자기 회사에 수없이 적용하려다가 문화가 안 맞아 실패했다는 것과도 연관되어 있는 문제입니다.

이를 해결하기 위해서는 이전의 모놀리식 구조도 꾀뚫고 있는 사람이 최근의 MSA 구조와 VM/컨테이너 운영 및 DevOps, CI, CD 등에도 빠삭하여 기존 구조를 이해하고 조금씩 분해해서 새로운 구조 환경으로 나아가야 한다는 것을 의미하는데 이런 능력을 지닌 개발자/운영자를 찾기에는 정말 어렵습니다. 따라서 기존의 것을 잘 모른채 최근 MSA, DevOps를 공부한 사람이 그런 역할을 하기에는 어렵지 않을까 싶습니다.

암튼 풀어야 하지만 쉽지 않은 부분입니다.

저는 오늘 새로운 관점에서 하나를 살펴보겠습니다.

왜 개발에서는 아직도 반려동물일 수 밖에 없는가 하는 것입니다. 이를 설명하기 위해서 좀 다른 각도에서 이야기를 출발해 보겠습니다. 우분투라는 리눅스를 사용하면 데스크탑과 서버 버전의 차이가 있습니다. 서버 버전은 X윈도우의 UI가 없습니다. 순수히 서비스를 돌리기 위한 구조라 생각하면 됩니다. 대신 데스크탑은 내 개발 서버와 같이 UI가 있어 쉽게 IDE등도 실행하고 에디터도 돌리고 하는 등의 일을 할 수 있습니다. 그래서 처음에 시도한 것은 우분투 서버 버전에 최소한의 UI 환경 및 원격접속 가능 환경을 만들어 이를 개발 환경으로 구축해 보는 것이었습니다. (해당 블로그 참조)

최근에는 우분투 서버를 토대로 이런 환경을 얹은 커스텀 ISO를 만들어 공개하기도 했습니다.


그래서 위의 이미지를 실제 서버에도 설치해 놓고, 자신의 노트북에 가상머신으로도 설치하여 개발한 다음 서버에 구동시키게 하는 작업을 수년 이상 해 왔었던 것 같습니다.

그러다가 작년 부터는 기존의 VM 위주의 개발환경을 docker 기반의 환경으로 이관하기 시작하였습니다. 그러다가 개발은 계속 VM 위주로 하고 이를 컨테이너 기반의 운영에 적용하려고 하였는데 역시 환경의 문제가 생기는 것을 알게 되었습니다.

가장 큰 차이는 우분투 서버는 실제 기계의 서버에 OS로 설치하기는 좋으나 이를 컨테이너 운영에는 너무 무겁다는 것을 알았습니다. 실제 컨테이너는 더 작게 구동시키기 위하여 alpine linux로 컨테이너를 대부분 구성한다는 사실을 알았습니다. 적어도 수백메가의 우분투 이미지가 아니라 단지 3.5메가바이트의 알파인 위에 동일한 서비스를 올리면 무척이나 가벼운 컨테이너를 만들 수 있기 때문입니다.

처음에는 알파인 리눅스를 VM에 설치하고 거기에 윈도우 환경을 구축하려고도 해 보았으나 역시 VM과 컨테이너간의 쓸데없는 고려 사항이 발생하는지라 결국 알파인 리눅스의 컨테이너에 X윈도우가 돌고 개발할 수 있는 IDE가 있는 환경을 구축할 수 있을까 하는 고민을 하게되었습니다. 시간을 좀 많이 소요되기는 하였지만 결국 일단락을 지었습니다.

위와 같이 특정 docker에서 컨테이너를 돌리고 이를 원격 데스크탑 또는 웹브라우저로 접속해서 위와 같은 UI 환경을 얻을 수 있습니다. 대신 개발 소스나 환경 등은 해당 docker 가 돌고 있는 서버의 볼륨에 마운트 되어 있겠지요.

docker-xfce : 약 588MB의 크기로 컨테이너를 구동시키면 X윈도우에 xfce4 윈도우 매니저가 동작하고 터미널과 firefox python2 등이 설치되어 있습니다. 우분투 기반에 구축하였다면 1GB 도 더 클텐데 많이 작아졌습니다. 

* docker-xfce-conda : 위의 docker-xfce 환경 위에 conda (miniconda) 환경을 추가하였습니다. IDE와 miniconda를 위한 패키지 등이 추가되어 약 1.18GB 입니다. 하지만 위의 docker-xfce 이미지 위에 구축되므로 그 이후의 이미지만 받아오면 되겠습니다.

* docker-xfce-pyenv : 위의 docker-xfce 환경 위에 pyenv 환경을 추가하였습니다. IDE와 pyenv를 위한 패키지 등이 추가되어 약 1.29GB 입니다. 하지만 위의 docker-xfce 이미지 위에 구축되므로 그 이후의 이미지만 받아오면 되겠습니다.

위의 컨테이너는 VM 대비 이렇게 하는 장점은 VM은 아주 쉽게 해당 하드가 급속하게 늘어나고 잘 줄어들지 않지만 위에 컨테이너는 마운트 된 자신의 작업 폴더를 제외하고는 아무리 늘어나더라도 컨테이너를 다시 재기동시키는 순간 원래 크기로 돌아갑니다. 또한 VM에 비해 더 sandboxing이 잘 되어 있기에 보안도 더 나으리라 봅니다.

결론.

성급하게 결론이라고 할 것 까지는 없지만, 어찌보면 반려동물 환경은 점차 사라지고 가축 환경으로 가는 것이 피할 수 없는 추세라 생각합니다. 결국 개발자 환경도 이런 가축으로 꾸며보면 어떨까에서 출발한 것이구요. 또한 운영 쪽에서도 생각해보면 기존의 무거웠던 데스크탑 가상화 (VDI) 등에서도 기존의 VM 위주와는 달리, 위와 같이 가벼운 컨테이너 기반으로 흘러가지 않을까도 예상해 봅니다.


어느 분께는 도움이 되셨기를... 

[macos] 맥에서 docker를 이용할 때 크기 조심

맥에서 docker를 잘 이용하여 사용하고 있습니다.(2017.8.16일 현재 최신 버전)그런데 잘 사용하고 있다가, 문득 ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2라는 파일이 36GB 의 어마무시한 크기인 것이었습니다.구글링 후 검... » 내용보기

맥북프로에 샤오미마우스 사용기

이제는 샤오미 전동 킥보드 뿐만 아니라 새 제품이 나오면과연 일반 비교 제품의 절반 가격에 얼마나 기능이 좋을까 하는 마음으로 구입하여 사용해 보기 시작했습니다.며칠 전에 오랫만에 판교 일렉트로 마트에 들렸다가샤오미 마우스를 구입하였습니다. 가격은 2만 몇천원 했던 것 같습니다.며칠 사용해 보고, 나름 다른 제품에 비해 좋은 것 같아 소개해 봅... » 내용보기

[macos] Sierra에서 각 폴더에 .DS_Store 파일이 안 생기도록 수정

맥을 한 십년간 잘 사용하고 있는데 언제부터인가 각종 폴더에 .DS_Store 라는 히든 파일이 생성됩니다.이 파일의 역할이 무엇일지 궁금했는데 위키피디어 내용에서 찾아보니,윈도우의 Disktop.ini 파일 (또는 .Thumbs.db ?) 등과 유사하게 아이콘이나Spotlight의 검색을 위한 메타 정보가 들어가 있는 것이라 하더군요.그런데 저는 $H... » 내용보기

[Mac] 메일에 첨부된 win mail.dat 읽기

가끔 맥에서 메일을 확인하다 보면 첨부파일 부분에위와 같이 winmail.dat 라는 첨부 파일이 보이는 경우가 있습니다.그냥 일반 메일 내용이면 상관없는데 메일 내용에는 분명 ... 첨부파일이 있다는 식으로 나옵니다.이런 현상이 발생한 이유는 마이크로소프트의 Exchange Mail 또는 Outlook 등에서 메일을 보낼 때일반 MIME 외에 TNEF... » 내용보기

구글애드텍스트