Last study of 2020 Year

DevOps 란 무엇인가?

DevOps 는 Application 과 Service 를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합이다. 기존의 프로세스를 적용한 조직보다 더 빠르고 혁신적으로 제품을 개선할 수 있고, 고객에게 좋은 서비스를 제공하고 시장에서 효과적인 경쟁을 할 수 있다.

• DevOps 작동 방식

DevOps 모델에서는 개발팀과 운영팀이 더 이상 “사일로” 에 묶여 있지 않게 된다. 두 팀이 단일팀으로 병합되어 엔지니어가 개발에서 테스트, 배포, 운영에 이르기까지 전체 애플리케이션 수명 주기에 걸쳐 작업하고 광범위한 기술을 개발한다.

이러한 팀에서는 DevOps 방식을 사용해 느리고 수동으로 수행되던 프로세스를 자동화한다. 또한, 안정적이고 빠르게 운영하고 개선하는 데 도움이 되는 기술과 도구를 사용한다. 이러한 이유로 엔지니어는 다른 팀의 도움 없이 작업을 독립적으로 수행할 수 있으며, 팀의 작업 속도가 빨라진다.

• DevOps 의 이점

  • 속도
  • 신속한 제공
  • 안정성
  • 확장성
  • 협업 강화
  • 보안

Reference : DevOps 란?(AWS)

SRE/DevOps 의 개념과 SRE 는 무엇을 하는가?

SRE (Site Reliability Engineering)

• DevOps 와 SRE

일반적으로 개발팀은 개발 속도에 무게를 두고, 운영팀의 경우는 시스템 안정성에 무게를 둔다. 그래서 개발팀이 무리하게 기능을 배포하면 장애로 이어지고, 이러한 장애로 인해 서로를 욕하는 상황이 만들어져 앞서 언급한 “사일로” 의 형태가 만들어진다. DevOps 는 이러한 두 팀을 한 팀에 묶어 놓고 운영하는 문화이자 일종의 운영 철학이다.

그러면 기존에 운영을 하던 사람은 무엇을 하는가? 요즘은 왠만한 부분은 개발자들이 직접 배포하고 운영도 할 수 있지만 시스템이 커질 경우 여전히 운영은 필요하다.

구글의 SRE(Site Reliability Engineering) 에서, 개발자가 셀프 서비스로 운영을 하기 위해서는 그 플랫폼이 자동화되어 있어야 한다. 애플리케이션을 빌드하고 유연하게 배포하고, 이를 모니터링하는 플랫폼이 필요한데, SRE 의 역할은 이 플랫폼을 개발하고, 플랫폼 위에서 개발자들이 스스로 배포, 운영을 하는 것이 목표이다. 완벽한 셀프 서비스는 물론 불가능하고 큰 장애 처리나 배포 등은 SRE 엔지니어가 관여하지만 많은 부분을 개발팀 스스로가 할 수 있도록 그 비중을 줄여 나간다.

class SRE implements DevOps

블로그의 주인은 위와 같이 SRE 와 DevOps 의 관계에 대해 표현한다. DevOps 가 어떠한 방향성을 제시한 것이라면, 구글의 SRE 는 이를 실제로 현실화한 사례로 볼 수 있는 것이다. SRE 는 크게 3가지 방향으로 앞서 얘기한 DevOps 가 등장하게 된 문제를 해결하고자 했다.

1. 가용성에 대한 명확한 정의
2. 가용성의 목표 정의
3. 장애 발생에 대한 계획

이러한 원칙의 의미는, 장애에 대한 책임을 모두 공유한다는 컨셉으로 볼 수 있다. 위의 3가지 원칙에 따라, 가용성 측정을 위해 어떤 지표를 사용할 것인지를 명확히 하고 그 지표에 어느 수준까지 허용할 것인지를 정해 그에 따른 의사결정을 한다.

• What does an SRE Engineer do?

SRE Engineer 가 하는 일을 크게 다섯가지로 분류하면

Metric & Monitoring

첫 번째로 모니터링을 위한 지표를 정의하고, 이를 모니터링하는 시스템을 올리는 일이다. 이러한 Metric 을 대쉬보드 형태로 시각화해 제공하고, 이 지표를 분석해서 인사이트를 찾아내는 일이다. 기본적으로 SRE 에서 가장 중요한 것은 모든 것은 데이터화하고, 의사결정은 데이터를 기반으로 이루어진다는 점이다.

Capacity Planning

두 번째는 용량 계획인데, 시스템 운영에 필요한 충분한 하드웨어 리소스를 확보하는 작업이다. 성장에 따른 일반적 증설 뿐 아니라 이벤트나 행사, 새로운 제품 출시 등과 같은 비정상적인 자원 요청에 대해서도 유연하게 대응이 가능해야 한다.

시스템의 자원이란 시스템이 필요로 하는 용량, 확보된 리소스 용량, 그리고 그 위에서 동작하는 소프트웨어의 최적화, 이 3가지에 대한 함수 관계로 볼 수 있다.

즉, 적절한 시스템 자원을 확보하는 것뿐 아니라, 소프트웨어의 튜닝 역시 중요하다는 얘기다. 그래서 SRE 엔지니어는 자원을 효율적으로 사용하는 측면에서 소프트웨어의 성능을, 안정성 측면에서 소프트웨어의 안정성을 함꼐 볼 수 있어야 한다.

Change Management

세 번째는 쉽게 말해 소프트웨어를 배포/업데이트 하는 영역으로 볼 수 있다. 시스템 장애의 원인은 대략 70% 가 시스템 변경에서 발생하는데, 그만큼 시스템의 안정성에는 변경을 관리하는 것이 중요하다. 특히 이런 에러의 원인은 대부분 사람이 관여했을 때 발생하기 때문에, 되도록이면 사람을 제외하고 자동화하는 방향으로 개선 작업이 진행된다.

따라서, 자동화의 Best Practice 는 다음과 같다. 점진적인 배포/변경을 할 것, 배포 시 장애가 발생했을 경우 빠르고 정확하게 문제를 찾아낼 것, 문제가 발생했을 때 빠르게 롤백할 수 있을 것.

자동화는 전체 프로세스 중 일부분이기에, 잠재적인 장애를 막기 위해서는 코드 관리, 버전 컨트롤, 테스트 등 전체 프로세스를 제대로 정의하는 것이 중요하다.

Emergency Response

네 번째는 장애 처리이다. 시스템 안정성이란, MTTF(Mean Time to Failure : 장애가 발생하지 않고 얼마나 오랜 시간 시스템이 정상 작동했는가?) 와 MTTR(Mean Time to Recover : 장애가 발생했을 때 복구 시간) 의 복합 함수의 개념이다.

이 중, 장애처리에 중요한 변수는 MTTR 인데, 장애 시스템의 정상화를 가급적 빠르게 해 MTTR 을 줄이는 것이 목표 중 하나이다.

복구 단계에서 사람이 직접 복구를 하게 되면 일반적으로 복구 시간이 더 많이 걸린다. 사람이 컨트롤을 하게 하되, 각 단계는 자동화되는 게 좋으며 사람이 해야 하는 일은 되도록 메뉴얼화 되어 있어야 한다. 이것을 “Playbook” 이라 하는데, 모든 엔지니어가 Super Engineer 는 아니기에, “Playbook” 기반으로 장애 처리를 할 경우 3배 이상 MTTR 이 낮다는 통계가 있다.

Culture

마지막으로 문화인데, SRE 엔지니어는 운영에 필요한 작업 뿐 아니라 SRE 문화를 전반적으로 만들고 지켜나가도록 해야 한다. 물론 혼자서 하는 일은 아니고, 전체 조직의 동의와 지원이 없다면 성공할 수 없다.

SRE 에는 Error Budget 이라는 개념이 있는데, 이 개념은 특정 시스템이 일정 시간동안 허용되는 장애 시간이다. 예를 들어 1년에 1시간 장애가 허용된다면 이 시스템의 Error Budget 은 1시간이고, 장애가 날 때마다 장애 시간만큼 그 시간을 Budget 에서 차감한다. 이후 Budget 이 0이 되면 더 이상 신규 기능을 배포하지 않고 안정성을 올리는 데 초점을 맞춘다.

그런데 만약, Budget 이 0이 되었는데 신규 기능 배포를 밀어붙인다면? 혹은 Budget 이 10시간이나 남았는데도 불구하고 10분 장애가 발생했는데, 전체 기능 개발을 멈추고 안정성을 높이라고 하면 어떻게 될까? 이러한 이유로 전체 조직이 SRE 의 원칙에 동의해야 하고 장애 발생 시에 책임을 나눠 갖도록 해야 한다.

• SRE 문화를 만들기 위한 3가지 가이드

  • 모든 의사결정은 데이터 기반으로 합리적으로 이루어져야 한다.
  • 서로 비난하지 않고, 장애 원인을 분석하고 이를 예방하는 문화
  • 책임을 나눠가지는 문화

Reference : SRE/DevOps 의 개념