멘탈을 복구하자

너무 깔끔하고 깨끗하게 하려고 집착했던게 문제였던거 같다.
사람이 살다보면 진흙탕을 뒹굴수도 있는건데 뭐 그런걸 무서워 했을까?
일단 부딪혀보고 진흙탕이면 씻고 나옴 되는거다.
그러다 깔끔하게 해결되면 기분 좋고 그런거지 뭐!
원래 진흙탕이라고 생각하니 마음이 편해진다.

이러다 진창만 뒹굴다 끝나는가 아닌가 하는 생각도 들지만 멍때리다 허송세월 보내는 것보단 나으니까….

Redhat OpenShift 분석 중

CF1으로 PaaS구축하는 일이 어느정도 끝나가는 마당에 CF1의 deprecated문제를 그냥 무시하고 지낼수는 없었다.
팀장님과 이야기를 나눈 결과 역시 deprecated된 녀석을 억지로 끌고 가는것도 정상적인 일은 아닌 것으로 결론이 났다.

그렇다고 밑바닥부터 뒹굴며 다시 만들수는 없으니 대체제를 찾아야 하는데 뭐 선택할 게 따로 있나? Cloud Foundry2나 OpenShift 둘중 하나지 뭐…

간단히 접한 Cloud Foundry 2에 대한 나의 생각은, 일단 CF1에 비해서 엄청 발전했다는 것이다. 하지만 고민하게 되는것은 역시 괴랄한 진입장벽인거 같다. Bosh를 사용한 뭔가 지랄맞은 설치 방법은 보고있다보면 토가 나올거 같다.

IaaS기 기본 사양이라니… 너무하잖아!

(사용법은 개떡같더라도) 설치는 무조건 쉽고 간단해야한다 라는 나의 철학과는 좀 많이 어긋난다. vgrant로 설치를 쉽게 해준 오픈소스가 있긴한데, 정규 프로젝트가 아니라는게 좀 마음에 걸린다. VMWare에 한번 데여서 인지, 앞으로 소스가 어떻게 바뀔지 모른다는 불안감이 크다. 그렇게 생각해보면 vgrant 유틸도 언젠가 제대로 안먹게 되겠지? 그럼 난 다시 멘붕 되겠지?

그리고 너무 CF에만 몰빵하는거 아닌가 하는 생각도 들어 슬쩍 OpenShift에 눈을 돌려보기로 했다. https://www.openshift.com/ 회원 가입도 하고, online 버전도 사용해 보고, enterprise 버전이랑 origin 버전 문서들도 좀 들여다 보고, 한 이틀정도 문서만 슬금슬금 보고 있다.

구조는 CF랑 뭔가 미묘하게 같은듯 다르면서 CF보다 뭔가 더 간단하다. (말이 뭐 이따구야.)

이래저래 문서보고 조금 써보면서 느낀건 CF는 사용자가 이미 완성된 구성을 사용하는 느낌이라면 OpenShift는 레고처럼 사용자가 취향에 맞게 적당히 조립해서 쓰는 느낌이다. 이런 사용성 부분은 취향에 따라 다르니 뭐가 좋다 나쁘다 하긴 어려울거 같다.

내 취향은 OpenShift쪽이다. 취향에 맞게 적당히 조립…. 덕 냄새가 좀 나잖아? 아키텍쳐 구성도 좀 간단하고, 대신 카트리지라는 개념이 새로 생기는 문제가 있었지만 그정도야 감안해줄 수 있지!

————————————

구성 간단히 요약

* Broker : 파스 관리 서버, Node에 Gear라는 단위의 가상머신(?)을 생성해주고 Cartridge를 설치해준다(카트리지는 후반에 설명), 관리 UI도 제공해주는거 같다.

* ActiveMQ : Broker<->Node간 메시징 채널

* Node : 물리 머신을 관리하는 컴포넌트라고 봐야할거 같다. Node가 Machine을 Gear 단위로 Virtualization 해준다. 그 단계에서 쓰이는 기술은 나중에~~ (과연 할까?) , CF로 생각하면 DEA라고 보면 될거 같다. DEA보다는 하는일이 좀더 많은거 같아 아직 한마디로 정의하기 어렵다.

** GEAR : Node에서 돌아가는 VM 단위 랄까? 여튼 Node는 사용자에게 GEAR단위로 자원이 분할되어 할당된다. 사용자는 자신에게 할당된 GEAR에 여러 툴들(카트리지)을 설치하여 사용하는 개념이다.

** CGroup, SELinux : Node에서 이놈들을 사용해서 머신을 GEAR단위로 쪼갠다. 덕분에 GEAR들은 지정된 자원 내에서만 사용자 프로세스를 돌릴 수 있다. 자세한 버추얼 기술은 내부 코드를 뜯어봐야 알수 있을거 같다. 어차피 오픈쉬프트를 사용하는 입장에서 주요 관심은 Broker와 아키텍쳐 구성일테니 이건 아직 자세히 안볼 생각.

** High-Density : 뭐 뭐신을 잘게 쪼개서 쓴다 뭐 그런 장점을 표현하는거 같은데 대충 넘어가기로…

* cartridge : 오픈쉬프트의 독특한 구성중 하나인데, GEAR에 설치되는 서비스들은 모두 카트리지라는 개념으로 제공된다. runtime이건 was이건 db건 다 카트리지다. 사용자는 자신의 gear안에 원하는 카트리지를 끼워넣는 구성이다. 내가 자바에 제이보스에 mysql을 돌릴거야! 라고 하면 gear를 하나 만들고 거기에 java 카트리지, jboss 카트리지, mysql 카트리지 를 낑겨 넣으면 된다. 레고 조립하는 느낌이다.

* horizontal App scaling : CF는 최상단에 goRouter라는 녀석이 ip랑 domain을 관리 해주기때문에 app instance간 scaling 걱정을 안해도 되는데 반해 오픈 쉬프트는 이런걸 따로 해줘야하는거 같다. HAProxy 카트리지가 있는데, 여러 GEAR에서 돌아가는 App을 Horizontal Scaling을 하려면 일단 여러 GEAR에 앱들을 배포하고 다시 다른 Gear에 HAProxy 카트리지 넣고 이녀석한테 request 라우팅을 맡기는 형태랄까? 이점에서는 CF가 좀더 편한거 같다.

* DNS : DNS도 얘네는 따로 설치해서 써야하는거 같다. CF는 goRouter가 다 관리해주니 그냥 *.xx.xxx Domain 잡아놓고 서비스하면 되는데, 구성상 DNS를 따로 만들어줘야하는거 같다. 그렇게 해놓으면 Broker에서 사용자가 만든 앱에대한 내용을 DNS에 등록해주는… 이건 귀찮은거잖아!

* git, jenkins : 기본으로 지원한다는데, 일단 지금의 주요관심사는 아니다. Broker랑 Node부터 때려잡아야 한다.

아무래도 지금까지 CF만 해왔으니 CF랑 자꾸 비교하게 되는거 같다.
Cloud Foundry가 {Router – Controller – HealthManager – DEA – SERVICE (Nats로 메시징)} 로 좀 복잡하다면
OpenShift는 {Broker – Node (ActiveMQ로 메세징)} 의 단촐한 구성이다.

Broker가 CF의 Controller, HealthManager, Router의 역할 을 담당하고
Node가 DEA, Service 역할을 담당하니 각각 컴포넌트는 내부가 더 복잡하지 않을까 예상해본다.

여튼 대충 파악 끝났으니, 다음주에는 실제 설치해봐야지

OpenShift공부하면서 좀 감동한건, RedHat에서 문서화를 엄청 잘해놨다 ㅠ.ㅠ
VMWare에 비하면 이건……흑흑…….업드려 절해주고 싶다.
서…설치 잘할게요…ㅠ.ㅠ

근데 개떡같은겓 왜 또 fedora 기준인거냐 ㅠ.ㅠ
CF하느라 CentOS버리고 Ubuntu 죽어라 했더니….
레드햇이니 팔은 안으로 굽는거니 ㅠ.ㅠ

Ubuntu 설치 법 따로 연구해야할거 같은 불안감이 엄습한다.

2013.10.13, Spring Camp, Cloud Foundry를 활용한 PaaS 구축기 발표, 소감

박용권 매니저님의 권유로 어제(13일) KSUG X 라스칼라코딩단(영어 쓰기 귀찮아..) 주최 Spring Camp에서 ‘Cloud Foundry를 활용한 PaaS 구축기’를 발표하기 되는 영광(?)을 얻게 되었다.

발표 전 첫 리뷰에서 야심차게 준비했던 발표자료는 ‘본부장님께 드리는 보고서’ 라는 낙인과 함게 강력하게 질타 받았고, 두번째 다시 만든 것은 그래도 많이 나아 졌다는 용권님의 승인(?)받아 그대로 질풍가도를 달리는 듯 했으나 발표자료에 첨부된 이미지들의 라이선스를 확인하지 않은 관계로 이미지를 전부 교체해야하는 뻘짓도 해야 했다. 이말년 작가님께는 이미지 사용 허가까지 받는 치밀함을 보여놓고 왜 나머지는 그럴 생각을 못했을까? 한이 맺히는 부분이다. 구글 이미지 검색에 라이선스 체크 옵션을 넣으니 맘에 드는 이미지가 진짜 안나오더라. 이미지 교체 작업으로만 한 네시간 날린것 같다. 지난 토요일 하루를 모두 발표자료 정리하는데 써버렸다.

발표 당일, 오전에 혹시나 하는 마음에 팀장님 리뷰 받고 일부 멘트랑 장표 순서 좀 조금 바꾸고 마무리를 했다. 발표 전까지 계속 진장이 되어 긴장을 풀고자 제자리를 빙빙돌며 걸었다. 오른 어깨에 간지나는 DSLR을 걸친채 뭘 그리 긴장하냐며 풋! 하고 웃으시는 변정훈님! 하지만 후에 변정훈님도 자신의 발표 시간이 다가오니 긴장되어 복도를 빙빙 돌더라는 웃지 못할 전설 같은 이야기…

발표 5분전, 디스플레이 미러링 해제하고 시작멘트 정리하고 마지막 장표 체크하는데 맥이 멈춰버렸다. 데모귀신인가! 커널패닉! 재빨리 강제 리붓! 다행이 시작 3분전에 준비가 완료되었다.

발표 1분전, 시작 전에는 좀 많이 떨렸는데 막상 시작하니 매우 마음이 덤덤해 지더라. 발표 중반부터는 그냥 준비했던 스크립트를 보지 않기 시작했다. 야심차게 준비했던 ‘이말년 시리즈’ 애드립은 대차게 실패하고, 개그를 쳤는데 청중이 그렇게 조용할 수가 없더라! 으아아! , 발표는 어느새 중반을 넘기고 있었다.

중간 즈음 Cloulu 시연에는 얼마전부터 속썩이덴 L4스위치 문제가 또 터져서 에러가 나기 시작. 오마이갓! 하며 리프레쉬를 반복하니 느리지만 다시 되긴 했다. 당황하지 않은척 하며 시연은 마칠 수 있었지만, 원래는 채팅 방도 열어 놓고 설문 사이트도 열어 놓으면서 파스를 자유롭게 쓰는 모습을 보여주고 싶었는데 그렇지 못한게 많이 아쉽다. 혹시나 또 에러나는거 아닐까 하는 걱정에 그냥 접었다. 에잇! 이게 다 L4 때문이다.

데모 삑사리와 회심의 애드립을 죄다 말아먹는 불상사가 있었지만 전반적으로 별 탈 없이 발표는 마무리 지을 수 있었다.

긴장풀려고 하루종일 빙글빙글 걸어다녔더니 다리가 매우 아프다. 내일 데뷰 행사는 잘 갈 수 있으려나.

마지막으로 의미있는 행사 준비하시느라 많은 고생 하셨을 KSUG 및 라스칼라코딩단 여러 분들께 감사드립니다.

발표 마무리에 Special Thanks to에 LG CNS때부터 알고 지내온 대(!)선배 채수원님과 이동욱님을 넣었는데, 멘트가 꼬여 마치 Cloulu개발에 도움을 주신 분처럼 묘사된거 같은 느낌이다. 오래전부터 많은 조언으로 큰 힘을 불어 넣어주신 이라고 말하고 싶었는데, 혀가 꼬인건지 멘트가 꼬인건지 엉망이 되어버렸다. 젠장.

Special Thanks to 인물 소개 사진으로 페북 프로필 사진을 따다 썼는데 때 마침 채수원님의 프로필 사진이 채수원님의 애견(dog). 시간이 없어 별 생각 없이 넣었는데 발표 끝나고 생각해보니(주변 분들 말씀도 그렇고) 오바한거 같다. 나중에 혼날거 같다. ㅠ.ㅠ 죄송합니다.

구글 드라이브에 올려놓은 발표자료 URL
https://drive.google.com/open?id=0B35qkFCKn8rjVm1qay00WlI5N3c

아! goddaddy.com 짜증나…

www.goddaddy.com로 서비스 받고 있는 인증서 하나가 의도치 않게 자동결재 되어 취소하려고 사이트 들어갔는데 정말 더럽게 느리다.

payment list에 있는 cancel 메뉴를 누르면 payment가 정말 취소되는지 알 길이 없어support 메뉴에서 online 문의하기를 눌렀는데 팝업뜨는데만 몇십초가 걸린다.

얼마전엔 사이트 자체가 다운되어 한참 속썩이더니 문의메일 하나 넣는데도 이렇게 힘이 들어서야 서비스 사용할 마음이 생길리가 없다.

해킹 당한적도 있다는 소문이 돌던데,

두번다시 쓰지 말아야지.