빌드 환경 분리 - Vingle

빙글은 단일 인스턴스로 서비스를 시작했다.

그리고 아직 그 구조에서 벗어나지 못했는데, 그 이유는 당장 도입해야 할 기능과 아직 더 버틸 수 있는 인프라 사이에서의 갈등 때문이었다.

당연히 종종 발생하는 서버 다운에 전혀 대비가 되지 않을 뿐더러, 인스턴스 자체의 로드가 서로에게 영향을 준다.

이런 구조는 실제로 유의미한 결과를 낳았다.

‘한 주에 각각 다른 이유로 세 번 다운되기’

더 이상 미룰 수 없다는 판단에, 이중화는 차치하고서라도 로그 롤링과 배포 환경을 우선 개선하기로 했다.

이건 그 두번째 이야기, 배포 환경 개선이다.

우리 머신은 2GB RAM을 가졌는데, 꾸역꾸역 4GB 스왑메모리를 잡고 개발서버와 운영서버를 모두 돌리고 있다.

아무리 NVMe SSD로 스왑 메모리가 충분히 빨라졌다고 하지만, 둘 사이에는 여전히 엄청난 속도 차이가 있으며,

OS는 둘을 동기화하기 위해 열일하고 있다.

빙글의 배포는 빌드 - 실행 - 트래픽 리다이렉션 - 기존 서버 종료 의 구조로 진행된다.

그러나 이 모든 과정을 단일 인스턴스에서 돌리다보니 빌드할 때 서버가 아주 느려지거나 다운되는 문제가 있다.

특히 빌드에 메모리를 많이 사용하기 때문인 것으로 보인다.

세상에 완벽한 건 (아직) 없고 스왑 메모리도 그렇다.

물리 메모리 부족을 어느정도 커버할 수는 있지만, 대체할 수는 없다.

페이지, 혹은 더 큰 단위로 디스크에서 푹 퍼오는 전략을 사용해 IO를 줄이려 노력하겠지만 물리 메모리 만큼 빠르지도, 안전하지도 않다.

잦은 스왑으로 인한 블로킹으로 오히려 전체 시스템이 느려지는 문제가 생기는 것이다.

그러다 삐끗하는 날엔 스타베이션 - 서버의 데드락 - 이어서 서버 동작에 문제가 생길 것이다.

아마 이런 이유로 원인 불명의 서버 다운이 있지 않았을까 예상한다.

그래서 이 문제를 해소하고자 빌드 과정을 분리해내기로 했다.

왜 이 생각을 미리 하지 못했을까. 고민이 부족했다.

테스트 및 빌드가 서버에 영향을 끼치지 않도록, 먼저 별도 runner에서 빌드한 jar를 artifact로서 업로드한다.

그러면 이어서 self-hosted runner에서 실행되는 배포 작업이 이 artifact를 다운로드, 실행, 개방 작업을 한다.

이렇게 하면 우리 작고 귀여운 t2.small은 자바 어플리케이션 실행만 하면 되니까 부담이 훨씬 감소한다.

이렇게 해서 배포 작업이 서버에 미치는 영향을 최소화 할 수 있었다.

아래는 그에 사용한 스크립트다. 보완할 점들이 있지만 참고가 되었으면 좋겠다.

• 서로 다른 runner에서의 job들이 needs를 활용해 동기적으로 실행된다는 점이 특징이고
• 서버의 UP을 실제 API를 사용해 확인한다는 점이 보완이 필요한 부분이다.
• Gradle Caching도 잘 안되는데, 이건 캐시 저장과 히트는 잘 되는데 적용(복원)이 안되는거라 조사가 좀 필요할 듯하다.