본문 바로가기
[Cloud]/심심풀이

RANCHER 1.6 도입을 회상 하여..

by journes 2019. 9. 6.

필자가 회사에 입사할 당시 직원수는 6명에, 시스템엔지니어는 내가 유일했던 신생 스타트업이었지만,  지금은 매출 100억에 직원수도 60명 정도 되는 규모있는 회사가 되었다.  ( 회사가 커져가면서 변해가는 여러가지 모습에 가끔은 지난날의 향수를 느낄때가 있다. )

 

아무튼, 회사가 초기엔 엔지니어가 필자 혼자였기에,  서버설치하고  네트웍구축하고 서비스운영, 장애처리에 문서정리 까지하고 나면

어느덧 막차시간이 다되어 퇴근하기 일쑤였다.  그렇게 Hosting 으로 몇개월 버텨 갈때쯤, 드디어 개발자분들이 들어오면서 솔루션 개발을 시작하게 되었고. Infa 역시 확장하기 시작 하였다.

 

내가 만든 레거시 시스템 들.

 초기 Hosting용 시스템들은  영업팀에서 확보한 고객이 원하는 기능은 무조건  만들어줘야 헸기에,  (비용을 받지 못하더라도.) 여러가지 아이디어를 뽑아냈던것 갔다. 가령 WMV 와 FILEUPLOAD용  Windwos 시스템을 구축 시  UPLOADDATA의 이중화 구성을 위한 data sync 작업까지 는 쉽게 진행했는데. log를  Ubuntu 서버에서 awstats로 수집하기로 결정 하게 되어,  Windows의 스케줄러로 시간에 맞춰 파일을 떨구면  sync툴 로 Ubuntu 서버쪽으로 밀어주고, 쉘스트립트를 돌려서 DATA 뽑았던 아찔한 기억도 있다.. ( 지금은 파일업로드용으로만 사용 중이다.)   

 

개발팀에 제공했던 초기 시스템 구성.. 지금은 상상할수 없는 구성이지만 초기엔 이정도면 개발이 가능했다.. (미안합니다. 개발팀.. ㅜㅜ)

 

레거시 시스템에서 DOCKER 환경으로.. 

회사가 성장하면서,  모든면에서 규모가 확장되었다. 시스템역시 빠르게 증가하게 되었고, 늘상 격는 문제들이 발생하게 되었다. 

첫째는 엔지니어의 숙련도에 따라, OS버전이나, 설치모듈이 달라지는 경우가 종종 발생하게 되어, 개발팀과  마찰이 생길때가 가끔씩 발생한다는 것이다. 같은 작업을 여러번 반복하는 건 서로간의 리소스 낭비이기에 반드시 해결하야할 부분이였다.

 

둘째는, 시스템의 물리적인 scale in/out 에 시간이 걸리다는 것이다. 최소 2일 정도 (서버 설치와 모듈설치등).의 시간이 걸린다. 서버를 추가로 설치한다는 것은 비용 상승( 원가상승)의 요인으로 작용할수 있기에 신중하게 진행할수 밖에 없다. 

  

이런 환경을 개선하기 위해  Docker환경에 대한  고민하기 시작했고, 일부 시스템에 적용을 하기 시작 했다. 

RANCHER1.6을 도입 하며..

초기 Docker 환경은 Dockerfile 기반으로 운영을 하게 되었는데..  패치작업을 할때마다 서버에서 매번 실행해줘야 하는등. 서버에 직접 접속해서 뭔가 작업한다는게 불편해 지기 시작하게 되면서, 오케스트레이션툴을 검토하기 시작 했다.. 

 

우선, Dockerfile 을 docker-compose 형태로 변환해서 Prod환경에 적용했다.  

 

그리고  아래와 같이  racher 1.6을 통한 Stage 구축 계획을 세웠다.. 우리는 AWS와 openstack 모두 사용하고 있었기에,  나름 하이브리드 형태(?)로 운영을 하고 싶었다.. 하지만 TEST를 진행하면서,, (AWS의 인스턴스 생성 절차가 복잡했고, openstack의 경우는 인스턴스 생성절차에서 뭔가 뭔제가 있었던  것으로 기억하고 있다). 여러가지 불편한 사항들로 인해, 온 프라임 기반에서  racher 1.6만 사용하기로 결정 했다.   * racher 1.6을 선택한 이유중 하나는 개발자가 사용하기에도 편하다는 것이다.    

초기 구축된 stage용 rahcer 1.6 시스템. (지금은 prod / stage / dev 모두 구축 완료)

 

당시에 "ElectricFlow" 라는 툴도 검토했었는데.. 지금 생각해 보면 이건좀.. 아닌듯 싶다.. 

 

 

Ingress(Traefik)도 필요 하다. 

rancher 1.6 도입으로 인해,  rolling update / rollback 쉬워졌고,  서버에 접속하지 않아도 Execute Shell을 통해 터미널 접속이 가능해 졌다.  (패치 작업이 진짜 편해졌다.. 굿!)  그런데 사용하다 보니 .몇가지  개선 사항이  필요 했다.

 

첫째, 하나의 Host에 80포트(443)를 사용하는 컨테이너를 여러개 띄우고 싶다. (비용적인 측면)

둘째, SSL 인증처리를 컨테이너 외부에서 처리하고, 컨테이너는 80포트로만 처리 하고 싶다. (운영적인 측면)

 

그래서 앞단에 Ingress 인 Traefik 을 설치 했다.

 

  • HTTP request를 HTTPS로 Redirect 및 SSL 인증 처리. 

  • Backend와는 HTTP로 통신.

 

 

우리가 Traefik을  사용하는 방법은 아래와 같다..  (중간에 GSLB가 있음) 

 

시스템엔지니어에서 플랫폼엔지니어로..

우리회사에는 아직  공식적인 DevOps가 없다.. 내가  하려는 업무에 대한 정의가 명확하지 않다고 생각을 했다.   다분히 DevOps 라는  표현으로는 뭔가 부족하다고 느끼고 있을때 쯤. 넷플릭스의 DevOps 조직 문화에 대한 내용을 접하면서  "플랫폼 엔지니어"라는 말을 알게 되었고, 생각하는 업무 성격에  딱! 맞는 표현이라고 생각한다. 그래서 나는  우리회사 1호 "플랫폼 엔지니어" 다!