VM Template 이미지를 어떻게 만들고 운영해야 유리할까~???
최근, Chef로 서비스 구성(Configuration) 자동화 파트를 다시 하게 되었다. 여기저기 타 부처 수행 인력과 협업도 해야 하는 상황이라, 가상화 인프라부터 논의를 통해 결정을 지어야 할 일이 많다... 서비스 구성에는 Hadoop Cluster, MySQL & Replication, Cassandra, MongoDB, HAProxy LB, Apache/Tomcat, 등등 여러가지 서비스들이 버튼 한번의 클릭으로, 동적 구성 및 동작이 되어야 한단다. (쉽게 이야기들 한다...쿨럭...) 이러한 일련의 자동화 구성/배포 전략 수립단계에서 여러사람들끼리 혼선도 있고, 의견 충돌이 있는 것은 당연하다. 왜? 정답이 없는 거니까~ ㅡ.ㅡㅋ 사실 이 섹션의 고민은 Cloud라는 단어가 국내에서 화자 되기전, RIS라는 OS 원격 설치 서비스를 구축 할 때에도 심각하게 고민됐었다... "과연 어느 선까지 사전에 설치 해두는 것이, 유연성과 편의성 두마리 토끼를 다 잡을 수 있을까?"...라는.... 결국 그 당시에는 지금의 Chef나 Puppet만큼 완성도 있는 도구가 없다는 핑계를 대며 일정에 쫓겨 최대한 밀어넣기(?)로 쫑친 기억이....
아무튼 그 중, 가장 어정쩡하게 결론이 난 것이 어떤 방식의 Template를 사용하냐~였다. 이참에 그 사항에 대해 정리를 나름대로 해두고 싶어 일단 펜을...아니 키보드를 두드려 둔다. 물론 서두는 없다. 생각 나는대로.. 우선...
PaaS, SaaS... 당연히 밑바탕이 IaaS라 불리는 가상화 서버스가 "반드시" 필요 한 것은 아니다. 그러나 즉시성, 그리고, 자원의 효율적 활용(이 부분도 아직 갈길이 멀기만 하지만...), 유연한 인프라 관리 체계(이 말도 참 귀에 걸면 귀걸이인 마케팅용...)라는 진부한 이야기들 외에 본 글에서는 오로지 Physical 인프라와 비교해 상대적으로 설치/구축이 쉬운 점을 감안하여 "필수적"이라는 가정하에 이야기를 풀어 볼 생각이다... (물론 이 말에는, 가상화를 위한 Physical 인프라는 이미, 그리고 부족함 없이 구축되어 있다는 대전제가 깔려 있어야....쿨럭..ㅡ.ㅡ;;)
여기서 논점의 주제는 뭐냐.....
1) Pre-Installed Template 방식
; 가상머신 이미지(VDI :: Virtual-Machine Disk Image)에 원하는 서비스와 설정들을 사전에 설치 해두는 것이 유리하냐?
아니면,
2) OS-Only Template 방식
; 가상머신 이미지는 순수 OS만 설치된 이미지를 그대로 사용하고 나머지는 그때 그때, 필요한 서비스들을 동적으로 배포/설치/설정 해주는 것이 유리하냐?
뭐가 좀 더 좋은 선택이냐~ 하는 것....
음.. 경험상 개인마다, 또 환경마다 호불호가 갈렸던 것 같다.
이후 말하고자 하는 것은... 일반적 또는 보편적으로 봤을때에는 "2) OS-Only Image" 방식을 사용하는 것이 유리하다...라는 것에 대해 이유를 정리 해볼려고 한다... 물론 전혀 현실성 없는 이야기로 보일 수도, 틀린 이야기일 수 도 있는 사견일뿐....
참 Template에 대한 용어 정리 부터 하자...
* 본 글에서 언급되는 "Template"이라 함은, Virtual Machine 생성에 공통적으로 복제/사용되는 Disk 이미지를 말한다. 통상적으로, RedHat/Ubuntu/CentOS/Windows 등과 같은 범용적으로 사용되는 OS레벨까지만 설치되어 있는 Disk Image 파일을 말한다.
자 그럼, 1)번의 경우, Hadoop이든, Cassandra든 뭐가 됐던, 모든 S/W, 관련 패키지, 라이브러리, 데이타 모두 사전에 각각에 대해 Template이미지를 미리 만들어 두어야 한다. 잘 이해가 안된다고? 아래 [그림1]을 보라.
[그림1]
(그림 설명)
- 가운데 점선은 Template으로부터 사용자에게 배포되는 경계를 나타냄. 일반적으로 Chef/Puppet가 담당.
지원하는 OS는 3종류로 가정한다. SuSe/RedHat/Ubuntu...
그리고, 지원하는 서비스로는 Hadoop/MySQL/Cassandra/Tomcat/HAProxy/Apache/GlusterFS 이정도로 7가지가 서비스할 계획이라고 치자...
따라서, 3*7=21 가지로서, 21개의 Template이미지를 사전에 확보/관리 되고 있어야 한다.
물론 생성 이후에 적용된 고유정보나, 설정은 Chef나 Puppet와 같은 Auto-Configuration 툴을 사용한다는 것을 전제로 한다.
Pre-Installed Template 방식의 장점은 아래와 같다.
(본 글과 연관이 있는 항목 위주)
- 설치/설정 작업에 필요한 소요시간 제거/단축.
- 요소 패키지의 버전 Upgrade등으로 인한 설치/설정 중 발생 가능한 오류 제거.
- 설치/설정 과정을 거친, 즉 작동이 검증된 이미지임을 보장.
위와 같은 이점을 누릴 수 있다. 이중에서도 1)번 방식을 주장하는 사람들이 가장 강하게 내세우는 점은 첫 번째 서비스 배포에 소모되는 "시간단축"이었다.
자, Pre-Installed Template이미지가 가지는 단점이 있겠으나, 아래 내용은 2)번 방식인 "OS-Only Template"방식을 살펴보고 비교해보는 것으로 충분할 것이다.
2번) 방식을 도식화한 [그림2]을 보자.
[그림2]
그림 2는?
Virtual VMs 영역은 "Pre-Installed Template"방식과 다를게 없다. 그러나, 아래 쪽 Template영역은 아주 딸랑 3개로 심플하다.
OS-Only Template 방식의 장점을 정리하면,
- 확보/관리 되어야할 Template이미지 대상 수가 현저히 적다.
- Template 이미지에 대한 Version Upgreae, Patch 이슈가 현저히 적다.
오직, 3개만, 그것도 순수 OS레벨까지만 구축되어 있는 Template를 확보하면 된다. 그럼 각각의 서비스들에 대한 설치/설정과 관련된 일들은 어디로 가버린거냐? 당연히 파란점선 부분에 존재하는 Chef/Puppet가 담당하게 된다.
그럼, 단점은?
- 모든 서비스가 VM생성 요청마다, 설치/설정 작업이 수반되어야 한다.
- Chef/Puppet의 역할이 매우 중요해진다.
- 설치/설정이 생성 요청때마다 발생하므로, 당연히 배포완료까지 소요되는 시간이 증가한다.
자, Pre-Installed Template 방식과, OS-Only Template방식을 간략히 살펴 보면 이와 같이 "일장일단"이 있다.
나름 가상화라는 파트를 접하면서 겪어오고 싸우기도 한 이 문제...
결국 논쟁의 핵심은(단, 국내 가상화 일선 현장에서이다.) 아래의 것들 이었다.
이러한 이유로 인해, 99%는 1)번 Pre-Installed Template 방식을 도입/적용 하는 것으로 가닥이 잡힌다. 설령 그것의 단점을 인지하고 있더라도...(최근에야 Chef나 Puppet의 비중을 높이려는 시도가 많이 보이나 쉽지는 않은듯 하고...)
아무튼, 이것은 단기적으로 봤을때는 충분히 설득력이 있고, 또 실제로 효과도 만점이다.
서비스 로직과 Web-UI연동, 빌링, 요구사항에 부합하는 서비스가 정상적으로 사용가능한지가 단기적인 프로젝트상 Output으로서 중요하지, Provisioning과정에서 생기는 시행착오나, 오류로 시간을 허비할 수는 없는 환경도 한 몫을 하고 있는 것 같다.
그러나 장기적으로 봤을 때, 덮어 두었던 문제들이 일순간 터져버리는 지뢰밭을 키우는 꼴이 될 확률이 대단이 높다.
왜?~~
1) 배포 소요 시간. 이것 부터 살펴 보자...
실제로 Hadoop, Apache, Cassandra 등등이 미리 설치 했을 때에 비해, 그때 그때 Instant하게 설치가 된다면 분명히 시간은 더 걸리겠으나, 과연 얼마나 더 소모될까? 10분? 아니면 1시간?.... 별의 별 S/W를 다 동적 Provisoning해봤지만, 어지간 해서는 3분을 넘기는 Provisioning을 필요로 하는 서비스는 굉장히 드물다....
(여담이지만, 이미지 복사하는데 훨씬 시간이 많이 걸린다... 왜? "Backing-File" 방식을 사용하지 않고, 10GB짜리를 그대로 10GB 통으로 복사를 하니..... 차라리 이런 시간을 줄이는게 훨씬 비용효율적일 것이다.)
2) 버전 관리의 복잡성
음... 이 문제는 기술적 의견차가 큰것도 있지만, 커뮤니케이션 부족이 한 몫을 한 것 같다.
이 부분을 지적한 사람들이 주로 주장하는 내용이, "apt-get이나, yum등의 버전이 수시로 바뀌고, 관련 conf 패턴도 바뀌어 문제가 많이 발생하더라. 설치 과정도 어렵고 하니 한번만 고생해서 만들어 두면 편하지 않느냐..." 이었다. 음... 틀린 말은 아니다. 그러나 미안한 말이지만, 이 부분은 전적으로 "관리 능력"의 부재로 인한 핑계일 뿐이다.
이유는, 이 이슈를 Pre-Installed Template방식에서는 더 Critical하게 접하게 될 이슈이기 때문인다. 무슨 말인지 이해가 잘 안된다고? 어느 서비스도 마찬가지겠지만, Cloud라는 이름이 붙은 서비스에서 특정 Version으로 Static하게 패키징된 Template으로 1~2년 서비스를 할 수는 있다고 치자. 패치/업그레이드가 다반사로 일어나는 Cloud관련 솔루션들인데, 그렇게 버텼다고 치자. 훗날 업그레이드는 어떻게 수행할 것인가? 안할 것인가? 한다면, 전체 다 할 것인가? 아니면 기존 이미지 27개(앞선 예를 기준)템플릿은 별개로 운영하고, 신버전의 동일 서비스의 Template이미지들을 또 추가하여 54개의 Template으로 운영할 것인가? 그러면 언제부터 사용한 서비스냐에 따라 기술지원 방식이나 메뉴얼, 대응팀 운영을 개별적으로 가져갈 것인가? 문제는 시간이 가면 갈수록 걷잡을 수 없는 악순환에 빠지고 만다.
결국 핵심 이야기는 이것이다. "현재 작은 문제로 인해 발생한 상황을 해결 하지 못하는데, 그 문제들이 누적되고 쌓인 미래의 상황은 해결이 가능할 것인가?" 하는 것이다.
아래 [그림3]을 보면서 이 항목에 대해서는 마무리 하자.
개발에서도 통용되는 오래된 그림이고 이야기이다. 버그나, 이슈에 대한 패치의 양과 주기에 대한 비교 그림이다.
왼쪽그림은 패치 주기가 길고, 한번에 패치하는 버그/이슈의 양이 많다.
반면에, 오른쪽은 패치 주기가 짧고, 버그/이슈의 양도 적다. 그만큼 한번의 패치 작업 때 변경되는 코드 양이 작고, 만에 하나 발생할 잠재위험(Risk)도 작다.
어느 것이 유리한가? 답은 굳이 말하지 않아도 자명할 것이다.
[그림3]
3) 배포 실패 가능성.
음.. 이부분은 2)번 "관리의 복잡성"의 내용과 중복되는 부분이 많다.
실제 Pre-Installed Template방식에 비해, OS-Only Template 방식이 가지는 핸디캡이기도 하다. 다시말해 Chef나 Puppet와 같은 Auto-Configuration 툴의 역할과 비중이 증대되어 미션크리티컬한 시스템 수준으로 올라가게 된다. 모든 것을 배포하고, 설정하고, 조율하고, 심지어 모니터링/관제 까지.. 그만큼 Auto-Configuration 시스템의 운영/관리가 철저히 되어야 하고, 만에 하나 장애나 오동작시, 전체 시스템에 어떠한 피해가 올지 모를 양날의 검과 같은 존재다. "잘 쓰면 이롭지만, 잘 못 쓰면 해가 되는..."
이러한 툴들이 수행되는 과정에서 발생 가능한 오류는 S/W버전의 상이함, 배포 로직상의 오류, 툴 자체적인 SPOF구조, 등이 대다수다. 심지어 일부 Network구간 단절로 Configuration 시스템은 멀쩡함에도 배포 실패가 발생할 수 있다. 그러나 이러한 Risk는 Pre-Installed Template방식도 동일하게 내포하고 있는 문제이다. 단지, OS-Only Template방식에 비해, 수행 과정이 적다 보니, 발생 가능성이 상대적으로 낮을 뿐이지... 따라서 이 이슈는 어떤 방식이든 "관리/운영 능력의 문제"일 뿐이다. 고민은 하되 호불호를 따질 필요는 없을 것이다.
정리~
좀더 적합한 것은 존재 하난 정답은 아직인 것 같다. 적어도 국내 일선 현장에서는...
다만, 지극히 개인적으로~ "OS-Only Template"이 보편적인 방식으로 자리 잡기를 희망할 뿐...
장기 이식 의학 분야로 이야기를 빗대어 보자면,
Pre-Installed Template 방식은 간이식, 콩팥이식, 심장이식, 안구이식 등과 같이 특정 장기(Pre-Installed)를 확보하여 이식(배포)하는 방법이라면,
OS-Only Template 방식은, 줄기세포(단순 OS플랫폼)만 있으면, 어떠한 장기나 신체부위도 재생해낼 수 있는 방식이라고 생각하면 쉬울 것 같다. 단, 중간에서 재생(배포)에 필요한 미세하고 정교한 작업을 수행하는 의사(Chef/Puppet류의 툴들)의 뛰어난 역량이 수반되어야 할 것 같다.
"선택은 자유다............."
(여담) 그런데 이이야기를 깡그리 무너뜨릴 수 있는 것은, "왜? 여러 OS플랫폼에 똑같은 서비스를 사용해요? 하나만 정해서 서비스 해요~!!" 라고 하면....ㅡ.ㅡ;;
이상,,, 할 일 없는 일요일 저녁... 머리속에서만 맴돌고 정리가 안되던, 그래서 더욱 주관적인 이야기.... 글로 끄적여도 여전히 만족할만큼 정리는 되지 않았으나, 대충 어렴풋했던 그림도 서너장 나왔고, 앞으로 계속 다음어 나가야 할 글임을 다시금 되뇌이며 오늘은 이만....
(별첨) Chef/Puppet ?????
이러한 Auto-Configuratio툴의... (철학까지는 아니라도) 컨셉에 대해 내 의견과 다른(누가 맞는 건지는 아직 모르니...) 이들이 많아 내 생각도 이참에 간략히 메모해 두고, 경험이 쌓이고 생각이 조금씩 늘어나면 이 것도 수정 보완 해야 할 것 같다.
Chef/Puppet류의 툴들이 말하는 Configuration.......
과거,, 또는 최근 얼마전까지의 Configuration은 아닐 것이다. 다시 말해, "설정"이라는 좁은 의미로 사용된 것이 아닌, "구성"이라는 넓은 의미로 봐야 하는 것이 적절 할 것이다.
"구성"... 특정 머신이나 특정 S/W를 구성하는 것만이 아닌, "Service"에 대한 모든 제반 사항을 "구성"한다고 봐야 한다. 그 목표하는 시스템이 비록 1대일지라도, 혹은 수천대 일지라도.. 둘다 동등한 "구성"이다.. 적어도 Cloud라는 아직까지는 실체가 무엇인지도 명확치 않는 트렌트하에서 Chef/Puppet에서는....
