DevOps와 SRE

과제로 작성했던 내용중 DevOps와 SRE에 대한 내용 올려봄.

 DevOps란 개발과 운영의 합성어로 개념적으로 보면 개발 조직과 운영 조직의 간극을 없애 사용자의 다양한 요구사항에 빠르게 대처할 수 있도록 하는 개발 방법론이나 문화 등을 말한다. 개발 조직과 운영 조직을 통합하는 업무를 가지고 있기 때문에 DevOps Engineer라고 하면 개발이 끝난 시점에서 부터 배포까지의 과정을 자동화하고 그 과정에서 발생하는 필요한 부분(개발 문화 도입이나 도구 사용 등)을 개발 조직 및 운영 조직과 협력해 해결해 나가는 포지션이다. 간단히 말하면 조직에 DevOps를 도입하는 업무라고 할 수 있다.

 

 퍼블릭 클라우드가 대중화되면서 소프트웨어 아키텍처는 큰 변화를 맞이하게 된다. 클라우드 환경의 가장 큰 장점은 리소스를 필요한 만큼 동적으로 할당 받아 변화에 빠르게 대응할 수 있다는 점이고 이런 이점을 최대한 활용하기 위해 많은 기업에서 마이크로 서비스 아키텍처(MSA)를 도입하기 시작했다. MSA는 DevOps의 중요성이 굉장히 큰 아키텍처이다. 마이크로 서비스는 작게 쪼개져있고 클라우드에서 스케일 아웃되기 때문에 어플리케이션 개발부터 배포까지 다양한 부분에서 신경을 써야하기 때문이다.

 

 Cloud 및 MSA 환경이 위에서 말한 DevOps Engineer가 크게 활약할 수 있는 환경이라 생각할 수 있겠지만 사실 그렇지가 않다. 콘웨이의 법칙에 따르면 시스템 구조와 조직의 커뮤니케이션 구조가 닮게 되는데, 실제로 MSA의 경우 기술적으로 격리된 조직 구성 보다는 각 서비스 마다 다양한 전문가들로 구성된 Cross-Functional팀으로 구성해 비즈니스 요구사항을 빠르게 대응하는 것이 훨씬 효과적이며 각 Cross-Functional팀의 구성원은 격리된 조직의 구성원보다 넓은 기술 스펙트럼을 가지고 있는 경우가 많고 DevOps 도입도 직접 수행하는 경우가 많기 때문이다.

 

 그렇다면 DevOps Engineer가 해야할 업무는 정확하게 무엇일까? 구글에서 업무를 하고 있는 한 아키텍트는 DevOps Engineer가 어떤 업무를 해야하는지에 대한 답을 구글의 SRE에서 찾았다고 한다. SRE는 사이트 신뢰성 엔지니어링의 약자로 신뢰도 높은 시스템을 운영하기 위한 엔지니어링을 말한다. 마이크로 서비스의 각 서비스 별로 Cross-Functional한 팀이 구성되면서 개발부터 운영까지 모든 업무를 각 서비스 팀이 스스로 해결하게 되었지만 큰 규모에서는 완벽한 셀프 서비스가 불가능하기 때문에 SRE팀은 각 서비스팀이 빌드 및 배포하고 모니터링할 수 있는 자동화된 플랫폼을 제공한다.

 

 SRE의 역할을 이해하려면 SRE가 어떻게 생기게된 것인지 그 과정을 이해할 필요가 있다. 개발 조직과 운영 조직은 서로 다른 목적(생산성, 안정성)을 가지고 있고, 생산성과 안정성은 반비례 할 수 밖에 없기 때문에 그 사이에서 타협점을 찾아야 한다. SRE라는 개념을 고안해낸 구글은 SRE를 통해 이런 타협점을 찾아내려했는데 그 타협점을 가용성에 대한 명확한 정의, 가용성 목표 정의, 장애 발생에 대한 계획을 통해 찾기로 하였다. 그리고 구글은 SRE(사이트 신뢰성 엔지니어)가 해야할 업무로 크게 모니터링, 용량 계획, 변경 관리, 장애 대응, 문화로 나누었다.

 모니터링 부분부터 보면 SRE는 타협점을 찾기 위해 가용성에 대한 명확한 정의와 목표를 정해야 한다고 했다. 가용성을 측정하기 위해서는 모니터링 시스템이 필수적인데, SRE는 모니터링으로 서비스의 정상 작동 여부를 측정해 정량화하고(서비스 수준 척도, SLI) SLI의 목표를 어느 정도를 할 것인지(서비스 수준 목표, SLO) 결정해야 한다. 중요한 것은 수준을 정하기만 하는 것이 아니라 모니터링 지표를 분석해 개선하면서 적정 수준의 가용성을 유지하는 것이다.

 두 번째로 볼 것은 용량 계획이다. 용량 계획은 다양한 유형의 하드웨어 리소스 요청에 대응할 수 있도록 계획하는 것을 말한다. 용량 계획을 세우기 위해서는 현재 가용할 수 있는 용량이 어느 정도 있는지, 요청 받은 시스템이 얼마나 리소스를 필요로 하는지, 그리고 리소스를 효율적으로 사용하기 위해 시스템을 얼마나 최적화시킬 수 있는지, 이런 것들을 모두 생각하고 계획을 세워야 한다.

 

 세 번째는 변경 관리이다. 인프라나 소프트웨어의 변경은 가용성에 가장 크게 영향을 주는 부분이다. 실제로 개발 조직과 운영 조직간의 갈등이 생기는 원인의 대부분이 변경사항에 대한 반영인 만큼 SRE에 중요한 부분이라고 할 수 있다. 변경관리에 대한 모범사례로는 점진적인 배포 전략을 세우고, 장애의 원인 파악이 가능하게 하며, 언제든지 롤백이 가능하게 하는 것이다. 물론 이 모든 것은 자동화가 되어야 한다.

 

 네 번째는 장애 대응이다. 장애 대응에는 두 가지를 체크해야 한다. 장애가 없이 얼마나 시스템이 정상작동 했는지(MTTF), 장애 발생 시 복구까지 걸리 시간(MTTR)이다. 이 중 중요한 것은 장애 발생 시 빠르게 장애를 복구해 MTTR을 줄이는 것이 중요하며, 이를 위해 장애 대응 메뉴얼을 만들어 두고 주기적으로 모의 훈련을 실시하는 것이 중요하다.

 

 마지막으로는 문화이다. SRE 문화를 지켜나가기 위해서는 조직 차원의 지원이 필요하다. SRE가 100% 가용성을 지향하는 것이 아닌 안정성과 생산성 사이에서 타협점을 찾는 것인 만큼 목표 수준에 해당하는 가용성, 생산성을 유지하면서 발생하는 문제들을 조직 차원에서 책임을 나눠가지고 개선해야한다.

 

 이렇게 SRE가 하는 역할을 정리해보면 DevOps와 비슷한 부분이 많은데 DevOps와 SRE가 생겨난 배경이 비슷하기 때문이다. 때문에 구글에서도 SRE가 DevOps를 구현한 것이라는 표현을 사용하는데 그 이유가 DevOps의 개념이 “개발 및 운영 조직간 간극을 없애기 위한 방법론 및 문화“와 같이 추상적인 개념이라면 SRE는 구체적으로 어떻게 해야하는지 말해주고 있기 때문이다.