DEVOPS/SRE 란?

DEVOPS란?

• 개발팀과 운영팀은 공존하기가 힘들다. 왜냐하면 서로 바라보는 시각이 다르기 때문.
• 이것을 해결하는 방법은? 두개를 하나로 묶어버리면 된다. 그렇게 되면 같은 팀이기 때문에 동일한 목표를 바라보게 되어 자연스럽게 해결이 된다.
• 그런데 이것이 가능한 이유는? 원래는 기존의 인프라를 구성하는 것이 아무나 할 수 있는 것이 아니었기 때문에 전문팀을 구성해야 했고 개발팀과 운영팀이 나누어질 수 밖에 없었다. 하지만 클라우드의 등장으로 인해 인프라 구성의 진입 장벽이 현저히 낮아졌고 개발팀과 운영팀을 합치는 것이 가능해졌다
• 하지만 이것은 이론일 뿐, 현실은 다르다
• 현실에서 개발팀과 운영팀을 하나로 합쳐서 하고 있는 기업은 찾기가 힘들다
• 개발팀과 DevOps팀으로 나누어 운영을 하는 기업이 대다수이다
• 그렇다면 DevOps팀이 진짜 해야하는 일은 무엇일까?

• DevOps팀의 현실적인 업무는 다음과 같다
• 개발팀이 혼자서 개발과 운영을 할 수는 있지만 처음부터 혼자 다 하기에는 벅차기 때문에 DevOps팀을 따로 만들어서 개발 환경을 위한 플랫폼 환경을 구축하게 하는 것이다. 모니터링, CI/CD와 같은 플랫폼을 만들고 개발팀이 그 플랫폼 위에서 개발과 운영을 할 수 있도록 만들어주는 것이 DevOps팀의 역할이라고 볼 수 있다.
• 즉, 처음에는 DevOps팀 역할의 비중이 컸다가 시간이 지나면서 점점 개발팀의 역할이 커지는 것이고, 새로운 프로젝트를 시작하면 다시 DevOps팀의 역할이 커졌다가 시간이 지나면서 개발팀에게 개발과 운영이 넘어가는 구조인 것이다.
• 물론 모든 운영을 개발팀에게 전가할 수는 없다. 아주 Deep Dive한 부분은 DevOps팀에서 수행한다.
• 정리하자면 개발팀 혼자 개발과 운영을 할 수 있도록 플랫폼을 구성하고 자동화하고, 교육을 진행하는 것이 DevOps팀의 역할이다.

DevOps vs SRE (Site Reliability Engineer)

• SRE(Site Reliability Engineering)는 DevOps의 원칙을 실제로 구현한 Google 버전의 DevOps팀이라고 볼 수 있습니다
• 구글에서의 SRE 원칙
  1. Decision based on data
     : All of decision needs to be made based on data → 데이터화, 수치화가 중요
  2. Be user centric
     : Even if metrics in monitoring system are healthy, user feels that system is unstable, the system is unstable
  3. Blameless culture & Share responsibility
     : Reduce silo by sharing ownership across organization (Dev,Ops and Leadership). System failure is not just caused by operation, but also by poor code, not enough time etc. → 문제가 발생하면 사람을 탓할게 아니라 빨리 시스템의 문제점을 찾아서 고칠 생각을 해야한다
• Be user centric에서 생각해봐야할 것은 예를 들어 한 사용자로부터 웹이 느리다는 컴플레인을 접수 받고 모니터링 툴을 통해 확인을 해보니 이상이 없었다. 이럴때 어떻게 대처를 해야하는가? 유저의 의견을 기반으로 해야하기 때문에 이건 웹서버가 느린 것이 맞고 조치를 취해야 한다. 그리고 사실 우리가 모니터링 툴을 통해 보는 지표는 평균값이기 때문에 정규분포 그래프에 의하면 웹 접속이 느린 사용자가 있는 것은 당연한 것이고 그 사람은 실제로 느렸기 때문에 접수한 것이다. 그러니까 조치를 취해야 한다

SRE가 하는 업무 ≑ DevOps가 하는 업무

• Capacity Planning이란 새로운 프로젝트를 런칭할 때 들어가는 서버 갯수, DB 용량 등을 계획하는 것을 말한다. 여기에는 새로 장비를 들여오는 것도 있지만 기존의 유휴장비를 이용하는 것도 포함이다. + FinOps
• SRE팀에서는 시스템을 배포하기 전에 시스템 아키텍쳐에 대해서 컨설팅까지 들어간다. 왜냐하면 운영 경험이 많기 때문에 어떻게 하면 장애를 피할 수 있는지 알고 있기 때문. (단순히 인프라 구조만 보는 수준이 아니다)
• SRE 엔지니어는 코딩 수준도 겸해야 한다. 코드 리뷰도 하는 경우도 있음

Monitoring & alerting

• Page: 서버의 응답속도가 떨어져서 서비스가 제대로 동작을 못함 또는 서버가 먹통 상태 → critical한 상황
• Ticket: 지금 당장 처리해야할 정도의 수준은 아닌 상황, 예를 들면 시스템은 돌아가는데 로그에 warning이 엄청 찍히고 있는 상황 → 이런걸 지라와 연동하여 자동으로 티켓을 생성할 수 있음

Capacity Planning - Demand forecasting

• Plan for organic growth → 서비스를 출시하고 자연스럽게 증가
  • Increased product adoption and usage by customers.
• Determine inorganic growth → 특정 이벤트 (ex.블랙프라이데이)로 인해 발생하는 증가
  • Sudden jumps in demand due to feature launches,marketing campaigns, etc.
• 이런 것들을 미리 대비하여 Capacity Planning을 해야함
• 용량 계획하는 것이 쉬운게 아니다. 현 상황을 보면 그래픽 카드 품절 현상으로 인해 돈이 있다고 하더라도 구할 수 없는 상황이다.
• 현재 워크로드에 비해 너무 비싼 인스턴스 타입? 낭비
  너무 싼 인스턴스 타입? 장애 발생
• 물론 완벽할 수는 없다. 하지만 계속 수정해가면서 최적화를 해나가야함
• FinOps
• 기존에 있는 유휴 장비를 활용하는 것도 중요함

Change Management - 배포

• 장애의 70% 이상은 배포 과정에서 발생한다 (구글의 실제 리서치 결과에 의하면)
• 실수는 사람이 한다. 그러니까 사람이 하는 영역을 줄이자 → 자동화
• 리스크가 발생했을 때 빠르게 롤백할 수 있는 구조(롤백 자동화)를 잘 만들고 배포할 때도 배포 전략을 잘 세워야 함
• 문제가 발생했을 때 원인을 빠르게 파악할 수 있도록 모니터링 시스템을 잘 구축해 놓는 것도 중요함

Emergency Response - 장애 대응

• 장애 대응에는 MTTR (Mean Time To Repair)을 잘 신경써야 한다
• 장애의 등급에 따라 조치를 잘 해야한다 ex) P0: 전사 장애, P1: 부분 장애, P2: 서비스는 되지만 부분 장애
  P0나 P1은 고치는건 둘째치고 일단 무조건 빠르게 복구
  P2는 현재 문제상황을 보고 분석해서 고침
• 장애 대응 메뉴얼 작성하면 MTTR을 3배는 줄일 수 있다
  모든 장애는 문서화를 시키자(나중에 검색이 가능하게 ex.지라)

SLI (Service Level Indicator)

• 워크로드에 따른 SLI 예시
  1. User-facing serving system ex.모바일앱, API 서버, 웹사이트
     
     • availabilities, latency, and throughput
  2. Storage system
     
     • latency, availability, and durability
  3. Big data analytics system
     
     • throughput, end-to-end latency
  4. Machine Learning system
     
     • latency, availability, throughput, accuracy (prediction) and training time (training)
• SLI 지표를 수집할 때는 평균값만 수집하는 것이 아니라 (위에서 정규분포 예시 생각) 여러 케이스를 생각해야 함
  보통 에러는 95~99%에서 발생

Standardized Indicator

• 같은 지표라고 할지라도 수집하는 부서가 시스템 엔지니어인지 개발자인지에 따라 값이 달라질 수 있기 때문에 표준화 작업을 거쳐야 한다

• 모니터링 시스템에서 가장 중요한 것은 어떤 툴을 사용하느냐가 아니라 무엇을 어떻게 모니터링할지에 대한 정보 모델을 잘 구축하는 것이 중요하다
• SLI는 시나리오 별로 3~5개가 적당하다. 보통 3개면 충분하다

SLO (Service Level Objectives)

• 세부적인 SLO도 존재해야 한다
• 처음에는 여유있게 정하고 서비스를 운영하면서 점점 수정해가는 것이 좋다
  처음부터 빡쌔게 가면 힘들다
• 그리고 기존에 운영하던 서비스들이 있다면 해당 지표값들을 참고해도 좋다
• Industry마다 어느정도 표준화된 값들이 있으니 그런 것들을 참고하는 것도 좋음

• SLO도 3~5개 정도가 적당하다
• 그럼 How to define SLO?

• 이런 식으로 정보 모델을 만들고

• 각 User Case마다 작성해준다
• 하지만 우리는 직장인이고 회사에서는 보고가 필수이다
• 그렇다면 우리가 작성한 것을 기반으로 대표님에게 보고를 할 때 SLO가 어쩌구 레이턴시가 어쩌구... 과연 알아들으실까?

• 이런 식으로 저희 서비스는 98퍼센트 정도는 저희 기준보다 빠르게 들어오고 99퍼센트는 저희 기준에 맞게 들어오고 있습니다. 이런 식으로 대답할 수 있어야 한다 (SLO 안에 들어오면 Good, 그것보다 20% 빠르면 Fast)

Error Budget

• Error Budget = [100% - Availability Target]
  전체 시간에서 시스템 장애 시간을 뺀 것
• 예를 들어서 24시간 중에서 우리 시스템은 30분 동안은 장애가 나도 상관이 없다라고 한다면 30분이라는 Error Budget을 운영팀이 소유하게 되는 것이다. 즉, 24시간 중 30분은 서버가 내려가도 OK.
• 장애가 나면 그 시간만큼 Error Budget에서 뺀다. 예를 들어 장애가 10분 발생했으면 30-10해서 Error Budget이 20분이 된다. 장애 뿐만 아니라 배포하다가 서버가 중지되거나 장애 도상 훈련을 하거나 이런 것들을 모두 뺀다.
• 그래서 Error Budget이 0이 되었고 무중단 배포가 아니라면 배포를 진행할 수 없게 정책이 만들어져야 한다
• 또한 Error Budget이 0이 되었다면 전체 프로젝트를 신규 기능 개발 이런 쪽이 아니라 안정성에 초점을 맞추고 진행해야 한다

Toil

• 시스템 운영이나 개발과 관련된 자동화되지 않은 단순 반복 업무를 의미한다
  
  • 예를 들어 에러 핸들링, 수동 배포, 수동 코드 릴리즈 등
  • 수동 경비 처리이런건 toil이 아니다. 시스템 운영이나 개발과 관련이 있어야 한다
• CI/CD 자동화 구축하는 것도 이런 Toil을 줄이는 것이라고 볼 수 있다
• 하지만 그렇다고 Toil을 무조건 0에 가깝게 만드는 것이 좋은 것은 아니다. 한 30% 정도는 남기는 것이 좋다. 왜냐하면 예를 들어 수동으로 1년에 한번 로그를 지우는 작업이 있다고 할 때, 1년에 한번 하는 것을 위해 테라폼으로 스크립트 만들고 막하는게 리소스 낭비라는 것이다. 오히려 그냥 수동으로 하는게 더 효율적일 수 있다
  → 효율성을 생각하자

모니터링 시스템 구축

• 모니터링 시스템을 구축할 때 첫번째로 중요한 것은 전체 시스템 토폴로지를 볼 수 있게 만드는 것이 중요하다

• 데이터독이 이런 것을 잘하기 때문에 일단 데이터독을 사용해보고 대시보드 구조를 따라서 만들자
  상위 레이어에서 어떤 지표를 보면서 들어가는지 그런 구조를 파악하자

모니터링 시스템 컨셉 구조

• 일단 전체 시스템의 계층을 나누어야 한다
  
  1. 인프라
  2. (쿠버네티스)
  3. 미들웨어
  4. 애플리케이션
• 로깅과 모니터링은 다른 것이다. 모니터링은 지표만 보는 것이고, 로깅은 텍스트까지 보는 것이다
• 위 예시로 보면 3가지 계층에서 두 가지 뷰로 보니까 3x2=6의 dimension을 가지게 된다. 그리고 이 6가지의 dimension에 대해서 Visualization하고 Alerting을 다 만들어야 한다
• 전체 시스템을 보는 것을 만든 후에는 metrics를 group에 따라서 분류하면 된다. 예를 들어 프론트엔드 서버, API 서버 이런 식으로 묶는다. 프론트엔드 서버라고 해서 서버가 한대가 아니고 여러개 이기 때문에 그룹화해주어야 함

• 쿠버네티스는 label를 이용하면 좋다. 클라우드 서비스도 보통 tag를 지원하기 때문에 해당 기능을 이용하면 좋다
• 멀티 tag를 통해 여러 차원으로 나눠서 볼 수도 있다. 리전이면 리전, az면 az 이런식으로 쪼개서 여러개로 볼 수 있다
• 서버를 그룹화했으면 이제 SLI를 정하면 된다

• 그리고 그래프로 표현

• 사실 데이터독 베끼면 됨

로그 수집

• 예전에는 트러블 슈팅용으로만 로그가 사용이 되었지만 최근 들어서는 로그 라우터를 중간에 두어서 데이터 수집 파이프라인과 같은 작업에 사용되고 있다
• JSON 형식의 로그 같은 경우에는 바로 Kafka에 실시간으로 보낼 수도 있다. 

단순 로그 수집

로그 라우팅 기능 활용

https://bcho.tistory.com/1313

로그 프레임워크 #2 - 기본 로깅 및 JSON 포맷으로 로깅하기

https://bcho.tistory.com/1316?category=431297

로그시스템 #4-MDC를 이용하여 쓰레드별로 로그 분류하기

• 로그는 다 수집하는게 아니라 필터링을 걸어주는 것이 좋다. 써드파티를 사용할 경우 비용이 많이 비싼 솔루션이 로깅이기 때문에 이런 식으로 비용 절감을 해야한다
• 예를 들어 WAS 서버 로깅 시스템이 존재하는 환경에서 WAS 서버가 5개 있다고 가정해보자. WAS 서버 5개의 로그를 전부 수집해서 Elastic Search에 보내면? 비용이 감당 안될 수도 있다. 그래서 서버 두개만 Elastic Search로 보내고 나머지 3개는 Archive에 보낸다.(s3 같은) 왜냐하면 어차피 서버 두개에서 에러가 발생하면 패턴적으로 같은 에러가 다른 서버에서도 발생하기 때문이다.
• 그리고 모니터링에서만 metric을 받을 필요는 없다. 예를 들어서 쿠팡에서 결제를 하고 json 로그를 남긴다고 할 때 이것을 굳이 db에 보내서 쿼리로 가져오게 만드는게 아니라, 저 로그를 필요한 내용만 parsing해서 보내면 실시간으로 매출 상황을 지표로 만들 수 있다
• 여러 시스템들을 중앙 집중화된 로그 시스템을 구축하는 것이 중요하다. 온프렘에 있건 gcp에 있던, aws에 있던 한 시스템에서 하나의 뷰로 볼 수 있는 구조를 만드는 것이 중요하다. 그래야 운영하기 좋다.
• 모니터링 시스템을 만들 때는 한눈에 어디서 문제가 생겼는지 볼 수 있게 만드는 것이 중요하다

• 그리고 문제가 발생한 부분을 자세하게 확인할 수 있게 만들어야 함

• 그리고 문제가 생겼을 때 어느 계층에서 생긴지 확인할 수 있게 만들어야 함

• 이런걸 데이터독이 참 잘한다
• incident가 발생하면 반드시 티켓이 자동으로 생성이되게 티켓팅 시스템과 연동을 해두자 (Jira)
• 밑에는 구글 디버깅 툴 중 하나인데 현재 상용 중인 서비스를 성능 저하 없이 디버깅할 수 있다

• 모니터링 시스템을 통해 앞으로 서버가 얼마나 들어갈지 예측도 가능하다 (Capacity planning)

How can we implement SRE

https://www.youtube.com/watch?v=uTEL8Ff1Zvk&list=PLIivdWyY5sqJrKl7D2u-gmis8h9K66qoj