배포 자동화와 오토스케일링의 기쁨

Photo by charlesdeluvio on Unsplash

안녕하세요. 현재 뉴닉에서 백엔드 엔지니어로 일하고 있는 윌리 👀 와 젠 🌏 입니다. 각각 입사한 지 1년, 6개월이 되었어요. 올해 1월에 런칭한 뉴닉 iOS 앱과 안드로이드 앱, 그리고 뉴닉 웹사이트를 지탱하는 서버를 단단히 만들고 있습니다.

뉴닉 개발팀은 어떻게 일하고 있을까 시리즈 2편: <뉴닉은 모든 것을 자동화한다>

뉴닉 개발팀은 손이 많이 가는 일이라면 뭐든지 자동화해서 관리하려고 노력 중입니다. 서버 배포 자동화, 서버 확장 자동화(오토스케일링)를 통해 프로세스가 알아서 동작하도록 하고 있어요. 담당자의 실수를 줄여 생산성을 높이고, 휴일에도 불안하지 않을 수 있도록 말이죠.

오늘은 그중 두 가지, 바로 서버 배포 자동화와 오토스케일링을 소개해드릴게요. 그 전에 먼저 뉴닉의 서버 인프라부터 알아야겠죠?

뉴닉의 서버 환경은 현재 어떻게 구성되어 있나

뉴닉의 서버 인프라를 먼저 간단히 소개해드릴게요. 뉴닉 서버는 모두 클라우드 환경에서 구동되고 있답니다. 여러 클라우드 플랫폼 중에 AWS를 사용하고 있어요. API 서버와 뉴닉 웹사이트는 클라우드의 가상 서버인 Amazon EC2(​​Elastic Compute Cloud) 인스턴스로 구동되어 트래픽에 따라 유동적으로 증감합니다. 각각 개발용 스테이징 서버도 따로 만들어 사용하고 있고요. 실행 중인 여러 대의 서버로 트래픽을 분산하기 위해 ELB(Elastic Load Balancer)를 사용해 로드밸런싱을 해주고 있습니다.

데이터베이스 역시 Amazon RDS(Relational Database Service)를 통해 관리하고 있으며, 스토리지로는 Amazon S3(Simple Storage Service)를 사용하고 있어요. 그리고 콘텐츠를 캐싱해 빠르게 제공하는 CDN으로 Amazon Cloudfront를 적극적으로 활용하고 있습니다. 몇몇 작은 단위의 호스팅은 파이어베이스(Firebase)도 병행해서 사용하고 있습니다만, 뉴닉의 서버 환경은 사실상 AWS에서 시작해서 AWS로 끝난다고 말 할 수 있겠네요.

뉴닉의 서버는 현재 어떻게 배포되고 있을까?

소스코드를 작성해서 서버에 한 번 배포한 후, 다시는 소스코드를 수정하지 않는다면 서버 배포는 별일이 아닐 겁니다. 하지만 뉴닉 백엔드 팀은 하루에도 수없이 코드를 수정하고 여러 차례 배포해요. 배포 과정이 복잡하거나 손이 많이 가면 그만큼 개발 생산성은 떨어지게 됩니다. 지속적인 가치 전달 및 지속적인 배포는 이제 스타트업 개발팀의 필수가 되었고, 저희 역시 하루에 100번 배포할 수 있는 조직을 만들기 위해 여러 가지 측면에서 서버 배포 자동화를 시도하고 있습니다. 두 가지 방식을 통해서입니다.

첫째, 깃헙 액션(Github Actions)를 통해 서버 배포를 자동화하고 있어요. 뉴닉 백엔드는 스테이징 브랜치에 머지하거나, 프로덕션 브랜치에 머지하면 자동으로 배포되게 처리가 되어있습니다. 서버 배포 및 DB 마이그레이션뿐 아니라 주기적으로 처리해야 하는 크론잡들도 모두 깃헙 액션으로 관리하고 있답니다. 데이터 집계, 콘텐츠 리마인더나 SEO 작업, 작업용 카드 삭제 등 많은 자동화 작업이 이곳에서 통합 관리되고 있어요. 깃헙 액션을 사용하는 프로세스가 점차 늘어나고 있고요.

둘째, 뉴닉 앱과 웹을 지탱하는 EC2 인스턴스를 오토스케일링으로 관리하고 있어요. 트래픽에 유연하게 대응하는 것은 백엔드 개발팀의 핵심 업무 중 하나입니다. 뉴닉은 트래픽에 따라 서버의 CPU 사용량을 모니터링해 사용량이 30% 이상이 되면 새로운 서버를 추가 구동해 부하가 분산되도록 설정해두었어요. 사용자가 많이 들어오면 이제 서버가 알아서 늘어난답니다.

기존의 배포 프로세스에는 어떤 문제가 있었길래

작년 말까지만 해도 뉴닉에는 웹 서버가 그 목적에 따라 여러 대의 서버로 쪼개져 있었고, 서버마다 수동으로 배포해야 했어요. 그 과정은 꽤나 지난했습니다. 각 AWS EC2 주소를 직접 지정해 SSH로 접속해서 배포 스크립트를 각각 수동으로 동작시키는 방식이었어요. 사람이 직접 손으로 하다보니 과정의 일부를 누락하는 등의 실수가 생길 수 있었고, 작업도 오래 걸렸습니다. 배포가 하나의 일이 되어버렸죠. 더구나 새로 온 개발자는 배포 과정에 쉽게 적응하기 어려웠어요.

서버 확장의 경우, 일부 자동화 구간이 있었지만 오토스케일로 서버가 여러 대가 될 때의 대응이 되지 않고 있었습니다. 뉴닉은 현재 뉴스레터가 메인 프로덕트라 아직은 웹과 앱의 트래픽이 높지 않은 편이지만, 가끔 CPU 사용량이 80% 이상으로 치솟을 때가 있어요. 실시간 모니터링이 되지 않다 보니, 트래픽이 많은 기간에는 사용자들이 접속할 때 레이턴시가 발생할 수 있었고요. 필요시 새로 인스턴스를 구동하여 로드밸런서에 연결해줘야 하는데, 손이 많이 가는 일이라 신속하게 작업하기는 어려웠고요. 여러모로 불안한 상황이 이어지고 있었다고 할 수 있겠습니다.

그래서 어떻게 했나면요

배포 자동화 도입 배포가 복잡하고 사람의 손을 많이 타니 배포 과정을 자동화 관리하자고 백엔드 팀에서 의사결정을 했어요. 여러 플랫폼을 검토해본 결과, 깃헙 액션(Github Actions)이 가장 장점이 많아 보여 이것을 사용하는 것으로 결론을 냈답니다. 깃헙 액션의 문법대로 workflows 디렉토리 하위에 deploy 파일들을 관리하기 시작했어요. 그때부터 디플로이용 워크플로우 파일들을 한땀 한땀 작성했습니다. 배포 프로세스 사이의 의존성 관리도 할 수 있게 설정했어요.

이미 크론잡들은 젠킨스(Jenkins) 등 여러 곳에 흩어져서 동작하고 있었는데, 이런 작업들도 깃헙 액션에서 일괄 통합해서 관리하기로 했습니다. 서버 관리 플랫폼이 여러 곳에 흩어져있으면 그 자체로 관리 비용이 많이 들기 때문이었어요.

오토스케일링 도입 뉴닉은 개발 초기부터 AWS EC2를 기반으로 서버 인프라를 세팅해두었기 때문에 AWS 오토스케일링을 사용해 확장하는 것이 다행히 큰일이 아니었어요.

오토스케일링과 관련해 네트워크 트래픽을 여러 영역에 배포하는 로드밸런싱 설정도 추가로 필요했습니다. 뉴닉은 기존에 로드밸런서로 AWS ELB를 쓰고 있었어요. ELB 타겟그룹(Target Group)을 설정하고 오토스케일링 시작 구성을 생성했습니다. 이는 오토스케일링을 통해 확장될 때 자동으로 생성되는 인스턴스를 미리 구성하는 개념이예요. 그 후 오토스케일링 그룹을 생성해서 등록해주었습니다.

이때는 사용자 자체 정책이 필요합니다. 서버 대수를 최소, 최대 몇 대로 할지, CPU 사용량을 어느 기준으로 스케일아웃 할지 내부에서 결정한 뒤 설정해주었어요. 하루 이틀의 수고로움이 동반되었지만, 그 효능은 확실했습니다.

작업의 하이라이트, “배포 자동화 X 오토스케일링 연동하기” 뉴닉은 서버 한 대를 스케일 업(Scale-up)으로 관리하고 있었는데요. 올해 초 서비스 오픈에 맞춰서 서버를 스케일 아웃(Scale-out) 형태로 관리할 필요성을 느꼈습니다. 배포 자동화와 오토스케일링이 서로 매끄럽게 연결될 때 비로소 이 작업은 의미를 가질 수 있었는데요. 각각을 설정하는 일은 어렵지 않았지만, 이 두 개를 잘 엮는 일은 만만치 않았습니다.

백엔드 팀의 윌리는 과거에 AWS 오토 스케일을 이용해 서버를 관리해본 경험이 있었지만, 배포 자동화를 같이 엮어본 적은 없었는데요. 과연 이게 잘 동작할지 고민이 컸습니다. 이전에는 곧잘 AWS 람다 같은 서버리스를 사용했지만, 이번에는 서버리스로 가지 않기로 결정을 내렸습니다. 오토스케일보다 작업 사이즈가 커질 것 같고, Zappa가 여전히 잘 동작할지 의문이 들어서였는데요. 그에 더해 서버리스보다 도커 쪽으로 가고 싶은 마음도 있었습니다.

배포 자동화와 오토 스케일을 엮는 과정에서 겪는 어려움의 핵심은 EC2의 Public IP가 동적으로 바뀌는 부분을 반영해야 하는 점이었어요. 꽤 골머리를 앓았답니다. 이를 해결하기 위해 동적 IP 주소를 알아내는 과정이 필요했고, BOTO3로 EC2 인스턴스 목록을 조회하는 잡(Job)을 새로 추가했습니다. 조회해온 IP 목록을 넘겨받는 과정에서 막혔는데 이 문제를 찾아보다가 깃헙 액션에서 제공하는 신기한 기능을 하나 발견했습니다. 바로 strategy matrix였어요. 이 매트릭스에 배열을 할당하면 잡을 배열만큼 자동으로 반복실행할 수 있었답니다. 첫 번째 잡(Job 1)을 통해 EC2의 IP 목록들이 넘어오면 두 번째 잡(Job 2)에 각각의 IP를 넘겨주고 job2가 서버의 대수만큼 실행됩니다. 각각의 서버가 병렬로 배포되는 거였죠. 작업을 잘 마무리 지은 뉴닉 백엔드 팀은 기쁨의 어깨춤을 덩실덩실 추었습니다.

자동화의 효과

서버 배포 자동화의 기쁨 배포가 무척 간단해졌어요. 서버 개발을 하며 요즘은 하루에도 몇 번이나 배포하고 있습니다. 빠른 고객가치 딜리버리가 가능해졌어요. 배포 오류 모니터링도 쉬워요. 히스토리도 남으니 어느 배포에 문제가 생겼는지 로그를 보기도 쉽습니다. 기능을 개발하고 사용자에게 내보내는 과정이 혁신적으로 짧아졌습니다.

오토스케일링의 기쁨 2022년 3월의 어느 날, 여느 때와 같이 뉴닉 앱의 푸시 알림이 나간 이후에 트래픽이 갑자기 폭주한 적이 있었습니다. 당일은 회사 휴일이라 백엔드 개발자들이 실시간으로 모니터링하고 있지 않은 상황이었어요. 그럼에도 서버가 자동으로 스케일아웃되어 n대가 늘어나면서 빠르게 트래픽을 받아냈습니다. 1~2분 정도 내의 짧은 시간 내에 말이죠. 이런 일을 예상하고 설정해둔 것은 아니었으나, 본의 아니게 회사 전체의 칭찬을 받았습니다.

채용합니다

저희 팀에 관심이 생기셨나요? 지금이 기회입니다. 뉴닉 제품팀에서 현재 채용을 진행 중입니다. 뉴닉 제품팀에서 함께 성장하고 싶은 분이라면 주저하지 말고 지원해주세요!

프론트엔드 엔지니어

프로덕트 디자이너