사랑줍는 거지

최근, Chef로 서비스 구성(Configuration) 자동화 파트를 다시 하게 되었다. 여기저기 타 부처 수행 인력과 협업도 해야 하는 상황이라, 가상화 인프라부터 논의를 통해 결정을 지어야 할 일이 많다... 서비스 구성에는 Hadoop Cluster, MySQL & Replication, Cassandra, MongoDB, HAProxy LB, Apache/Tomcat, 등등 여러가지 서비스들이 버튼 한번의 클릭으로, 동적 구성 및 동작이 되어야 한단다. (쉽게 이야기들 한다...쿨럭...) 이러한 일련의 자동화 구성/배포 전략 수립단계에서 여러사람들끼리 혼선도 있고, 의견 충돌이 있는 것은 당연하다. 왜? 정답이 없는 거니까~ ㅡ.ㅡㅋ 사실 이 섹션의 고민은 Cloud라는 단어가 국내에서 화자 되기전, RIS라는 OS 원격 설치 서비스를 구축 할 때에도 심각하게 고민됐었다... "과연 어느 선까지 사전에 설치 해두는 것이, 유연성과 편의성 두마리 토끼를 다 잡을 수 있을까?"...라는.... 결국 그 당시에는 지금의 Chef나 Puppet만큼 완성도 있는 도구가 없다는 핑계를 대며 일정에 쫓겨 최대한 밀어넣기(?)로 쫑친 기억이....

아무튼 그 중, 가장 어정쩡하게 결론이 난 것이 어떤 방식의 Template를 사용하냐~였다. 이참에 그 사항에 대해 정리를 나름대로 해두고 싶어 일단 펜을...아니 키보드를 두드려 둔다. 물론 서두는 없다. 생각 나는대로.. 우선...

PaaS, SaaS... 당연히 밑바탕이 IaaS라 불리는 가상화 서버스가 "반드시" 필요 한 것은 아니다. 그러나 즉시성, 그리고, 자원의 효율적 활용(이 부분도 아직 갈길이 멀기만 하지만...), 유연한 인프라 관리 체계(이 말도 참 귀에 걸면 귀걸이인 마케팅용...)라는 진부한 이야기들 외에 본 글에서는 오로지 Physical 인프라와 비교해 상대적으로 설치/구축이 쉬운 점을 감안하여 "필수적"이라는 가정하에 이야기를 풀어 볼 생각이다... (물론 이 말에는, 가상화를 위한 Physical 인프라는 이미, 그리고 부족함 없이 구축되어 있다는 대전제가 깔려 있어야....쿨럭..ㅡ.ㅡ;;)

여기서 논점의 주제는 뭐냐.....

아니면,

뭐가 좀 더 좋은 선택이냐~ 하는 것....

음.. 경험상 개인마다, 또 환경마다 호불호가 갈렸던 것 같다. 

이후 말하고자 하는 것은... 일반적 또는 보편적으로 봤을때에는 "2) OS-Only Image" 방식을 사용하는 것이 유리하다...라는 것에 대해 이유를 정리 해볼려고 한다... 물론 전혀 현실성 없는 이야기로 보일 수도, 틀린 이야기일 수 도 있는 사견일뿐....

참 Template에 대한 용어 정리 부터 하자...

자 그럼, 1)번의 경우, Hadoop이든, Cassandra든 뭐가 됐던, 모든 S/W, 관련 패키지, 라이브러리, 데이타 모두 사전에 각각에 대해 Template이미지를 미리 만들어 두어야 한다. 잘 이해가 안된다고? 아래 [그림1]을 보라.

[그림1]

(그림 설명)

- 가운데 점선은 Template으로부터 사용자에게 배포되는 경계를 나타냄. 일반적으로 Chef/Puppet가 담당.

지원하는 OS는 3종류로 가정한다. SuSe/RedHat/Ubuntu...

그리고, 지원하는 서비스로는 Hadoop/MySQL/Cassandra/Tomcat/HAProxy/Apache/GlusterFS 이정도로 7가지가 서비스할 계획이라고 치자...

• OS플랫폼 : 3가지
• 서비스 종류: 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개로 심플하다.

자, 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플랫폼에 똑같은 서비스를 사용해요? 하나만 정해서 서비스 해요~!!" 라고 하면....ㅡ.ㅡ;;

이상,,, 할 일 없는 일요일 저녁... 머리속에서만 맴돌고 정리가 안되던, 그래서 더욱 주관적인 이야기.... 글로 끄적여도 여전히 만족할만큼 정리는 되지 않았으나, 대충 어렴풋했던 그림도 서너장 나왔고, 앞으로 계속 다음어 나가야 할 글임을 다시금 되뇌이며 오늘은 이만....