System Compleat.

'Openstack swift / keystone'에 해당되는 글 1건

  1. Swift based web service, "The Velox"

Swift based web service, "The Velox"

Techs

(younjin.jeong@gmail.com, 정윤진) 


최근들어 다양한 주제로 블로그에 찾아오시는 분들이 제법 있음에도 불구하고 한동안 블로그를 처박아두다시피 했는데, 오늘 파이어준의 포스팅을 보니 웬지 간만에 블로깅 의욕이 불끈 솟아 내일 출장을 위해 일찍 일어나야 함에도 불구하고 간단하게나마 포스팅이 필요 할 것 같아 몇자 적어본다. 





회사 대표님의 "드랍박스 비슷한 서비스를 Openstack Swift 기반으로 만들어 보자" 라는 심플하고도 아리송한 제안으로 시작된 이 프로젝트는, 기업 고객을 대상으로 클라우드 인프라 기반의 컨텐츠 공유 및 저장을 목적으로 하고 있다. Velox 라는 이름은 원래 프로젝트 코드명이었는데, 어차피 기업용 제품이고 해서 다른 이름을 아무리 가져다 붙여도 팀 구성원 그 누구도 기타등등의 서비스 이름에 동조를 해 주지 않아 서비스 이름으로 굳어지는 분위기이다. ( 이미 인증서 구매까지 완료 했으니 어쩌랴! ) 검색해 보시면 알겠지만, Velox 는 Swift 의 그리스 ( 라틴어 였던가 ) 단어다. 


이 Openstack 의 Swift 인프라는 이미 국내 굴지의 ISP 를 위해 진행되었던 스토리지 클라우드의 제품으로 인프라의 설계와 트러블슈팅 등에 참여했던 이력이 있어 그 동작에 대해서는 다른 분들보다 조금 먼저 서비스 레벨로서의 접근이 가능했었다. 이 오픈소스 인프라가 가지고 있는 한계라던가 운영상의 주요 포인트, 그리고 확장을 위한 네트워크 아키텍쳐와 성능 향상을 위해서 어떤 부분을 조율 해야 하는지 등을 신경써서 디자인 할 필요가 있었다. 물론 지금 이 제품은 개발 및 스테이징 단계기 때문에 그 인프라 구성이 매우 간단하지만, 그 확장 모델에 대해서는 이미 기업환경을 위해 플랜이 짜여 있으므로 향후 사이징이나 성능에 문제가 없겠다. 


이 프로젝트는 사실 제대로 스프린트를 한 것이 5개월 남짓 되는데, 전체 플로우는 다음과 같았다. 


1. 인력 구성- 토탈 3명 : 파이어준 ( aka 경준호 ), 임성렬 ( backend ), 나 ( 인프라 ). 

2. Swift - Keystone 및 Reverse - proxy 등의 설치 / 협업 도구 redmine 및 github 등의 리소스 준비 

3. Swift 클러스터를 위한 자동화 스크립트와 Chef 를 통한 코드 구현 

4. 구현된 인프라를 개발팀에 인계, 개발팀 요구사항을 인프라에 즉시 반영 

5. 기업 관계자들로 부터의 feedback 수렴 및 기능 추가, 반영 

6. 테스트 프로젝트 기획, 실행 중. 


각 단계별로 난관이 있었는데, 이는 비단 개발 및 인프라 설계 및 설치 뿐만 아니라 인력등과 관계된 부분들이 제법 많았다. 

제품의 스크린샷은 준호형이 워낙 잘 떠놨기 때문에 준호형의 포스트를 링크한다. 여기 를 참조하시면 되겠다. 


이 프로젝트는 완벽한 오픈소스 기반 솔루션들의 조합으로 이루어졌으며, 하드웨어 역시 Commodity 라 할 수 있는 하드웨어들 기반으로 동작한다. 네트워킹에는 현재 10g 가 사용되었지만, Swift 아키텍처는 특정 부분을 제외하고는 대부분 1G 네트워크를 사용하는 것이 가능하다. 또한 밸런싱 및 프락싱, 그리고 SSL Endpoint 에는 상용 밸런서나 하드웨어 기반의 L7 장비들이 전혀 사용되지 않았다. 따라서 이는 기업의 요구에 따라 5T 부터 수십 Peta 까지 확장이 가능하며, 구조적인 팁을 더한다면 거의 무한대에 가까운 Zeta 레벨로까지의 확장이 가능하다. 인증은 기업의 AD 나 LDAP 등과도 연동이 가능하며, 이런 인증 시스템이 없어 별도로 필요하다면 따로이 데이터베이스를 사용하여 운용 할 수도 있다.  


이 포스팅에서는 기술적으로 세부사항이 어떻게 되고 하는 것을 설명하기 보다는, 팀원 세명이 마치 Garage 에서 컴퓨터 놓고 개발하여 1.0 을 만들어 내는 과정을 경험 해 본 것이 가장 의미 깊었던 일임을 알리고 싶다. 서로 다른 전문 분야를 가진 사람들이 소수의 인원으로 팀으로서 구성되어 빠른 의사결정 과정과 최대한 저렴한 비용 소비를 통해 제품을 만들어 내는 과정은 돌이켜 보면 난점도 꽤 있었지만 결과물을 어느정도 만들어 낸 지금 굉장히 고무적이다. 


Nutanix 와 같은 제품을 만드는 것은 엔지니어링 적으로 굉장히 높은 수준의 사람들이 뭉쳐야 가능 한 것이지만, 우리는 시장에 필요할 것같은 제품을 최대한 빠른 속도로 사용 가능한 버전으로 만들어 내는 것에 중점을 두고 있었기 때문에 기술적 깊이는 다소 낮을 수 있겠다. 하지만 Node.js 에서의 쉽지 않은 바이너리 처리와, 이를 인프라에서 솔루션을 내어 어플리케이션 또는 프레임웍 자체가 가지고 있는 문제를 우회하도록 하는 솔루션을 만들어 내는 것은 어플리케이션과 인프라를 뗄레야 뗄 수 없는 관계로 만들어 냄으로서 보다 의미있는 작업이 된 것 같다. 이를 테면, 기존에는 아파치 설정은 아파치 대로 돌지만 어플리케이션과는 상관 없는 형태였다면, 이 제품은 인프라의 설정 파일마저 github 에 등록해야 할 정도로 그 긴밀성이 대단하다. 일례로 url 라우팅과 같은 부분을 SSL Endpoint 와 함께 처리하는 것은 프락싱 해 줘야 하는 어플리케이션의 부담을 낮춤과 동시에, 개발자들이 별도로 크게 노력하지 않아도 분산구조를 취할 수 있도록 해 주는 것과 같은 것이다. 


백엔드와 프론트엔드의 롤 간에 다양한 이야기들이 있지만, 여기에 인프라까지 끼는 이야기는 많지 않을 것이다. 이 제품이 얼마나 크게 빛을 발할 지 모르겠지만, 지금까지의 작업은 그 어디에서도 경험 해 보지 못한 귀중한 것이며, 개발을 위한 팀이 어떠한 모습이어야 하는지를 배우게 해 준 동료들에게 매우 감사한다. 


이제 막 알파 정도의 서비스이며, 지금 굴리고 있는 인프라도 조촐하지만 기업 환경을 위해서는 얼마든지 확장 가능한 준비가 되어 있기 때문에 현재 인프라와 어플리케이션의 한계를 보는것이 주요하겠다. 


마지막으로, 이런 업무환경이 가능하도록 도움을 주신 지금 회사의 대표님과 이 회사에 입사 하여 각종 대형 클라우드 서비스 구현에 핵심에 서 있도록 해 주었던 Nicholas S. Lee, 그리고 장비를 준비 해 준 재성형에게도 감사한다. 


제품 컨셉과 스크린샷 등의 확인은 파이어준의 블로그에서. 

그리고 성렬형 결혼 축하!! 



덧.)  splunk 는 매우 획기적인 로그 수집, 검색 도구다. 로그가 쌓이는 양이 그다지 많지 않다면 사용해 볼 만 하다. 다만, 특정 사이징이 넘어가게 되면 비용을 지불해야 하므로 주의 할 것. 한가지 더, 데모 기간이 지나면 계정 관리가 되지 않는다. 이 말은, 바로 그냥 로그인 되어 버리므로 인터넷에서 접근 가능하도록 구성하였다면 반드시 패스워드 등을 걸어 둘 것. 




아이피들이 나와 있기는 한데 뭐 별일 있겠나 싶어서 그냥 올린다.


덧2.) 로그 서버가 없거나 빈약하다면 다음의 서비스를 알아 보는 것도 좋다. 

http://www.sumologic.com/ 



( younjin.jeong@gmail.com, 정윤진 )