개요
왜 우리는 DevOps, SRE 직무에 종사하고 있을까?
기업은 바보가 아니다. 이유가 있기 때문에 현업 종사자들에게 금액을 지불하고 업무를 맡기는 것 이다.
그중 DevOps와 SRE와 같은 엔지니어들이 해야하는 필수적인 사항이 있다.
바로 안정적인 인프라, 서비스 제공이다.
나는 이 본질을 잊고 지냈다.
기술에 매몰되어 다양한 기술을 연마하는데만 집중을 했다.
앞으로 이런 시각을 기르기 위해 난 SLI, SLA, SLO와 같은 전략을 적극적으로 몸에 벨 수 있도록 더욱 노력 해보려한다.
SLI, SLA, SLO
SLA란?
SLA는 대상에게 제공하는 최소한의 지표에 대한 계약을 의미한다.
내가 외주를 맡기는 A회사라고 가정해보자.
A회사에게 B라는 회사가 "우리한테 서버 운영을 맡기면 1년 기준 99.99%의 업타임을 보장할게" 라고 계약서에 명시한다면
A회사는 B라는 회사에게 큰 신뢰를 가질 수 있다.
이는 서비스 만족도 측면에서, 그리고 서비스를 제공하는 입장에서 최소한의 방어책이자, 성과의 지표로 나타낼 수 있다.
"작년 SLA계약도 성실하게 이행한 바가 있으므로 올해 계약도 저희와 진행해주시면 좋을 것 같습니다."
또한 제공사는 SLA 범위 내라면 대응을 하지 않아도 문제 없는 하나의 방어책이 될 수도 있다.
SLO란?
SLO는 서비스 수준의 목표치를 의미한다.
예를 들어 방금 전 B회사가 명시한 바와 같이 A회사에게 B라는 회사가
"우리한테 서버 운영을 맡기면 1년 기준 99.99%의 업타임을 보장할게" 라고 계약서에 명시했을때
99.99% <- 이러한 수치가 바로 SLO가 되는 것이다.
이 SLO를 성실하게 이행하는 것이 바로 서비스 제공자가 해야하는 큰 몫이다.
SLI란?
실질적으로 서비스의 업타임와 같은 서비스 자체에 대한 지표이다.
SLO와 별개로 SLI는 실제 수치를 의미한다.
SLO가 목표, SLI는 실제 수치이다.
SLI > SLO가 성립된다면 이는 SLA계약을 위반 한 것이다.
지키기 위해서 어떤걸 해야할까?
나는 다음과 같은 사항을 생각하고 있다.
- 모니터링 체계 대폭 개선 (로그 수집 방식 고도화, Alert설정, On Call 설정, 대시보드 개편 등)
- SLO 대시보드, 알림을 만들어서 현재 SLI가 어느정도인지를 책정 할 수 있도록 한다.
- Infra레벨에서 고가용성을 보장하도록 개선 (Node, Pod 모두 고가용성을 보장해야함)
모니터링 체계 대폭 개선
모니터링 체계 대폭 개선은 필수적인 요소이다.
정확한 지표값이 있어야 정확한 모니터링이 가능하다.
지표 자체가 신뢰할 수 없는 지표라면 그를 토대로 만들어진 SLO를 어찌 신뢰할 수 있겠는가
나는 당장 내일부터 바로 이 토대가 되는 지표를 한번 고도화해볼까 한다.
- 서비스가 모니터링 되는 지표가 정확한지, 불필요한 모니터를 데이터독에 만들었는지 등등
이는 SLO, SLI 준수에 있어서 큰 영향을 미칠 것으로 보인다.
서비스 만족도에 목마른 현재 나의 갈망 때문에라도 반드시 해보고 싶다.
SLO 대시보드, 현재 SLI 책정
선행작업으로 신뢰할 수 있는 지표가 생겼다면 이를 기반으로 SLO를 산정해 대시보드화 해야한다.
인프라 다운타임 계산 방식, 서비스 다운타임 계산 방식 등을 종합적으로 고려하여야 한다.
그리고 가장 중요한 현재 SLI가 어느정도인지 수치를 책정해야한다.
나는 이 SLO를 산정하고 계산식을 만드는 것이 가장 머리 아픈 일이라고 생각한다.
99.99%의 인프라 업타임 SLO는 1년에 52분의 다운타임을 허용한다.
99.95%의 인프라 업타임 SLO는 4시간 22분의 다운타임을 허용한다.
https://docs.aws.amazon.com/ko_kr/wellarchitected/latest/reliability-pillar/availability.html
가용성 - 안정성 원칙
가용성 가용성(서비스 가용성이라고도 함)은 복원력을 정량적으로 측정하는 데 일반적으로 사용되는 지표이자 목표 복원력 목표이기도 합니다. 가용성은 워크로드를 사용할 수 있는 시간의 비
docs.aws.amazon.com
내게 있어서 이런 고민은 내가 DevOps 더 나아가 프로덕트를 언젠가 관리하고 오너쉽을 가지고서 행동하는데 있어 큰 이점이 되리라 자부한다.
Infra레벨에서 고가용성을 보장하도록 개선
고가용성은 Infra Engineer, DevOps Engineer, SRE, Cloud Engineer를 구분하지 않고 중요한 사항이다.
이는 다양한 방법으로 풀어낼 수 있지만 K8S기준 Node와 Pod단위에서 어떻게 해야 이를 잘 풀어낼 수 있을지를 꾸준히 고민하고 있다.
이는 매일매일 조금씩 나아가는 중으로 당장 하루만에 큰 결과물이 나오기란 어렵다고 생각한다.
그렇기에 오늘은 개발계 디팬던시를 줄이는 일을, 내일은 운영계 불필요한 리소스를 지우는 일을 하면서 조금씩 조금씩 변화해나가고 있다.
간혹 Best Practices를 보며 '나는 왜 이런 기술을 빨리 습득하지 못할까?'라고 자책하기도 한다.
그러나 이는 내 개인적인 채찍질이지 실제로 인프라는 매일매일 조금씩 누구도 눈치채지 못하게 견고해져가고 있다.
https://github.com/aws/aws-eks-best-practices
결론
아직은 잘 모르겠다.
SLO, SLI만으로 이 모든 인프라가 견고해지리라 확언하지 않는다.
그러나 선제대응, 후속조치시 누구보다 강한 백업 능력을 갖추기에는 명확하게 좋은 전략이라고 생각한다.
동시에 나의 기술력, 사고방식이 점점 커져나가야만 앞으로의 미래에 있어서 더 큰 비지니스 임팩트를 낼 수 있을 것이라 생각한다.
PS. 이제부터 글 제목 양식을 바꿔보려고 한다. 이번이 첫 시도다.