이번 글에는 새로이 만들어지는 프로젝트에서 구상하는 개발 인프라에 대해서 말해 볼려고 합니다.
기존방식과 구축을 생각하기까지의 과정
기존에는 코드관리는 GitLab에서 빌드는 로컬에서 혹은 파일을 실서버에 복사해서 수동으로 명령어를 입력을 해서 빌드를 하고 배포는 SSH로 수동을 복사를 했으며 커뮤니티는 텔레그램을 사용했다.
처음 입사 했을 때 배포를 수동으로 하는 걸 보고 매번 수동으로 하는 게 싫어 전직장에서 사용했던 Jenkins를 로컬PC에 설치하여 개인적으로 배포를 했었다. 그러다 Jenkins를 AWS에 설치하여 같이 쓸 수 있게 하려고 했다.
하지만 docker로 Jenkins를 설치를 했었는 데 docker라는 것이 있다는 것이 알고만 있었지 실제로 사용해보는 게 처음이라 인터넷에서 검색한 명령어 복사&붙여넣기 정도였고 문제가 생기면 처리가 힘들었다. 그외에도 로컬에서 할 때 와는 다른 권한문제로 스크립트가 실행이 안되는 문제, 공개키 설정, npm을 설치했는 데 해당 npm으로 스크립트가 실행 안되는 것... 등 여러가지 문제에 부딫쳐 몇일동안 붙잡고 있다 다른 일도 있어 포기를 했었다.
그렇게 이 상태에서 운영하면 문제가 생길 거 같다는 생각을 계속 가지고 있었고 그런 상태에서 DevOps를 공부하고 있었다. 어느 정도 공부를 했으면 하나씩 적용했으면 됬을 텐데 이것저것 다 알아봐야 해!, 어느정도 쓸 줄 알아야 돼 하면서 완벽주의를 고집하면서 어영부영 하다가 이번에 새로이 기업의 투자와 관련된 플랫폼을 만들게 되었다. 그 프로젝트를 하는 데 있어 기존의 회사의 인프라로는 불편한 게 있어 이번에 인프라를 구축하려고 한다.
❗인프라 구축의 필요성
인프라가 필요했던 이유는 안정성, 자동화 이 두가지가 가장 컷다.
😱안정성
- 실섭에 바로 배포를 하는 방식이라 중간에 테스트가 미비했다. 그래서 자잘한 버그가 많았다.
- 서버가 한대이기 때문에 해당 서버가 문제가 생기면 서비스가 문제가 생긴다.
- AWS에서 제공하는 모니터링툴이 있지만 기능적으로 모자란 부분이 있었다.
- 로그를 한번에 볼 수 있는 로그 수집툴이 없다.
- 문제가 생겼을 경우 메신저로 알람이 오는 게 없다.
⚙자동화
- 만들려고 하는 인프라 계획 상 서버가 여러대 이기에 매번 수동으로 배포는 버거러울 거 같았다.
- 테스트를 CI서버에서 자동으로 돌아가게 하고 싶다.
인프라 구축 계획
인프라를 계획 할 때에도 고려사항이 있었는 데 안정성과 자동화 그리고 유지비였다.
안정성과 자동화는 당연했고 맘 같아서는 서비스 하나당 하나의 서버를 쓰게 하고 싶지만 유지비를 생각 안 할 수가 없었다.
아래 그림은 계획을 세우면서 전직장의 인프라와 책을 참조하여 세운 계획을 간단히 도식화한 그림이다.
🖥 서버
일단 보면 4가지로 서버가 그룹화 되어있다. 프론트와 백엔드(API)로 구분된다. Docker로 구성하여 환경을 똑같이 맞출 생각이다. 보면 일단 책에서 나오는 방식에서 몇몇부분이 빠져있다. 유지비를 최소화 할려다 보니 선택적으로 빼게 되었다.
- Dev(Local): 개발PC이다.
- Test: 개발한 프로그램을 테스트 하는 서버이다. 리포지토리와 DB는 로컬과 같은 거를 보고 있다. 연동되는 API와 프론트를 확인한다.
- Stage: 리포지토리는 따로 구성되고 DB는 실섭과 같은 거를 바라본다. 다른 데서는 실섭과 같이 서버 두대씩 구성해 로드밸런싱을 할고 실섭DB를 복사해서 새로 구성한 DB를 하는 데 유지비를 생각해 뺏다. 😭
- Real: 실제 유저가 접속할 서버이다. 최소 두대씩 서버를 구성해 한대가 문제가 생겼을 때 다른 서버로 서비스르 하면서 다른 한대를 복구할 시간을 벌 수 있게 했다.
PLAN
Notin, G Suite, Jira
BUILD
Maven
CODE
Git, GitLab, Sonatype Nexus, Verdaccio
CONTINUOUSINTERGRATION
Jenkins
TEST
JUnit, Jest, SeverSpec
DEPLOY
Docker
OPERATE
Kubernetes, Ansible
MONITOR
PMM, Prometheus, JMeter, nGrinder, Slack, ELK
DevOps
커뮤니티
현재 텔레그램이 사용되고 있는 데 현재로서는 불편함이 없기 때문에 쓰고 있지만 차츰 slack으로 바꿀려고 생각 중이다. 처음에는 그냥 텔레그램을 써볼까도 했지만 한 블로그글에서 같은 상황에서 slack로 전환을 했고 다른 툴과 연동이나 문서의 양으로 봤을 때 slack이 낫다 생각했다.
현재는 Git commit, merge, JIRA 글 알람 같은 거를 현재 개인적으로는 slack으로 받아볼 수 있게 하는 정도만 쓰고 있지만 나중에 bot으로 배포, 테스트, 에러나 슬로우 쿼리 알람을 받을 정도가 되면 전부 사용할 수 있게 할려고 한다.
형상관리
코드관리는 GitLab에서 관리를 하며 리포지토리는 Nexus를 기본으로 NPM 라이브러리 같은 경우 README 파일을 볼수 있게 Prive 저장소로는 Verdaccio를 사용하고 있다. 현재는 거의 구축되어 있고 GitLab 서버에 구축된 Verdaccio만 Nexus서버로 이전할 계획이다.
Deploy
배포되는 환경을 맞추고 자동화를 위해 Docker로 구성할 생각이며 이 Docker들을 관리할 오케스트레이션으로 쿠버네티스를 사용할 생각이다.
모니터링 툴
컨테이너를 모니터링할 툴로는 Prometheus를 DB 모니터는 PMM DB 모니터링 툴을 생각하고 있다. 오픈소스로 무료로 사용할 수 있어서 선택했다. 그리고 PMM 모니터링 툴의 데이터를 Prometheus에서 연동해서 볼 수 있다.
CI
Jenkins를 생각하고 있다. ANSIBLE로 인프라를 설정하고 SERVERSPEC로 테스트를 하는 걸 생각하고 있다. 코드에 대한 테스트는 Java와 React를 사용해 개발을 하기 때문에 JUnit와 Jest가 될 테고 커버리지는 70%를 생각하고 있다. 서버 여러대에 일일히 수동배포를 하지 않기 위해서라도 가장 먼저 구축을 생각 중이다.
로그 수집
ELK Stack을 생각 중이다.
성능평가
JMeter, nGrinder를 고려 중이다.
고려했던 혹은 고려중인 툴
이슈 트래킹
문서화
- notion: 최근 스타트업에서 많이 사용된다. 문서화 외에서 이슈트래킹에도 사용된다.
- Confluence: 유료
- 레드마인의 위키
커뮤니케이션
로그
- ELK Stack: 엘라스틱, 로그 스태치, 키바나
- Grafana: 키바나는 엘라스틱서치와만 연동되고 그라파나는 자율성이 높다고 해서 고려중이다. 로그를 시각화하는 툴, 오픈소스이다.
CI
모니터링 툴
- Scouter: 국내에서 만든 모니터링 툴, 해당 툴을 사용하는 책이 최근 출판되었다.
- Prometheus: 최근 많이 사용되는 모니터링 툴
- Zabbix
- Munin
인프라 구축도구
구축 테스트
- Serverspec
- InSpec
그 외에 남은 것
요즘은 라즈베리파이4가 나왔는 데 해당모델 4G 짜리고 GitLab과 리포지토리, 모니터링툴을 구성하는 거는 어떨 까 생각 중이다. 외부로 노출되지 않는 내부인프라 같은 경우 3~4개월 정도 사용한다면 유지비 측면서 더 낳은 선택일 거 같다. 여기에 관련해서는 다음에 한번 후기 때 글을 써볼까 한다.
설치형 말고 바로 GitLab를 사용하는 방식도 생각 중이다.
Test와 Stage를 합쳐 테스트하고 확인하는 것도 생각 중이다. 유지비...😭
PS
이상으로 현재 계획 중인 개발 인프라에 대해 설명했다. 이게 어떻게 될 지는 현재로써는 모르겠다. 제대로 될 지 아니면 갈아엎을 지 아님 산으로 갈지.. .기회가 된다면 중간 진행과정도 쓸 까 하는 데 역시 어찌 될지는 모른 다.
애자일 책이나 DevOps책에서 한결 같이 말하는 게 팀 그리고 기업에 전파하는 게 가장 어렵다는 데 그 말이 맞는 거 같다.
나중에 후기를 쓸 수 있게 되면 좋겠다. 후기를 쓴다는 거는 그래도 어느정도는 잘 됬다는 거라는 소리이지 않을 까?
댓글