운영 자동화와 최적화

DevOps 에서는 개발자가 운영자가 된다. 물론 24시간 대응하는 티어그룹이 따로 있을 수는 있지만 결국에 원인을 분석해서 이슈를 수정하는 책임은 보통 개발자가 된다. 이슈가 많아지면 개발자는 고통받는다. 심지어 개발팀이 정상적인 개발업무를 수행하기 어려워진다.

 

보통은 온콜(oncall) 프로세스를 도입하여 당번제 처럼 돌아가면서 한두명의 개발자가 들어오는 CS나 이슈를 모두 처리하도록 하여 다른 개발자들이 개발에 집중할수 있도록 한다.

 

하지만, 빈번히 발생하는 이슈를 계속해서 온콜로만 대응하다가는 개발팀의 효율이 개선되지 않는다. 그러므로 운영에 있어서 자동화와 최적화는 지속적으로 이루어져야 한다.

 

자동화의 범위

어느정도 게으른 개발자가 되라는 얘기가 있듯이, 개발자는 항상 개선을 고민해야 한다. 그게 이상적인 자동화가 아니라도 말이다.

반자동화 정도로만 해도 충분한 경우가 있다.

 

가령 사내 유저들이 특정 시스템의 권한을 요청하는 경우를 생각해보자. 이를 관리해주는 개발자는 단순히 권한을 승인해주는 작업만 할 경우 이를 어떻게 자동화할 것인가? 이상적인 경우라면 개발자가 신경쓰지 않아도 신청 > 승인 작업을 완전히 자동화하고 싶을 것이다. 하지만 최소한 개발자가 신청내용을 살펴봐야 하는 거라면 완전한 자동화는 어려울수 있다.

 

그럴 경우 자동화를 포기하기 보다는 일부라도 자동화를 생각해봐야한다. 만약 승인을 해주는 방식이 어떤 시스템에 들어가서 하나씩 해주는거라면 최소한 개발자가 "승인" 이라는 단계를 트리거하면(댓글 키워드 입력이나 상태변경 등) 이를 한꺼번에 해주는 자동화봇을 적용해볼 수 있다.

 

자동화 여부 기준

반대로 자동화까지는 불필요할 수도 있다. 정말 빈도가 낮은 CS인데 이를 완전히 자동화하는데 많은 시간이 소요된다면, 차라리 그냥 안하는게 낫다. 그렇다면 그 자동화 여부를 결정하는 기준은 어떻게 정해야할까?

 

구글 SRE에 에러버짓(Error budget)이라는 개념이 나온다. 여기서는 특정 기간동안에 특정 이슈를 처리하는데 드는 시간 혹은 비용이 에러버짓을 넘어가면, 온콜대응과 다른 개발을 중지하고 해당 이슈를 해결하는데 개발팀이 투입된다.

 

이와 마찬가지로 온콜처리 버짓을 정해서 한달 평균 특정 개수를 넘어간다던가, 온콜 처리시간 합이 특정 기준시간을 넘어간다고 하면 해당 CS 또는 이슈를 자동화하는데 개발팀을 투입한다. 예를 들어, 한달에 온콜버짓을 5시간으로 정해두고, 이를 넘어가는 특정 이슈가 있다면 이를 해결할때까지 개발업무를 중단하거나 개발시간의 일부를 할해하는 것이다.

 

운영 최적화

자동화를 해놓은 부분도 지속적으로 최적화를 해야한다.

 

내가 사는 동네에는 두 개의 큰 사거리가 있다. 각 사거리의 신호등의 변경순서는 몇년동안 동일했는데, 특정 라인에서만 초록불 신호가 매끄럽게 연결되고 다른 라인들은 매끄럽지 않았다. 가령 한쪽 사거리를 통과하더라도 다른 사거리가 바로 빨간불로 바뀌어서 금방 다시 차를 멈춰야하는 불편함이 있었다. 아이들이 통학할 때도 마찬가지였다. 두 개의 사거리가 동시에 횡단보도불이 들어왔기 때문에 아이들은 한 사거리를 건너고 다시 다른 사거리를 건너기까지 대기시간이 길었다. 두 개를 대기없이 건너려면 뛰어야 했다. 하지만 그 몇년동안 개선은 없었다. 

 

헌데, 어느날부터 신호등 변경순서가 변경되었다. 모든 라인들의 대기시간이 줄었다. 출퇴근시간에 트래픽이 감소되었으며, 아이들은 사거리를 한꺼번에 건너기 위해 더 이상 뛰지 않아도 되었다. 단순히 순서만 변경했는데 말이다. 공무원 혹은 동네 누군가가 개선을 고민하지 않았다면 동네사람들은 지속적으로 시간을 낭비했을 것이다. 

 

이처럼 자동화도 지속적으로 개선해야한다. 좀 더 편한 시스템을 활용할수 있고, 개선의 폭이 크다면 적극적으로 도입해야 한다.

 

예를 들어, VM위에 젠킨스를 이용하여 자동화를 하다가, Kubernetes 로 옮겨가면 배포, 확장 등 관리 측면에서 많은 개선을 할 수 있다. 보통 VM에 배포 관리를 하려면, VM을 생성하고 앤서블과 같은 스크립트를 돌려서 한다. 추가로 리소스가 필요하면 다시 VM을 추가하고 앤서블을 돌려야한다. 하지만 Kubernetes로 옮겨간다면 Helm이나 Kustomize으로 배포형상을 작성하고 argo cd로 배포를 자동화한다면, Kubernetes 노드를 늘려주고, Replica만 수정해 배포하면 끝이다.