창업한 회사에 팀원이 늘어나게 되니 직접적인 개발보다는 방향을 잡는 업무가 자연스럽게 늘어나버렸다.
처음 창업했을 때는 프론트엔드 + 백엔드 개발이 위주였다가 개발팀이 3명이 되니 프론트엔드 업무가 사라지고 백엔드 + 인프라 업무를 맡게 되었다.
이제 개발팀이 5명이 되고나서는 서비스의 이용자도 늘어나고 가끔씩 장애도 일어나면서 인프라 업무가 DevOps 업무로 전환되었다.
팀원이 5명이 되니 백엔드, 프론트엔드 개발은 다른사람이 할 수 있게 되었는데, DevOps 업무는 아무도 할 수 없게 되었다. 그래서 주로 DevOps 업무를 위주로 요즘은 하게 되는 것 같다.
DevOps란 수동으로 진행되던 배포과정 및 모니터링 과정을 자동화하여 유지 관리하는 업무를 말하는데, 우리 회사에서는 DevOps 관련해서 주로 다음 기술 스택을 사용하고 있다.
기술 스택
[배포 자동화]
- Docker 및 Docker Compose
- Jenkins
[모니터링]
- Grafana
- Loki
- influxDB
[장애 알림]
- Sentry -> Slack
[테스트 자동화]
안하고 있다ㅎㅎ
왜 그 기술을 선택했는가?
기술1. Docker 및 Docker Compose
사실 이 정도 규모에서 Docker는 선택할 수도 있고 안할 수도 있다고 생각한다.
내가 Docker를 선택했던 이유는 대한민국에서 비주류인 Ruby를 백엔드 언어로 사용하고 있기 때문이다.
Windows에서 Ruby를 사용하게 되면 진짜 온갖 버그에 직면하게 된다. 루비 사용자가 많지 않다보니 아무래도 Windows 개발 환경이 별로 좋지 못한 것이다.
이런 상황에서 개발자가 2명 더 들어왔었다. 혼자서 감당하던 개발환경 세팅 + 버그들을 3배 더 겪을 생각을 하다보니 자연스럽게 단일한 Linux 가상환경에서 개발할 수 있는 Docker에 관심을 갖게 되었고 도입하게 되었다.
Docker를 도입하고 나서 확실히 개발환경 세팅이나 서버 세팅을 하게 될때 스트레스가 확 줄게 되었다.
내가 다음과 같이 생긴 docker-compose.yml 파일을 하나 작성해놓으면 개발환경과 서버 배포환경 모두 해결할 수 있었다.
version: "3.9"
services:
db:
image: postgresql
volumes:
- mewpot-postgres:/var/lib/postgresql/data
- ./docker/postgres/pull_database.sh:/pull_database.sh
environment:
POSTGRES_PASSWORD: $DATABASE_PASSWORD
DATABASE_PASSWORD: $DATABASE_PASSWORD
ports:
- "5432"
web:
build:
context: .
environment:
RAILS_MASTER_KEY: $RAILS_MASTER_KEY
DATABASE_HOST: db
DATABASE_PASSWORD: $DATABASE_PASSWORD
volumes:
- .:/myapp
ports:
- "3000:3000"
depends_on:
- db
volumes:
mewpot-postgres:
driver: local물론 그렇다고 해서 세팅하는 삽질이 아예 사라지는건 아니다. 반복적인 삽질이 최초의 삽질 한번으로 줄어든 것 뿐이다.
기술2. Jenkins
Jenkins는 배포 및 테스트 자동화 오픈소스이다. Jenkins를 쓰기 전에는 모든 작업을 Cron으로 처리 했었는데 로그 보기도 힘들고 뭐가 어떻게 돌아가는지 한눈에 안들어왔다.
게다가 사용하는 서버를 여러대로 늘리면서 Cron이 여기저기 흩어지면서 더 정신이 없어져버렸다.
또한 Rails가 배포할때 보통 느리고 귀찮은게 아니다. 배포하는데 1분이 넘어가면서부터 배포 자동화가 필연적이라고 생각이 들었다.
Jenkins를 도입하니 이 두가지 문제가 모두 해결되었다. 주기적으로 작업해야 했던 것들을 한번에 관리할 수 있어졌고, 배포 자동화 코드를 넣어놓으니 Github에서 푸쉬를 하면 바로 배포를 진행하게 되었다.
Jenkins는 오픈소스로 관리되면서도 기능이 꽤 괜찮기 때문에 상업적으로 널리 쓰이는 CI/CD 서비스들을 대신해서 소규모 서비스에 사용하기에 괜찮다.
기술3. Grafana + Loki + influxDB
이 조합은 다음에 제대로 한번 다뤄보겠다. 도입한지 얼마 안됐는데, 꽤 괜찮은 것 같다
왜 테스트 자동화는 도입을 안했는가?
왜냐하면 테스트 코드를 작성해서 관리하기에는 우리 팀의 규모가 작기 때문이다.
테스트 코드를 쓰면 3가지 정도의 장점이 있다.
- 설계하는 사람과 구현하는 사람을 나눠서 일할 수 있다.
- 자신이 작성한 코드에 책임을 질 수 있다.
- 테스트 코드가 개발문서를 대신하여 코드의 의도를 알려준다.
하지만 이런 장점에도 불구하고 우리 개발팀은 5명이고 5명이서 무슨 코드를 짜는지 내가 관리가 된다. 또한 누가 잘못했는지 찾지 않아도 그냥 티가 난다.
스피드와 효율성이 생명인 스타트업에서 코드의 신뢰성이 엄청 중요한 상황이 아니라면 굳이 소규모 팀에 테스트 코드를 도입해야하는지 의문이 있다.
테스트 코드는 대규모 리팩토링을 할때만 인테그레이션 코드로 간단하게 작성해서 활용하고 있다.
