IT 서비스를 둘러싼 환경이 시시각각 변하는 가운데 소프트웨어 개발 속도와 안정성을 양립시키는 건 개발 현장에서 중요한 포인트 중 하나가 되고 있다. 팀 커뮤니케이션 도구인 슬랙(Slack) 엔지니어가 자사의 소프트웨어 개발 수행 흐름을 블로그에 설명하고 있다. 이들은 어떻게 속도와 안정성을 양립한 소프트웨어 개발을 실현하고 있을까.
슬랙에선 깃(Git)을 이용한 개발을 수행하며 사내에서 코드 리뷰와 테스트를 통과하면 개발자는 풀 리퀘스트(pull request)를 마스터 브랜치에 병합할 수 있다. 마스터 브랜치 개발 환경 배포는 예상하지 못한 문제에 대응할 수 있게 북아메리카에 위치한 본사 영업시간 내에 이뤄진다. 배포는 매일 12회 진행되며 각각 배치에 대해 책임이 할당된다. 배포를 세분화하는 건 오류 영향을 최소화하기 위한 것이다.
슬랙은 소프트웨어를 새로운 빌드로 출시할 때 먼저 깃에서 릴리스 브랜치를 생성한다. 릴리스 브랜치는 릴리스 기록을 태그하는데 필요한 것으로 프로덕션 환경에 롤아웃 중 발견된 문제를 해결하는 포인트다. 릴리스 브랜치에서 작업이 끝나면 비공개 테스트 환경에 새로운 빌드를 배포하고 테스트를 실시한다. 테스트를 통과한 빌드는 내부 직원에 의해 평가되며 문제가 없으면 슬랙 전체 이용자 중 10%, 25%, 50%, 75%, 100%로 단계적으로 새로운 빌드를 공개해 나가는 구조로 이뤄져 있다.
배포에서 문제가 생긴 경우 각 배치별 책임자가 대응을 지시한다. 가급적 조기에 문제 원인인 풀 리퀘스트를 발견하고 문제 부분을 수정해 새로운 빌드를 만들 수 있지만 프로덕션 환경에 배포한 뒤 문제가 발생하면 이전 빌드로 롤백한다.
이런 개발 흐름을 확립하기까지 수많은 시행착오가 있었다고 한다. 슬랙 자체가 현재보다 훨씬 소규모였던 시절에는 아마존 AWS 10인스턴스에서 서비스를 운영했으며 아르싱크(rsync)를 통해 모든 서버를 동기화하는 시스템이었다. 개발 흐름은 테스트 환경에서 테스트를 통과하면 프로덕션 환경에 곧바로 배포하는 간단한 것으로 개발자가 서버에 자유롭게 자신의 코드를 배포할 수 있었다고 한다.
하지만 슬랙 서비스 규모가 확대되면서 개발이 가속화됐고 개발자는 각 서버에 작용해 코드를 배포해 전체 서버를 아르싱크로 동기화하는 방법에도 한계가 도달했다. 이런 이유로 서버별 콘솔 키를 모니터링하고 키 변경 통지를 받은 서버가 아마존 S3에 대해 전개를 요구하는 방식으로 바꿨다. 이런 변경으로 인해 서비스 규모 확대에 따른 개발 가속화에 대응할 수 있었다고 한다.
현재 배포 체계를 지탱하는 또 하나의 프로젝트는 아토믹 딜레이(Atomic deploy)다. 이를 채택하기 전 실행 중인 운영 환경에 직접 배포를 했기 때문에 새로운 함수보다 먼저 그 함수를 호출하기 위한 기술이 적용되어 버려 오류가 발생하거나 웹페이지가 손상될 수 있었다고 한다. 아토믹 딜레이에서 실행 중인 버전인 핫디렉터리와 가동하지 않는 콜드 디렉터리를 준비하고 새로운 버전을 초기 디렉터리에 적용해 핫디렉터리와 콜드 디렉터리를 대체해 오류를 발생시키지 않고 새로운 버전을 배포할 수 있게 됐다고 한다.
슬랙은 개발 시스템을 더 나은 도구와 자동화를 통해 지속적으로 개선할 것이라고 밝히고 있다. 관련 내용은 이곳에서 확인할 수 있다.