2018.07.06

대규모 데브옵스 운영의 정석··· 저스트잇의 'SRE 팀' 사례 분석

Scott Carey | Computerworld UK
음식 배달 기업 저스트 잇(Just Eat)은 데브옵스(DevOps) 문화를 잘 운영하는 대표 레퍼런스로 꼽힌다. 5개 지역, 35개 소프트웨어 개발팀이 서로 협업하며 마이크로서비스 450개를 유지하는 대규모 도입 사례이기도 하다.



이 기업은 중앙 집중화된 사이트 안정성 엔지니어링(Site Reliability Engineering, SRE) 팀을 구성했고 툴링(Tooling)을 전면 개편했으며, 이제는 추가로 프로세스 자동화를 위해 인공지능(AI)에 주목하고 있다.

토요일 저녁 등 피크시간에 저스트 잇은 처리하는 주문량은 분당 2,700건에 달한다. 이를 위해 AWS 인스턴스를 1,500개 이상 사용한다. 엔지니어링팀은 주당 최대 500개 릴리즈를 공개하며, 하루에만 1.5TB의 로그를 만들어내고 있다.

중앙 SRE 팀 구성하기
음식 배달 시장은 경쟁이 치열하다. 저스트 잇은 우버잇츠(UberEats), 딜리버루(Deliveroo) 등과 경쟁하고 있다. 특히 배달 시스템에 장애가 발생하면 '굶주린' 고객이 격렬한 반응을 보이기 때문에 SRE가 매우 중요하다. 실제로 발렌타인 데이 다음으로 바쁜 날인 새해 첫 날 저스트 잇의 장애 관련된 한 트윗(Tweet)에는 200건 이상의 댓글이 달리기도 했다.

지난 주 앱다이내믹스(AppDynamics)의 런던 행사에서 저스트 잇의 기술 이사 리차드 하이는 "개발팀이 제품을 소유하고 있다는 점이 SRE의 가장 기초적인 가정이다. 개발팀은 코드를 작성해 제공하며 저녁에도 이를 살펴보고 집에서도 근무하며 코드에 문제가 있으면 새벽 3시에라도 연락을 받고 문제를 수정한다. 문자 그대로 '요람부터 무덤까지' 코드를 소유한다"라고 말했다.

단, 모든 책임이 개발팀에 집중되는 것은 아니다. 하이에 따르면, 저스트 잇의 개발팀은 '5개의 핵심 요건'으로 운영되는 전담 SRE 팀의 지원을 받는다. 요건의 주요 내용은 다음과 같다.

- 사이트 가용성을 가차 없이 보호하라.
- 변경사항을 빠르게 제공할 수 있도록 하면서도 자동화된 배달 파이프라인 사용 시 품질을 확보하라.
- 확장 가능한 클라우드 솔루션을 사용하고 적절한 지출을 통해 인프라와 자원 활용을 최적화하라.
- 오픈 소스, 상용, 자체 개발 등 툴링과 관련해 혁신을 선도하고 가능한 최선의 솔루션을 확보하라.
- 청렴한 문화를 조성하고 팀의 자율성을 확보하라.

중앙의 SRE팀은 50~60명으로 구성되며 상시 운영된다. 하이는 "이들은 문제 발생시 최초 10분 동안 상황을 주도한다"라고 말했다. 또한 이 팀은 다양한 클라우드 플랫폼에서의 호스팅, 배달 자동화(CI/CD 파이프라인), 전체 모니터링, 팀 내부적인 로깅 및 경보(이를 내부적으로 '관찰 가능성'이라 부른다), 일련의 서비스 관리도 담당한다.


툴링
저스트 잇은 여러 팀 간의 의사소통을 원활히 하기 위해 다양한 방안을 활용한다. 우선, 일일 회의를 통해 지난 24시간 동안 발견한 문제를 검토하고 작업의 우선순위를 정한다. 또한 각 팀은 바쁜 주말 기간 전에 주간 위험 회의를 진행한다. 마지막으로 월간 기술 전체 회의를 통해 교훈과 새로운 툴링에 관해 토론한다.

툴링과 관련해 저스트 잇은 개발팀에 완전한 자율성을 허용하면서도, 중앙의 팀이 사용할 툴을 통제하는 합의점을 찾으려 노력한다. 다양성과 분권화를 지지하면서도 규모가 크고 비즈니스에 더 중요한 것은 일부 통제하는 것이다.

하이는 "그래서 우리는 모니터링 스택 등 일련의 툴링을 위한 중앙의 스택이 있으면서도 개발팀이 오픈 소스 방식으로 상호작용할 수 기회를 제공한다. 이를 통해 특정 버전을 분할하고 조정해 제공했을 때 결과물이 만족스럽다면 코드 베이스에 통합해 모두가 사용할 수 있도록 한다"라고 말했다.

물론 새 툴을 도입할 때는 그 위험을 파악하고 결국 가장 적합한 툴만 사내에 살아 남는다. 하이는 "해당 툴을 선택하고 정말로 훌륭하다고 생각되면(최근 슬랙이 그랬다) 다음 팀이 이를 추가로 검토한다. 여기서도 좋은 평가가 나오면 이를 배치한다. 이 과정에서 확장성, 기업 지원 등을 고려해 다른 사람들이 쉽게 도입할 수 있도록 한다"라고 말했다.

이번 행사에서는 저스트 잇의 SRE 책임자인 베니 존스턴도 발표자로 나섰다. 그는 지난 4년 동안 하루 1회 릴리즈에서 현재 주당 500회 릴리즈까지 늘리면서 데브옵스를 확대한 과정을 소개했다.

그는 "4년 전 우리 개발팀은 개발 관련 문제 해결을 지원할 실행서를 마련했다. 그러나 이런 것으로 데브옵스를 확대할 수 없었다. 더구나 사업이 커지면서 개발팀이 계속 늘어났다. 결국 우리는 기존 서비스형 플랫폼팀을 확대해야 한다는 것을 깨달았고, 그 시기 즈음부터 모니터링도 강화했다"라고 말했다.

이에 따라 개발팀은 이런 프로세스 중 일부를 자동화하는데 도움이 되는 적절한 툴을 찾기 시작했고 그 결과가 앱다이내믹스였다. 존스턴은 "우리는 운영팀이 트래픽 흐름에 영향을 주고 핵심 사용자 경험을 보호할 수 있는 적절한 툴을 찾고 있었고 결국 앱다이내믹스를 선택했다. 이 솔루션을 도입한 이후 모니터링 업무를 중앙에 집중할 수 있었다. 우리는 초기부터 서비스형 모니터링이 있었으며 이를 통해 데브옵스를 실행할 수 있었다. 무엇인가를 운영하고 있다면 눈으로 확인할 수 있어야 한다"라고 말했다.

문제는 모니터링 시스템을 각 팀이 자체 서비스를 위해 개발해 왔다는 점이다. 결국 파편화된 상태로 운영되고 있었다. 예를 들어, 주문 API의 경우 훌륭한 모니터링 기준이 있었지만 운영 관점에서는 실제 진행 상황을 거의 파악할 수 없었다. 심지어 실시간 주문율도 파악하지 못했고, 3일 후에나 데이터베이스를 통해 파악할 수 있었다. 존스턴은 "그러나 앱다이내믹스를 도입한 이후 모든 팀과 서비스를 살펴보고 원인의 상관관계를 파악해 시스템을 파악할 수 있었다"라고 말했다.

AI
아직 끝이 아니다. 저스트 잇은 이후 단계까지 고민하고 있다. 바로 '문제를 해결하는' AI다. 현재는 관리자가 아침에 회사에 도착해 많은 힙챗(HipChat) 채팅 로그를 보고 밤 사이 발생한 문제와 이슈를 확인한다. 그러나 하이의 최종적인 목표는 아침에 출근했을 때 이슈가 발생했다고 해도 굳이 엔지니어를 깨울 필요가 없는 환경을 만드는 것이다. 예를 들면 봇(Bot)과 시스템은 무엇이 잘못되었는지 파악하고 해당 시스템을 복구하는 방법을 찾는 것이다.

하이는 "이런 시스템이 서로 통신하고 시스템 변화의 의미를 이해할 수 있다면 더할 나위 없이 좋을 것이다. 이런 시스템은 협력해 문제를 해결하고 우리는 무결성만 확인하면 되는 것이다. 이렇게 되면 모든 것이 해당 힙챗 채널에 기록되어 우리는 아침에 출근했을 때 시스템의 문제가 무엇이었고 이를 해결하는 방법이 무엇인지 바로 파악할 수 있다. 점점 더 시스템을 고도화하는 것도 가능하다"라고 말했다. ciokr@idg.co.kr 

2018.07.06

대규모 데브옵스 운영의 정석··· 저스트잇의 'SRE 팀' 사례 분석

Scott Carey | Computerworld UK
음식 배달 기업 저스트 잇(Just Eat)은 데브옵스(DevOps) 문화를 잘 운영하는 대표 레퍼런스로 꼽힌다. 5개 지역, 35개 소프트웨어 개발팀이 서로 협업하며 마이크로서비스 450개를 유지하는 대규모 도입 사례이기도 하다.



이 기업은 중앙 집중화된 사이트 안정성 엔지니어링(Site Reliability Engineering, SRE) 팀을 구성했고 툴링(Tooling)을 전면 개편했으며, 이제는 추가로 프로세스 자동화를 위해 인공지능(AI)에 주목하고 있다.

토요일 저녁 등 피크시간에 저스트 잇은 처리하는 주문량은 분당 2,700건에 달한다. 이를 위해 AWS 인스턴스를 1,500개 이상 사용한다. 엔지니어링팀은 주당 최대 500개 릴리즈를 공개하며, 하루에만 1.5TB의 로그를 만들어내고 있다.

중앙 SRE 팀 구성하기
음식 배달 시장은 경쟁이 치열하다. 저스트 잇은 우버잇츠(UberEats), 딜리버루(Deliveroo) 등과 경쟁하고 있다. 특히 배달 시스템에 장애가 발생하면 '굶주린' 고객이 격렬한 반응을 보이기 때문에 SRE가 매우 중요하다. 실제로 발렌타인 데이 다음으로 바쁜 날인 새해 첫 날 저스트 잇의 장애 관련된 한 트윗(Tweet)에는 200건 이상의 댓글이 달리기도 했다.

지난 주 앱다이내믹스(AppDynamics)의 런던 행사에서 저스트 잇의 기술 이사 리차드 하이는 "개발팀이 제품을 소유하고 있다는 점이 SRE의 가장 기초적인 가정이다. 개발팀은 코드를 작성해 제공하며 저녁에도 이를 살펴보고 집에서도 근무하며 코드에 문제가 있으면 새벽 3시에라도 연락을 받고 문제를 수정한다. 문자 그대로 '요람부터 무덤까지' 코드를 소유한다"라고 말했다.

단, 모든 책임이 개발팀에 집중되는 것은 아니다. 하이에 따르면, 저스트 잇의 개발팀은 '5개의 핵심 요건'으로 운영되는 전담 SRE 팀의 지원을 받는다. 요건의 주요 내용은 다음과 같다.

- 사이트 가용성을 가차 없이 보호하라.
- 변경사항을 빠르게 제공할 수 있도록 하면서도 자동화된 배달 파이프라인 사용 시 품질을 확보하라.
- 확장 가능한 클라우드 솔루션을 사용하고 적절한 지출을 통해 인프라와 자원 활용을 최적화하라.
- 오픈 소스, 상용, 자체 개발 등 툴링과 관련해 혁신을 선도하고 가능한 최선의 솔루션을 확보하라.
- 청렴한 문화를 조성하고 팀의 자율성을 확보하라.

중앙의 SRE팀은 50~60명으로 구성되며 상시 운영된다. 하이는 "이들은 문제 발생시 최초 10분 동안 상황을 주도한다"라고 말했다. 또한 이 팀은 다양한 클라우드 플랫폼에서의 호스팅, 배달 자동화(CI/CD 파이프라인), 전체 모니터링, 팀 내부적인 로깅 및 경보(이를 내부적으로 '관찰 가능성'이라 부른다), 일련의 서비스 관리도 담당한다.


툴링
저스트 잇은 여러 팀 간의 의사소통을 원활히 하기 위해 다양한 방안을 활용한다. 우선, 일일 회의를 통해 지난 24시간 동안 발견한 문제를 검토하고 작업의 우선순위를 정한다. 또한 각 팀은 바쁜 주말 기간 전에 주간 위험 회의를 진행한다. 마지막으로 월간 기술 전체 회의를 통해 교훈과 새로운 툴링에 관해 토론한다.

툴링과 관련해 저스트 잇은 개발팀에 완전한 자율성을 허용하면서도, 중앙의 팀이 사용할 툴을 통제하는 합의점을 찾으려 노력한다. 다양성과 분권화를 지지하면서도 규모가 크고 비즈니스에 더 중요한 것은 일부 통제하는 것이다.

하이는 "그래서 우리는 모니터링 스택 등 일련의 툴링을 위한 중앙의 스택이 있으면서도 개발팀이 오픈 소스 방식으로 상호작용할 수 기회를 제공한다. 이를 통해 특정 버전을 분할하고 조정해 제공했을 때 결과물이 만족스럽다면 코드 베이스에 통합해 모두가 사용할 수 있도록 한다"라고 말했다.

물론 새 툴을 도입할 때는 그 위험을 파악하고 결국 가장 적합한 툴만 사내에 살아 남는다. 하이는 "해당 툴을 선택하고 정말로 훌륭하다고 생각되면(최근 슬랙이 그랬다) 다음 팀이 이를 추가로 검토한다. 여기서도 좋은 평가가 나오면 이를 배치한다. 이 과정에서 확장성, 기업 지원 등을 고려해 다른 사람들이 쉽게 도입할 수 있도록 한다"라고 말했다.

이번 행사에서는 저스트 잇의 SRE 책임자인 베니 존스턴도 발표자로 나섰다. 그는 지난 4년 동안 하루 1회 릴리즈에서 현재 주당 500회 릴리즈까지 늘리면서 데브옵스를 확대한 과정을 소개했다.

그는 "4년 전 우리 개발팀은 개발 관련 문제 해결을 지원할 실행서를 마련했다. 그러나 이런 것으로 데브옵스를 확대할 수 없었다. 더구나 사업이 커지면서 개발팀이 계속 늘어났다. 결국 우리는 기존 서비스형 플랫폼팀을 확대해야 한다는 것을 깨달았고, 그 시기 즈음부터 모니터링도 강화했다"라고 말했다.

이에 따라 개발팀은 이런 프로세스 중 일부를 자동화하는데 도움이 되는 적절한 툴을 찾기 시작했고 그 결과가 앱다이내믹스였다. 존스턴은 "우리는 운영팀이 트래픽 흐름에 영향을 주고 핵심 사용자 경험을 보호할 수 있는 적절한 툴을 찾고 있었고 결국 앱다이내믹스를 선택했다. 이 솔루션을 도입한 이후 모니터링 업무를 중앙에 집중할 수 있었다. 우리는 초기부터 서비스형 모니터링이 있었으며 이를 통해 데브옵스를 실행할 수 있었다. 무엇인가를 운영하고 있다면 눈으로 확인할 수 있어야 한다"라고 말했다.

문제는 모니터링 시스템을 각 팀이 자체 서비스를 위해 개발해 왔다는 점이다. 결국 파편화된 상태로 운영되고 있었다. 예를 들어, 주문 API의 경우 훌륭한 모니터링 기준이 있었지만 운영 관점에서는 실제 진행 상황을 거의 파악할 수 없었다. 심지어 실시간 주문율도 파악하지 못했고, 3일 후에나 데이터베이스를 통해 파악할 수 있었다. 존스턴은 "그러나 앱다이내믹스를 도입한 이후 모든 팀과 서비스를 살펴보고 원인의 상관관계를 파악해 시스템을 파악할 수 있었다"라고 말했다.

AI
아직 끝이 아니다. 저스트 잇은 이후 단계까지 고민하고 있다. 바로 '문제를 해결하는' AI다. 현재는 관리자가 아침에 회사에 도착해 많은 힙챗(HipChat) 채팅 로그를 보고 밤 사이 발생한 문제와 이슈를 확인한다. 그러나 하이의 최종적인 목표는 아침에 출근했을 때 이슈가 발생했다고 해도 굳이 엔지니어를 깨울 필요가 없는 환경을 만드는 것이다. 예를 들면 봇(Bot)과 시스템은 무엇이 잘못되었는지 파악하고 해당 시스템을 복구하는 방법을 찾는 것이다.

하이는 "이런 시스템이 서로 통신하고 시스템 변화의 의미를 이해할 수 있다면 더할 나위 없이 좋을 것이다. 이런 시스템은 협력해 문제를 해결하고 우리는 무결성만 확인하면 되는 것이다. 이렇게 되면 모든 것이 해당 힙챗 채널에 기록되어 우리는 아침에 출근했을 때 시스템의 문제가 무엇이었고 이를 해결하는 방법이 무엇인지 바로 파악할 수 있다. 점점 더 시스템을 고도화하는 것도 가능하다"라고 말했다. ciokr@idg.co.kr 

X