안녕하세요. 개발팀 김형진입니다.
이번 글에는 새로이 만들어지는 프로젝트에서 구상하는 개발 인프라에 대해서 말해 볼려고 합니다.
1. 인프라 구축의 필요성
인프라가 필요했던 이유는 안정성, 자동화 이 두가지가 가장 컸다.
1.1 안정성
- • 실섭에 바로 배포를 하는 방식이라 중간에 테스트가 미비하여 자잘한 버그가 많았다.
- • 서버가 한 대이기 때문에, 해당 서버가 문제가 생기면 서비스가 문제가 생긴다.
- • AWS에서 제공하는 모니터링툴이 있지만 기능적으로 모자란 부분이 있었다.
- • 로그를 한 번에 볼 수 있는 로그 수집툴이 없다.
- • 문제가 생겼을 경우 메신저로 알람이 오는 게 없다.
1.1 자동화
- • 만들려고 하는 인프라 계획 상 서버가 여러 대이기에, 매번 수동으로 배포는 번거로울 것이다.
- • 테스트를 CI서버에서 자동으로 돌아가게 하고 싶다.
2. 인프라 구축 계획
인프라를 계획 할 때에도 고려사항이 있었는 데 안정성과 자동화 그리고 유지비였다.
안정성과 자동화는 당연했고 마음 같아서는 서비스 하나당 하나의 서버를 쓰게 하고 싶지만 유지비를 생각 안 할 수가 없었다.
아래 그림은 계획을 세우면서 이전 직장의 인프라와 책을 참조하여 세운 계획을 간단히 도식화한 그림이다.
2.1 서버
일단 보면 4가지로 서버가 그룹화 되어있다.
프론트와 백엔드(API)로 구분된다. Docker로 구성하여 환경을 똑같이 맞출 생각이다.
보면 일단 책에서 나오는 방식에서 몇몇 부분이 빠져있다. 유지비를 최소화 하기 위해 선택적으로 제외했다.
- • Dev(Local): 개발PC이다.
- • Test: 개발한 프로그램을 테스트 하는 서버이다. 리포지토리와 DB는 로컬과 같은 거를 보고 있다. 연동되는 API와 프론트를 확인한다.
- • Stage: 리포지토리는 따로 구성되고 DB는 실섭과 같은 거를 바라본다. 다른 데서는 실섭과 같이 서버 두 대씩 구성해 로드밸런싱을 할고 실섭DB를 복사해서 새로 구성한 DB를 하는 데 유지비를 생각해 제외했다.
- • Real: 실제 유저가 접속할 서버이다. 최소 두 대씩 서버를 구성하여 한대가 문제가 생겼을 때 다른 서버로 서비스르 하면서 다른 한 대를 복구할 시간을 벌 수 있게 했다.
PLAN
Notion, G Suite, Jira
CODE
Git, GitLab, Sonatype Nexus, Verdaccio
BUILD
Maven
CONTINUOUS INTERGRATION
Jenkins
TEST
JUnit, Jest, SeverSpec
DEPLOY
Docker
OPERATE
Kubernetes, Ansible
MONITOR
PMM, Prometheus, JMeter, nGrinder, Slack, ELK
2.2 DevOps
커뮤니티
현재 Telegram이 사용하고 있으며 불편함이 없기 때문에 쓰고 있지만, 차츰 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를 고려 중이다.
2.3 고려중인 툴
이슈 트래킹
- • JIRA: 10명까지는 무료
- • Redmine
- • Trac
- • Dooray
문서화
- • Notion: 최근 스타트업에서 많이 사용된다. 문서화 외에서 이슈트래킹에도 사용된다.
- • Confluence: 유료
- • 레드마인의 위키
로그
- • ELK Stack: 엘라스틱, 로그 스태치, 키바나
- • Grafana: 키바나는 엘라스틱서치와만 연동되고 그라파나는 자율성이 높다고 해서 고려중이다. 로그를 시각화하는 툴, 오픈소스이다.
모니터링 툴
- • Scouter: 국내에서 만든 모니터링 툴, 해당 툴을 사용하는 책이 최근 출판되었다.
- • Prometheus: 최근 많이 사용되는 모니터링 툴
- • Zabbix
- • Munin
CI
- • Jenkins: 가장 많이 사용되는 툴
- • Travis CI
- • Circleci
커뮤니케이션
- • Slack
구축 테스트
- • Serverspec
- • InSpec
인프라 구축도구
- • Ansible
3. P.S
이상으로 현재 계획 중인 개발 인프라에 대해 설명했다.
어떻게 될 지는 현재로써는 모르겠다. 제대로 될 지 아니면 갈아엎을 지 아님 산으로 갈지…
기회가 된다면 중간 진행 과정도 쓸까 하는 데 역시 어찌 될지는 모른다.
애자일 책이나 DevOps책에서 한결 같이 말하는 게 팀 그리고 기업에 전파하는 게 가장 어렵다는 데 그 말이 맞는 거 같다.
나중에 후기를 쓸 수 있게 되면 좋겠다.
후기를 쓴다는 거는 그래도 어느 정도는 잘 됬다는 거라는 소리이지 않을까?
