[아이티데일리] 

크루즈(Cruise) 소개

자동차가 스스로 주행하는 미래를 만들기 위해서는 무엇이 필요할까? 크루즈(Cruise)는 2013년부터 이러한 고민을 하면서 자율주행차 기술 개발에 주력해왔다. 크루즈의 목표는 사람들이 관심을 갖고 있는 장소와 사물, 그리고 사용환경에 안전하게 연결할 수 있는 세계 최고의 자율주행 자동차 네트워크를 구축하는 것이다. 크루즈는 더 안전하고, 경제적이며, 보다 발전된 미래의 도시를 설계하고 있다. 이 회사는 전기자동차를 운영할 수 있는 자율주행 기업이자, 100% 재생 에너지로 자동차에 동력을 공급하는 기업이다.

크루즈 개요
ㆍ 100명 이상 개발자 보유
ㆍ 150개의 셀프-서비스 리소스
ㆍ 매주 100여 개의 구성을 생성 및 업데이트
ㆍ 50개 이상의 엔지니어링 팀
ㆍ 1,000여 개의 매니지드 리소스
ㆍ 150개의 지원 애플리케이션

크루즈, 혁신의 시작

혁신을 선도하기 위해서는 기존 방식으로는 불가능하다. 기존의 틀에서 벗어나 생각하고, 새로운 접근방식을 발굴함으로써 혁신은 가능하다.

크루즈는 최첨단 맞춤형 하드웨어 플랫폼 설계에서부터 고도로 최적화된 소프트웨어 코드 작성에 이르기까지 모든 작업을 수행할 수 있는 최신 및 최상의 툴을 찾는데 주력해 왔다. 크루즈는 하드웨어와 소프트웨어 스택을 완전히 통합한 접근방식을 통해 업계의 리더가 되었으며, 세계에서 가장 까다로운 환경 도시 중 하나인 캘리포니아 샌프란시스코에서 무인 자동차를 처음으로 시험 운행했다.

크루즈의 각 팀들은 보다 나은 협업 방법을 모색했다. 애플리케이션 개발 팀은 궁극적으로 자율주행차 기술을 구성하는 애플리케이션 구축을 책임지고, 소수의 SRE(Site Reliability Engineer)로 구성된 인프라 팀은 이러한 애플리케이션을 위한 인프라와 리소스를 제공해야 했다.

크루즈의 개발과 인프라 팀은 핵심 워크플로우를 도입하면서 더 많은 운영자와 SRE 및 개발자들이 쉽게 온보딩할 수 있는 방법을 필요로 했다. 이 회사의 목표는 두 팀이 가능한 안전하고, 효율적으로 혁신, 검증, 반복 및 중복 작업을 수행할 수 있도록 인프라 프로비저닝에 대한 협업적 접근방식을 수립하는 것이었다.

단 한 명으로 구성된 초기의 크루즈 인프라 팀은 HCL(HashiCorp Configuration Language)을 사용하여 클라우드 리소스 프로비저닝을 수행하기 위해 하시코프 테라폼(HashiCorp Terraform) 오픈소스(OSS)를 채택했다. 보다 쉽게 코드를 공유할 수 있도록 모든 구성 코드는 단일 리포지토리에 저장했으며, 소수의 엔지니어만 액세스하여 구성 변경사항을 구축할 수 있도록 했다.

테라폼 OSS 채택 후 크루즈 인프라 팀은 40개 이상의 SRE로 확장됐다. 또한 개발 조직은 소프트웨어 엔지니어가 800명 이상으로 늘어났다. 이런 상황에서 인프라 팀은 테라폼 OSS로 구축했던 것보다 워크플로우가 훨씬 커졌다는 것을 알게 되었다.

조직에 따라 확장 가능한 접근방식

크루즈는 조직안에서 팀이 늘어나면서 애플리케이션 및 소프트웨어를 유지하기 위해 엔지니어들이 지속 가능한 방식으로 인프라를 신속하게 확장할 수 있는 방법이 필요했다. 크루즈는 하시코프 테라폼으로 이런 문제를 해결했다. 하시코프 테라폼이 크루즈가 안고 있는 문제를 해결할 핵심 기술을 제공한 것이다. SRE는 테라폼 엔터프라이즈(Terraform Enterprise)를 통해 개발자들이 효율성을 높일 수 있도록 했다.

“크루즈는 엔지니어링 민첩성을 향상시키고, 자율주행차 기술을 빠르게 구현하기 위해 하시코프의 테라폼을 채택했다”

전체 조직의 생산성 향상

크루즈의 각 팀은 작업공간을 사용하여 모노-리포지토리를 잘 정의된 별도의 마이크로-리포지토리로 구분하고, 작업공간 내에서 코드의 활용 및 실행을 나눌 수 있었다. 각 사용자는 인프라를 코드로 작성하고, 이를 실행하여 인프라를 생성할 수 있는 고유의 작업공간에 액세스할 수 있었다. 또한 이러한 작업공간을 사용하면, 해당 작업공간 외부에서 생성 및 관리되는 인프라 오류로부터 영향을 받지 않게 된다. 기업들은 코드화되고, 재사용이 가능한 인프라 구성요소인 모듈을 사용할 수 있다. SRE 팀의 승인을 받은 모듈은 애플리케이션 개발자가 개별 작업공간 내에서 사용할 수 있다.

센티넬 정책 및 거버넌스로 위험 감소

수백 명의 사람들이 인프라를 프로비저닝할 경우 부주의로 인해 보안 및 운영 모범사례에 영향을 미치는 것을 방지할 수 있도록 규칙을 수립해야 한다. 이를 위해 핵심 인프라 팀은 하시코프의 코드 접근방식 정책인 센티넬(Sentinel)을 활용하여 버전 제어에서 정책을 코드화한 다음, 인프라가 프로비저닝되기 전에 이를 시행하도록 한다. 이 접근방식을 통해 다음과 같은 정책 검사를 자동화할 수 있다.

ㆍ 프로비저닝되는 리소스가 승인되었는가?
ㆍ AWS S3 버킷에 감사용 로깅이 설정되어 있는가?
ㆍ 리소스를 삭제할 수 있는 권한이 있는가?
ㆍ VPC 서브넷과 동일한 리전에서 리소스가 생성되고 있는가?

센티넬은 모듈과 함께 SRE 팀이 모든 인프라를 안전하고, 모범사례를 준수하는 방식으로 프로비저닝할 수 있도록 해준다.

직면과제

ㆍ 생산성에 영향을 미치는 대규모 모노-리포지토리에 대한 관리의 어려움
ㆍ 변경사항에 대한 수동 조정의 복잡성과 프로비저닝 속도 저하
ㆍ 단일 개발자가 도입한 오류로 인해 다른 많은 개발자에게 미칠 수 있는 위험성 증가
ㆍ 개발자가 인프라를 프로비저닝할 때마다 가드레일이 배치되었는지 확인하기 어려움

개발자의 민첩성 향상

크루즈에서는 SRE가 인프라 전문가이며 인프라를 프로비저닝하고, 사용하는 방법에 대한 기준 표준을 만든다. 이 팀은 모듈을 사용해 개발자들이 테라폼 엔터프라이즈에서 프로비저닝하는데 사용할 수 있는 버전이 지정되고, 검증 및 승인된 150개의 리소스 라이브러리를 제공한다. 모듈이 없는 경우, 개발자는 모듈을 생성해 SRE 팀의 검증 및 승인을 위해 제출할 수 있다.

초기에는 모듈 리포지토리에 승인된 소규모의 모듈 세트가 있었지만, 시간이 지나면서 대부분의 개발 조직을 위한 공통 리소스가 포함될 정도로 성장했다. 그런 다음 이 프로세스는 웹훅(Webhook)을 사용하여 깃허브(GitHub)와 통합된 자동화된 파이프라인에 구현됐다.

결과

ㆍ 조직 전체의 효율성 및 생산성 향상
ㆍ 의도치 않은 오류 위험성 완화 및 개발자의 생산성 향상
ㆍ 100명의 개발자를 위한 자동화된 인프라 프로비저닝

테라폼 엔터프라이즈로 운영 효율성 극대화

크루즈 팀은 자율주행 자동차에서 실행되는 자율주행차 소프트웨어를 빠르게 구현함으로써 변화하는 환경에 효율적으로 대응하고, 지원할 수 있도록 인프라 자동화 파이프라인을 구축할 필요성이 있었다. 테라폼 엔터프라이즈 워크플로우를 통해 크루즈 팀은 지속적으로 운영 효율성을 극대화하고, 위험을 최소화하면서도 적절한 가드레일을 유지하면서 성장할 수 있었다.

크루즈의 SRE 파트너

마크 스파호크(Mark Sparhawk)는 크루즈의 사이트 신뢰성 엔지니어링 매니저로 자율주행차 프로그램의 모든 측면을 관리하고 있다. 마크는 다양성과 포용성, 소속감에 중점을 두고 팀이 높은 성과를 달성하는데 주안점을 두었다. 그는 여러 임베디드 SRE 팀과 중앙집중식 툴링, 라이브러리 및 서비스 팀은 물론, 역량 및 효율성 팀을 책임지고 있다.