2019.12.24

글로벌 칼럼 | 사이트 신뢰성 엔지니어링과 데브옵스가 만나는 곳은 어디인가

Isaac Sacolick | InfoWorld
클라우드 애플리케이션, 데브옵스, 테스트 자동화, 사이트 신뢰성 엔지니어(site reliability engineers)가 등장하기 이전 시대에는 개발자와 테스터, 시스템 관리자가 웹 및 모바일 애플리케이션을 개발하고 지원했다. 개발자가 애자일 방법론을 추종했다면 시스템 관리자는 ITIL의 사고 관리 및 기타 실천 방안을 채택했다.

당시에는 테스트, 배포, 인프라를 자동화하기 위한 툴의 수도 지금처럼 많지 않았으므로 코드 완성부터 프로덕션 단계에 이르기까지 난관이 많았다. 운영 데이터와 모니터링 툴, 지원 워크플로우가 쉽게 통합되지 않았기 때문에 프로덕션 인프라와 애플리케이션을 모니터링하고 프로덕션 문제의 근본 원인을 찾기 위해서는 기술과 상황 대처 능력, 두 가지 모두 필요했다.

많은 측면에서 지금의 애플리케이션 개발, 테스트, 지원은 예전에 비해 쉬워졌지만 용어와 역할 정의, 실무적 책임을 해석하고 적용하기는 훨씬 더 어려워졌다. 사이트 신뢰성 엔지니어링이 속한 영역은 데브옵스인가, 보완적 서비스인가? CI/CD(지속적 통합/지속적 제공) 파이프라인과 코드형 인프라를 책임지는 사람은 누구인가? 프로덕션 사고가 발생하는 경우 문제를 해결하고 근본 원인을 찾고 최적의 교정안을 구현하기 위한 가장 효율적인 프로세스는 무엇인가?


구글의 문화와 방식, 모든 조직에 맞는 건 아니다

앞서 질문에 대한 보편적인 모범 답안은 없다. 조직의 크기, 규모와 복잡성은 제각기 다르기 때문이다. 10여 명의 엔지니어가 있는 신생 기업에서 통하는 방법과 규제를 받는 업계에서 활동하는 다국적 기업에 적용되는 방법은 다르다. 

마찬가지로, 구글, 넷플릭스, 마이크로소프트와 같은 대형 IT 업체에서 효과적인 문화와 관행, 기술이 레거시 시스템과 기술 부채가 많은 다른 산업이나 기업 관점에서는 그림의 떡인 경우가 많다.

그래서 일반적인 이해에 도달하기 위해서는 다음과 같은 5가지 관점에 대한 용어의 정의가 필요하다.

- 조직이 지원하는 미션, 문화, 협업, 사고방식
- 비즈니스 목표, 고객 정의, 가치 제안, 성공 KPI(주요 성과 지표)
- 애플리케이션 개발, 테스트, 배포, 모니터링을 위한 기술적 작업
- 애플리케이션을 계획. 제공, 지원하기 위해 팀에서 사용하는 워크플로우와 실행 방안
- 이 작업을 성공적으로 수행하기 위해 필요한 툴과 자동화

보기에는 간단하지만 실제 환경에서 조직의 운영 방식은 매우 복잡하고 실행 방안 간의 경계도 뚜렷하지 않다. 예를 들어 필자는 애자일 방법론을 워크플로우 실행 방안으로 정의하지만 조직에서 애자일 실행 방안을 어떻게 정의하는지는 비즈니스 목표와 기술 아키텍처, 소프트웨어 개발 라이프사이클, 현행 데브옵스 자동화 방법에 따라 달라진다. 

데브옵스의 실행/문화와 사이트 신뢰성 엔지니어의 업무/책임 간의 교차점 역시 마찬가지다. 데브옵스와 SRE(Site Reliability Engineering)에 있어서는 의견이 매우 다양하다. 이 가운데 몇 가지 예를 들면 다음과 같다.

- 구글은 조직 사일로 감소, 실패를 정상으로 받아들이기, 점진적 변화 구현, 툴과 자동화 활용, 모든 것 측정하기를 비롯한 여러 가지 데브옵스 목표를 정의한다. 또한 구글은 포괄적인 헌장을 두는 “만물의 SRE” 모델부터 개발 팀을 위한 컨설턴트 역할을 하면서 코드 수정에는 거의 관여하지 않는 모델에 이르기까지 여러 SRE 운영 모델을 제안한다.

- 컴퓨팅 기기 협회(The Association for Computing Machinery)는 SRE 역할에 대해 운영에 더 초점을 두는 헌장을 규정하고 모니터링, 지표, 응급 대응, 용량 계획, 서비스 관리, 변경 관리, 성능을 SRE의 핵심적인 기능으로 본다.

- 데브옵스와 SRE의 차이점을 설명하는 또 다른 기사에서는 “데브옵스가 일반적으로 무엇에 초점을 두는 반면 SRE는 “어떻게”에 초점을 둔다고 하는데, 필자도 그 말에 동의한다. 기사는 또한 “SRE는 대규모 애플리케이션을 관리하고자 하는 기업과 조직에 적합하다”고 조언한다.

필자는 SRE가 주로 대규모 조직에 적합하다는 의견에는 동의하지 않으며, 맞춤형 애플리케이션, 데이터 통합, 데이터 과학 실험, 머신러닝 모델을 구축하고 지원하는 모든 조직에는 규모와 관계없이 개발 책임을 보완하기 위해 SRE가 필요하다고 생각한다. SRE의 7가지 책임에는 서비스 수준 목표에 따른 관리, 수작업 최소화, 개발자와의 소유권 공유 등이 포함된다. 규모와 상관없이 어느 조직이든 이러한 책임을 소유하고 처리해야 하기는 마찬가지다.


시스템 관리에서 사이트 신뢰성으로 초점 이동

‘드라이빙 디지털(Driving Digital)’에서 필자는 SRE 역할을 “애자일 운영(agile operations)”으로 기술했다. 이 책에서 필자는 “이상적으로, 개발자는 사용자와 함께 새로운 기능을 개발하는 데 시간의 70~80%를 소비하고 지원에는 20~30%만 소비해야 한다”는, 지나치게 단순화되고 비현실적이기도 한 목표를 언급했다. 

지원은 CI/CD 파이프라인 자동화부터 코드형 인프라 구현과 애플리케이션 모니터링 자동화에 이르기까지 비기능적인 모든 부분을 포괄한다.

이런 기능은 필수적이긴 하지만 어디까지나 개발의 효율성, 일관성, 신뢰성을 확보하기 위한 비계 작업일 뿐이다. 자동화에는 코딩이 필요하지만 필자라면 이를 구현하기 위한 젠킨스(Jenkins), 서클CI(CircleCI), 애저 데브옵스(Azure DevOps), 퍼펫(Puppet), 셰프(Chef), 앤서블(Ansible)을 비롯한 다양한 데브옵스 플랫폼에 숙련된 엔지니어가 있는 편을 더 선호할 것이다.

그러나 개발, 테스트, 프로덕션에서 안정적이고 성능이 우수하고 확장 가능하고 안전한 애플리케이션을 보장하는 것 역시 중대한 책임이다. 이 작업이 갈수록 작업 과정의 앞쪽으로 이동하면서 개발 및 테스트 단계에서 이러한 부분을 파악해 처리하는 경우가 늘고 있다. 안정성 보장은 팀 전체의 책임이지만 필자라면 팀원 일부가 방법과 툴을 익혀 구현을 책임지는 편을 더 선호할 것이다.

10년 전의 업계에서는 이 책임을 시스템 관리 또는 시스템 엔지니어링으로 지칭했다. 지금은 클라우드 인프라, 툴 프로비저닝, 자동화를 통해 더 효율적인 인프라 패턴이 실현되고 시스템 작업이 줄어들었다. 마찬가지로, 변경 관리와 같은 자동화 및 통제 수단 덕분에 수작업 일부가 줄어들면서 관리 작업도 대폭 줄었다.


애플리케이션 신뢰성을 위해 개발자와 SRE의 협업 필요

과거 “시스템 관리” 또는 “시스템 엔지니어링”으로 불렸던 책임을 지금 관점에서 더 적절한 표현하면 “사이트 신뢰성 엔지니어링”이다. 이 역할을 맡는 사람은 인프라부터 최종 사용자 경험에 이르기까지의 성능을 두루 파악해야 한다. 이들은 사고가 발생할 때 최전선 방어를 담당하며, 근본 원인을 찾아 문제를 교정하기 위한 리더십과 기술적 책임감도 갖춰야 한다.

이런 부분은 SRE의 사후 대응 책임에 속하지만 사전 대응에 해당하는 중요한 기술과 작업도 많다. 이러한 책임과 툴의 형태는 애플리케이션의 속성에 따라 다르다. 침투 테스트 자동화, 코드 리뷰, 성능 테스트, 성능과 신뢰성 또는 확장성에 영향을 미치는 비기능적 기술 부채가 있는 코드의 리팩터링 등이 포함될 수 있다.

개발자 협업의 시작은 SRE 역할, 그리고 개발 책임이 끝나고 SRE 책임이 시작되는 경계를 이해하는 것이다. 또한 이 점을 이해한다 해도 대부분의 조직에서 SRE의 수는 개발자에 비해 훨씬 적으므로 SRE가 어디에 위치하고 누구에게 보고하며 애자일 팀에 속하는지 또는 외부 서비스 공급자로 활동하는지 여부에 관계없이 협업은 필요하다. SRE는 개발자와 동일한 툴과 개발 실천 방안을 사용해야 하지만 이들에게 할당되는 작업과 개발자에 의해 구현되는 패턴이나 모범사례는 많은 측면에서 다르다.

이것이 왜 중요한가? 최종 사용자와 고객에게 영향을 미치는 사고와 끊임없이 맞서 싸우는 일은 아무도 원하지 않기 때문이다. editor@itworld.co.kr 


2019.12.24

글로벌 칼럼 | 사이트 신뢰성 엔지니어링과 데브옵스가 만나는 곳은 어디인가

Isaac Sacolick | InfoWorld
클라우드 애플리케이션, 데브옵스, 테스트 자동화, 사이트 신뢰성 엔지니어(site reliability engineers)가 등장하기 이전 시대에는 개발자와 테스터, 시스템 관리자가 웹 및 모바일 애플리케이션을 개발하고 지원했다. 개발자가 애자일 방법론을 추종했다면 시스템 관리자는 ITIL의 사고 관리 및 기타 실천 방안을 채택했다.

당시에는 테스트, 배포, 인프라를 자동화하기 위한 툴의 수도 지금처럼 많지 않았으므로 코드 완성부터 프로덕션 단계에 이르기까지 난관이 많았다. 운영 데이터와 모니터링 툴, 지원 워크플로우가 쉽게 통합되지 않았기 때문에 프로덕션 인프라와 애플리케이션을 모니터링하고 프로덕션 문제의 근본 원인을 찾기 위해서는 기술과 상황 대처 능력, 두 가지 모두 필요했다.

많은 측면에서 지금의 애플리케이션 개발, 테스트, 지원은 예전에 비해 쉬워졌지만 용어와 역할 정의, 실무적 책임을 해석하고 적용하기는 훨씬 더 어려워졌다. 사이트 신뢰성 엔지니어링이 속한 영역은 데브옵스인가, 보완적 서비스인가? CI/CD(지속적 통합/지속적 제공) 파이프라인과 코드형 인프라를 책임지는 사람은 누구인가? 프로덕션 사고가 발생하는 경우 문제를 해결하고 근본 원인을 찾고 최적의 교정안을 구현하기 위한 가장 효율적인 프로세스는 무엇인가?


구글의 문화와 방식, 모든 조직에 맞는 건 아니다

앞서 질문에 대한 보편적인 모범 답안은 없다. 조직의 크기, 규모와 복잡성은 제각기 다르기 때문이다. 10여 명의 엔지니어가 있는 신생 기업에서 통하는 방법과 규제를 받는 업계에서 활동하는 다국적 기업에 적용되는 방법은 다르다. 

마찬가지로, 구글, 넷플릭스, 마이크로소프트와 같은 대형 IT 업체에서 효과적인 문화와 관행, 기술이 레거시 시스템과 기술 부채가 많은 다른 산업이나 기업 관점에서는 그림의 떡인 경우가 많다.

그래서 일반적인 이해에 도달하기 위해서는 다음과 같은 5가지 관점에 대한 용어의 정의가 필요하다.

- 조직이 지원하는 미션, 문화, 협업, 사고방식
- 비즈니스 목표, 고객 정의, 가치 제안, 성공 KPI(주요 성과 지표)
- 애플리케이션 개발, 테스트, 배포, 모니터링을 위한 기술적 작업
- 애플리케이션을 계획. 제공, 지원하기 위해 팀에서 사용하는 워크플로우와 실행 방안
- 이 작업을 성공적으로 수행하기 위해 필요한 툴과 자동화

보기에는 간단하지만 실제 환경에서 조직의 운영 방식은 매우 복잡하고 실행 방안 간의 경계도 뚜렷하지 않다. 예를 들어 필자는 애자일 방법론을 워크플로우 실행 방안으로 정의하지만 조직에서 애자일 실행 방안을 어떻게 정의하는지는 비즈니스 목표와 기술 아키텍처, 소프트웨어 개발 라이프사이클, 현행 데브옵스 자동화 방법에 따라 달라진다. 

데브옵스의 실행/문화와 사이트 신뢰성 엔지니어의 업무/책임 간의 교차점 역시 마찬가지다. 데브옵스와 SRE(Site Reliability Engineering)에 있어서는 의견이 매우 다양하다. 이 가운데 몇 가지 예를 들면 다음과 같다.

- 구글은 조직 사일로 감소, 실패를 정상으로 받아들이기, 점진적 변화 구현, 툴과 자동화 활용, 모든 것 측정하기를 비롯한 여러 가지 데브옵스 목표를 정의한다. 또한 구글은 포괄적인 헌장을 두는 “만물의 SRE” 모델부터 개발 팀을 위한 컨설턴트 역할을 하면서 코드 수정에는 거의 관여하지 않는 모델에 이르기까지 여러 SRE 운영 모델을 제안한다.

- 컴퓨팅 기기 협회(The Association for Computing Machinery)는 SRE 역할에 대해 운영에 더 초점을 두는 헌장을 규정하고 모니터링, 지표, 응급 대응, 용량 계획, 서비스 관리, 변경 관리, 성능을 SRE의 핵심적인 기능으로 본다.

- 데브옵스와 SRE의 차이점을 설명하는 또 다른 기사에서는 “데브옵스가 일반적으로 무엇에 초점을 두는 반면 SRE는 “어떻게”에 초점을 둔다고 하는데, 필자도 그 말에 동의한다. 기사는 또한 “SRE는 대규모 애플리케이션을 관리하고자 하는 기업과 조직에 적합하다”고 조언한다.

필자는 SRE가 주로 대규모 조직에 적합하다는 의견에는 동의하지 않으며, 맞춤형 애플리케이션, 데이터 통합, 데이터 과학 실험, 머신러닝 모델을 구축하고 지원하는 모든 조직에는 규모와 관계없이 개발 책임을 보완하기 위해 SRE가 필요하다고 생각한다. SRE의 7가지 책임에는 서비스 수준 목표에 따른 관리, 수작업 최소화, 개발자와의 소유권 공유 등이 포함된다. 규모와 상관없이 어느 조직이든 이러한 책임을 소유하고 처리해야 하기는 마찬가지다.


시스템 관리에서 사이트 신뢰성으로 초점 이동

‘드라이빙 디지털(Driving Digital)’에서 필자는 SRE 역할을 “애자일 운영(agile operations)”으로 기술했다. 이 책에서 필자는 “이상적으로, 개발자는 사용자와 함께 새로운 기능을 개발하는 데 시간의 70~80%를 소비하고 지원에는 20~30%만 소비해야 한다”는, 지나치게 단순화되고 비현실적이기도 한 목표를 언급했다. 

지원은 CI/CD 파이프라인 자동화부터 코드형 인프라 구현과 애플리케이션 모니터링 자동화에 이르기까지 비기능적인 모든 부분을 포괄한다.

이런 기능은 필수적이긴 하지만 어디까지나 개발의 효율성, 일관성, 신뢰성을 확보하기 위한 비계 작업일 뿐이다. 자동화에는 코딩이 필요하지만 필자라면 이를 구현하기 위한 젠킨스(Jenkins), 서클CI(CircleCI), 애저 데브옵스(Azure DevOps), 퍼펫(Puppet), 셰프(Chef), 앤서블(Ansible)을 비롯한 다양한 데브옵스 플랫폼에 숙련된 엔지니어가 있는 편을 더 선호할 것이다.

그러나 개발, 테스트, 프로덕션에서 안정적이고 성능이 우수하고 확장 가능하고 안전한 애플리케이션을 보장하는 것 역시 중대한 책임이다. 이 작업이 갈수록 작업 과정의 앞쪽으로 이동하면서 개발 및 테스트 단계에서 이러한 부분을 파악해 처리하는 경우가 늘고 있다. 안정성 보장은 팀 전체의 책임이지만 필자라면 팀원 일부가 방법과 툴을 익혀 구현을 책임지는 편을 더 선호할 것이다.

10년 전의 업계에서는 이 책임을 시스템 관리 또는 시스템 엔지니어링으로 지칭했다. 지금은 클라우드 인프라, 툴 프로비저닝, 자동화를 통해 더 효율적인 인프라 패턴이 실현되고 시스템 작업이 줄어들었다. 마찬가지로, 변경 관리와 같은 자동화 및 통제 수단 덕분에 수작업 일부가 줄어들면서 관리 작업도 대폭 줄었다.


애플리케이션 신뢰성을 위해 개발자와 SRE의 협업 필요

과거 “시스템 관리” 또는 “시스템 엔지니어링”으로 불렸던 책임을 지금 관점에서 더 적절한 표현하면 “사이트 신뢰성 엔지니어링”이다. 이 역할을 맡는 사람은 인프라부터 최종 사용자 경험에 이르기까지의 성능을 두루 파악해야 한다. 이들은 사고가 발생할 때 최전선 방어를 담당하며, 근본 원인을 찾아 문제를 교정하기 위한 리더십과 기술적 책임감도 갖춰야 한다.

이런 부분은 SRE의 사후 대응 책임에 속하지만 사전 대응에 해당하는 중요한 기술과 작업도 많다. 이러한 책임과 툴의 형태는 애플리케이션의 속성에 따라 다르다. 침투 테스트 자동화, 코드 리뷰, 성능 테스트, 성능과 신뢰성 또는 확장성에 영향을 미치는 비기능적 기술 부채가 있는 코드의 리팩터링 등이 포함될 수 있다.

개발자 협업의 시작은 SRE 역할, 그리고 개발 책임이 끝나고 SRE 책임이 시작되는 경계를 이해하는 것이다. 또한 이 점을 이해한다 해도 대부분의 조직에서 SRE의 수는 개발자에 비해 훨씬 적으므로 SRE가 어디에 위치하고 누구에게 보고하며 애자일 팀에 속하는지 또는 외부 서비스 공급자로 활동하는지 여부에 관계없이 협업은 필요하다. SRE는 개발자와 동일한 툴과 개발 실천 방안을 사용해야 하지만 이들에게 할당되는 작업과 개발자에 의해 구현되는 패턴이나 모범사례는 많은 측면에서 다르다.

이것이 왜 중요한가? 최종 사용자와 고객에게 영향을 미치는 사고와 끊임없이 맞서 싸우는 일은 아무도 원하지 않기 때문이다. editor@itworld.co.kr 


X