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 설치 법 따로 연구해야할거 같은 불안감이 엄습한다.

2731 Total Views 1 Views Today

Leave a Reply