Part 3. DevOps vs SRE ?(공통점과 차이점)

 

앞선 글에서 DevOps와 SRE가 하는 역할에 대해 간략하게 적어봤습니다.

DevOps : https://hwan-shell.tistory.com/361

Part 1. DevOps 란 무엇일까?

SRE : https://hwan-shell.tistory.com/362

Part 2. SRE란 무엇일까?

 

이 두 직군은 공통되는 것이 굉장히 많습니다.

하여 이 둘의 차이점에 대해 설명해보고자 합니다.

 

1. DevOps와 SRE의 공통점.

이 둘의 공통점은 문화에 있습니다. 둘 다 DevOps라는 철학과 문화를 바탕으로 만들어진 직군이며 방법론이기 때문입니다.

1. IaC

두 직군 모두 Infra를 다뤄야 합니다. 즉, IaC를 통해 협업을 하며, 고객 수준에 맞는 Infra를 구축해야 합니다.

또한 Infra architecture를 설계해서 문제 없이 운영되게 해야 합니다. (Cloud환경에서)

만약 Cloud환경이 아니라면 On-premise환경에서 Cloud로의 전환을 해야 합니다.

 

2. Monitoring

두 직군 모두 모니터링을 해야 합니다. 즉, Metric을 측정하고, 측정된 데이터를 기반으로 문제점을 파악하고 개선해야 합니다.

즉, 두 직군 모두 데이터 지향적입니다.

 

3. Postmortem Culture

두 직군 모두 "개선"에 포커싱 되어있는 문화 입니다. 때문에 문제가 발생 했을 시,

원인을 파악하고, 조치를 취하고, 개선점을 찾으며, 같은일이 발생하지 않게 해야 합니다.

때문에 사후 문화가 중요한 직군입니다. 사후 문화에서 중요한 것은 컨텍스트 파악입니다.

제 3자가 봤을 때 이해하지 못하는 컨텍스트면 그것은 잘못된 사후 조치 보고서입니다.

이에 관해선 Naver의 사후 문화가 잘 되어 있다고 생각합니다.

Google : https://sre.google/sre-book/postmortem-culture/

Google - Site Reliability Engineering

Naver : https://d2.naver.com/helloworld/2047663

 

4. CI/CD

두 직군 모두 CI/CD를 구축해야 하며, CI/CD를 통해 배포를 자동화 시켜야 합니다.

개발, 수정된 코드들에 대해 안전성 있고, 퀄리티 있게 자동으로 배포가 되는 프로세스를 구축해야 합니다.

또한 Dev와 Ops간의 사일로를 줄여야 합니다.

 

 

이렇게 놓고 보니 DevOps와 SRE는 비슷한 직군으로 인식될 수 밖에 없을 것 같습니다.

다음은 이 둘에 대한 목표와 차이점에 대해 설명하겠습니다.

2. DevOps와 SRE의 차이점

DevOps와 SRE의 가장 큰 차이점은 목표 입니다.

DevOps같은 경우 개발 -> 운영 단계까지의 배포에 대해 좀 더 초점이 맞춰져 있습니다.

반면 SRE의 경우 개발 -> 운영 단계는 비슷하지만 좀 더 운영 쪽에 초점이 맞춰져 있습니다.

 

1. Metric

모니터링 하는 수준은 같지만, 모니터링으로 보는 데이터의 종류는 다릅니다.

즉, 수집하는 Metric은 서로 다릅니다.

 

DevOps같은 경우 주로 배포에 초점을 맞춥니다.

• Lead time for changes : 코드가 변경되어 배포됐을 때, 배포 후 Prodection에 적용되기 까지의 걸린 시간입니다.
• Deployment time : 배포 시간입니다. 만약 배포하는데 1시간 이상 걸린다면, 해당 문제를 파악하여 개선해야 할 것입니다.
• Deployment frequency : 배포의 빈도 수 입니다. 배포의 빈도수가 많을수록 좋습니다. 잦은 배포는 QA에서 오류를 발견 하기 더 쉬워지며, 문제점이 발견됐을 때 수정이 쉽습니다. 빈도수가 너무 적다면 원인을 찾아 개선해야 합니다.
• Automated tests pass % : 코드가 Master branch에 Marge될 때 통과되는 테스트의 통과율 입니다. 테스트 통과율이 너무 타이트 하면 배포되는데 까지 걸리는 시간이 지연될 것입니다. 때문에 테스트는 광범위하게 가져가는 것이 좋습니다. 
• Availability : 코드가 배포 후 Prodection에 적용 되었을 때의 Downtime을 측정하는 것이 중요합니다.
  이를 통해 너무 Downtime이 길어진다면 이를 개선해야 합니다.
• Failed deployments : 배포 실패의 빈도 수 입니다. 배포를 실패 빈도 수를 측정하여 얼만큼 실패하였는지, 원인은 무엇인지 파악하는 것이 중요합니다.
• Mean time to recovery(MTTR) : 배포 후 실패로 인해 서비스가 중단이 되었을 때 복구할 수 있는 평균 시간입니다. 이 매트릭 수집은 서비스와 직접적인 연관이 있기 때문에 굉장히 중요합니다.

결국 DevOps는 개발 파이프라인에 병목 지점을 파악하고 품질을 향상시키고, 릴리즈 주기를 단축시켜야 합니다.

 

SRE의 경우 운영적인 측면에 초점을 맞춥니다.

SRE의 경우 2가지로 분류가 되는데, 하드웨어적 모니터링, 서비스 관련 모니터링 입니다.

그리고 이를 측정할 때 황금 신호(The Four Golden Signals) 를 반드시 측정하라고 합니다.

4가지 황금 신호는 다음과 같습니다.

• Latency : 요청을 처리하는 데 걸리는 시간입니다. 서비스를 운영하면서 요청에 대한 응답이 느리다면 이는 문제가 있는 것입니다.
  특히 주의해야할 점은 Latency를 평균 값으로 보면 안됩니다. 평균 값은 특정 구간에 대한 문제점을 놓칠 수 있기 때문에 가능하면
  히스토그램으로 확인합니다.
• Traffic : API요청 수, 스트리밍에 사용되는 대여폭(I/O크기) 또는 Connection 갯수 등... 전반적인 Network에 대한 Traffic을 측정해야 합니다. Latency가 좋아도 Traffic을 감당하지 못해 병목현상이 일어나면 결국 Latency 또한 느려질 것입니다.
• Errors : 오류를 측정 합니다. 오류에는 여러가지 종류가 있을 수 있습니다. (Http 500 code, Http 200 code를 return했지만 잘못된 컨텐츠 제공, 응답이 1초 이상 된 것은 모두 오류로 취급 등...) 이러한 오류들을 모두 측정하여 데이터화 시킵니다.
• Saturation : 포화도 입니다. 가용성이라고 말해도 될 것 같습니다. 즉, 시스템이 100% 사용률이 되기도 전에 이미 시스템 저하가 발생합니다. 성능 저하가 발생하기 전의 최대 포화상태를 측정합니다. 이를 통해 시스템 한계에 대해 알 수 있으며, 효율적인 Scaling이 가능 해집니다.

2. Automation

DevOps와 SRE의 자동화 부분은 상대적으로 차이점을 나타냅니다.

 

DevOps의 경우 CI/CD에 중점을 두어 자동화를 진행합니다. 때문에 모든 테스트를 자동화하고,

"개발 - 배포" 단계에 이르기 까지의 모든 과정을 자동화 시킵니다.

즉, 개발자가 코드를 운영서버에 배포하기 까지의 모든 행동들에 대해서 자동화 시킵니다.

 

반면 SRE의 경우 운영 측면에 중점을 두어 자동화를 진행합니다. 

• 사용자 계정 자동생성
• 서버에서 사용되는 소프트웨어의 업데이트(Linux, Java, Python, Software solution, etc...)
• Zero-Downtime rotation
• 서버 런타임 변경 (AWS EC2 Userdata, Dockerfile, kubernetes configuration, etc...)
• 오류로 인해 서비스에 이상이 생겼을 시 자동으로 복구하는 작업
• 스트레스 테스트 자동화

이것 외에도 서비스 운영에 대해 자동화 시킬 수 있는 부분에 대해서 전부 자동화 작업을 합니다.

 

결론.

DevOps와 SRE를 나누는 가장 큰 차이는 개발에 중점을 둔 것이냐, 운영에 중점을 둔 것이냐의 차이입니다.

그 차이로 인해 두 직군이 포커싱할 작업 또한 나뉘게 됩니다.

DevOps는 소프트웨어 제공을 가속화 시키면서, 팀 전체의 업무효율을 증가 시키는 것에 목적이 있습니다.

SRE는 IT운영을 간소화 시키면서 고객이 플랫폼 이용을 계속해서 사용할 수 있도록 제공하는 것에 목적이 있습니다.

 

하지만 이 두 직군이 중점을 두는것이 다를 뿐, DevOps라는 문화를 이루기 위해 지향하는 목표는 동일 합니다.

팀간의 사일로를 줄이고, 사람이 반복적으로 하는 것을 자동화 시키며, Metric을 수집하여 데이터화 시킵니다.

때문에 두 직군의 역할이 많이 겹치는 이유이기도 합니다.

 

저는 DevOps와 SRE를 공부하면서 DevOps를 할 줄 알면 SRE로 전향이 가능해야하며,

SRE를 하고 있다면 DevOps로 전향이 가능해야 한다고 생각했습니다. 

물론 역할이 교체될 때 교육, 훈련이 필요하겠지만, 거부감을 느껴선 안된다고 생각합니다.

 

구글에서 말합니다.

DevOps는 조직마다 정의와 관점이 다양한 "자유로운 정신"에 가깝습니다.

때문에 각 기업마다 DevOps엔지니어, SRE엔지니어 채용 조건을 보면 하는 일이 다 다릅니다.

 

하지만 이것은 "DevOps와 SRE의 공통된 부분에서 어느 정도까지 가져갈 것이냐?" 의 정의를 회사마다 다르게 정한 것이지,

두 직군이 중점을 두고 있는 서로의 영역에 대해서 침범하는 것은 좋지 않다고 생각합니다. 

그 이유는 너무나 많은 업무를 가져가는 것이 되는 것이라고 생각하기 때문입니다.

 

Generalist가 될 것이냐, Specialist가 될 것이냐, Simple labour가 될 것이냐는 한 끝 차이인 것 같습니다.

긴 글 봐주셔서 감사합니다. (_ _)

 

 

 

참고.

DevOps : https://stackify.com/15-metrics-for-devops-success/#post-14669-_jx3advhf4n5g

15 Metrics for DevOps Success

https://www.atlassian.com/devops/frameworks/devops-metrics

4 Key DevOps Metrics to Know | Atlassian

 

SRE : https://sre.google/sre-book/monitoring-distributed-systems/

Google - Site Reliability Engineering

https://blog.invgate.com/sre-signals

SRE Signals: 3 Types of Metrics for Site Reliability Engineering

 

DevOps vs SRE: https://codilime.com/blog/sre-vs-devops-what-is-the-difference/

SRE vs. DevOps — what’s the difference?

http://blog.creation.net/devops-vs-sre-vs-choas-engineering

DevOps vs. SRE vs. 카오스 엔지니어링 :: Channy's Blog