제주패스 구축 이야기

자신을 완벽하게 이길 수 있으면
다른 어떤 것도 쉽게 통달할 수 있다.
자신을 이겨내는 것이 가장 완벽한 승리이다.
— 토마스 A. 캠피스 —

개발 리더 관점으로 바라본 프로젝트 이야기. 많은 일들이 있었는데 점점 기억에서 사라지는 중이라 생각나는대로 정리해 본다.

잠깐 제주패스에 대해서 얘기하면, 국내최초, 최대 제주도 렌터카 실시간 가격비교 플랫폼이라고 한다. 기존 플랫폼이 v1이었고, 이번 구축이 v2.

https://www.jejupass.com/web/introduce/company

악몽의 시작

입사 3개월차, MSA에 대해 스터디를 한참 하고 있을 때 였다. CTO가 와서 지연되고 있는 사내 프로젝트를 맡아달라고 했다. 제주패스 포털사이트 구축 프로젝트에 개발PL로 참여해달라는 것이었다. 아름다운 미래, 밝은 회사생활을 위해 수락했다.

나름대로 프로젝트를 분석했는데, 기획이 많이 지연되고 있었다. 결정이 되지 못한 건들이 많았고 누군가는 결정을 해줘야 일이 진행될 수 있는 상황이었다. 생각보다 많이 지연된 상황이라 작업자들은 아직 컨펌받지 못한 기획서로 작업을 진행하고 있었다.

작업자들이 일을 시작하려면, 배정된 일감이 있어야 하고, 완료 기한이 있어야 한다. 개발리더는 일이 기한안에 잘 끝나는지 관리만 잘하면 된다.

그래서 WBS를 작성하고 그걸로 진행상황을 체크하는데, 작성을 다 하고 보니 개발 공수가 36mm 가 나왔다. 개발자 한명이 36개월 동안 작업이 가능한 일정이라는 의미로 3개월안에 작업을 완료하기 위해서는 12명이 필요한 상황이다. 즉, 개발자가 12명이 있으면 프로젝트를 할 수 있다는 것인데...

충분히 가능한 해 보였고, 해내야 했다.

준비를 하다

요구사항 분석

다음은 RFP에서 시스템 관련 요구사항이다.

1. 카테고리별로 서브도메인 분리.
2. MSA 적용

MSA란?

마이크로서비스 아키텍쳐의 약자로 작은 단위의 서비스들을 모아 하나의 서비스를 이루는 구조로 쉽게 말해서 프로젝트에서 쪼갤수 있는 단위의 서비스를 독립적으로 구현하고 그것을 조합하여 사용하는 구조라고 할 수 있다.

MSA 스터디

MSA는 당시만 해도 대기업에서 많이 전환하고 있다는 말이 많았고 그만큼 핫했다. 그래서 우리팀에서도 스터디를 진행했다. 스터디를 진행한 이후에 이건 꼭 하자라는 의견이 많았고 물론 단점도 있지만 장점이 더 큰걸로 판단되서 MSA를 적용하기로 했다.

(스터디 내용은 추후 포스팅으로 정리해 보겠다.)

프로젝트 관리

프로젝트를 쉽게 관리할 수있게 준비를 잘 해놔야 끝까지 스마트한 프로젝트 관리 생활이 될 수 있을 것이다.

일정은 레드마인으로 (현재는 지라를 사용함)

엑셀로 프로젝트 관리하는 것은 너무 올드하다. 그런데도 아직도 엑셀로 프로젝트를 관리하는 곳이 많다. 가장 큰 단점은 하나의 문서를 바라보기가 어려운 점이다. 그나마 구글 스프레드 시트를 사용하는 곳은 좀 낫다. 내가 사용해본 툴 중에서는 레드마인과 지라가 가장 사용하기 편했고 그 중에서도 지라를 개인적으로 더 선호 하는데, UI부터 레드마인 보다는 더 시원시원하고 요즘 트렌드에 맞다. 총알만 충분하다면, 무조건 지라를 쓰도록 한다.(유료)

하지만 초기 프로젝트 시작할 때는 레드마인으로 시작을 했다. 왜냐하면 지라의 비용이 생각보다 높았던 것. 무료로 사용이 가능한 레드마인은 기능이 불편한 것들이 많다. 이런 불편한 것들도 상용 레드마인을 사용하면 어느정도 해소가 되지만, 이왕 구매한다면 지라를 쓰는게 맞다고 생각한다.(같은 유료라도 지라가 더 비싸다.)

지식&문서관리는 컨플루언스

지라와 연동이 쉬운 컨플루언스를 쓰자. 아틀라시안 제품중에서 컨플루언스를 가장 좋아한다. 지라는 안써도 컨플루언스는 꼭 설치해서 사용한다. 프로젝트에서 안사주면 개인적으로 서버설치버전을 구매해서라도 사용했었다.(지금은 서버 설치용의 구매가 불가능하다.)

프로젝트 초기 레드마인을 사용할 때는 어쩔 수 없이 레드마인 안에 위키를 사용했는데, 마크다운도 어느정도는 사용을 해봐서 쉽게 사용이 가능하긴 하지만 표를 그릴 때 힘들다. 이후에 레드마인을 지라로 바꾸면서, 자연스럽게 위키도 컨플루언스로 변경하였다.

소스관리는 Gitlab 으로 (현재는 Bitbucket 사용)

사내 nas(이하 나스)에 Gitlab(이하 깃랩) 서버를 설치해서 사용하고 있었는데 서울 프로젝트의 대부분이 깃랩에 있었고 제주패스 프로젝트 소스도 깃랩에 올렸다. 그런데 프로젝트 중간에 나스가 죽는 현상이 간간히 발행해서 원인을 찾아보니 깃랩에서 많은 메모리를 사용하고 있었다. 제주패스 프로젝트를 진행하면서 깃랩에 부하가 더 많이 간 것으로 보였고, 깃랩 서버를 이전해야겠다고 판단했다. 후보는 Github, Gitlab 그리고 Bitbucket(이하 비트버킷) 이었는데 이미 아틀라시안 제품들을 많이 사용하게 되어서 비트버킷을 쓰는게 더 나아보였다. 비트버킷을 구매해서 쓰는 김에 모든 프로젝트를 비트버킷으로 이전하고 깃랩서버는 중지했다.

커뮤니케이션은 슬랙, ZOOM

슬랙은 최고다. 타 어플리케이션과 연동해서 사용할 때, 막강함이 더 잘 드러난다. 모니터링 툴과 연계되서 경고 알림등 받는 데도 사용되고, 외부업체와 커뮤니케이션 할 때도 사용된다. 심지어 비트버킷과 연동되서 저장소도 컨트롤 할 수가 있다. 이건 무조건 써야하는게 아닌가? ZOOM(이하 줌)은 사실 화상미팅솔루션의 한계 때문에 도입했다. 아무래도 유명한 회사고 제일 많이 사용되는 솔루션인데 당연히 품질도 좋을 것이라고 판단이 되었고, 팀원중에 한명(@마틴)이 “다 써봤는데, 무조건 줌이죠” 라는 한마디에 결정되었다.

어플리케이션 설계

MSA, 관련자료로 11번가의 교육 혹은 영상자료들이 많았다.

시스템 설계

제주패스 운영 서버로 주어진 서버는 4대로, 이미 내가 투입되기 전에 정해져 있었다. 명목상으로 1대는 개발서버, 또 1대는 웹서버 그리고 나머지 두대는 WAS 다. DBMS는 오라클로 DB 서버는 빵빵한 녀석으로 이미 기존 부터 사용 중이었던 것을 그대로 사용하기로 했다.

먼저 진행한 어플리케이션 설계대로 개발서버 세팅을 하기위해서 도커를 사용하기로 결정을 했다. 모듈별로 컨테이너를 생성하고 추가로 게이트웨이 서버, 디스커버리 서버를 올리기 위한 컨테이너가 두개 더 추가된다. (추후에 컨피그 서버를 추가해서 컨테이너가 하나더 추가되게 된다.)

쿠버네티스 도입

개발서버는 스프링 클라우드로 구성을 했지만, 운영서버를 구성하면서 모두 쿠버네티스 환경에 맞게 변경하고 싶었다. 그래서 스터디를 먼저 진행했다. 책도 구매해서 보고 쿠버네티스에 대한 지식이 전무했기 때문에 관련 책도 몇권 구매해서 읽어보았다.  너무 어려웠다. 설정할 것도 많고 많고 많고, ‘이거 어떻게 하지? 내가 할 수 있나?’ 의구심을 품고 있을 때쯤, 미들웨어 관리업체와의 미팅을 가지게 되었다.

Accordion(이하 아코디언) 이라는 솔루션을 알게 되었고 최종적으로 아코디언을 사용하기로 결정했다. 아코디언은 국내 개발업체 맨택이라는 회사에서 만든 제품으로 쿠버네티스를 랩핑해서 여러기능들을 추가해서 편하게 UI적으로 쿠버네티스를 컨트롤 할 수 있게 해주는 제품이다. 사실 아코디언이 없었으면 아주 힘든 길을 가지 않았을까 싶다.

스프링 클라우드의 게이트웨이를 쿠버네티스의 인그래스로 대체하고 컨피그 서버를 컨피그맵으로 변경하고(물론 할수 있는 기능은 많이 다르다.) 최종적으로 스프링 클라우드에서 필요한 서버(게이트웨이, 디스커버리, 컨피그)를 모두 제거했다. 참고로 쿠버네티스 위에서 스프링 클라우드도 물론 사용할 수가 있다. 쿠버네티스에서 가능한 기능을 굳이 스프링 클라우드로 사용하고 싶지 않아서 모두 제거했다.

로그관리, 이후 데이터독 도입

쿠버네티스에 fluentd, elastic search, kibana 를 설치했다.

fluentd에서 로그를 수집해서 엘라스틱서치로 데이터를 전송하고 정재된 데이터를 키바나에서 비쥬얼로 볼 수 있다. 로그데이터를 NAS에 쌓았는데 하루에 40Gb씩 쌓이니 쌓이는 양이 상당해서 로그 최적화를 하려고 시도하다가 로그를 몇번 날려먹었다. (운영팀 미안해! 날려먹어서 미안해!!!) 이 후에 데이터독으로 로그를 쌓아봤는데(비지니스 모니터링을 위해서) 로그 검색하는 속도도 빠르고 쌓이는 로그를 연동해서 여러가지를 할 수 있어서 매우 좋았다. 완벽히 데이터독으로 로그관리를 하게 되면 fluentd, elastic search, kibana는 제거할 생각이다.

모니터링, 와탭 도입, 이후 데이터독 추가 도입

기존에 제니퍼를 사용하고 있었지만, 제니퍼는 MSA에 적합하지가 않다. 이전에 일하던 곳에서 와탭을 사용 중이었는데, 좋게 쓴 경험이 있어서 와탭을 쓰자고 했다. 와탭 좋다.

오픈 후에 비지니스 모니터링에 대한 니즈가 있어서 데이터독을 도입하게 되었는데 커스텀매트릭으로 실시간 매출금액을 화면에 표기 할 수 있다.

프로젝트 준비에 대한 이야기가…

프로젝트 준비할 때의 얘기를 해보려 했는데, 삼천포로 빠졌다. 각 부분별 상세한 이야기는 나중에 또 별도 포스트로 이야기 할 수 있으면 좋을 것 같다.

용자들을 모집하다

이제 프로젝트 준비도 어느정도 되었다. 제일 중요한 것은 사람이다. 어떤 사람이 들어오냐에 따라서 프로젝트가 성패가 좌우된다.

앞서 말했듯, 12명의 개발자가 필요한 상황이었는데, 인력이 구해지지 않았다. 결국 프로젝트 중반이 될때까지도 인력이 제대로 수급되지 못했다. 그래서 있는 인력으로 어떻게든 개발을 해야되는 상황이었다. (네카라쿠베에서 개발자를 다 땡겨간건지 인력을 구하기가 하늘의 별따기, 뉴스에서는 어느 기업에서는 개발자 연봉을 1200만원씩 올려줬다. 부터 시작해서 개발자 모셔가기 혹은 내 개발자 안뺏기기 열풍이 불었는지 난리가 아니었다.)

제주패스는 여러지역에 지사가 있는데, 제주가 제일 크고 그 다음으로 서울지사에 사람이 많다. 구인에 실패하고 결국 서울 지사의 개발자들을 프로젝트에 투입시키게 된다. 서울지사에 일하는 개발자들은 모자이카라는 서비스를 개발/운영 하는 개발자들로 아마도 많이 당황스러웠을 것이다.

프로젝트 때문이라고 얘기할 수는 없겠지만 이 때 서울 개발자들이 많이 퇴사를 한다. 그래서 인력관리가 중요하다. 이런 인력문제는 큰 이슈가 된다.

인력은 계속 필요한 상황, 제주지사 개발자와 블루웨이브 개발자들이 투입된다.

본격적으로 대 개발 시대의 막이 열린다.(결국 이들과 끝까지 함께 한다.)

끝까지 가볼께요~

2022년에 와서 살아남은 개발파트 인원을 보니, 서울 4인, 제주 6인, 블루 5인, 헬퍼 2인.

1월부터 1월 초중순까지 제주인원이 모두 서울로 올라와서 합숙하며 서울 인원과 같이 개발을 진행했다. 암묵적으로 오전 10시에 출근하여 새벽까지 강행군으로 개발을 했고, 부상자들이 속출하였다.  이 쯤 되면 빤스런 하거나 끝까지 가거나 둘중 하나다.  우리는 끝까지 함께 했다.

2월 초 부터는 서울인원이 제주로 내려갔다. 이 때, 서울인원 3명이 동시에 코로나 확진, CEO @오션 이 마련해 준 숙소에 격리되게 된다. 이 숙소는 다자요 라는 서비스에서 팔고 있는 숙소로 진짜 최고 였다. 나를 포함한 3인은 이 때 아픈 와중에도 최적의 환경에서 개발했던 이 때를 가장 기억에 많이 남는다.  

이런 와중에도 프로젝트는 계속 진행된다. 컨디션이 안좋은 개발자들은 일찍가서 쉬고 다른 개발자들이 받쳐주고를 반복했다.  서로 도우면서 계속 만들었다. 정말 힘들었다.

1. 회사
2. 숙소
3. 1번으로

무한 루프 시작.(빠져나가는 조건은 오픈)

동시에 진행되는 테스트.

기간이 빠듯하니 계속 개발을 하면서 테스트도 진행, 테스트에서 나온 오류나 수정사항도 반영하면서 개발도 계속 하고.. 자신과의 싸움이었다.

오픈전에 수행한 스트레스 테스트도 무사히 통과.

스트레스 테스트는 게틀링이라는 도구를 사용했는데, 말그대로 게틀링건으로 ‘두다다다다다다다’쏘듯이 부하테스트가 가능한 도구다. 레코더라는 기능이 있어서 레코딩을 시작하고 내가 대상되는 서버에서 했던 행위를 바탕으로 수집된 요청데이터를 기반으로 자동으로 테스트 스크립트를 만들어주는 기능이다. JMeter로 되어있는 가이드 문서들이 많아서 주로 사용했었는데, 게틀링을 써보자마자 너무 맘에 들었다. 앞으로도 애용할 예정이다.

그리고 마지막…

결말… 그후 이야기

결국, 오픈을 했다. 오픈 초반에 JPA를 잘못 사용한 부분으로 인해 결제서버에 과부하가 발생 서버가 다운되는 현상이 발생하였다. 파드 갯수를 늘려서 파드 하나가 죽으면 즉시 살리는 방법으로 인공호흡. 여기서 또 한번 쿠버네티스가 이래서 쓰는구나 하고 느꼈다. 그 외에는 크게 크리티컬한 장애는 없이 서비스가 정상 운영중인 것 같다.

정말 오픈에 참여한 모든 사람들, 리스펙한다. 하나하나 이름을 나열하고 싶지만 개인정보 보호를 생각해서 참는다.

@앨런 @이와이 @레오 @클로이 @리암 @밥 @조 @에메스 @가웨인 @도슨 그리고 블루개발자분들(실명이라 호명은 안하겠다.) @스노우 @루덴스

이 들이 불가능을 가능하게 만들었다고 생각한다.

이전보다 좋아진 점

배포가 너무 쉬워졌다. 무중단으로 배포가 진행되니 업무중에도 배포를 진행할 수 있어서 따로 일과시간 이후에 배포 일정을 잡고 배포를 할 필요가 없다.

배포한 소스에 문제가 있다면 거의 롤백을 즉각적으로 할 수가 있다. (파드에서 스프링 어플리케이션이 구동되는 시간 정도만 소모된다. )

그래서 작업자들에게 용기가 더 생겼다. (배포 후 장애에 대한 공포가 많이 줄어들었다)

우리도 하루에 천번 배포도 가능해 보인다.

추후에 아코디언에 blue-green 배포 방식이 추가된다고 하니 변경하면 더 좋아질 것 이다.

앞으로

아직도 갈 길이 멀다.

현금영수증 자동 대사 배치, 로그인 로직 개선, 프로젝트 모듈 분리작업, 캐시개선, 렌터카 검색 속도개선, 프론트앤드 프레임워크 도입…  해야 할 것들이 아직도 많다.

중요한 것은 지속적으로 좋은 방향으로 개선해 나가려고 하는 의지 인것 같다. 그러면 계속 발전할 수 있을거고, 지금보다는 계속 나아질 것이다.

끗!